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

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

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

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

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

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

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

"לטשטש" את הנתונים

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

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

דוגמה

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

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

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

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

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

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

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

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

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

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

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

מה מותר לעשות

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

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

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

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

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

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

קוד 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.

סיבה

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