הוספת נתונים מיותרים היא טכניקה שמשמשת להגנה על פרטיות המשתמשים כשמבצעים שאילתה במסד נתונים. הוא פועל על ידי הוספת רעש אקראי לסעיף SELECT של צבירה בשאילתה. הנתונים המיותרים האלה מגנים על פרטיות המשתמשים ומספקים תוצאות מדויקות למדי, כך שאין צורך בבדיקות של ההפרשים וסף הצבירה הנדרש לפלט נמוך יותר. אפשר להריץ את רוב השאילתות הקיימות במצב רעש, עם כמה מגבלות.
מהם היתרונות של שימוש בהוספת רעשים
בדיקות ההבדלים לא חלות: כשמריצים שאילתות עם הוספת רעשי רקע, מערכת Ads Data Hub לא מסננת שורות בגלל דמיון למערכי תוצאות קודמים. המשמעות היא שעדיין תוכלו לקבל תמונה כוללת של הנתונים, תוך שמירה על פרטיות המשתמשים.
פתרון בעיות פשוט יותר: השורות מושמטות רק בגלל דרישות צבירה, ולכן קל יותר לפתור בעיות ולהתאים שאילתות.
אין תחביר חדש שצריך ללמוד: לא צריך ללמוד תחביר חדש של שאילתות או להכיר מושגים שקשורים לפרטיות כדי להשתמש ברעש במקום בבדיקות של הבדלים.
דיוק התוצאות ברור: אם העבודה הצליחה, מוצג האחוז הכולל של הנתונים עם כמות הרעש הצפויה.
איך רעשים משפיעים על דרישות הפרטיות
בדיקות הבדלים: הוספת רעשי רקע לא מסתמכת על בדיקות הבדלים קיימות ב-Ads Data Hub. כשמשתמשים בהחדרת רעש, בדיקות ההבדלים מושבתות.
דרישה לצבירה: נתוני החשיפות שמתקבלים מהוספת רעשי רקע מייצגים כ-20 משתמשים ייחודיים או יותר, ונתוני הקליקים או ההמרות מייצגים כ-10 משתמשים ייחודיים או יותר.
בדיקות סטטיות: אין השפעה.
תקציבים ומגבלות על שאילתות: שאילתות שמופעלות באמצעות שיתוף רעשים משתמשות בתקציב של גישה לנתונים שמשמש לבדיקות של הבדלים. בדומה לבדיקות של הבדלים, אם מריצים את אותה שאילתה על אותו מערך נתונים הרבה פעמים, יכול להיות שתאבדו את הגישה לתאריכים שנכללים בשאילתות לעיתים קרובות במערך הנתונים. זה יכול לקרות אם מריצים שאילתות של חלון נע או אם שולחים את אותה בקשה כמה פעמים.
במצב רעש, מוטלות מגבלות נוספות ומחמירות יותר על חישוב מחדש של אותן תוצאות מצטברות בתוך שאילתות או בין שאילתות. בדומה למגבלות על תקציב הגישה לנתונים, יכול להיות שלא תהיה לכם גישה לתאריכים שמופיעים לעיתים קרובות בשאילתות במערך הנתונים. עם זאת, מגבלות שנובעות מחישוב מחדש של אותן תוצאות מצטברות יגבילו רק שאילתות במצב רעש, ולא שאילתות במצב בדיקת הבדלים. מידע נוסף זמין במאמר בנושא תוצאות חוזרות.
איך הוספת רעשי רקע משפיעה על התוצאות
מערכת Ads Data Hub מוסיפה רעשי רקע כדי לצמצם את הסיכון לחשיפת מידע – הסיכון שמישהו יוכל ללמוד מידע על משתמש ספציפי. הוא מאזן בין פרטיות לבין שימושיות.
הוספת רעשי רקע ב-Ads Data Hub משנה את תוצאות השאילתה באופן הבא:
- הוא מצמצם את התרומה של משתמשים חריגים בתוצאות המצטברות. הוא מסכם את התרומה של כל משתמש בכל צבירה, ואז מגביל כל תרומה באמצעות גבולות הידוק מינימליים ומקסימליים.
- הוא מסכם את התרומות של כל משתמש אחרי ההגבלה.
- היא מוסיפה רעש לכל תוצאה מצטברת – התוצאה של כל קריאה לפונקציית צבירה בכל שורה. הקנה מידה של הרעש האקראי הזה הוא יחסי לגבולות המהודקים.
- היא מחשבת ספירת משתמשים עם רעש לכל שורה ומסירה שורות עם מעט מדי משתמשים. זה דומה ל-k-anonymity במצב של בדיקת הבדלים, אבל בגלל הרעש, עבודות שמופעלות על אותו מערך נתונים יכולות להשמיט שורות שונות. בנוסף, במצב רעש נשמטות פחות שורות כי דרישת הצבירה נמוכה יותר (בערך 20 לעומת בדיוק 50).
התוצאה הסופית היא מערך נתונים שבו כל שורה מכילה תוצאות מצטברות עם רעשי רקע, וקבוצות קטנות נמחקו. ההסוואה הזו מסתירה את ההשפעה של משתמש ספציפי על התוצאות שמוחזרות.
מידע על צמצום צבירה
הוספת רעשי רקע ב-Ads Data Hub מתבצעת באמצעות הגבלת צבירה מרומזת או מפורשת, כדי להגביל את ההשפעה של ערכים חריגים. אתם יכולים לבחור את סוג ההגבלה שבו תרצו להשתמש, בהתאם לתרחיש השימוש.
הגבלה משתמעת
במקרים של חסימה משתמעת, הגבולות נקבעים באופן אוטומטי. לא צריך להשתמש בתחביר SQL מיוחד כדי להשתמש בהגבלה משתמעת. אם בשורה אחת יש טווח רחב יותר של ערכים מאשר בשורה אחרת, התכונה 'הגדרת גבולות משתמעת' מוצאת גבולות שונים לשורות האלה. בדרך כלל זה מוביל למרווח שגיאה נמוך יותר לכל תוצאה. מצד שני, לכל צבירה יש גבולות שונים של חסימה ורמות שונות של רעש, ולכן קשה להשוות ביניהן.
הצמצום המרומז עלול להיכשל כשמצטברים נתונים ממספר קטן מדי של משתמשים – לדוגמה, קריאה ל-COUNTIF() עם תנאי נדיר. במקרים האלה, הפונקציה מחזירה תוצאות של NULL. חשוב גם לציין ש-COUNT(DISTINCT user_id) משתמש באופן אוטומטי בהגבלת ערכים מפורשת עם גבולות של 0 ו-1.
הגבלת ערכים מפורשת
הגבלת ערכים מפורשת מגבילה את התרומה הכוללת של כל משתמש לטווח מסוים. הגבולות המפורשים חלים באופן אחיד על כל השורות וחייבים להיות ערכים מילוליים. גם אם בחלק מהשורות יש טווח רחב יותר של תרומות לכל משתמש מאשר בשורות אחרות, אותם גבולות חלים על כולן. כך אפשר להשוות בין התוצאות בשורות שונות, אבל חלק מהשורות מקבלות יותר רעשי רקע מאשר אם היה נעשה שימוש בהגבלת ערכים משתמעת.
הגבלת ערכים מפורשת משתמשת בחצי מכמות הרעש בהשוואה להגבלת ערכים מרומזת, עבור קבוצה נתונה של גבולות הגבלה. לכן, אם אתם יכולים להעריך גבולות סבירים, כדאי להגדיר אותם באופן מפורש כדי לקבל תוצאות טובות יותר.
כדי להשתמש בהגבלת ערכים מפורשת, מגדירים את הגבולות לכל פונקציית צבירה נתמכת על ידי הוספת מספרים שלמים שמייצגים את הגבול התחתון והגבול העליון. לדוגמה:
SELECT
campaign_name,
-- Set lower and upper bounds to 0 and 1, respectively
ADH.ANON_COUNT(*, contribution_bounds_per_group => (0,1))
FROM data
GROUP BY 1
הפעלת שאילתה באמצעות החדרת רעש
- פותחים דוח.
- לוחצים על המתג הגדרות "רעש" להגנה על הפרטיות כדי להעביר אותו למצב שימוש ברעש.
- מריצים את השאילתה.
- בודקים את ההשפעה של הרעש שנוסף.
- אופציונלי: מתאימים את השאילתה כדי לצמצם את ההשפעה של הרעש.
בדיקת ההשפעה של הרעש
אחרי שהעבודה מסתיימת בהצלחה, בסיכום הפרטיות מוצגת רמת המהימנות של התוצאה ב-Ads Data Hub. המהימנות מבוססת על אחוז התאים בפלט שהושפעו מאוד מרעש. ערך בטבלת התוצאות נחשב כמושפע מאוד אם קנה המידה של הרעש שנוסף גדול מ-5% מהתוצאה בתא.
במערכי נתוני הפלט שהושפעו, בסיכום הפרטיות מפורטות עשר העמודות עם הכי הרבה רעשי רקע, מההשפעה הגבוהה ביותר לנמוכה ביותר, והתרומה שלהן לרעשי הרקע. זה הפירוט של כמות הרעש הצפויה.
| תוצאות עם רעש של יותר מ-5% | צבע האינדיקטור | השפעה |
|---|---|---|
| פחות מ-5% | ירוק | השפעה נמוכה |
| 5% עד 15% | צהוב | השפעה בינונית |
| 15% עד 25% | Orange | השפעה חזקה |
| יותר מ-25% | אדום | השפעה גבוהה מאוד |
אפשר גם לראות תצוגה מקדימה של סיכום הפרטיות של משימות דיווח מהזמן האחרון בדף דף הבית. כדי לראות תצוגה מקדימה של הגדרות הפרטיות של משרה מסוימת, מעבירים את העכבר מעל סמל טיפ הפרטיות privacy_tip בכרטיס המשרה בקטע פעילות אחרונה.
התאמת שאילתות
בתוצאות מצטברות יש סיכוי גבוה יותר לכמות לא צפויה של רעש כשמספר המשתמשים שתורמים לתוצאות האלה נמוך. זה יכול לקרות אם יש מעט משתמשים בשורות או אם חלק מהמשתמשים לא משפיעים על התוצאות – למשל, כשמשתמשים בפונקציה COUNTIF. על סמך פרטי הרעש, יכול להיות שתרצו לשנות את השאילתה כדי להגדיל את אחוז הנתונים עם כמות הרעש הצפויה.
אלה הנחיות כלליות:
- מרחיבים את טווח התאריכים.
- לשכתב את השאילתה כדי לצמצם את רמת הפירוט של הנתונים, למשל על ידי קיבוץ לפי פחות פרמטרים או החלפת
COUNTIFב-COUNT. - הסרת עמודות עם רעשי רקע.
- משתמשים בהגבלת ערכים מפורשת.
פונקציות צבירה נתמכות
הפונקציות המצטברות הבאות נתמכות עם רעש:
SUM(...)COUNT(*)COUNT(...)COUNTIF(...)COUNT(DISTINCT user_id)APPROX_COUNT_DISTINCT(user_id)AVG(...)
מילת המפתח DISTINCT נתמכת רק בפונקציה COUNT, ורק כשמשתמשים בה עם הפניה ישירה לעמודה user_id מטבלה ב-Ads Data Hub או מביטוי שמחזיר user_id או NULL, כמו COUNT(DISTINCT IF(..., user_id, NULL)).
מידע על תוצאות של מספרים שלמים
מערכת Ads Data Hub תזריק רעשי רקע באופן אוטומטי לפונקציות הצבירה האלה, אבל חתימות הפונקציות לא ישתנו. מכיוון שפונקציות כמו COUNT או SUM של INT64 מחזירות INT64, כל חלק עשרוני של התוצאה עם הרעש מעוגל. בדרך כלל ההשפעה הזו זניחה ביחס לגודל התוצאה ולרעשי הרקע.
אם אתם צריכים את רמת הפירוט של המספר העשרוני בתוצאה, אל תכתבו פונקציות שמחזירות INT64. לדוגמה, אפשר להשתמש בפונקציה SUM עם קלט שמומר ל-FLOAT64.
מידע על תוצאות שליליות
באופן עקרוני, רעשי רקע עם ערכים קטנים מאוד יכולים להוביל למספרים שליליים, גם אם מבחינה סמנטית זה לא אמור לקרות בשאילתה. כדי לשמור על התנהגות צפויה, כל הצורות של COUNT ו-COUNTIF מוגבלות אוטומטית לאפס, כך שהן אף פעם לא יניבו תוצאות שליליות. אם רוצים להשתמש באותה התנהגות עם פונקציה אחרת, כמו SUM, אפשר להגביל את התוצאות באופן ידני באמצעות GREATEST(0, SUM(...)).
בדרך כלל השינוי הזה זניח, אבל הוא יוצר הטיה חיובית קלה בתוצאות הכוללות. אם אתם רוצים להימנע מכך, כדאי להשתמש ב-ADH.ANON_COUNT במקום ב-COUNT, או להשתמש ב-GROUP BY ROLLUP כדי לחשב את הסכומים הכוללים בשורות.
דפוסי שאילתות נתמכים
חשוב: רוב השיטות המומלצות הרגילות של Ads Data Hub עדיין רלוונטיות לשאילתות שמשתמשות בהוספת רעש. בפרט, מומלץ לעיין בהנחיות בנושא שאילתות חוזרות לגבי אותם נתונים.
בקטע הזה מתוארים דפוסי שאילתות שנתמכים כשמריצים שאילתות באמצעות הוספת רעש.
נתונים מצטברים ברמת המשתמש
מערכת AdMob תומכת בנתונים מצטברים ברמת המשתמש ללא הגבלות, בדיוק כמו במצב בדיקת ההבדלים. הוספת הרעש מתבצעת רק בצבירות שמשלבות נתונים של כמה משתמשים. צבירות שמקובצות באופן מפורש לפי user_id, או פונקציות אנליטיות שמחולקות לפי user_id, לא מקבלות רעש ומותרות לשימוש. צבירות ברמת המשתמש שלא מקובצות במפורש לפי user_id – לדוגמה, GROUP BY impression_id – נחשבות לצבירות חוצות משתמשים, ולכן נוסף רעש.
קיבוץ לפי external_cookie לא מספיק. אפשר להשתמש ב-external_cookie כדי לצרף טבלאות *_match לטבלאות שבבעלות הלקוח, אבל כשמבצעים צבירה של נתונים של משתמש יחיד, צריך לקבץ במפורש לפי העמודה user_id, ולא רק לפי העמודה external_cookie.
דוגמה לפונקציית צבירה:
WITH user_paths AS (
# Grouping by user_id, no noise needed, all functions allowed
SELECT user_id, STRING_AGG(campaign_id, ">" ORDER BY query_id.time_usec) AS path
FROM adh.google_ads_impressions
GROUP BY 1
)
# Noise applied here to num_users
SELECT path, COUNT(*) AS num_users
FROM user_paths
GROUP BY 1;
דוגמה לפונקציה אנליטית:
WITH events AS (
# Partitioning by user_id, no noise needed, all functions allowed
SELECT
campaign_id,
ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY query_id.time_usec) AS index
FROM adh.google_ads_impressions
)
# Noise applied here to first_impressions
SELECT campaign_id, COUNT(*) AS first_impressions
FROM events
WHERE index = 1
GROUP BY 1;
צבירות מקבילות
כל צבירה של נתונים בין משתמשים מקבלת רעשי רקע בנפרד. אפשר להריץ כמה צבירות כאלה בהצהרה אחת, ולשלב את התוצאות בטבלה אחת באמצעות JOIN או UNION.
דוגמה:
WITH result_1 AS (
# Noise applied here to num_impressions
SELECT campaign_id, COUNT(*) AS num_impressions
FROM adh.google_ads_impressions
GROUP BY 1
), result_2 AS (
# Noise applied here to num_clicks
SELECT campaign_id, COUNT(*) AS num_clicks
FROM adh.google_ads_clicks
GROUP BY 1
)
SELECT * FROM result_1 JOIN result_2 USING(campaign_id)
שימו לב שהאפשרות הזו נתמכת, אבל מומלץ להימנע ממנה במצב של בדיקת הבדלים. השיטה הזו לא גורמת לבעיות שקשורות לרעשי רקע, כי כל צבירה מקבילה עוברת סינון והוספת רעשי רקע בנפרד.
נתונים נצברים שמאוחדים עם נתונים לא נצברים
מכיוון שמערכת Ads Data Hub תומכת רק בחלונות ניתוח שמחולקים למחיצות לפי user_id, פתרון עקיף נפוץ הוא לצבור את התוצאות האלה בנפרד ולבצע self-join לפני צבירה נוספת. השאילתות האלה נתמכות במצב רעש, ולרוב הביצועים שלהן טובים יותר מאשר במצב בדיקת הבדלים, כי דרישות הפרטיות נפתרות מוקדם יותר.
דוגמה:
WITH campaign_totals AS (
# Noise applied here to campaign_imps
SELECT campaign_id, COUNT(*) AS campaign_imps
FROM adh.google_ads_impressions
GROUP BY 1
)
# Noise applied here to imps
SELECT campaign_id, demographics, campaign_imps, COUNT(*) AS imps
FROM adh.google_ads_impressions JOIN campaign_totals USING(campaign_id)
GROUP BY 1,2,3
מצב הרעש מונע צבירה מחדש של תוצאות מצטברות, כמו AVG(campaign_imps).
דפוסי שאילתות לא נתמכים
בקטע הזה מתוארים דפוסי שאילתות שלא נתמכים כשמריצים שאילתות באמצעות הוספת רעש.
שאילתות שכוללות את היום
בשאילתות במצב רעש אין תמיכה בשאילתות לגבי נתונים מהיום הנוכחי. (לא מומלץ לעשות זאת במצב בדיקת ההבדלים). אי אפשר לבחור את התאריך הנוכחי בשאילתות שמשתמשות בהוספת רעשי רקע.
תוצאות חוזרות
במצב רעש, מערכת Ads Data Hub מגבילה את התדירות שבה אפשר לחזור על אותה צבירה. אם תגיעו למגבלות האלה, השאילתות במצב רעש לא יוכלו לגשת לתאריכים במערך הנתונים שמתבצעות לגביהם שאילתות בתדירות גבוהה. הנה כמה דוגמאות לאופן שבו זה יכול לקרות.
חזרה על שאילתה מתרחשת כשמריצים את אותה שאילתה כמה פעמים עם אותם פרמטרים או עם פרמטרים דומים מאוד, כמו טווחי תאריכים חופפים. כדי להימנע מכך, אפשר להשתמש בנתונים שכבר יוצאו לפרויקט BigQuery.
שימו לב: אם שתי משימות מבצעות שאילתות על טווחי תאריכים חופפים, יכול להיות שהן יפיקו חזרות אם הן מבצעות את אותו חישוב על אותם משתמשים. לדוגמה, השאילתה הבאה, שמופעלת על טווחי תאריכים חופפים, יוצרת חזרות כי היא מחלקת לפי תאריך:
SELECT DATE(TIMESTAMP_MICROS(event.event_time)) AS date,
COUNT(*) AS cnt
FROM adh.cm_dt_clicks
GROUP BY 1
במקרה כזה, כדאי להריץ את השאילתה על פלחי תאריכים לא רציפים.
דוגמה נוספת לחזרה היא כשנתונים לא תלויים בתאריך מסוים. השאילתה הבאה יוצרת חזרות כשמריצים אותה על תאריכים חופפים, כששתי המשימות מכסות את כל משך החיים של הקמפיין:
SELECT campaign_id, COUNT(*) AS cnt
FROM adh.google_ads_impressions
GROUP BY 1
במקרה כזה, כדאי להריץ את השאילתה רק פעם אחת כי התוצאה לא משתנה.
חזרה על צבירה מתרחשת כשאותה צבירה חוזרת על עצמה כמה פעמים בשאילתה:
SELECT COUNT(*) AS cnt1, COUNT(*) AS cnt2
FROM table
במקרה כזה, צריך להסיר את אחת החזרות.
שימו לב שאפילו אם הצבירות שונות מבחינה תחבירית אבל מחשבות את אותו ערך, הן ייחשבו כחזרה. במילים אחרות, אם הערכים של condition1 ו-condition2 זהים לכל המשתמשים עם ערך מסוים של key, השאילתה הבאה תחזור על עצמה:
SELECT key, COUNTIF(condition1) AS cnt1, COUNTIF(condition2) AS cnt2
FROM table
GROUP BY key
אם יש לכם תנאים דומים מאוד לכמה קבוצות של משתמשים, כדאי לשקול לכתוב מחדש את השאילתה כך שתכלול רק COUNT אחד.
שכפול שורות מתרחש כשמצטרפים לטבלת Ads Data Hub טבלה של BigQuery באופן שבו כל שורה מטבלת Ads Data Hub תואמת לכמה שורות בטבלת BigQuery. לדוגמה, השאילתה הבאה יוצרת חזרה אם יש כמה שורות עם אותו מזהה קמפיין ב-bq_table:
SELECT r.campaign_id, COUNT(*) AS cnt
FROM adh_table
INNER JOIN bq_table ON l.campaign_id = r.campaign_id
במקרה כזה, צריך לשנות את מבנה השאילתה כך שלכל ערך של מפתח הצירוף (campaign_id במקרה הזה) יהיה רק שורה אחת ב-bq_table.
שימו לב: ביטול הקינון של מערך מטבלה ב-Ads Data Hub יכול להניב את אותה תוצאה אם לרוב המשתמשים יש את אותם מערכים של ערכים:
SELECT in_market_id, COUNT(*)
FROM adh.dv360_youtube_impressions,
UNNEST(in_market) AS in_market_id
GROUP BY 1
מידע נוסף על שיטות מומלצות לשאילתות
צבירה ישירה מחדש
הרעש מוחל על השכבה הראשונה של צבירת נתונים בין משתמשים בשאילתה. שאילתות עם כמה שכבות של צבירה ישלבו תוצאות עם רעשי רקע, ולכן יכול להיות שרעשי הרקע בצבירות הסופיות יהיו גבוהים בהרבה. השאילתות האלה מקבלות אזהרה באימות:
WITH layer_1 AS (
# Noise applied here to partial_result
SELECT campaign_id, demographics, location, COUNT(*) AS partial_result
FROM adh.google_ads_impressions
GROUP BY 1,2,3
HAVING partial_result > 5
)
# Reaggregation of partial_result with no user-level data, will be rejected
SELECT campaign_id, SUM(partial_result) AS final_result
FROM layer_1
GROUP BY 1
כדי לקבל את התוצאות הכי טובות מהרעש, צריך לחשב את כל הפעולות של משתמשים שונים במסגרת צבירה אחת. לדוגמה, אפשר להשתמש ב-SUM של אירועים במקום ב-SUM של ספירות ביניים.
אם אי אפשר להימנע מצבירה רב-שכבתית, אפשר לפתור את האזהרה על ידי ייצוא התוצאות ישירות מהשכבה הראשונה. כדי לעשות את זה במסגרת עבודה אחת בלי לשנות את תוצאות הסקריפט, יוצרים טבלה זמנית (או טבלה שמיוצאת לפרויקט BigQuery) באמצעות התחביר OPTIONS(privacy_checked_export=true). לדוגמה:
CREATE TEMP TABLE layer_1 OPTIONS(privacy_checked_export=true) AS (
# Noise applied here to partial_result
SELECT campaign_id, demographics, location, COUNT(*) AS partial_result
FROM adh.google_ads_impressions
GROUP BY 1,2,3
HAVING partial_result > 5
);
# Reaggregation of privacy checked data, no noise needed
SELECT campaign_id, SUM(partial_result) AS final_result
FROM layer_1
GROUP BY 1
אם רמת הצבירה הראשונה מפורטת מדי לצורכי בדיקות פרטיות, כדאי לשקול לכתוב מחדש את השאילתה עם צבירות ברמת המשתמש. אם זה לא אפשרי, השאילתה הזו לא נתמכת במצב רעש.
מזהי משתמשים שלא צורפו
שאילתות במצב רעש לא יכולות לשלב נתונים ממשתמשים שונים בשורה אחת, אלא אם מתבצעת צבירה עם רעש. לכן, כשמבצעים פעולות join על נתונים לא מצטברים ב-Ads Data Hub, צריך לבצע אותן באופן מפורש על העמודה user_id.
השאילתה הזו לא מצטרפת באופן מפורש לעמודה user_id, ולכן מוצגת אזהרת אימות:
SELECT …
FROM adh.google_ads_impressions
JOIN adh.google_ads_clicks USING(impression_id)
יכול להיות שצירופים כאלה לא יפעלו כמו שציפיתם, כי רק שורות עם אותו ערך user_id יתאימו. כדי לפתור את הבעיה, צריך לשנות את סעיף USING כך שיכלול במפורש את user_id – לדוגמה, USING(impression_id, user_id).
חשוב לציין שהמגבלה הזו חלה רק על שאילתות איחוד בין טבלאות ב-Ads Data Hub (למעט טבלאות מאפיינים). היא לא חלה על טבלאות בבעלות הלקוח. לדוגמה, מותר:
SELECT …
FROM adh.google_ads_impressions
JOIN bigquery_project.dataset.table USING(any_column)
צירופים חיצוניים ימניים ב-Ads Data Hub-BigQuery
צירופים חיצוניים עם נתונים בבעלות הלקוח עלולים להוביל לשורות שחסרים בהן מזהי משתמשים, ולכן לא ניתן להשתמש בהסרת רעשי רקע בצורה יעילה.
שתי השאילתות האלה מפיקות אזהרות אימות כי הן מאפשרות שורות לא תואמות עם מזהי משתמשים חסרים בצד של Ads Data Hub:
SELECT …
FROM adh.google_ads_impressions
RIGHT JOIN bigquery_project.dataset.table USING(column)
SELECT …
FROM bigquery_project.dataset.table
LEFT JOIN adh.google_ads_impressions USING(column)
שימו לב: אם סדר הטבלאות היה הפוך, כל אחת מההצטרפויות הייתה פועלת. יש גם חריג לגבי טבלאות RDID שמצטרפות ישירות ל-device_id_md5. לדוגמה, השאילתה הבאה תפעל ללא אזהרות:
SELECT …
FROM bigquery_project.dataset.table
LEFT JOIN adh.google_ads_impressions_rdid USING(device_id_md5)
סיכום השורות שסוננו
מפרט סיכום השורה המסוננת לא נתמך במצב רעש. בדרך כלל אין צורך בתכונה הזו כשמוסיפים רעש, כי שיעורי הסינון נמוכים יותר ואין סינון מבדיקות ההבדלים.
אם אתם רואים סינון משמעותי של נתונים בתוצאה של רעש, כדאי להגדיל את הנתונים המצטברים. אפשר לבצע צבירה מקבילה על מערך הנתונים המלא כדי להשוות אומדן של הסכום הכולל. לדוגמה:
SELECT campaign_name, COUNT(*)
FROM data
GROUP BY 1
UNION ALL
SELECT 'Total', COUNT(*)
FROM data
GROUP BY 1
שימו לב שהספירה הכוללת עוברת רעש באופן עצמאי, ולכן יכול להיות שהערכים הכוללים לא יסתכמו, אבל הספירה הכוללת לרוב מדויקת יותר מסיכום של שורות עם רעש.
טבלאות שנוצרו במצב מעורב
אפשר להשתמש בטבלאות שלא יוצאו ב-Ads Data Hub רק באותו מצב פרטיות שבו הן נוצרו. אי אפשר ליצור טבלה במצב צבירה רגיל ולהשתמש בה במצב רעש, או להיפך (אלא אם הטבלה הזו מיוצאת קודם ל-BigQuery).