השתמשו רק בנתונים שצריכים

דרך טובה לצמצם את הסיכון למשתמשים היא לא לאחסן נתונים רגישים לגבי המשתמשים שאתם לא צריכים, ושהשפעה על הפרטיות שלהם. יש מספר מפתיע של דרכים לעשות זאת תוך עמידה ביעדים העסקיים שלכם, וחשוב לבחון כל אחת מהן. תוכלו:

• להסביר למה אתם צריכים את הנתונים.
• איסוף נתונים ברמת פירוט נמוכה יותר.
• צריך להסיר את הנתונים כשמשתמשים בהם.
• לא לאסוף אותם מלכתחילה.

כל אחת מהגישות האלה יכולה לעזור למשתמשים להרגיש יותר בנוח לגבי מה שאתם עושים והסיבה לכך, וזה תורמת במידה רבה ליחסים ביניכם. שקיפות מובילה לאמון, וחשוב לזכור שאמון יכול להיות נקודת מכירה ייחודית. הרבה אנשים מניחים שהמשתמשים והלקוחות סומכים עליהם כברירת מחדל, אבל צרכנים בודקים כל הזמן מוצרים ושירותים, ויכול להיות שהם לא סומכים עליכם. אם תיצרו קשר עם המשתמשים שלכם שבו הם יבטחו בכם לטפל בנתונים שלהם ולנהל את האינטראקציות שלכם בצורה מכבדת, תוכלו ליהנות מיתרון תחרותי כפרויקט או כעסק: זהו מאפיין ייחודי שאולי המתחרים שלכם לא יוכלו להתחרות בו.

נבחן את הגישות שלמעלה לפי הסדר של היעילות הגבוהה ביותר (אבל גם ההשפעה הגדולה ביותר על העסק) ועד ליעילות הנמוכה ביותר, אבל ההטמעה הכי פחות מפריעה.

אין לאסוף אותם מלכתחילה

הדרך הברורה ביותר למנוע סיכון לנתוני המשתמשים היא לא לאסוף אותם. איסוף נתונים מסוים הכרחי כדי לספק שירותים, אבל יש יותר מקומות שבהם תוכלו להימנע מאיסוף נתונים ממה שציפיתם. לדוגמה, ביצוע תשלום כאורח. כשמשתמשים מגיעים כדי לרכוש משהו באמצעות אפליקציית האינטרנט שלכם, יכול להיות שתצטרכו להירשם לחשבון, כי תיעדתם פרטים אישיים למילוי הזמנות במועד מאוחר יותר: אפשר להוסיף אותם לרשימת התפוצה, הם כבר אושרו מראש כלקוחות מעוניינים, וכו'. עם זאת, הלקוחות מזהים את הבעיה הזו ולא אוהבים אותה: ב-2021, מחקר מצא שכל 4 עסקאות שהלקוחות נטשו נגרמו בגלל שהאתר דרש מהמשתמשים ליצור חשבון. אם אין לכם צורך בחשבון, יש סיכוי גבוה יותר לשמר את הלקוחות האלה. כשמאפשרים להשלים רכישה בלי להירשם למשתמשים יהיו אפשרויות טובות יותר, וגם לא נותר לך חלק גדול מהנתונים שלהם להגן ולאבטח אותם.

'ערפול' של הנתונים

כמובן, יכול להיות שלא תהיה לכם אפשרות להימנע מאיסוף נתונים בכלל. חשוב לאסוף נתונים כדי לספק שירותים ולוודא ומקבלים החלטות עסקיות מושכלות. ניתן גם להיעזר בבניית תקשורת שיווקית בהקשר של יחסי אמון. עם זאת, חשוב גם להבין שההחלטות שאנחנו מקבלים באופן מצטבר (כלומר, החלטות שמשפיעות על הרבה משתמשים בו-זמנית) מתקבלות לגבי נתונים באופן מצטבר (כלומר, לגבי המאפיינים הקולקטיביים של הנתונים).

