این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

تزریق نویز

تزریق نویز تکنیکی است که برای محافظت از حریم خصوصی کاربر هنگام جستجو در پایگاه داده استفاده می شود. با اضافه کردن نویز تصادفی به یک عبارت SELECT جمع آوری یک پرس و جو کار می کند. این نویز از حریم خصوصی کاربر محافظت می کند و در عین حال نتایج نسبتاً دقیقی را ارائه می دهد، نیاز به بررسی تفاوت را از بین می برد و آستانه تجمع مورد نیاز برای خروجی را کاهش می دهد. اکثر پرس و جوهای موجود را می توان در حالت نویز، با برخی محدودیت ها ، اجرا کرد.

با مزایای استفاده از تزریق نویز آشنا شوید

بررسی‌های تفاوت اعمال نمی‌شوند: هنگام اجرای عبارت‌های جستجو با تزریق نویز، Ads Data Hub ردیف‌ها را به دلیل شباهت به مجموعه‌های نتایج قبلی فیلتر نمی‌کند. این بدان معنی است که شما همچنان می توانید در عین محافظت از حریم خصوصی کاربر، دیدی جامع از داده ها داشته باشید.

عیب یابی ساده شده است: ردیف ها فقط به دلیل الزامات تجمع حذف می شوند و عیب یابی و تطبیق پرس و جوها را ساده تر می کند.

هیچ نحو جدیدی برای یادگیری وجود ندارد: برای استفاده از نویز به جای بررسی تفاوت، نیازی به یادگیری سینتکس پرس و جو جدید یا آشنایی با مفاهیم حریم خصوصی ندارید.

دقت نتیجه واضح است: یک کار موفق، درصد کل داده ها را با مقدار نویز مورد انتظار نشان می دهد.

بیاموزید که نویز چگونه بر الزامات حریم خصوصی تأثیر می گذارد

بررسی تفاوت: تزریق نویز به بررسی‌های تفاوت موجود در Ads Data Hub متکی نیست. هنگامی که از تزریق نویز استفاده می کنید، بررسی تفاوت غیرفعال می شود.

الزامات تجمیع: تزریق نویز داده‌های برداشتی را که توسط تقریباً 20 کاربر منحصر به فرد یا بیشتر ارائه می‌شود، و داده‌های کلیک یا تبدیل که توسط تقریباً 10 یا بیشتر کاربر منحصربه‌فرد ارائه می‌شوند، خروجی می‌دهد.

چک های استاتیک: بدون تاثیر.

بودجه ها و محدودیت های پرس و جو: پرس و جوهایی که با استفاده از نویز اجرا می شوند، بودجه دسترسی به داده های مورد استفاده با بررسی های تفاوت را به اشتراک می گذارند. همانند بررسی‌های تفاوت، اگر یک پرس و جو را بارها بر روی یک مجموعه داده مشابه اجرا کنید، ممکن است دسترسی به تاریخ‌های مکرر در مجموعه داده را از دست بدهید. این ممکن است در صورتی اتفاق بیفتد که پرس و جوهای پنجره کشویی را اجرا کنید، یا اگر یک درخواست را چندین بار انجام دهید.

حالت نویز محدودیت‌های اضافی و سخت‌گیرانه‌تری را برای محاسبه مجدد نتایج مجموع یکسان در داخل یا در میان پرس‌و‌جوها اعمال می‌کند. مانند بودجه دسترسی به داده، می توانید دسترسی به تاریخ های مکرر در مجموعه داده را از دست بدهید. اما محدودیت‌های ناشی از محاسبه مجدد نتایج مجموع یکسان، درخواست‌ها را فقط در حالت نویز محدود می‌کند، نه درخواست‌ها در حالت بررسی تفاوت. برای اطلاعات بیشتر، به نتایج تکراری مراجعه کنید.

درباره بررسی حریم خصوصی بیشتر بیاموزید .

درک اینکه چگونه تزریق نویز بر نتایج تأثیر می گذارد

Ads Data Hub برای کاهش خطر افشای نویز تزریق می کند - خطری که فرد بتواند اطلاعاتی درباره یک کاربر خاص یاد بگیرد. حریم خصوصی را در مقابل سودمندی متعادل می کند.

تزریق نویز در Ads Data Hub نتایج پرس و جو را به صورت زیر تبدیل می کند:

