הזרקת רעש היא טכניקה שמשמשת להגנה על פרטיות המשתמשים כששולחים שאילתות למסד נתונים. הוא פועל על ידי הוספת רעש אקראי לתנאי SELECT של צבירה בשאילתה. הרעש הזה מגן על פרטיות המשתמשים ומספק תוצאות מדויקות למדי, בלי צורך בבדיקות של הבדלים ובלי להגדיל את סף הצבירה הנדרש לפלט. אפשר להריץ את רוב השאילתות הקיימות במצב רעש, עם מגבלות מסוימות.
מהם היתרונות של שימוש בהחדרת רעשים
בדיקות ההבדלים לא חלות: כשמריצים שאילתות עם הזרקת רעש, מערכת Ads Data Hub לא מסננת שורות בגלל דמיון לקבוצות תוצאות קודמות. כך תוכלו לקבל תמונה מקיפה של הנתונים תוך שמירה על פרטיות המשתמשים.
פתרון בעיות פשוט יותר: שורות מושמטות רק בגלל דרישות צבירת נתונים, כך שקל יותר לפתור בעיות ולהתאים שאילתות.
אין צורך ללמוד תחביר חדש: כדי להשתמש ברעש במקום בבדיקות ההבדלים, לא צריך ללמוד תחביר חדש של שאילתות או להכיר את מושגי הפרטיות.
הדיוק של התוצאות ברור: כשהמשימה מסתיימת בהצלחה, מוצג האחוז הכולל של הנתונים עם כמות הרעש הצפויה.
איך רעש משפיע על דרישות הפרטיות
בדיקות הבדלים: הוספת הרעש לא מסתמכת על בדיקות הבדלים קיימות ב-Ads Data Hub. כשמשתמשים בהחדרת רעש, בדיקות ההבדלים מושבתות.
דרישה לצבירה: הזרקת הרעש יוצרת נתוני חשיפות שמייצגים כ-20 משתמשים ייחודיים או יותר, ונתוני קליקים או המרות שמייצגים כ-10 משתמשים ייחודיים או יותר.
בדיקות סטטיות: אין השפעה.
תקציבים ומגבלות על שאילתות: שאילתות שמבוצעות באמצעות רעש משתתפות בתקציב הגישה לנתונים שמשמש לבדיקות ההבדלים. בדומה לבדיקות ההבדלים, אם מריצים את אותה שאילתה על אותו מערך נתונים פעמים רבות, יכול להיות שתאבדו את הגישה לתאריכים שבהם מתבצעות שאילתות לעיתים קרובות במערך הנתונים. מצב כזה יכול לקרות אם מריצים שאילתות בחלון זז, או אם שולחים את אותה בקשה כמה פעמים.
מצב הרעש מטיל מגבלות נוספות וקפדניות יותר על חישוב מחדש של אותן תוצאות מצטברות בתוך שאילתות או בין שאילתות. בדומה לתקציב הגישה לנתונים, יכול להיות שתאבדו את הגישה לתאריכים שבהם מתבצעות לעיתים קרובות שאילתות במערך הנתונים. עם זאת, המגבלות שנובעות מחישובים מחדש של אותן תוצאות מצטברות יגבילו רק שאילתות במצב רעש, ולא שאילתות במצב בדיקת ההבדלים. מידע נוסף זמין במאמר תוצאות חוזרות.
איך הוספת רעש משפיעה על התוצאות
מערכת Ads Data Hub מחדירה רעשי רקע כדי לצמצם את הסיכון לחשיפת מידע – הסיכון שמישהו יוכל לקבל מידע על משתמש מסוים. הוא מאזן בין הפרטיות לבין התועלת.
הוספת רעש ב-Ads Data Hub גורמת לשינוי בתוצאות השאילתות באופן הבא:
- הוא מצמצם את התרומות של משתמשים חריגים בתוצאות המצטברות. המערכת מסכמת את התרומה של כל משתמש בכל צבירת נתונים, ולאחר מכן מגבילה כל תרומה באמצעות גבולות מינימום וחסימת מקסימום.
- הוא מצטבר את התרומות המצטברות לכל משתמש.
- הוא מוסיף רעש לכל תוצאה מצטברת – התוצאה של כל קריאה לפונקציית צבירת נתונים בכל שורה. עוצמת הרעש האקראי הזה פרופורציונלית למגבלות הלחיצה.
- המערכת מחשבת את מספר המשתמשים עם רעשי רקע בכל שורה ומחסלת שורות עם מעט מדי משתמשים. המצב הזה דומה לאנונימיות k במצב של בדיקת ההבדלים, אבל בגלל הרעש, משימות שפועלות באותו מערך נתונים יכולות להוציא שורות שונות. בנוסף, במצב רעש נמחקות פחות שורות כי דרישת הסיכום נמוכה יותר (כ-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% מהתוצאה בתא.
לגבי קבוצות נתוני פלט שהושפעו, סיכום הפרטיות מציג את 10 העמודות עם רמת הרעש הגבוהה ביותר, מההשפעה הגבוהה ביותר לנמוכה ביותר, ואת התרומה שלהן לרעש. זוהי פירוט של כמות הרעש הצפויה.
| תוצאות עם רעש של יותר מ-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)).
הפונקציות הבאות לא נתמכות באופן ישיר, אבל אפשר להחליף אותן בצבירה אחרת עם רעש כדי לקבל תוצאות סטטיסטיות. הערכים המספריים הם דוגמאות בלבד:
LOGICAL_OR(...). הצעת החלפה:COUNT(DISTINCT IF(..., user_id, NULL)) > 0LOGICAL_AND(...). הצעת החלפה:COUNT(DISTINCT IF(NOT ..., user_id, NULL)) <= 0
מידע על תוצאות שלמים
מערכת Ads Data Hub תוסיף באופן אוטומטי רעש לפונקציות הצבירה האלה, אבל חתימות הפונקציות לא ישתנו. מכיוון שפונקציות כמו COUNT או SUM של INT64 מחזירות את הערך INT64, כל חלק עשרוני של התוצאה עם הרעש מעוגל. בדרך כלל, הערך הזה זניח ביחס לגודל התוצאה ולרעש.
אם אתם צריכים את רמת הפירוט של הספרות העשרוניות בתוצאה, כדאי להימנע מכתיבת פונקציות שמחזירות את הערך INT64 – לדוגמה, באמצעות SUM עם הטמעת הקלט שלו ל-FLOAT64.
דפוסי שאילתות נתמכים
חשוב: רוב השיטות המומלצות הסטנדרטיות של Ads Data Hub עדיין רלוונטיות לשאילתות שמשתמשות בהחדרת רעש. באופן ספציפי, מומלץ לעיין בהנחיות בנושא שליחת שאילתות חוזרות על אותם נתונים.
בקטע הזה מתוארים דפוסי שאילתות שנתמכים כשמריצים שאילתות באמצעות הזרקת רעש.
נתונים מצטברים ברמת המשתמש
יש תמיכה בצבירה ללא הגבלה ברמת המשתמש, באותו אופן שבו יש תמיכה בה בבדיקה של ההבדלים. המערכת מחדירה רעש רק בצבירה של נתונים ממספר משתמשים. צבירות שמקבצות לפי 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, פתרון נפוץ הוא לצבור את התוצאות האלה בנפרד ולבצע איחוד עצמי לפני שמבצעים צבירת נתונים שוב. השאילתות האלה נתמכות במצב רעש, ולרוב הביצועים שלהן טובים יותר מאשר במצב בדיקת ההבדלים, כי דרישות הפרטיות נפתרות בשלב מוקדם יותר.
דוגמה:
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
במקרה כזה, צריך לשנות את המבנה של השאילתה כך שב-bq_table תהיה רק שורה אחת לכל ערך של מפתח המיזוג (campaign_id, במקרה הזה).
חשוב לזכור שביטול עריכה של מערך מטבלת 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
אם שכבת הצבירה הראשונה מפורטת מדי לצורך בדיקות פרטיות, כדאי לנסות לכתוב מחדש את השאילתה עם צבירות ברמת המשתמש. אם אי אפשר לעשות זאת, סימן שהשאילתה הזו לא נתמכת במצב רעש.
מזהי משתמשים שלא הצטרפו
אסור לשלב שאילתות במצב רעש עם נתונים ממשתמשים נפרדים בשורה אחת, אלא אם מבצעים צבירת נתונים עם רעש. כתוצאה מכך, כדי לבצע צירופים של נתונים מ-Ads Data Hub שלא עברו צבירת נתונים, צריך לבצע צירוף מפורש בעמודה user_id.
בשאילתה הזו לא מתבצעת צירוף מפורש של העמודה user_id, וכתוצאה מכך מתקבלת שגיאת אימות:
SELECT …
FROM adh.google_ads_impressions
JOIN adh.google_ads_clicks USING(impression_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
כדי לבצע צבירת נתונים עם רעש, צריך שמזהי המשתמשים יניבו ביצועים טובים. לנתונים שבבעלות הלקוח ב-BigQuery אין מזהי משתמשים, ולכן אי אפשר לאחד אותם עם צבירת רעשי רקע בלי לצרף אותם לטבלה של Ads Data Hub.
השאילתה הזו מניבה שגיאת אימות:
SELECT COUNT(*) FROM (
SELECT 1 FROM adh.google_ads_impressions
UNION ALL
SELECT 1 FROM bigquery_project.dataset.table
)
כדי לפתור את הבעיה, צריך לצרף את הטבלה ב-BigQuery כדי להוסיף נתונים של Ads Data Hub במקום לבצע איחוד, או להפריד את הנתונים כדי לצבור כל מקור בנפרד.
חשוב לזכור שאפשר ליצור איחוד בין כמה טבלאות של Ads Data Hub עם נתוני משתמשים, או בין כמה טבלאות BigQuery בבעלות הלקוח, אבל אי אפשר לשלב בין השניים.
צירופי ימין בין 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)
שימו לב שכל אחת מההצטרפות תפעל אם הסדר של הטבלאות יוחלף.
סיכום של שורות מסוננות
אין תמיכה במפרט הסיכום של השורות המסוננות במצב רעש. ברוב המקרים אין צורך בתכונה הזו עם רעש, בגלל שיעורי סינון נמוכים יותר והיעדר סינון מבדיקות ההבדלים.
אם אתם רואים סינון נתונים משמעותי בתוצאה של רעש, כדאי להגדיל את הנתונים המצטברים. אפשר לבצע צבירת נתונים במקביל על מערך הנתונים המלא כדי להשוות אומדן של הסכום הכולל, לדוגמה:
SELECT campaign_name, COUNT(*)
FROM data
GROUP BY 1
UNION ALL
SELECT 'Total', COUNT(*)
FROM data
GROUP BY 1
חשוב לזכור שהמספר הכולל מושפע מרעש באופן עצמאי, וייתכן שהערכים הכוללים לא יתווספו זה לזה, אבל בדרך כלל המספר הכולל מדויק יותר מאשר הסכום של השורות עם הרעש.
טבלאות שנוצרו במצבים שונים
אפשר להשתמש בטבלאות שלא יוצאו ב-Ads Data Hub רק באותו מצב פרטיות שבו הן נוצרו. אי אפשר ליצור טבלה במצב צבירה רגיל ולהשתמש בה במצב רעש, או להפך (אלא אם הטבלה מיוצאת קודם ל-BigQuery).