לדוגמה, לפעמים רצוי להבין את הדמוגרפיה של הקהל שלכם: לאילו טווחי גילים הוא משתייך, המיקום וכו'. כתוצאה מכך, יכול להיות שתצטרכו לשנות את המסר או את הגישה שלכם. עם זאת, זה לא אומר שאתם צריכים לאסוף את הגיל המדויק של כל משתמש בשירות שלכם. בדרך כלל אתם מחפשים מגמות ומאפיינים כלליים. אם ההחלטה שאתם רוצים לקבל מושפעת מכך שרוב הקהל שלכם נמצא ב'קבוצה הדמוגרפית העיקרית של 18-34', השאלה היחידה שאתם צריכים לשאול היא אם המשתמשים שלכם נמצאים בקבוצה הדמוגרפית הזו. כך הם נאספים בשני 'קטגוריות': בקבוצה הזו ולא בקבוצה הזו. ייתכנו מצבים שבהם תצטרכו נתונים מפורטים יותר, אבל סביר מאוד להניח שתרצו לעיין ברשימת המאפיינים הדמוגרפיים שבהם אתם משתמשים כדי לקבל החלטות, ולבקש מהמשתמשים לסווג את עצמם באמצעות הרשימה הזו.

דוגמה

לכן, אם אתם רוצים לדעת איך מתחלקת בסיס המשתמשים שלכם בין קטגוריות הגיל '18-34', '35-49', '49-64' ו'65 ומעלה', תוכלו לבקש מהמשתמשים לבחור לאיזו קטגוריה הם שייכים. מפתה לבקש תיאור מפורט במיוחד, מידע אישי ומותאמים אישית, ולאחר מכן לסווג את המשתמשים בעצמך, כי כך לא תצטרך לשאול שוב את אותה שאלה פרטים נוספים בהמשך; לדוגמה, כדי לבקש גיל ותאריך לידה מדויקים, ולאחר מכן להשתמש בנתון הזה כדי ליצור רשימות משלכם הרבה משתמשים נמצאים בפילוח "35-49" בקטגוריה שלכם. אבל חשוב להבין איך זה נראה, מכיוון שהקורס כבר למדנו נעסוק שוב, אם תבקשו רמות מפורטות של נתונים, זה עלול לגרום לאנשים להרגיש אי-נוחות, וכתוצאה מכך להפחית את אמון המשתמשים בארגון שלכם, ובמקביל מוסיפה סיכון.

חשוב גם לקחת בחשבון את צורכי הנתונים שלכם. לפעמים ה'צורך' בנתונים מפורטים יותר הוא ספקולטיבי, דרישה 'למקרה הצורך'. יכול להיות שכרגע אנחנו צריכים לסווג את המשתמשים רק לארבע קבוצות הגיל האלה, אבל בעתיד יכול להיות שנרצה לצמצם את הקבוצות האלה, ולכן כדאי לאסוף נתונים מפורטים מאוד עכשיו כדי להשאיר את האפשרות הזו פתוחה לעתיד. כדאי לבדוק באיזו תדירות השתמשתם בעבר בנתונים המפורטים יותר כדי לקבל החלטות. מבקשים נתונים תפיסה כפולשנית ביחס לשירות שמוצע בהכרח יוביל לירידה במידת האמון שהמשתמשים שלך סומכים עליהם של הארגון. אם הנתונים האלה נאספים למקרה הצורך, יכול להיות שאתם לא רק מוותרים על אמון המשתמשים לטובת החלטות עסקיות טובות יותר, אלא גם מוותרים עליו רק לטובת האפשרות של החלטה עתידית תיאורטית שאולי אפילו לא תהיה, תוך התחייבות לדרישות אבטחה לגבי המידע הזה.

