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

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

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

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

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

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

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

'Fuzz' הנתונים שלך

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

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

דוגמה

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

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

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

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

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

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

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

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

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

חשוב להכיר בחשיבות של ביטולי הסכמה קלים וברירת מחדל: "כדי לבנות אמון והכרה, חברות יכולות תחילה בהסכמה לחוזה חברתי שבו הם מתחייבים לכבד את הקהל שלהם בכל אחת מנקודת המגע עם הלקוח, מקשיבים לצרכים שלהם ומגיבים בהתאם", אומרת IAPP. לפי קבוצת Nielsen Norman: המשתמשים "צריכים לסמן בבירור 'יציאת חירום' כדי לצאת מהפעולה הלא רצויה בלי שתצטרכו לעבור תהליך ארוך'. כולם מודעים לכך קל יותר להירשם מאשר לבטל את ההרשמה. אבל, כפי שאמר נילסן נורמן, הוא מאפשר למשתמשים להתרחק מבלי שיצטרכו לקפוץ דרך חישוקים, "מייצר תחושה של חופש וביטחון". מחקרים אקדמיים מחזקים את העניין הזה וקוראים לו "העיקרון ביטול", "הממשק צריך לאפשר למשתמש לבטל בקלות רשויות שהמשתמש העניק בכל מקום היא אפשרית. צריך לאפשר למשתמשים לבטל הסכמה כזו, וכך לצמצם את הגישה של הרשויות למשאבים שלהם אם אפשר." (ראו דוגמאות ב-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 לא אמורה להיות נשלח בדף היציאה עצמו, אבל במשאב אחר הדף נטען. הסיבה לכך היא שבמחשב איטי יותר עם מטמון גדול, הדף ייחסם בזמן שהוא מנקה את המטמון וכך מונע ניווט. פעולה זו עשויה להימשך דקות ספורות, מה שעלול לתסכל את המשתמש. לא סביר שזה יקרה, אבל קשה לבדוק את זה, ולכן מומלץ לזכור זאת.

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

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

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

דוגמה ל-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.

סיבה

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