דף זה תורגם על ידי Cloud Translation API.

הזרקת רעש

החדרת רעש היא שיטה שמשמשת להגנה על פרטיות המשתמשים כששולחים שאילתות למסד נתונים. היא פועלת על ידי הוספת "רעש אקראי" לסעיף 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

הרצת שאילתה באמצעות החדרת רעש

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

בדיקת ההשפעה של הרעש

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

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

נתונים עם כמות הרעש הצפויה	צבע החיווי	השפעה
מעל 95%	ירוק	השפעה נמוכה
85%-95%	צהוב	השפעה בינונית
75%-85%	Orange	השפעה חזקה
פחות מ-75%	אדום	השפעה חזקה מאוד

כדי לראות מידע מפורט על ההשפעה של הרעש, צריך:

לוחצים על Reports.
בוחרים דוח מהרשימה. בהסבר הקצר של סיכום הפרטיות מוצג אחוז התוצאות עם כמות הרעש הצפויה, שתואמת לכמות הרעש שנוסף שגדולה מ-5% מהתוצאה.
כדי לראות מידע נוסף, לוחצים על משרות > פרטים.
מעיינים בהודעות הפרטיות בפרטי המשימה. התוצאות משתייכות לאחת מהקטגוריות המפורטות.
אם צריך, משנים את השאילתה כדי לשפר את התוצאה.

התאמת שאילתות

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

הערה: אפשר להשתמש בכל אחד מהאיחודים (join) אם סדר הטבלאות הפוך.

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

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

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

SELECT campaign_name, COUNT(*)
FROM data
GROUP BY 1
UNION ALL
SELECT 'Total', COUNT(*)
FROM data
GROUP BY 1

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

טבלאות שנוצרו במצבים שונים

אפשר להשתמש בטבלאות שלא יוצאו ב-Ads Data Hub רק עם אותו מצב פרטיות שבו הן נוצרו. אי אפשר ליצור טבלה במצב צבירה רגיל ולהשתמש בה במצב רעש או להיפך (אלא אם הטבלה מיוצאת קודם ל-BigQuery).