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

تزریق نویز

تزریق نویز تکنیکی است که برای محافظت از حریم خصوصی کاربر هنگام پرس‌وجو از پایگاه داده استفاده می‌شود. این تکنیک با اضافه کردن نویز تصادفی به عبارت 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

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

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

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

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

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

درصد نتایج تحت تأثیر	رنگ نشانگر	تأثیر
<5٪	سبز	تأثیر کم
۵٪ - ۱۵٪	زرد	تأثیر متوسط
۱۵٪-۲۵٪	نارنجی	تأثیر بالا
>25%	قرمز	تاثیر بسیار بالا

همچنین می‌توانید خلاصه حریم خصوصی را برای گزارش‌های اخیر مشاغل در صفحه اصلی پیش‌نمایش دهید. برای پیش‌نمایش حریم خصوصی یک شغل خاص، اشاره‌گر را روی آیکون نکته حریم خصوصی privacy_tip در کارت شغل در زیر فعالیت اخیر نگه دارید.

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

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

موارد زیر دستورالعمل‌های کلی هستند:

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

توابع تجمیعی پشتیبانی‌شده

توابع تجمیعی زیر با نویز پشتیبانی می‌شوند:

SUM(...)
COUNT(*)
COUNT(...)
COUNTIF(...)
COUNT(DISTINCT ...)
APPROX_COUNT_DISTINCT(...)
AVG(...)

کلمه کلیدی DISTINCT فقط با تابع COUNT پشتیبانی می‌شود. هنگامی که با ارجاع مستقیم به ستون user_id از جدول Ads Data Hub یا عبارتی که user_id یا NULL را برمی‌گرداند، مانند COUNT(DISTINCT IF(..., user_id, NULL)) استفاده شود، توابع COUNT DISTINCT و APPROX_COUNT_DISTINCT(...) با محدود کردن سهم هر کاربر به 1 محاسبه می‌شوند. هنگامی که COUNT DISTINCT به یک ستون غیر user_id ارجاع می‌دهد، با استفاده از APPROX_COUNT_DISTINCT با محدود کردن ضمنی، تقریب زده می‌شود.

توابع تجمیعی تکمیلی

علاوه بر پشتیبانی از تجمیع‌کننده‌های معمولی، 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_COUNT_DISTINCT( ..., [ max_contributions_per_group => 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 : یک متغیر عددی که بزرگترین مقداری که باید در یک تجمیع گنجانده شود را نشان می‌دهد.

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

max_contributions_per_group : مشارکت‌ها به ازای هر کاربر برای هر پارتیشن تعریف شده توسط کلیدهای GROUP BY محدود می‌شوند. حد بالا، حداکثر مشارکت کاربر در هر گروه را پس از تجمیع مقادیر به ازای هر کاربر محدود می‌کند.
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 اکسپورت شود).

تزریق نویز با مجموعه‌ها، منظم بمانید ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.

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

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

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

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

کلمپ ضمنی

بستن صریح

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

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

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

توابع تجمیعی پشتیبانی‌شده

توابع تجمیعی تکمیلی

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

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

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

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

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

داده‌های تجمیعی سطح کاربر

مصالح موازی

داده‌های تجمیع‌شده به داده‌های تجمیع‌نشده متصل می‌شوند

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

پرسش‌های شامل امروز

نتایج تکراری

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

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

شناسه‌های کاربری غیرعضو

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

خلاصه ردیف فیلتر شده

جداول ایجاد شده در حالت متقابل

تزریق نویز