בדיקות פרטיות ב-Ads Data Hub

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

לפניכם סקירה כללית של תכונות הפרטיות ב-Ads Data Hub, עם פירוט נוסף בקטעים הבאים:

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

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

בדיקות סטטיות

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

תקציב לגישה לנתונים

תקציב הגישה לנתונים מגביל את המספר הכולל של הפעמים שתוכלו לגשת לנתון נתון. משתמשים שמתקרבים לסוף התקציב שלהם יקבלו הודעה בנושא פרטיות מסוג DATA_ACCESS_BUDGET_IS_NEARLY_EXHAUSTED. אפשר לעקוב אחרי התקציב באמצעות נקודת הכניסה data access budget או באמצעות התראות התקציב בממשק המשתמש.

דרישות לצבירת נתונים

סף צבירת המשתמשים הוא הבסיס לבדיקות הפרטיות של Ads Data Hub. ברוב השאילתות, אפשר לקבל נתוני דיווח רק לגבי 50 משתמשים או יותר. עם זאת, אפשר להשתמש בשאילתות שמקבלות גישה רק לקליקים ולהמרות כדי לדווח על 10 משתמשים או יותר.

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

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

בדוגמה הבאה, השורה שמכילה את הקמפיין 125 תסונן מהתוצאות הסופיות, כי היא אוספת תוצאות מ-48 משתמשים, פחות ממספר המשתמשים המינימלי של 50.

מזהה קמפיין משתמשים חשיפות
123 314 928
124 2718 5772
125 48 353

מצבי פרטיות

ב-Ads Data Hub יש שני מצבי פרטיות – בדיקות הבדלים והחדרת רעש. בקטעים הבאים מתוארים המצבים האלה ומתבצעת השוואה ביניהם.

שימוש בבדיקות דיפרנציאליות

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

  • הם משווים בין התוצאות של המשימה שפועלת לבין התוצאות הקודמות.
  • הן משווים בין שורות באותה קבוצת תוצאות.

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

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

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

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

משימה 1
מזהה קמפיין משתמשים
123 400
124 569
משרה 2
מזהה קמפיין משתמשים
123 401
224 1325

אם הסכום של המשתמשים בכל השורות בקבוצת תוצאות דומה לזה של משימה קודמת, מערכת Ads Data Hub תסנן את כל קבוצת התוצאות. בדוגמה הזו, כל התוצאות מהמשימה השנייה יסוננו.

משימה 1
מזהה קמפיין משתמשים
123 400
124 1367
משרה 2
מזהה קמפיין משתמשים
123 402
124 1367

שימוש בהחדרת רעש

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

השוואה בין בדיקות ההבדלים להחדרת רעש

נתונים בפועל
מזהה קמפיין מספר החשיפות
101 35
102 63
201 142
202 21
301 56
302 99
תוצאות באמצעות בדיקות הבדלים
מזהה קמפיין מספר החשיפות
101 35
102 63
201 142
202 21
301 56
302 99
תוצאות באמצעות החדרת רעש
מזהה קמפיין מספר החשיפות
101 37.8373
102 60.9104
201 182.0955
202 26.2332
301 58.0871
302 97.5018
דוגמה לקמפיין 101 במצב רעש
מזהה קמפיין חשיפות בפועל נוספו רעשים חשיפות שהוחזרו (ANON_COUNT)
101 35 2.8373 37.8373

סיכום השורות שסוננו

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

סינון פרטיות בוטה

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

תרחישים לדוגמה:

  • אתם מפרסמים שמחפשים את כל ההמרות לפי סוג אירוע השיוך בחשבון Google Ads המקושר שלכם, שכולל נתונים מ-EEA.
  • אתם שותפי מדידה שמחפשים את כל ההמרות לפי סוג אירוע השיוך בחשבון Google Ads המקושר שלכם.

כדי לקבל את הסכום של ההמרות בחשבון Google Ads, אפשר לכתוב מחדש את השאילתה באמצעות תנאי OPTIONS(privacy_checked_export=TRUE) כדי להחיל בדיקות פרטיות על כל שירות של Google בנפרד.

בדוגמאות שמוצגות בקטע הזה נעשה שימוש ב-rewrite כדי:

  1. המערכת שולחת שאילתות לכל שירות של Google בנפרד, ומפעילה בדיקות פרטיות באופן מפורש על כל קבוצת תוצאות ביניים.
  2. המערכת יוצרת טבלת זמנית נפרדת לתוצאות של בדיקת הפרטיות בכל שירות של Google: YouTube,‏ Gmail ו-Network.
  3. הפונקציה אוספת ומסכמת את מספרי ההמרות שעברו בדיקה לאימות הפרטיות מהטבלאות הזמניות.
CREATE TEMP TABLE youtube_agg OPTIONS(privacy_checked_export=TRUE) AS
SELECT
 impression_data.campaign_id,
 attribution_event_type,
 COUNT(1) AS num_convs
FROM adh.google_ads_conversions_policy_isolated_youtube
WHERE impression_data.campaign_id IN UNNEST(@campaign_ids)
 AND conversion_type IN UNNEST(@conversion_type_list)
GROUP BY campaign_id, attribution_event_type;

CREATE TEMP TABLE network_agg OPTIONS(privacy_checked_export=TRUE) AS
SELECT
 impression_data.campaign_id,
 attribution_event_type,
 COUNT(1) AS num_convs
FROM adh.google_ads_conversions_policy_isolated_network
WHERE impression_data.campaign_id IN UNNEST(@campaign_ids)
 AND conversion_type IN UNNEST(@conversion_type_list)
GROUP BY campaign_id, attribution_event_type;

CREATE TEMP TABLE gmail_agg OPTIONS(privacy_checked_export=TRUE) AS
SELECT
 impression_data.campaign_id,
 attribution_event_type,
 COUNT(1) AS num_convs
FROM adh.google_ads_conversions_policy_isolated_gmail
WHERE impression_data.campaign_id IN UNNEST(@campaign_ids)
 AND conversion_type IN UNNEST(@conversion_type_list)
GROUP BY campaign_id, attribution_event_type;

SELECT
 campaign_id,
 attribution_event_type,
 SUM(num_convs) AS num_convs
FROM (
 SELECT * FROM youtube_agg
 UNION ALL
 SELECT * FROM network_agg
 UNION ALL
 SELECT * FROM gmail_agg
)
GROUP BY campaign_id, attribution_event_type

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

כלי ייעוץ לשאילתות

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

הטריגרים כוללים את הדפוסים הבאים:

כדי להשתמש ביועץ השאילתות:

  • ממשק משתמש. ההמלצות יוצגו בעורך השאילתות, מעל טקסט השאילתה.
  • API משתמשים בשיטה customers.analysisQueries.validate.

  1. מלבד נתונים שהם הביעו הסכמה לשתף, כמו במקרה של פאנליסטים. ↩

  2. אלא אם יש הגבלות פרטיות, למשל אם המשתמשים בסיכום של שורות מסוננות לא עומדים בדרישות הסיכום. ↩