تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

إضافة التشويش

تشويش البيانات هو أسلوب يُستخدَم لحماية خصوصية المستخدم عند طلب البحث في قاعدة بيانات. تعمل هذه التقنية من خلال إضافة تشويش عشوائي إلى عبارة تجميع SELECT في طلب بحث. ويحمي هذا التشويش خصوصية المستخدمين مع توفير نتائج دقيقة بشكل معقول، ما يلغي الحاجة إلى عمليات التحقّق من الاختلافات ويقلّل من الحد الأدنى المطلوب للتجميع من أجل الحصول على الناتج. يمكن تنفيذ معظم طلبات البحث الحالية في وضع "الضوضاء"، مع بعض القيود.

التعرّف على مزايا استخدام تقنية إضافة الضوضاء

لا تنطبق عمليات التحقّق من الاختلافات: عند تنفيذ طلبات بحث تتضمّن تشويشًا، لا تستبعد خدمة Ads Data Hub الصفوف بسبب التشابه مع مجموعات النتائج السابقة. وهذا يعني أنّه سيظل بإمكانك الحصول على نظرة شاملة على البيانات مع الحفاظ على خصوصية المستخدم.

تبسيط عملية تحديد المشاكل وحلّها: لا يتم حذف الصفوف إلا بسبب متطلبات التجميع، ما يسهّل تحديد المشاكل وحلّها وتعديل طلبات البحث.

لا حاجة إلى تعلُّم صيغة جديدة: لا تحتاج إلى تعلُّم أي صيغة جديدة للاستعلام أو الإلمام بمفاهيم الخصوصية لاستخدام الضوضاء بدلاً من عمليات التحقّق من الاختلاف.

يتم عرض دقة النتائج: تعرض المهمة الناجحة النسبة المئوية الإجمالية للبيانات التي كان من الممكن أن تتأثر بالتشويش.

التعرّف على تأثير الضوضاء في متطلبات الخصوصية

عمليات التحقّق من الاختلاف: لا تعتمد عملية إدخال التشويش على عمليات التحقّق الحالية من الاختلاف في Ads Data Hub. عند استخدام ميزة "إضافة التشويش"، يتم إيقاف عمليات التحقّق من الاختلافات.

متطلبات التجميع: يجب أن تعرض بيانات مرات الظهور الناتجة عن إضافة التشويش بيانات تمثّل 20 مستخدمًا فريدًا أو أكثر، وأن تعرض بيانات النقرات أو الإحالات الناجحة بيانات تمثّل 10 مستخدمين فريدين أو أكثر.

عمليات التحقّق الثابتة: ليس لها أي تأثير.

الميزانيات وحدود طلبات البحث: تتشارك طلبات البحث التي يتم تنفيذها باستخدام الضوضاء ميزانية الوصول إلى البيانات المستخدَمة مع عمليات التحقّق من الاختلافات. كما هو الحال مع عمليات التحقّق من الاختلافات، إذا نفّذت طلب البحث نفسه على مجموعة البيانات نفسها عدة مرات، قد تفقد إمكانية الوصول إلى التواريخ التي يتم البحث عنها بشكل متكرر في مجموعة البيانات. يمكن أن يحدث ذلك إذا نفّذت طلبات بحث باستخدام نافذة منزلقة، أو إذا قدّمت الطلب نفسه عدة مرات.

يفرض "وضع التشويش" حدودًا إضافية وأكثر صرامة على إعادة احتساب النتائج المجمّعة نفسها ضمن طلبات البحث أو في ما بينها. كما هو الحال مع ميزانية الوصول إلى البيانات، قد تفقد إمكانية الوصول إلى التواريخ التي يتم الاستعلام عنها بشكل متكرر في مجموعة البيانات، ولكن القيود الناتجة عن إعادة احتساب النتائج المجمّعة نفسها ستقتصر على الطلبات في وضع التشويش فقط، وليس الطلبات في وضع التحقّق من الفرق. لمزيد من المعلومات، يُرجى الاطّلاع على النتائج المكرّرة.

مزيد من المعلومات عن فحوصات الخصوصية

فهم تأثير إضافة التشويش في النتائج

تضيف خدمة Ads Data Hub تشويشًا للحدّ من خطر الإفصاح، أي خطر أن يتمكّن شخص من معرفة معلومات عن مستخدم فردي. وتوازن بين الخصوصية والفائدة.

تعمل ميزة "إضافة التشويش" في Ads Data Hub على تحويل نتائج طلب البحث على النحو التالي:

