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

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

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

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

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

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

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

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

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

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

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

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

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

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

מצבי פרטיות

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

שימוש בבדיקות הבדלים

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

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

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

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

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

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

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

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

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

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

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

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

סינון פרטיות מפורש

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

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

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

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

בדוגמה הבאה לשינוי כתובת URL, מתבצעות הפעולות הבאות:

1. הוא שולח שאילתה לכל שירות של Google בנפרד, ומחיל באופן מפורש בדיקות פרטיות על כל קבוצת תוצאות ביניים.
2. הוא יוצר טבלת זמנית נפרדת לתוצאות של כל שירות Google שנבדקו מבחינת פרטיות: YouTube,‏ Gmail והרשת.
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.