יש גם דרכים אלגוריתמיות מפורטות יותר לצמצום רמת הפירוט של הנתונים שנאספים. שיטות תגובה אקראיות פירוש הדבר שהנתונים נאספים במידה ניתנת לכוונון של אי-דיוקים, ושנעשה בהם שימוש במשך עשרות שנים מדעיים בעת איסוף מידע שעשוי להיות פולשני או רגיש תוך שמירה על סודיות המשיב. השיטה שלמעלה לאיסוף נתונים כוללת הרחבת תשובות המשתמש (כלומר, "מה גילך", "לאיזו אחת מקבוצות הגיל הבאות אתם משתייכים"), כאשר התשובה האקראית כוללת יחס מסוים מהמשתמשים שקריים לגבי התשובות שלהם. אם שיעור המשתמשים שמגיבים באופן שגוי ידוע, יש מסקנות משמעותיות עדיין יכולים להילקח מהנתונים שנאספו, אבל הפרטיות של כל משתמש נתון לא נפגעת מפני שהנתונים שנאספו עלולים יהיה שגוי. במקרה הזה, אם 80% מהקהל עדיין מצהיר שהם שייכים לדמוגרפיה של בני 18-34, תוכלו יחסית להיות בטוחים שזה עדיין החלק הגדול ביותר, גם אם 10% מהם נותנים תשובות שגויות בכוונה. אפשר גם לשנות את מידת השגיאה באופן פרוגרמטי, כך שתמיד מתבקשות תשובות נכונות, אבל התוכנה משנה אחוז מסוים מהתשובות לפני שהן מועברות. התהליך הזה וההשלכות שלו עלולים גם יוסבר למשתמשים כאשר הנתונים נאספים: כלומר, המשתמשים לא חייבים לסמוך על כך שלא תנצלו לרעה את שנאספו, כי נתונים ספציפיים לא מהימנים.

תהליך דומה, אבל מורכב יותר מבחינה טכנית, הוא פרטיות דיפרנציאלית. פעולה זו משתמשת בטכניקות מתמטיות כדי לשנות את אחסון הנתונים כך שהמאפיינים הנצברים של הנתונים עדיין יהיו קיימים, אי אפשר אפילו לזהות אם אדם מסוים בכלל סיפק נתונים, או איזה נתונים הוא סיפק. כמו תגובה אקראית, גם האפשרות הזו מגינה על נתוני המשתמשים גם מפניכם, ומראה את הכוונה הברורה שלכם: אי אפשר להשתמש בנתוני המשתמשים אם אין לכם את הנתונים האלה.

הגישה הזו גישות דומות מספקות גם אבטחה מוגברת מפני פרצות וסיכוני זליגת מידע, כי הנתונים שנאספים מפחיתים את הפגיעה בפרטיות המשתמשים, גם שלכם, וגם את רמת הפגיעה אם הנתונים יזלגו. עם זאת, חשוב לזכור שאם אתם מחילים שיטות לשמירה על פרטיות דיפרנציאלית בשרת (כך שהמשתמשים שלכם ישלחו אתכם לא נצברים, ולאחר מכן משתמשים בטכניקות כדי לצבור אותם), עדיין צריך לאבטח את נתוני המשתמשים הגולמיים ואז למחוק אותו אחרי העיבוד, וצריך להיות לו מדיניות ברורה ולפעול לפיו כדי לוודא שאתם לא משתמשים בו לפני כן או צבירת נתונים (או שברור לך למה אתה משתמש בהם).

שמירה: איסוף נתונים והסרה שלהם לאחר השימוש בהם

חשוב לזכור שלנתונים שנאספים יש מחזור חיים: הם נאספים, משמשים לקבלת החלטות עסקיות, ואז בשלב מסוים צריך להסיר אותם. שוב, מדובר בפשרות: כשאתם שואלים את המשתמשים שאלות, או שומרים מידע על אתרים אחרים שבהם הם ביקרו, או עוקבים אחרי הדברים שהם צפו בהם ובמשך כמה זמן כדי לחזות את ההעדפות שלהם, אלה הנתונים שמוענקים לכם למטרה ספציפית – ולא כמתנה ללא הגבלה שהמפתח יכול להשתמש בה כרצונו. כשאין יותר צורך בנתונים האלה למטרה הזו – לפעמים אחרי דקה, לפעמים אחרי שנים רבות – צריך למחוק אותם.