ويؤدي ذلك إلى حصر مساهمات المستخدمين المتطرفين في النتائج المجمّعة. يجمع هذا الإجراء مساهمة كل مستخدم في كل عملية تجميع، ثم يضع حدًا أدنى وأقصى لكل مساهمة.
يجمع هذا المقياس المساهمات المحدودة لكل مستخدم.
تضيف هذه الآلية ضوضاء إلى كل نتيجة مجمّعة، أي نتيجة كل استدعاء لدالة تجميع في كل صف. ويتناسب مقياس هذه الضوضاء العشوائية مع الحدود المثبّتة.
ويحتسب عددًا مشوّشًا للمستخدمين لكل صف، ويزيل الصفوف التي تتضمّن عددًا قليلاً جدًا من المستخدمين. يشبه ذلك إخفاء الهوية k في وضع التحقّق من الاختلاف، ولكن بسبب التشويش، يمكن أن تتجاهل المهام التي يتم تنفيذها على مجموعة البيانات نفسها صفوفًا مختلفة. بالإضافة إلى ذلك، يؤدي وضع التشويش إلى إسقاط عدد أقل من الصفوف لأنّ متطلبات التجميع تكون أقل (حوالي 20 صفًا مقابل 50 صفًا بالضبط).

والنتيجة النهائية هي مجموعة بيانات يتضمّن كل صف فيها نتائج مجمّعة مشوّشة، وتمت إزالة المجموعات الصغيرة. يؤدي ذلك إلى إخفاء تأثير مستخدم فردي على النتائج المعروضة.

لمحة عن الحدّ من تجميع البيانات

تستخدم عملية إدخال التشويش في Ads Data Hub عملية تجميع ضمنية أو صريحة لتقييد مساهمة القيم الشاذة. يمكنك اختيار نوع التثبيت الذي تريد استخدامه، وذلك حسب حالة الاستخدام.

التثبيت الضمني

لا تحتاج إلى أي بنية SQL خاصة لاستخدام التقييد الضمني، إذ يتم تطبيقه تلقائيًا. يتم استنتاج الحدود الضمنية من البيانات نفسها، ويتم تحديدها لكل عملية تجميع. إذا كانت بعض عمليات التجميع تتضمّن نطاقًا أوسع من القيم مقارنةً بغيرها، يمكن أن يستنتج التحديد الضمني حدودًا مختلفة لعمليات التجميع المختلفة حسب الاقتضاء. يؤدي ذلك عادةً إلى تقليل الأخطاء. يُرجى العِلم أنّ COUNT(DISTINCT user_id) تستخدم تلقائيًا التقييد الصريح مع الحدّ الأعلى 1.

التثبيت الصريح

يؤدي التحديد الصريح إلى حصر إجمالي المساهمة من كل مستخدم في نطاق محدّد. يتم تطبيق الحدود الصريحة بشكل موحّد على جميع عمليات التجميع، ويجب أن تكون قيمًا حرفية. قد يؤدي التقييد الصريح إلى نتائج أفضل عندما تكون الحدود معروفة بشكل عام. على سبيل المثال، يشير تحديد الأعمار بين 0 و100 عام إلى معلومات عامة لأنّ أعمار معظم الأشخاص تقع بشكل عام ضمن هذا النطاق.

توفّر خدمة Ads Data Hub 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

تنفيذ طلب بحث باستخدام إضافة التشويش

افتح تقريرًا.
انقر على زر التبديل إعدادات وظائف إخفاء هوية المستخدمين للحفاظ على الخصوصية إلى وضع استخدام الضوضاء.
نفِّذ الاستعلام.
راجِع تأثير التشويش المضاف.
اختياري: تعديل طلب البحث للحدّ من تأثير التشويش

مراجعة تأثير الضوضاء

بعد اكتمال مهمة بنجاح، يعرض Ads Data Hub مدى موثوقية النتيجة في ملخّص الخصوصية. تستند الموثوقية إلى نسبة الخلايا في الناتج التي قد تتأثر بشكل كبير بتفاوت الأداء. تُعدّ القيمة في جدول النتائج متأثرة إذا كان مقياس التشويش المضاف أكبر من %5 من النتيجة في الخلية.

بالنسبة إلى مجموعات بيانات الإخراج المتأثرة، يعرض ملخّص الخصوصية الأعمدة العشرة الأكثر تشويشًا، بدءًا من الأعلى تأثيرًا إلى الأقل تأثيرًا، ومساهمتها في التشويش. في ما يلي تفاصيل تصنيفات تأثير الضوضاء.

النسبة المئوية للنتائج المتأثرة	لون المؤشر	التأثير
<5%	أخضر	تأثير منخفض
‫5%-15%	أصفر	تأثير متوسط
‫15%-25%	برتقالي	تأثير عالٍ
أكثر من %25	أحمر	تأثير كبير جدًا

