تزریق نویز

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

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

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

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

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

دقت نتیجه گزارش می‌شود: یک کار موفق، درصد کل داده‌هایی را که می‌توانستند تحت تأثیر نویز قرار گیرند، نشان می‌دهد.

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

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

الزام تجمیع: تزریق نویز، داده‌های مربوط به تعداد نمایش تبلیغ (impression) را که تقریباً توسط ۲۰ کاربر منحصر به فرد یا بیشتر نمایش داده می‌شود، و داده‌های مربوط به کلیک یا تبدیل را که تقریباً توسط ۱۰ کاربر منحصر به فرد یا بیشتر نمایش داده می‌شود، خروجی می‌دهد.

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

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

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

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

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

هاب داده تبلیغات، نویز را تزریق می‌کند تا ریسک افشا را کاهش دهد - ریسکی که در آن شخصی می‌تواند اطلاعات یک کاربر خاص را به دست آورد. این سرویس، حریم خصوصی را در مقابل سودمندی متعادل می‌کند.

تزریق نویز در Ads Data Hub نتایج جستجو را به صورت زیر تغییر می‌دهد:

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

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

درباره کلمپ تجمعی

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

کلمپ ضمنی

برای استفاده از مهار ضمنی به هیچ سینتکس SQL خاصی نیاز ندارید، این مهار به طور پیش‌فرض اعمال می‌شود. مرزهای ضمنی از خود داده‌ها گرفته می‌شوند و برای هر تجمیع تعیین می‌شوند. اگر برخی از تجمیع‌ها طیف وسیع‌تری از مقادیر را نسبت به سایرین داشته باشند، مهار ضمنی می‌تواند مرزهای متفاوتی را برای تجمیع‌های مختلف به صورت مناسب استنباط کند. این معمولاً منجر به خطاهای کمتری می‌شود. توجه داشته باشید که COUNT(DISTINCT user_id) به طور خودکار از مهار صریح با حد بالای 1 استفاده می‌کند.

بستن صریح

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

مرکز داده‌های تبلیغات، توابع تجمیعی ADH.ANON تکمیلی را برای مهار صریح ارائه می‌دهد. برای استفاده از مهار صریح، با جمع اعداد صحیح که نشان دهنده حد پایین و حد بالا هستند، مرزهای هر تابع تجمیعی پشتیبانی شده را تعیین کنید. به عنوان مثال:

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

اجرای یک کوئری با استفاده از تزریق نویز

  1. یک گزارش باز کنید.
  2. روی گزینه تنظیمات نویز حریم خصوصی (Privacy noise settings) کلیک کنید و آن را به موقعیت استفاده از نویز (Use noise) تغییر دهید.
  3. کوئری را اجرا کنید .
  4. تأثیر نویز اضافه شده را بررسی کنید .
  5. اختیاری: پرس‌وجو را طوری تنظیم کنید که تأثیر نویز را کاهش دهد.

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

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

برای مجموعه داده‌های خروجی تحت تأثیر، خلاصه حریم خصوصی، ده ستون از پر نویزترین ستون‌ها را از بیشترین تا کمترین تأثیر و سهم مربوط به آنها در ایجاد نویز فهرست می‌کند. این تفکیک برچسب‌های تأثیر نویز است.