این کمک‌های کاربران پرت را در نتایج جمع‌آوری می‌کند. سهم هر کاربر را در هر تجمع جمع‌آوری می‌کند و سپس هر سهم را با حداقل و حداکثر محدودیت‌های گیره درپوش می‌دهد.
این مشارکت‌های clamped برای هر کاربر را جمع‌آوری می‌کند.
به هر نتیجه انبوه نویز اضافه می کند - نتیجه هر فراخوانی تابع تجمع در هر ردیف. مقیاس این نویز تصادفی متناسب با مرزهای بسته شده است.
تعداد کاربران پر سر و صدا را برای هر ردیف محاسبه می کند و ردیف هایی را که تعداد کاربران بسیار کمی دارند حذف می کند. این شبیه به k-anonymity در حالت بررسی تفاوت است، اما به دلیل نویز، کارهایی که روی یک مجموعه داده اجرا می‌شوند می‌توانند ردیف‌های مختلفی را رها کنند. همچنین، حالت نویز ردیف‌های کمتری را کاهش می‌دهد زیرا نیاز تجمع کمتر است (تقریباً 20 در مقابل 50).

نتیجه نهایی یک مجموعه داده است که در آن هر ردیف نتایج کل نویز دارد و گروه های کوچک حذف شده اند. این امر تأثیر یک کاربر را بر نتایج برگشتی پنهان می کند.

در مورد گیره تجمع

تزریق نویز در Ads Data Hub از گیره تجمع ضمنی یا صریح برای محدود کردن سهم پرت استفاده می‌کند. بسته به مورد استفاده خود می توانید نوع گیره را انتخاب کنید.

بستن ضمنی

در بستن ضمنی، کران ها به طور خودکار تعیین می شوند. برای استفاده از clamping ضمنی نیازی به دستور 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 enter details برای یک کار جدید کلیک کنید.
روی گزینه تنظیمات حریم خصوصی کلیک کنید تا موقعیت استفاده از نویز را انتخاب کنید.
پرس و جو را اجرا کنید .
نویز اضافه شده را مرور کنید .
اختیاری: پرس و جو را برای کاهش تاثیر نویز تطبیق دهید .

بررسی تاثیر نویز

هنگامی که یک پرس و جو با موفقیت کامل شد، Ads Data Hub قابلیت اطمینان نتیجه را بر اساس تعداد سلول های خروجی دارای میزان نویز مورد انتظار نشان می دهد. اگر مقیاس نویز اضافه شده بیشتر از 5 درصد نتیجه در سلول باشد، یک مقدار در جدول نتیجه بسیار تأثیرگذار در نظر گرفته می شود. محدوده تاثیر را در جدول زیر مشاهده کنید.

برای مجموعه داده‌های خروجی تأثیرگذار، تب جزئیات 10 ستون پر سر و صدا را از بیشترین تا کمترین تأثیر و سهم مربوط به نویز را فهرست می‌کند. این تجزیه مقدار مورد انتظار نویز است.

داده ها با مقدار نویز مورد انتظار	رنگ نشانگر	تأثیر
>95%	سبز	تاثیر کم
85%-95%	رنگ زرد	تاثیر متوسط
75٪ - 85٪	نارنجی	تاثیر بالا
<75%	قرمز	تاثیر بسیار بالا

برای مشاهده اطلاعات دقیق در مورد تاثیر نویز:

روی گزارش ها کلیک کنید.
گزارشی را از لیست انتخاب کنید. راهنمای ابزار خلاصه حریم خصوصی، درصد نتایجی را نشان می‌دهد که میزان نویز مورد انتظار را دارند، مربوط به مقدار نویز اضافه شده که بیشتر از 5٪ نتیجه است.
برای مشاهده اطلاعات بیشتر، روی Jobs > Details کلیک کنید
پیام های حریم خصوصی را در جزئیات کار مشاهده کنید. نتایج در یکی از دسته بندی های ذکر شده قرار می گیرند.
در صورت نیاز، درخواست خود را برای بهبود نتیجه تنظیم کنید.

پرس و جوها را تطبیق دهید

زمانی که تعداد کمی از کاربران در این نتایج مشارکت داشته باشند، نتایج انبوه به احتمال زیاد دارای نویز غیرمنتظره ای هستند. این ممکن است زمانی اتفاق بیفتد که ردیف‌ها تعداد کمی از کاربران داشته باشند یا زمانی که برخی از کاربران بر نتایج تأثیر نمی‌گذارند - به عنوان مثال، هنگام استفاده از تابع 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 را می توان برای پیوستن به جداول *_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 صادر شود).