يمكنك أيضًا معاينة ملخّص الخصوصية لمهام التقارير الحديثة في صفحة الصفحة الرئيسية. لمعاينة إعدادات الخصوصية لوظيفة معيّنة، مرِّر المؤشر فوق رمز تلميح الخصوصية privacy_tip في بطاقة الوظيفة ضمن النشاط الأخير.

تعديل طلبات البحث

من المرجّح أن تتأثر عمليات التجميع بالتشويش عندما يساهم عدد قليل من المستخدمين في النتيجة. ويمكن أن يحدث ذلك عند احتساب عمليات التجميع من مجموعات صغيرة من المستخدمين أو عندما لا يؤثّر بعض المستخدمين في النتائج، كما يحدث مثلاً مع الدالة COUNTIF. استنادًا إلى تقرير الضوضاء، قد تحتاج إلى تعديل طلب البحث لتقليل نسبة النتائج المتأثرة.

في ما يلي إرشادات عامة:

وسِّع النطاق الزمني.
أعِد كتابة طلب البحث لتقليل دقة البيانات، مثلاً من خلال التجميع حسب عدد أقل من المَعلمات أو استبدال COUNTIF بـ COUNT.
إزالة الأعمدة التي تتضمّن بيانات غير دقيقة
جرِّب الحدّ من القيم الصريحة عندما يمكن اختيار حدود معقولة.

دوال التجميع المتوافقة

تتوفّر دوال التجميع التالية مع التشويش:

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

لا تتوافق الكلمة الرئيسية DISTINCT إلا مع الدالة COUNT، وذلك فقط عند استخدامها مع مرجع مباشر إلى العمود user_id من جدول في "مركز بيانات إعلانات Google" أو تعبير يعرض user_id أو NULL، مثل COUNT(DISTINCT IF(..., user_id, NULL)).

يُرجى العِلم أنّ هذه القيود تنطبق فقط على عمليات التجميع التي تتضمّن تشويشًا، وهي المستوى الأول من عمليات التجميع على مستوى عدة مستخدمين. تجميعات على مستوى المستخدم والتجميعات التي تتبع عملية إضافة التشويش غير مقيّدة.

دوال التجميع الإضافية

بالإضافة إلى إتاحة أدوات التجميع العادية، يقدّم Ads Data Hub دوال تجميع ADH.ANON إضافية تتيح التقييد الصريح. تتشارك أدوات التجميع هذه البنية مع دوال التجميع الخاصة بالفروق في الخصوصية في 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 من القيم التي يمكن استخدامها كمفاتيح تجميع، مثل تاريخ الحدث، يمكنك أولاً استخدام GROUP BY مع هذه القيمة، ثم حساب 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، يتم تجميع النتائج المجهولة المصدر لطلب بحث معيّن على مستوى المجموعات. يتم تطبيق حدود التجميع للتأكّد من توفّر عدد كافٍ من المستخدمين في المجموعة، وذلك لحماية بيانات المستخدمين الفرديين. تُعرف عملية تحديد المجموعات التي يمكن إصدارها باسم "اختيار الأقسام".

في كثير من الحالات، قد تكون المجموعات معروفة للجميع. على سبيل المثال، لا يعتمد التجميع حسب إصدار المتصفّح أو يوم الأسبوع أو المنطقة الجغرافية على بيانات المستخدم إذا كانت قيم مفتاح التجميع معروفة مسبقًا. في هذه الحالة، يمكن حذف اختيار القسم، لأنّ توفّر مجموعة أو عدم توفّرها في الناتج لا يقدّم أي معلومات جديدة عن المستخدمين.

يحدّد Ads Data Hub طلبات البحث المؤهّلة للمجموعات العامة ولا يطبّق حدود التجميع على هذه الطلبات. وهذا يعني أنّه لم يتم استبعاد أي صفوف من النتائج. يُرجى العِلم أنّ النتائج المحسوبة من عدد صغير من المستخدمين يمكن أن تتأثر بشكل كبير بالتشويش.

لكي تكون مؤهلاً للمجموعات العامة، يجب أن يكون طلب البحث منظَّمًا لضمان معرفة جميع مفاتيح التجميع مسبقًا. يجب أن تستوفي أعمدة التجميع الشروط التالية:

تأتي هذه البيانات من جدول متاح للجميع (جدول أو عبارة 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;

يمكن أن يكون عدم الفلترة في طلبات البحث الخاصة بالمجموعات العامة مفيدًا لطلبات البحث التي يتم تنفيذها بشكل متكرر، لأنّه يتم دائمًا عرض الناتج لقيم مفاتيح التجميع الثابتة نفسها. يمكن أن يكون ذلك مفيدًا بشكل خاص، مثلاً، لإنشاء لوحات بيانات دورية.

ملاحظة: إذا كان جدول عام يوفّر عددًا كبيرًا جدًا من قيم مفاتيح التجميع، قد تحصل على العديد من الصفوف التي تتضمّن بيانات قليلة أو لا تتضمّن أي بيانات، وسيتم الإبلاغ عن أنّ هذه الصفوف لها تأثير كبير على التشويش. في هذه الحالة، عليك تقديم قائمة أصغر من المفاتيح تتضمّن القيم التي تهمّك فقط.

أنماط طلبات البحث المتوافقة

ملاحظة مهمة: تظلّ معظم أفضل الممارسات العادية في "مركز بيانات إعلانات Google" سارية على طلبات البحث التي تستخدم ميزة "إضافة التشويش". ننصحك بشكل خاص بمراجعة الإرشادات حول الاستعلام بشكل متكرّر عن البيانات نفسها.

يوضّح هذا القسم أنماط طلبات البحث المتوافقة عند تنفيذ طلبات البحث باستخدام ميزة "إضافة التشويش".

عمليات التجميع على مستوى المستخدم

تتوفّر إحصاءات مجمّعة على مستوى المستخدمين بدون قيود بالطريقة نفسها التي تتوفّر بها في وضع التحقّق من الخصوصية التفاضلية. لا يتم إدخال الضوضاء إلا في عمليات التجميع التي تجمع البيانات من عدة مستخدمين. عمليات التجميع التي يتم فيها التجميع بشكل صريح حسب 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

مزيد من المعلومات حول أفضل الممارسات الأخرى المتعلّقة بطلبات البحث

لمحة عن فترات معاينة الإعلان

تُنشئ بعض أنماط طلبات البحث تقارير على مدى فترة زمنية طويلة، وتتم إعادة إنشائها بشكل دوري لتضمين نتائج جديدة. قد تحتاج هذه الاستعلامات إلى تعديلات لتعمل في وضع "الضوضاء"، لأنّه سيتم حظرها إذا أعادت احتساب النتائج السابقة. بدلاً من ذلك، يجب أن تؤدي كل مهمة إلى إنشاء نتائج جديدة فقط، ثم يمكن دمج النتائج الجديدة مع نتائج من مهام سابقة للحصول على تقرير كامل.

على سبيل المثال، إذا كنت بصدد إنشاء تقرير عن المقاييس حسب التاريخ، يتم تعديله يوميًا:

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، ما يؤدي إلى ظهور تحذير بشأن صحة البيانات:

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 (باستثناء جداول السمات). ولا ينطبق ذلك على الجداول التي يملكها العميل. على سبيل المثال، يُسمح بما يلي:

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

عمليات الربط الصحيحة بين 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)

يُرجى العلم أنّ أيًا من عمليات الضم ستنجح إذا تم عكس ترتيب الجداول. هناك أيضًا استثناء لجداول معرّفات الأجهزة المرتبطة بالمستخدمين والتي يتم ربطها مباشرةً بعمود device_id_md5. على سبيل المثال، سيعمل طلب البحث التالي بدون ظهور أي تحذيرات:

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 أولاً).

إضافة التشويش تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

التعرّف على مزايا استخدام تقنية إضافة الضوضاء

التعرّف على تأثير الضوضاء في متطلبات الخصوصية

فهم تأثير إضافة التشويش في النتائج

لمحة عن الحدّ من تجميع البيانات

التثبيت الضمني

التثبيت الصريح

تنفيذ طلب بحث باستخدام إضافة التشويش

مراجعة تأثير الضوضاء

تعديل طلبات البحث

دوال التجميع المتوافقة

دوال التجميع الإضافية

حساب الحد الأدنى والحد الأقصى

لمحة عن نتائج الأعداد الصحيحة

لمحة عن النتائج السلبية

المجموعات العامة

أنماط طلبات البحث المتوافقة

عمليات التجميع على مستوى المستخدم

عمليات التجميع المتوازية

البيانات المجمَّعة المرتبطة بالبيانات غير المجمَّعة

أنماط طلبات البحث غير المتوافقة

طلبات البحث التي تتضمّن اليوم

النتائج المتكرّرة

لمحة عن فترات معاينة الإعلان

إعادة التجميع المباشر

أرقام تعريف المستخدمين غير المرتبطة

عمليات الربط الصحيحة بين Ads Data Hub وBigQuery

ملخّص الصفوف التي تمّت فلترتها

الجداول التي تم إنشاؤها في الوضعين

إضافة التشويش