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

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

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

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

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

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

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

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

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

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

סינון תוכן בוטה

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

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

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