בכל פעם שאתם אוספים מידע על המשתמשים שלכם, חשוב שתדעו למה אתם משתמשים בנתונים האלה (ראו בהמשך), וגם מתי ולמה תפסיקו לאחסן אותם. זה יכול להיות כשהמשתמש בוחר למחוק את התוכן, או חותם עליו. לא, אחרי פרק זמן מסוים או אחרי שאירוע מסוים מתרחש. דרך מצוינת לבנות אמון בקשר היא להסביר למשתמשים בצורה ברורה איך הם יכולים לשלוט בנתונים שלהם, כולל, במידת האפשר, ביטול הסכמה חד-צדדי. איך הם מוחקים את הנתונים שלהם? איך הם מוחקים את החשבון שלהם? בנוסף ליצירת הקשר הזה, מומלץ לאחסן נתונים רק למשך הזמן הנדרש לעיבוד שלהם, ולא יותר. בנוסף, צריכה להיות למשתמשים אפשרות לראות ולהסיר נתונים שאתם אוספים מהם או בשמם. יכול להיות שיש אפילו חקיקה בנושא הזה באזורים שבהם אתם פועלים.

זהו תחום שבו אפשר להגדיר יעדים טכניים ברורים, וכך לעזור למשתמשים בשירות עצמי. אם המשתמשים יכולים לבטל את הסכמתם במחסן הנתונים (data warehouse) בלי לבקש הרשאה, אז הם יוכלו להרגיש הרבה יותר בנוח עם ההצטרפות, ולא להשתמש בכל משאב תמיכה כדי לעשות זאת.

חשוב להכיר בחשיבות של ביטולי הסכמה קלים וברירת מחדל: "כדי לבנות אמון והכרה, חברות יכולות תחילה בהסכמה לחוזה חברתי שבו הם מתחייבים לכבד את הקהל שלהם בכל אחת מנקודת המגע עם הלקוח, מקשיבים לצרכים שלהם ומגיבים בהתאם", אומרת IAPP. לפי Nielsen Norman Group, למשתמשים "צריך להיות 'יציאת חירום' מסומנת בבירור כדי לצאת מהפעולה הלא רצויה בלי לעבור תהליך ארוך". כולם מודעים לכך קל יותר להירשם מאשר לבטל את ההרשמה. אבל, כפי שאמר נילסן נורמן, הוא מאפשר למשתמשים להתרחק מבלי שיצטרכו לקפוץ דרך חישוקים, "מייצר תחושה של חופש וביטחון". מחקרים אקדמיים מחזקים את העניין הזה וקוראים לו "העיקרון ביטול", "הממשק צריך לאפשר למשתמש לבטל בקלות רשויות שהמשתמש העניק בכל מקום היא אפשרית. המשתמשים צריכים להיות מסוגלים לבטל את ההסכמה הזו, וכך לצמצם את הרשאות הגישה למשאבים שלהם, אם אפשר". (דוגמאות מופיעות ב-Yee וב-Iacono).

משך הזמן שבו שומרים נתונים והנתונים ששומרים משתנים מאוד בין ארגונים ובין פרויקטים, אבל יש כמה הנחיות נפוצות שכדאי להביא בחשבון.

מה מותר לעשות

מומלץ לאפשר למשתמשים למחוק חשבונות (וכל נתון משויך, אם אפשר לעשות זאת) ולמחוק באופן קבוע (למשל, ביציאה) נתונים זמניים ונתונים שמאוחסנים באופן מקומי באמצעות הכותרת Clear-Site-Data.