درصد نتایج تحت تأثیر رنگ نشانگر تأثیر
<5٪ سبز تأثیر کم
۵٪ - ۱۵٪ زرد تأثیر متوسط
۱۵٪-۲۵٪ نارنجی تأثیر بالا
>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 توابع تجمیع ADH.ANON تکمیلی را معرفی می‌کند که از مهار صریح پشتیبانی می‌کنند. این تجمیع‌کننده‌ها سینتکس خود را با توابع تجمیع Differentially private در BigQuery به اشتراک می‌گذارند، با این حال، به عبارت WITH DIFFERENTIAL_PRIVACY نیازی ندارند:

  • ADH.ANON_SUM( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

  • ADH.ANON_COUNT( *, [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

  • ADH.ANON_COUNT( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

  • ADH.ANON_AVG( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

  • ADH.ANON_PERCENTILE_CONT( ..., percentile, contribution_bounds_per_row => (lower_bound, upper_bound) )

پارامترهای ADH.ANON_SUM ، ADH.ANON_COUNT و ADH.ANON_AVG :

  • contribution_bounds_per_group GROUP BY
  • lower_bound : یک متغیر عددی که نشان‌دهنده کوچکترین مقداری است که باید در یک تجمیع گنجانده شود.
  • upper_bound : یک متغیر عددی که بزرگترین مقداری که باید در یک تجمیع گنجانده شود را نشان می‌دهد.

پارامترهای ADH.ANON_PERCENTILE_CONT :

  • percentile : صدکی که قرار است محاسبه شود، عددی در بازه [0, 1] .
  • contribution_bounds_per_row : مشارکت‌های هر کاربر بر اساس هر سطر (هر رکورد) محدود می‌شوند. توجه داشته باشید که محدودیت‌های محدودکننده‌ی صریح برای صدک مورد نیاز است و بنابراین فقط به عنوان یک تابع تکمیلی پشتیبانی می‌شود.
  • lower_bound : یک متغیر عددی که نشان‌دهنده کوچکترین مقداری است که باید در یک تجمیع گنجانده شود.
  • upper_bound : یک متغیر عددی که بزرگترین مقداری که باید در یک تجمیع گنجانده شود را نشان می‌دهد.

محاسبه حداقل و حداکثر

توابع MIN و MAX مستقیماً در تجمیع نویز پشتیبانی نمی‌شوند، اما اغلب روش‌های جایگزینی برای محاسبه این نتایج وجود دارد.

اگر مقادیری با MIN یا MAX دارید که می‌توانند به عنوان کلیدهای گروه‌بندی استفاده شوند، مانند تاریخ رویداد، می‌توانید ابتدا بر اساس آن مقدار گروه‌بندی کنید، سپس MIN / MAX پس از آن محاسبه کنید. این روش حداقل یا حداکثر مقداری را که از آستانه تجمیع عبور می‌کند، برمی‌گرداند.

مثال:

WITH campaign_date_ranges AS (
  SELECT campaign_id, MIN(event_date) AS min_date, MAX(event_date) AS max_date
  FROM (
    # Aggregation thresholding will be applied here
    SELECT DISTINCT
      campaign_id,
      DATE(query_id.time_usec, @time_zone) AS event_date
    FROM adh.google_ads_impressions
  )
)
SELECT campaign_id, num_impressions, min_date, max_date
FROM (
  # Noise and aggregation thresholding will be applied here
  SELECT campaign_id, COUNT(*) AS num_impressions
  FROM adh.google_ads_impressions
)
JOIN campaign_date_ranges USING(campaign_id)

از طرف دیگر، اگر حداقل یا حداکثر مقادیر جزئی با مرزهای مشخص دارید، می‌توانید PERCENTILE_CONT با مرزهای صریح برای یک نتیجه تقریبی استفاده کنید.

مثال:

SELECT
  campaign_id,
  COUNT(*) AS num_impressions,
  ADH.ANON_PERCENTILE_CONT(
    query_id.time_usec, 0,
    contribution_bounds_per_row => (@min_timestamp, @max_timestamp))
    AS min_timestamp,
  ADH.ANON_PERCENTILE_CONT(
    query_id.time_usec, 1,
    contribution_bounds_per_row => (@min_timestamp, @max_timestamp))
    AS max_timestamp
FROM adh.google_ads_impressions

درباره نتایج عدد صحیح

اگرچه Ads Data Hub به طور خودکار برای این توابع تجمیعی نویز تزریق می‌کند، اما امضای توابع تغییر نمی‌کند. از آنجا که توابعی مانند COUNT یا SUM از INT64 مقدار INT64 را برمی‌گردانند، هر بخش اعشاری از نتیجه نویزدار گرد می‌شود. این مقدار معمولاً نسبت به اندازه نتیجه و نویز ناچیز است.

اگر به جزئیات اعشاری در نتیجه خود نیاز دارید، از نوشتن توابعی که INT64 برمی‌گردانند خودداری کنید - برای مثال، با استفاده از SUM و تبدیل ورودی آن به FLOAT64 .

درباره نتایج منفی

در اصل، نویز با مقادیر بسیار کوچک می‌تواند منجر به اعداد منفی شود، حتی زمانی که این امر از نظر معنایی برای پرس و جو غیرممکن باشد. برای حفظ رفتار مورد انتظار، تمام اشکال COUNT و COUNTIF به طور خودکار در صفر محدود می‌شوند، بنابراین هرگز نتایج منفی نمی‌دهند. اگر می‌خواهید همین رفتار را با تابع دیگری مانند SUM داشته باشید، می‌توانید نتایج را به صورت دستی با استفاده از GREATEST(0, SUM(...)) محدود کنید.

این تغییر معمولاً ناچیز است، اما تأثیر مثبت کوچکی بر نتایج کلی می‌گذارد.

گروه‌های عمومی

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

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

مرکز داده‌های تبلیغات، کوئری‌های واجد شرایط برای گروه‌های عمومی را شناسایی می‌کند و آستانه تجمیع را برای این کوئری‌ها اعمال نمی‌کند. این بدان معناست که هیچ ردیف خروجی فیلتر نمی‌شود. توجه داشته باشید که نتایج محاسبه‌شده از تعداد کمی از کاربران می‌تواند به شدت تحت تأثیر نویز قرار گیرد.

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

  • آنها از یک جدول عمومی (یک جدول یا عبارت SELECT بدون داده‌های کاربر Ads Data Hub) می‌آیند.
  • آنها SELECT DISTINCT را برای اعمال مقادیر منحصر به فرد اعمال کرده‌اند.
  • آنها با یک OUTER JOIN روی تمام ستون‌های جداگانه به کوئری متصل می‌شوند.

نمونه‌هایی از پرسش‌های گروه‌های عمومی:

SELECT age_group_id, COUNT(*) FROM adh.google_ads_impressions
RIGHT OUTER JOIN (SELECT DISTINCT age_group_id FROM adh.age_group)
ON demographics.age_group = age_group_id
GROUP BY age_group_id

SELECT age_group_id, COUNT(*) FROM adh.google_ads_impressions
RIGHT OUTER JOIN (SELECT DISTINCT * FROM UNNEST([1, 2, 3]) AS age_group_id)
ON demographics.age_group = age_group_id
GROUP BY age_group_id

در مثال اول، adh.google_ads_impressions table محافظت‌شده به جدول adh.age_group که حاوی داده‌های کاربر در ستون age_group_id نیست، متصل شده است. همان ستون age_group_id در جدول عمومی در عبارت GROUP BY ظاهر می‌شود.

به طور مشابه، در مثال دوم، جدول adh.google_ads_impressions محافظت‌شده به جدول عمومی متصل شده است که به صراحت به صورت UNNEST([1, 2, 3]) ارائه شده است. توجه داشته باشید که در هر دو مثال، کلید گروه‌بندی age_group_id از جدول عمومی می‌آید.

همچنین می‌توان چندین مورد گروه‌بندی ارائه داد، برای مثال:

SELECT campaign_id, COUNT(*) FROM adh.google_ads_impressions
RIGHT OUTER JOIN (SELECT DISTINCT campaign_id, customer_id FROM adh.google_ads_campaign)
USING (campaign_id, customer_id)
GROUP BY campaign_id, customer_id

SELECT p.campaign_id, p.browser, COUNT(*) FROM adh.google_ads_impressions AS i
RIGHT OUTER JOIN (
 SELECT DISTINCT * FROM UNNEST([1, 2]) AS campaign_id
 CROSS JOIN UNNEST(['Chrome', 'Other']) AS browser
) AS p
 ON i.campaign_id = p.campaign_id AND i.browser = p.browser
GROUP BY campaign_id, browser;

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

یک نکته: اگر یک جدول عمومی تعداد بسیار زیادی از مقادیر کلید گروه‌بندی را ارائه دهد، ممکن است ردیف‌های زیادی با داده‌های کم یا بدون داده داشته باشید و همه این ردیف‌ها به عنوان دارای تأثیر نویز بالا گزارش شوند. در این حالت، باید به صراحت لیست کوچک‌تری از کلیدها را فقط با مقادیری که به آنها علاقه‌مند هستید، ارائه دهید.

الگوهای پرس‌وجوی پشتیبانی‌شده

مهم : اکثر شیوه‌های استاندارد 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_creative_conversions
  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

درباره سایر بهترین شیوه‌های پرس‌وجو اطلاعات کسب کنید .

درباره ویندوز Lookback

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

برای مثال، اگر در حال ایجاد گزارشی از معیارها بر اساس تاریخ هستید که روزانه به‌روزرسانی می‌شود: 

SELECT
  campaign_id,
  DATE(TIMESTAMP_MICROS(query_id.time_usec), @time_zone) AS event_date,
  COUNT(*) AS impressions
FROM adh.google_ads_impressions
GROUP BY 1,2

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

اگر نیاز به به‌روزرسانی نتیجه قبلی دارید (مثلاً برای در نظر گرفتن داده‌های دیررس)، باید از محاسبه مجدد هر نتیجه بیش از ۱ یا ۲ بار خودداری کنید. در غیر این صورت، ممکن است به دلیل تلاش‌های مکرر برای پرس‌وجو، با خطا مواجه شوید.

تجمع مجدد مستقیم

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

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 عمل join را انجام نمی‌دهد، که منجر به یک هشدار اعتبارسنجی می‌شود: 

SELECT …
FROM adh.google_ads_impressions
JOIN adh.google_ads_creative_conversions USING(impression_id)

ممکن است اتصال‌هایی از این دست آنطور که انتظار می‌رود رفتار نکنند، زیرا فقط ردیف‌هایی با مقدار user_id یکسان مطابقت دارند. این مشکل را می‌توان با تنظیم عبارت USING برای گنجاندن صریح user_id برطرف کرد - برای مثال، USING(impression_id, user_id) .

توجه داشته باشید که این محدودیت فقط برای اتصال بین جداول Ads Data Hub (به استثنای جداول dimension) اعمال می‌شود. این محدودیت برای جداول متعلق به مشتری اعمال نمی‌شود. به عنوان مثال، موارد زیر مجاز است: 

SELECT …
FROM adh.google_ads_impressions
JOIN bigquery_project.dataset.table USING(any_column)

اتصال‌های راستِ مرکز داده‌ی تبلیغات-بیگ‌کوئری

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

هر دوی این کوئری‌ها منجر به هشدارهای اعتبارسنجی می‌شوند، زیرا امکان وجود ردیف‌های نامتناسب با شناسه‌های کاربری گمشده در سمت 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 کار می‌کنند. همچنین یک استثنا برای جداول RDID وجود دارد که مستقیماً در device_id_md5 join می‌شوند. برای مثال، کوئری زیر بدون هیچ هشداری کار خواهد کرد: 

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 اکسپورت شود).

،

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

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

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

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

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

دقت نتیجه گزارش می‌شود: یک کار موفق، درصد کل داده‌هایی را که می‌توانستند تحت تأثیر نویز قرار گیرند، نشان می‌دهد.

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

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

الزام تجمیع: تزریق نویز، داده‌های مربوط به تعداد نمایش تبلیغ (impression) را که تقریباً توسط ۲۰ کاربر منحصر به فرد یا بیشتر نمایش داده می‌شود، و داده‌های مربوط به کلیک یا تبدیل را که تقریباً توسط ۱۰ کاربر منحصر به فرد یا بیشتر نمایش داده می‌شود، خروجی می‌دهد.

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

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

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

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

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

هاب داده تبلیغات، نویز را تزریق می‌کند تا ریسک افشا را کاهش دهد - ریسکی که در آن شخصی می‌تواند اطلاعات یک کاربر خاص را به دست آورد. این سرویس، حریم خصوصی را در مقابل سودمندی متعادل می‌کند.

تزریق نویز در Ads Data Hub نتایج جستجو را به صورت زیر تغییر می‌دهد:

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

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

درباره کلمپ تجمعی

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

کلمپ ضمنی

برای استفاده از مهار ضمنی به هیچ سینتکس SQL خاصی نیاز ندارید، این مهار به طور پیش‌فرض اعمال می‌شود. مرزهای ضمنی از خود داده‌ها گرفته می‌شوند و برای هر تجمیع تعیین می‌شوند. اگر برخی از تجمیع‌ها طیف وسیع‌تری از مقادیر را نسبت به سایرین داشته باشند، مهار ضمنی می‌تواند مرزهای متفاوتی را برای تجمیع‌های مختلف به صورت مناسب استنباط کند. این معمولاً منجر به خطاهای کمتری می‌شود. توجه داشته باشید که COUNT(DISTINCT user_id) به طور خودکار از مهار صریح با حد بالای 1 استفاده می‌کند.

بستن صریح

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

مرکز داده‌های تبلیغات، توابع تجمیعی ADH.ANON تکمیلی را برای مهار صریح ارائه می‌دهد. برای استفاده از مهار صریح، با جمع اعداد صحیح که نشان دهنده حد پایین و حد بالا هستند، مرزهای هر تابع تجمیعی پشتیبانی شده را تعیین کنید. به عنوان مثال:

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

اجرای یک کوئری با استفاده از تزریق نویز

  1. یک گزارش باز کنید.
  2. روی گزینه تنظیمات نویز حریم خصوصی (Privacy noise settings) کلیک کنید و آن را به موقعیت استفاده از نویز (Use noise) تغییر دهید.
  3. کوئری را اجرا کنید .
  4. تأثیر نویز اضافه شده را بررسی کنید .
  5. اختیاری: پرس‌وجو را طوری تنظیم کنید که تأثیر نویز را کاهش دهد.

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

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

برای مجموعه داده‌های خروجی تحت تأثیر، خلاصه حریم خصوصی، ده ستون از پر نویزترین ستون‌ها را از بیشترین تا کمترین تأثیر و سهم مربوط به آنها در ایجاد نویز فهرست می‌کند. این تفکیک برچسب‌های تأثیر نویز است.

درصد نتایج تحت تأثیر رنگ نشانگر تأثیر
<5٪ سبز تأثیر کم
۵٪ - ۱۵٪ زرد تأثیر متوسط
۱۵٪-۲۵٪ نارنجی تأثیر بالا
>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 توابع تجمیع ADH.ANON تکمیلی را معرفی می‌کند که از مهار صریح پشتیبانی می‌کنند. این تجمیع‌کننده‌ها سینتکس خود را با توابع تجمیع Differentially private در BigQuery به اشتراک می‌گذارند، با این حال، به عبارت WITH DIFFERENTIAL_PRIVACY نیازی ندارند:

  • ADH.ANON_SUM( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

  • ADH.ANON_COUNT( *, [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

  • ADH.ANON_COUNT( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

  • ADH.ANON_AVG( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )

  • ADH.ANON_PERCENTILE_CONT( ..., percentile, contribution_bounds_per_row => (lower_bound, upper_bound) )

پارامترهای ADH.ANON_SUM ، ADH.ANON_COUNT و ADH.ANON_AVG :

  • contribution_bounds_per_group GROUP BY
  • lower_bound : یک متغیر عددی که نشان‌دهنده کوچکترین مقداری است که باید در یک تجمیع گنجانده شود.
  • upper_bound : یک متغیر عددی که بزرگترین مقداری که باید در یک تجمیع گنجانده شود را نشان می‌دهد.

پارامترهای ADH.ANON_PERCENTILE_CONT :

  • percentile : صدکی که قرار است محاسبه شود، عددی در بازه [0, 1] .
  • contribution_bounds_per_row : مشارکت‌های هر کاربر بر اساس هر سطر (هر رکورد) محدود می‌شوند. توجه داشته باشید که محدودیت‌های محدودکننده‌ی صریح برای صدک مورد نیاز است و بنابراین فقط به عنوان یک تابع تکمیلی پشتیبانی می‌شود.
  • lower_bound : یک متغیر عددی که نشان‌دهنده کوچکترین مقداری است که باید در یک تجمیع گنجانده شود.
  • upper_bound : یک متغیر عددی که بزرگترین مقداری که باید در یک تجمیع گنجانده شود را نشان می‌دهد.

محاسبه حداقل و حداکثر

توابع MIN و MAX مستقیماً در تجمیع نویز پشتیبانی نمی‌شوند، اما اغلب روش‌های جایگزینی برای محاسبه این نتایج وجود دارد.

اگر مقادیری با MIN یا MAX دارید که می‌توانند به عنوان کلیدهای گروه‌بندی استفاده شوند، مانند تاریخ رویداد، می‌توانید ابتدا بر اساس آن مقدار گروه‌بندی کنید، سپس MIN / MAX پس از آن محاسبه کنید. این روش حداقل یا حداکثر مقداری را که از آستانه تجمیع عبور می‌کند، برمی‌گرداند.

مثال:

WITH campaign_date_ranges AS (
  SELECT campaign_id, MIN(event_date) AS min_date, MAX(event_date) AS max_date
  FROM (
    # Aggregation thresholding will be applied here
    SELECT DISTINCT
      campaign_id,
      DATE(query_id.time_usec, @time_zone) AS event_date
    FROM adh.google_ads_impressions
  )
)
SELECT campaign_id, num_impressions, min_date, max_date
FROM (
  # Noise and aggregation thresholding will be applied here
  SELECT campaign_id, COUNT(*) AS num_impressions
  FROM adh.google_ads_impressions
)
JOIN campaign_date_ranges USING(campaign_id)

از طرف دیگر، اگر حداقل یا حداکثر مقادیر جزئی با مرزهای مشخص دارید، می‌توانید PERCENTILE_CONT با مرزهای صریح برای یک نتیجه تقریبی استفاده کنید.

مثال:

SELECT
  campaign_id,
  COUNT(*) AS num_impressions,
  ADH.ANON_PERCENTILE_CONT(
    query_id.time_usec, 0,
    contribution_bounds_per_row => (@min_timestamp, @max_timestamp))
    AS min_timestamp,
  ADH.ANON_PERCENTILE_CONT(
    query_id.time_usec, 1,
    contribution_bounds_per_row => (@min_timestamp, @max_timestamp))
    AS max_timestamp
FROM adh.google_ads_impressions

درباره نتایج عدد صحیح

Although Ads Data Hub will automatically inject noise for these aggregate functions, the function signatures don't change. Because functions like COUNT or SUM of INT64 return INT64 , any decimal part of the noised result is rounded. This is usually negligible relative to the size of the result and noise.

If you need the granularity of the decimal in your result, then avoid writing functions that return INT64 –for example, by using SUM with its input cast to FLOAT64 .

About negative results

In principle, noise with very small values can result in negative numbers, even when this should be semantically impossible for the query. To maintain expected behavior, all forms of COUNT and COUNTIF are automatically clamped at zero, so they never give negative results. If you want this same behavior with another function, such as SUM , then you can clamp results manually using GREATEST(0, SUM(...)) .

This change is usually negligible, but it does introduce a small positive bias to overall results.

گروه‌های عمومی

With a GROUP BY clause, the anonymized results of a query are aggregated over groups. Aggregation thresholding is applied to make sure that a sufficient number of users are present in the group so that individual user data is protected. The process of determining which groups can be released is called "partition selection".

In many cases groups may be public knowledge. For example, grouping by browser version, day of the week, or a geographical region does not depend on user data if the grouping key values are known in advance. In this instance, the partition selection can be omitted, since the presence or absence of a group in the output does not provide any new information about the users.

Ads Data Hub identifies queries eligible for public groups and does not apply aggregation thresholding to these queries. This means that no output rows are filtered out. Note that results computed from a small number of users can be heavily impacted by noise.

To be eligible for public groups, the query must be structured to ensure that all grouping keys are known in advance. The grouping columns must satisfy the following conditions:

  • They come from a public table (a table or SELECT clause with no Ads Data Hub user data).
  • They have SELECT DISTINCT applied to enforce unique values.
  • They are joined into the query with an OUTER JOIN on all of the individual columns.

Examples of public groups queries:

SELECT age_group_id, COUNT(*) FROM adh.google_ads_impressions
RIGHT OUTER JOIN (SELECT DISTINCT age_group_id FROM adh.age_group)
ON demographics.age_group = age_group_id
GROUP BY age_group_id

SELECT age_group_id, COUNT(*) FROM adh.google_ads_impressions
RIGHT OUTER JOIN (SELECT DISTINCT * FROM UNNEST([1, 2, 3]) AS age_group_id)
ON demographics.age_group = age_group_id
GROUP BY age_group_id

In the first example, the protected adh.google_ads_impressions table is joined with the adh.age_group table that does not contain user data on the age_group_id column. The same public table age_group_id column appears in the GROUP BY clause.

Similarly, in the second example the protected adh.google_ads_impressions table is joined with the public table, which is provided explicitly as UNNEST([1, 2, 3]) . Notice that in both examples, the grouping key age_group_id comes from the public table.

Multiple grouping items can be provided as well, for example:

SELECT campaign_id, COUNT(*) FROM adh.google_ads_impressions
RIGHT OUTER JOIN (SELECT DISTINCT campaign_id, customer_id FROM adh.google_ads_campaign)
USING (campaign_id, customer_id)
GROUP BY campaign_id, customer_id

SELECT p.campaign_id, p.browser, COUNT(*) FROM adh.google_ads_impressions AS i
RIGHT OUTER JOIN (
 SELECT DISTINCT * FROM UNNEST([1, 2]) AS campaign_id
 CROSS JOIN UNNEST(['Chrome', 'Other']) AS browser
) AS p
 ON i.campaign_id = p.campaign_id AND i.browser = p.browser
GROUP BY campaign_id, browser;

The absence of filtering in the public groups queries can be beneficial for recurrently run queries, since the output is always returned for the same fixed grouping keys' values. This can be particularly useful, for example, for building periodical dashboards.

A caveat: if a public table provides a very large number of grouping key values, then you may get many rows with little or no data, and these rows will all be reported as having high noise impact. In this case, you should consider explicitly providing a smaller list of keys with just the values you are interested in.

Supported query patterns

Important : Most of Ads Data Hub's standard best practices still apply to queries that use noise injection. In particular, we recommend that you review the guidance on repeatedly querying the same data .

This section describes query patterns that are supported when running queries using noise injection.

User-level aggregates

Unrestricted user-level aggregates are supported in the same way that they are in difference check mode. Noise is only injected in aggregations that combine data across multiple users. Aggregations that explicitly group by user_id , or analytic functions that partition by user_id , don't receive any noise and any function is allowed. User-level aggregations that don't explicitly group by user_id –for example, GROUP BY impression_id , are treated as cross-user aggregations, so noise is added.

Grouping by external_cookie is not enough. While external_cookie can be used to join *_match tables with customer-owned tables, any single-user aggregations should explicitly group by user_id column, not just the external_cookie column.

Aggregate function example:

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;

Analytic function example:

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;

Parallel aggregates

Each cross-user aggregation receives noise independently. You can run multiple such aggregations in a single statement, combining results into one table using a JOIN or 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_creative_conversions
  GROUP BY 1
)
SELECT * FROM result_1 JOIN result_2 USING(campaign_id)

Note that this would be supported but should be avoided in difference check mode. This practice is not a problem with noise, as each parallel aggregate is noised and filtered independently.

Aggregated data joined with unaggregated data

Since Ads Data Hub only supports analytic windows that partition by user_id , it is a common workaround to aggregate these results separately and self-join them before aggregating again. These queries are supported in noise mode, and often perform better than they would with in difference check mode due to privacy requirements being resolved earlier.

مثال: 

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

Noise mode discourages reaggregating aggregate results, such as AVG(campaign_imps) .

Unsupported query patterns

This section describes query patterns that are not supported when running queries using noise injection.

Today-inclusive queries

Noise mode queries don't support querying the current day's data. (This is discouraged in difference check mode.) The current date is not selectable for queries that use noise injection.

Repeated results

In noise mode, Ads Data Hub limits how often you can repeat the same aggregation. If you reach these limits, your noise mode queries will lose access to frequently queried dates in the dataset. The following are examples of how this can occur.

Query repetition happens when the same query is run multiple times with the same parameters or highly similar parameters, such as overlapping date ranges. You can avoid this by using data that is already exported to your BigQuery project.

Note that if two jobs are querying overlapping date ranges, they might produce repetitions if performing the same computation on the same users. For example, the following query, executed on overlapping date ranges, creates repetitions because it partitions by date: 

SELECT DATE(TIMESTAMP_MICROS(event.event_time)) AS date,
COUNT(*) AS cnt
FROM adh.cm_dt_clicks
GROUP BY 1

In this case, you should run the query on disjoint date segments.

Another example of a repetition happens when data is somewhat date independent. The following query produces repetitions when executed on overlapping dates, where both jobs cover the entire lifetime of a campaign: 

SELECT campaign_id, COUNT(*) AS cnt
FROM adh.google_ads_impressions
GROUP BY 1

In this case, you should run this query only once since the result doesn't change.

Aggregation repetition happens when the same aggregation is repeated multiple times within a query: 

SELECT COUNT(*) AS cnt1, COUNT(*) AS cnt2
FROM table

In this case, you should remove one of the repetitions.

Note that even if the aggregations are syntactically different but compute the same value, it would count as a repetition. In other words, if the values of condition1 and condition2 are the same for all users with some value of key , the following query would have a repetition: 

SELECT key, COUNTIF(condition1) AS cnt1, COUNTIF(condition2) AS cnt2
FROM table
GROUP BY key

If you have conditions that are very similar for some groups of users, you might consider rewriting the query to have only one COUNT .

Row duplication happens when an Ads Data Hub table is joined with a BigQuery table in a way that each row from the Ads Data Hub table matches multiple rows in the BigQuery table. For example, the following query produces a repetition if there are multiple rows with the same campaign ID in bq_table : 

SELECT r.campaign_id, COUNT(*) AS cnt
FROM adh_table
INNER JOIN bq_table ON l.campaign_id = r.campaign_id

In this case, you should restructure the query so that bq_table would have only one row per join key value ( campaign_id , in this case).

Note that unnesting an array from the Ads Data Hub table could produce the same effect if most users have the same arrays of values: 

SELECT in_market_id, COUNT(*)
FROM adh.dv360_youtube_impressions,
UNNEST(in_market) AS in_market_id
GROUP BY 1

Learn about other query best practices .

About Lookback Windows

Some query patterns generate reports over a large timeframe, periodically regenerating to include new results. These queries may need adjustments to work in noise mode because if they recompute previous results, they will be blocked. Instead, each job should only generate new results, then new results can be combined with results from previous jobs for a full report.

For example, if you are creating a report of metrics by date, refreshed daily: 

SELECT
  campaign_id,
  DATE(TIMESTAMP_MICROS(query_id.time_usec), @time_zone) AS event_date,
  COUNT(*) AS impressions
FROM adh.google_ads_impressions
GROUP BY 1,2

You shouldn't run this with a large date range as this will recompute results of previous days. Instead, you should run each job only the latest day, which has new data, then combine with results from previous jobs.

If you do need to refresh a previous result (for example to account for late arriving data), then you should avoid recomputing any single result more than 1 or 2 times. Otherwise, you may get errors due to repeated query attempts.

Direct reaggregation

Noise is applied to the first layer of cross-user aggregation in the query. Queries with multiple layers of aggregation will combine noisy results, so final aggregates may have much higher noise. These queries receive a warning on validation: 

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

To get the best results from noise, compute all cross-user operations within a single aggregation. For example, take a SUM of events rather than a SUM of intermediate counts.

If multi-layer aggregation is unavoidable, you can resolve the warning by exporting results directly from the first layer instead. To do this within a single job without changing script results, create a temp table (or a table exported to your BigQuery project) with the OPTIONS(privacy_checked_export=true) syntax. For example: 

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

Learn more about temp tables .

If the first layer of aggregation is too granular for privacy checks, consider rewriting the query with user-level aggregates . If this is not possible, then this query is not supported in noise mode.

Unjoined user IDs

Queries in noise mode must not combine data from separate users into a single row, except when performing an aggregation with noise. As a result, joins of unaggregated Ads Data Hub data should explicitly join on the user_id column.

This query does not explicitly join on the user_id column, which results in a validation warning: 

SELECT …
FROM adh.google_ads_impressions
JOIN adh.google_ads_creative_conversions USING(impression_id)

Joins like this may not behave as expected because only rows with the same user_id value will match. This can be fixed by adjusting the USING clause to explicitly include user_id – for example, USING(impression_id, user_id) .

Note that this limitation applies only to joins between Ads Data Hub tables (with the exception of dimension tables). It does not apply to customer-owned tables. For example, the following is allowed: 

SELECT …
FROM adh.google_ads_impressions
JOIN bigquery_project.dataset.table USING(any_column)

Ads Data Hub-BigQuery right joins

Outer joins with customer-owned data can lead to rows with missing user identifiers, which prevents noise from working well.

Both of these queries result in validation warnings because they allow for unmatched rows with missing user identifiers on the Ads Data Hub side: 

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)

Note that either join would work if the order of the tables was reversed. There is also an exception for RDID tables that join directly on device_id_md5 . For example, the following query will work with no warnings: 

SELECT …
FROM bigquery_project.dataset.table
LEFT JOIN adh.google_ads_impressions_rdid USING(device_id_md5)

Filtered Row Summary

The filtered row summary spec is not supported in noise mode. This feature is most often unnecessary with noise due to lower filtering rates and the lack of filtering from difference checks.

If you observe significant data filtering in a noise result, then increase the aggregated data. You may perform a parallel aggregation over the full dataset to compare an estimate of the total, for example: 

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

Note that the total count is independently noised and total values may not add up, but the total count is often more accurate than taking the sum of noised rows.

Cross-mode created tables

Unexported tables in Ads Data Hub can only be used with the same privacy mode where they were created. You can't create a table in normal aggregation mode and use it in noise mode, or the other way around (unless that table is exported to BigQuery first).