הפרטיות של משתמשי הקצה עומדת בבסיס כל הפעילות של Ads Data Hub, והיא הבסיס שעליו מבוססת הפלטפורמה שלנו. כדי לשמור על הפרטיות ולעזור ללקוחות שלנו לפעול בהתאם לתקנות, אנחנו מחילים בדיקות והגבלות מסוימות שנועדו למנוע העברה של נתונים לגבי משתמשים ספציפיים1 בנתונים שהם מפיקים מהפלטפורמה.
זוהי סקירה כללית של תכונות הפרטיות של Ads Data Hub, עם פרטים נוספים בסעיפים הבאים:
- בדיקות סטטיות בודקות את ההצהרות בשאילתות כדי לאתר בעיות ברורות ומיידיות בנוגע לפרטיות.
- תקציבי גישה לנתונים מגבילים את מספר הפעמים הכולל שאפשר לגשת לנתונים מסוימים.
- בדיקות צבירה מבטיחות שכל שורה מכילה מספר גדול מספיק של משתמשים כדי להגן על הפרטיות של משתמשי הקצה.
- בדיקות הבדלים (או 'בדיקות הבדלים') משווה בין קבוצות של תוצאות כדי למנוע מכם לאסוף מידע על משתמשים ספציפיים על ידי השוואת נתונים מכמה קבוצות של משתמשים.
- החדרת רעש היא חלופה לבדיקות הבדלים.
הוספת רעש אקראי לסעיף
SELECTמצטבר בשאילתה מגנה על פרטיות המשתמשים תוך מתן תוצאות מדויקות במידה סבירה, ביטול הצורך בבדיקות הבדלים ומפחית את סף הצבירה הדרוש לפלט.
כשתוצאה לא עוברת את הבדיקות לאימות הפרטיות, ב-Ads Data Hub תוצג או תחזיר הודעה לגבי פרטיות על כך ששורה מסוננת. זה יכול להיות כל דבר, משורה אחת ועד קבוצת תוצאות שלמה. כדי להבטיח שסכומי הדיווח הכוללים יהיו מדויקים, כדאי להשתמש בסיכום שורות מסונן כדי לספור נתונים מהשורות שהוסרו2.
בדיקות סטטיות
בדיקות סטטיות בודקות את ההצהרות בשאילתות כדי לזהות חששות ברורים ומיידיים בנוגע לפרטיות, כמו ייצוא של מזהי משתמשים, כל פונקציה של מזהי המשתמשים או שימוש בפונקציות אסורות בשדות שמכילים נתונים ברמת המשתמש. כדי להימנע משגיאות בשאילתות מבדיקות סטטיות, כדאי לעיין בשיטות המומלצות ולהבין באילו פונקציות מותר להשתמש.
תקציב גישה לנתונים
תקציב הגישה לנתונים מגביל את מספר הפעמים הכולל שניתן לגשת
לחלק מהנתונים. משתמשים שמתקרבים לסוף התקציב יקבלו התראה עם הודעה בנושא פרטיות מסוג DATA_ACCESS_BUDGET_IS_NEARLY_EXHAUSTED. אפשר לעקוב אחרי התקציב דרך נקודת הכניסה לתקציב גישה לנתונים, או על ידי הצגת התראות לגבי תקציב בממשק המשתמש.
דרישות צבירה
הבסיס לבדיקות הפרטיות ב-Ads Data Hub הוא הסף לצבירת משתמשים. ברוב השאילתות אפשר לקבל נתוני דיווח רק לגבי 50 משתמשים או יותר. עם זאת, אפשר להשתמש בשאילתות עם גישה רק לקליקים ולהמרות כדי לדווח על 10 משתמשים או יותר.
- אירועים עם מזהי משתמשים אפס נספרים כמשתמש יחיד במסגרת הסף לצבירת נתונים, ללא קשר למספר המשתמשים שיצרו את האירועים בפועל.
- משתמשים עם מזהי null לא נכללים בסף הצבירה.
- איך מצב הרעש משפיע על דרישות הצבירה
השיטה המומלצת: להגדיר סיכום שורות מסוננות כדי לדווח על נתונים שהושמטו. כך אפשר לשמור על בסיס עקבי בדוחות.
בדוגמה הבאה, השורה שמכילה את קמפיין 125 תסונן מהתוצאות הסופיות כי היא צוברת תוצאות מ-48 משתמשים, פחות מהמינימום ל-50 משתמשים.
| מזהה הקמפיין | משתמשים | חשיפות |
|---|---|---|
| 123 | 314 | 928 |
| 124 | 2718 | 5772 |
| 125 | 16 | 353 |
מצבי פרטיות
ב-Ads Data Hub יש שני מצבי פרטיות – בדיקות דיפרנציאליות והחדרת רעש. בקטעים הבאים מתוארים המצבים האלה ומשווים ביניהם.
שימוש בבדיקות הבדלים
בדיקות הבדלים עוזרות להבטיח שלא ניתן יהיה לזהות משתמשים באמצעות השוואה של כמה תוצאות מצטברות מספיק, בדרכים הבאות:
- הם משווים בין התוצאות בעבודה שהרצתם לבין התוצאות הקודמות.
- הם משווים שורות בתוך אותה קבוצת תוצאות.
הפרות של בדיקת הבדלים יכולות לנבוע משינויים בנתונים בסיסיים בין שתי משימות. כשמשווים בין תוצאות של משימה לתוצאות קודמות, מערכת Ads Data Hub מחפשת נקודות חולשה ברמת משתמשים ספציפיים. לכן אפשר לסנן גם תוצאות מקמפיינים שונים או תוצאות שמדווחות על אותו מספר משתמשים, אם יש להן מספר גדול של משתמשים חופפים.
מצד שני, לשתי קבוצות של תוצאות מצטברות עשוי להיות אותו מספר משתמשים – הן נראות זהות, אבל הן לא משתפות משתמשים ספציפיים. כלומר, הן לא יסוננו.
ב-Ads Data Hub מחושבים נקודות החולשה של תוצאה חדשה על סמך נתונים מהתוצאות ההיסטוריות. כלומר, כשמריצים את אותה שאילתה שוב ושוב, נוצרים יותר נתונים לבדיקות הבדלים שבהם אפשר להשתמש כשמביאים בחשבון את נקודות החולשה של תוצאה חדשה. בנוסף, הנתונים הבסיסיים עשויים להשתנות, וכך ייווצרו הפרות של בדיקת הפרטיות בשאילתות שנחשבות ליציבות.
כשהתוצאות ברמת המשימה שונות במידה מספקת, אבל שורה מסוימת דומה לשורה במשימה קודמת, Ads Data Hub יסנן את השורה הדומה. בדוגמה הזו, השורה שמכילה את קמפיין 123 בתוצאות של המשימה השנייה תסונן כי היא שונה מהתוצאה הקודמת לפי משתמש יחיד.
|
|
||||||||||||||||
אם סכום המשתמשים בכל השורות בקבוצת תוצאות דומה לזה של משימה קודמת, Ads Data Hub יסנן את קבוצת התוצאות כולה. בדוגמה הזו יסוננו כל התוצאות מהמשימה השנייה.
|
|
||||||||||||||||
שימוש בהחדרת רעש
החדרת רעש היא שיטה שמשמשת להגנה על פרטיות המשתמשים כששולחים שאילתות למסד נתונים. היא פועלת על ידי הוספת "רעש אקראי" לסעיף SELECT שצובר בשאילתה. הרעש הזה מגן על פרטיות המשתמשים ומספק תוצאות מדויקות במידה סבירה, ולא צריך לבדוק הבדלים ומפחית את סף הצבירה הדרוש לפלט. את רוב השאילתות הקיימות ניתן להריץ במצב רעש, עם מגבלות מסוימות. למידע נוסף על מצב רעש ועל האופן שבו החדרת רעש משפיעה על דרישות הפרטיות, קראו את המאמר החדרת רעש.
השוואה בין בדיקות הבדלים להחדרת רעש
|
|
||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||
סיכום השורות שסוננו
בסיכומי שורות שסוננו המערכת מחשבת את הנתונים שסוננו בגלל בדיקות לאימות הפרטיות. הנתונים משורות מסוננות מסוכמים ומתווספים לשורה כוללת. אמנם לא ניתן לנתח את הנתונים המסוננים בצורה מפורטת יותר, אך הוא מספק סיכום של כמות הנתונים שסוננו מהתוצאות.
יועץ שאילתות
אם ה-SQL תקין אבל עלול לגרום לסינון יתר, יועץ השאילתות יציג עצות לביצוע פעולות במהלך פיתוח השאילתה, כדי למנוע תוצאות לא רצויות.
הטריגרים כוללים את הדפוסים הבאים:
- הצטרפות לשאילתות משנה מצטברות
- איחוד נתונים לא נצברים עם משתמשים שעשויים להיות שונים
- טבלאות זמניות שמוגדרות באופן רקורסיבי
כדי להשתמש ביועץ השאילתות:
- ממשק משתמש. ההמלצות יופיעו בעורך השאילתות, מעל לטקסט של השאילתה.
- API. צריך להשתמש בשיטה
customers.analysisQueries.validate.
-
מלבד נתונים שהם הסכימו לשתף, למשל במקרה של חברי פאנל.↩
-
אלא אם קיימות הגבלות על פרטיות, למשל כשהמשתמשים בסיכום השורה המסוננת לא עומדים בדרישות צבירת הנתונים.↩