לספק כותרת Clear-Site-Data כדי להסיר חלק מנתוני המשתמש או את כולם שאוחסנו בצד הלקוח (באמצעות קובצי cookie, LocalStorage או IndexedDB, או במטמון הדפדפן, כאשר הדבר סביר. התרחיש לדוגמה הברור של 'ניקוי נתוני אתר' הוא כאשר משתמש מתנתק, אבל ניתן להשתמש בו גם לאחר תקריות אבטחה כדי לוודא שאין עקבות או מעקב מתמשכים בחשבון שעלול להיות בסיכון. של נתונים שנפרצו במכשיר הלקוח.

הוספת תמיכה ל-Clear-Site-Data כרוכה בשליחת כותרת HTTP, Clear-Site-Data, כשהמשתמש יוצא מהחשבון (או בחשבון אחר פעמים שבהן ברצונך לנקות את האחסון בצד הלקוח), בדף שמאשר את סטטוס ההתנתקות (https://your-site/logout) או דומה). הכותרת הזו יכולה לכלול חלק מהערכים הבאים או את כולם, או "*" לכולם:

Clear-Site-Data: "cache", "cookies", "storage"

הערכים האלה מנקים, בהתאמה, דפים שנשמרו במטמון (ומשאבים אחרים במטמון HTTP), קובצי Cookie מאוחסנים, LocalStorage ו-IndexedDB וכדומה. יכול להיות שתראו הפניה לאפשרות אחרת, executionContexts, אבל האפשרות הזו לא נתמכת בדפדפנים רבים. הערה: סביר להניח שיהיה קל יותר להשתמש בכותרת Clear-Site-Data מאשר למחוק בעצמכם בנפרד את כל המשאבים שנוצרו, כי לא צריך להריץ קוד JavaScript בלקוח (והיא הדרך הרשמית היחידה לנקות את המטמון של הדפדפן), אבל לא כל הדפדפנים תומכים בה.

הערה לגבי השימוש: אם אתם מנקים את המטמון (על ידי שליחת Clear-Site-Data: cache), אסור לשלוח את הכותרת Clear-Site-Data בדף היציאה בפועל, אלא במשאב אחר כלשהו שהדף טוען. הסיבה לכך היא שבמחשב איטי יותר עם מטמון גדול, הדף ייחסם בזמן ניקוי המטמון, וכתוצאה מכך לא תהיה אפשרות לנווט. פעולה זו עשויה להימשך דקות ספורות, מה שעלול לתסכל את המשתמש. לא סביר שזה יקרה, אבל קשה לבדוק את זה, ולכן מומלץ לזכור זאת.

להסביר למה אתם צריכים את הנתונים

כבר אמרנו כמה פעמים כמה חשוב שהמשתמשים יאמינו בשירות שלכם, כי האמון הזה מגדיל את משך הזמן שהמשתמשים משתמשים בשירות. היא גם מספקת יתרון תחרותי. אחת הדרכים להגביר את רמת האמון הזו היא באמצעות שקיפות לגבי התהליכים שלכם. שקיפות היא דרך טובה להסביר במה אתם רוצים לקבל נתונים. למדתם קודם לכן שלכל דבר שנאסף אתם צריכים לדעת כשהדבר הזה יימחק. כדי לדעת זאת, עליכם לדעת למה אתם רוצים את הנתונים האלה, ובאילו שאלות ספציפיות הם נדרשים כדי למצוא תשובות, ואילו החלטות יתקבלו על ידי איסוף התשובות. אחרי שתדעו למה אתם צריכים את הנתונים האלה שביקשת מהמשתמשים למסור, כדאי להסביר להם את זה כדי לבסס אמון. במדיניות הפרטיות שלכם או כשאתם שואלים שאלות בחשבון יצירתן, תארו למה אתם צריכים תשובה לשאלה המסוימת הזו, מה תעשו עם הנתונים האלה, מתי ואיך אפשר להסיר אותם.

ההסברים האלה הרבה יותר גלויים כשהם מוצגים במקום. הטמעת ההסברים במסמך מדיניות צפוף במקום אחר באתר עשויה להיראות כניסיון להסתיר אותם. בטופס הרשמה, בטופס תשלום או בטופס בקשה אפשר לציין את הסיבות לאיסוף הנתונים לצד האיסוף עצמו. לרוב, שדה בטופס מסומן בכוכבית (*) כדי לציין שצריך למלא אותו. בטופס מורכב בדרך כלל מופיע קישור למידע (i) שמסביר מה המשמעות של השדה. כדאי להוסיף להסברים האלה תיאור של הסיבה לאיסוף הנתונים. משפט נפוץ לכך הוא 'למה אנחנו צריכים את זה?' לצד שדה טופס, וכשלוחצים עליו מוצג הסבר בחלון קופץ.

דוגמה לקוד HTML עשויה להיראות כך, ואז CSS ו-JavaScript ידאגו להסתרת ה-<aside> ולהצגתו כחלון קופץ כשלוחצים על הקישור. (חשוב לוודא שאפשר לגשת לטופס שאתם יוצרים עבור האתר!) האופן שבו תציגו את המידע הזה תלוי בסגנון ובגישה שלכם, אבל הנקודה העיקרית היא לשייך ישירות את איסוף הנתונים להסבר על הסיבה לאיסוף הנתונים. לא צריך לעשות זאת בכל שדה. אף אחד לא צריך הסבר למה אתם דורשים ממנו לבחור סיסמה במהלך ההרשמה. עם זאת, כדאי להוסיף לכל בקשה למידע אישי ולפרטים ליצירת קשר הסבר על האופן שבו אתם מתכוונים להשתמש במידע ולשמור אותו, כדי להבהיר למשתמשים שאתם משקיעים מאמצים כדי להגן על הנתונים שלהם.

<div>
    <label for="email">Email address*</label>
    <input id="email" type="email" name="email" required aria-describedby="whyemail">
    <a href="#whyemail">Why do we need this?</a>
    <aside id="whyemail">We need this information as a unique identifier for you, and if you forget your password we can send you a reminder. We will use your email address to send you regular updates on the service if you choose, and will delete your email address from any mailing lists if you delete your account.</aside>
</div>

ביצוע התהליך הזה עם כל המידע שאתם אוספים על משתמש יכול גם לעזור בתהליכים ובדיונים פנימיים. מוקדם יותר ראיתם איך יכול להיות מפתה לאסוף נתונים "ליתר ביטחון". כשאתם שקופים לגבי הסיבות שאתם אוספים את המידע, יכול להיות שזה יהיה די ברור. אם אתם נמנעים לכתוב את מה שאתם רוצים, לנתוני משתמשים, מכיוון שההסבר לא ימצא חן בעיניהם. זה יכול להיות סימן לכך שכדאי לחשוב מחדש על איסוף הנתונים את זה. ההסבר הלא נעים יכול להיות גם פולשני מדי ('אנחנו נשתמש בזה כדי לעקוב אחרי המקומות שבהם אתם מבקרים על בסיס שעתי'), נרחב מדי ('אנחנו עדיין לא יודעים למה נשתמש בזה, אבל אנחנו רוצים אותו למקרה שנחשוב על משהו') או עקיף מדי ('אנחנו נשתמש בזה למטרות פנימיות שלא נחשוף'). זו לא רק שאלה של מוסר. אנשים מספיק חכמים כדי לזהות זאת, כפי שכבר תיארנו, והמשתמשים מצפים שניסוי במשהו לא יהיה תחילתו של מחויבות לטווח ארוך. עיצוב חוויית המשתמש כולל בדרך כלל הרשמה קלה ופשוטה ככל האפשר, כי בשלבים המוקדמים המשתמש (לפי הגדרה) לא משקיע הרבה בשירות, ולכן חשוב לאפשר לו להשקיע יותר בקלות כשעדיין אין לו נטייה לעשות זאת. אם קל לעזוב שוב, הניסוי בשירות הופך לניסוי אמיתי ולא להתחלה לא רצונית של התחייבות לטווח ארוך. כמו קודם, זה נשמע פרדוקסלי אבל זה נכון: הדרך הטובה ביותר לבנות אמון היא לא לדרוש מהמשתמשים לבטוח בכם אם הם לא רוצים.

לאנשים יש סיבות טובות לא לשתף נתונים, או לשתף נתונים מינימליים. בתחילת הקשר ביניכם, גם אם אין להם סיבה לסמוך עליכם וגם לא צריכה להיות להם. המטרה שלכם היא להראות למה כדאי להם לעשות את זה.

מה מותר לעשות

• עליכם להחליט למה אתם רוצים לאסוף את כל הנתונים שאתם מתכננים לאסוף, ולכמה זמן אתם רוצים לשמור אותם.
• כשמבקשים את הנתונים האלה, צריך להסביר למשתמשים למה אתם אוספים אותם.
• למחוק אותו ממסדי הנתונים של השרת אחרי שמשתמשים בו.
• בעזרת הכותרת Clear-Site-Data, אפשר לאפשר למשתמשים למחוק חשבונות שהם יצרו ולנקות נתונים שנשמרו באחסון שלהם.

סיבה

בניית מערכת יחסים עם המשתמשים היא עניין של אמון, ואמון מבוסס על פתיחות. אם תוכלו להוכיח שאתם לא רק אוספים כמה שיותר נתונים על המשתמשים שלכם ומסתירים את השימושים שלכם בהם, תוכלו לבנות אמון, וזה יכול להיות יתרון תחרותי מול מתחרים פחות נקיים.