حقن الضوضاء

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

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

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

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

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

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

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

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

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

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

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

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

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

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

فهم مدى تأثير إدخال الضوضاء في النتائج

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

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

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

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

لمحة عن الحدّ الأقصى لتجميع البيانات

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

التقييد الضمني

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

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

التقييد الصريح

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

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

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

SELECT
campaign_name,
-- Set lower and upper bounds to 0 and 1, respectively
ADH.ANON_COUNT(*, contribution_bounds_per_group => (0,1))
FROM data
GROUP BY 1

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

1. افتح أحد التقارير.
2. انقر على مفتاح التبديل إعدادات وظائف إخفاء هوية المستخدمين للحفاظ على الخصوصية لضبطه على استخدام وظائف إخفاء هوية المستخدمين للحفاظ على الخصوصية.
3. نفِّذ طلب البحث.
4. راجِع تأثير الضوضاء المُضافة.
5. اختياري: عدِّل الطلب لتقليل تأثير الضوضاء.

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

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

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

النتائج التي تحتوي على تشويش بنسبة تزيد عن% 5	لون المؤشر	التأثير
أقل من %5	أخضر	تأثير منخفض
من %5 إلى %15	أصفر	تأثير متوسط
‫‎15%-25%	Orange	تأثير عالٍ
‫>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)).

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

• LOGICAL_OR(...). البديل المقترَح: COUNT(DISTINCT IF(..., user_id, NULL)) > 0
• LOGICAL_AND(...). البديل المقترَح: COUNT(DISTINCT IF(NOT ..., user_id, NULL)) <= 0

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

على الرغم من أنّ Ads Data Hub ستُدخل تلقائيًا بيانات عشوائية في دوال التجميع هذه، لن تتغيّر توقيعات الدوال. بما أنّ الدوالّ مثل COUNT أو SUM أو INT64 تعرِض INT64، يتم تقريب أي جزء عشري من نتيجة الضوضاء. وعادةً ما يكون هذا التأثير ضئيلًا مقارنةً بحجم النتيجة والتشويش.

إذا كنت بحاجة إلى دقّة الكسور العشرية في النتيجة، تجنَّب كتابة دوالّ تعرض INT64، على سبيل المثال، باستخدام SUM مع تحويل الإدخال إلى FLOAT64.

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

من حيث المبدأ، يمكن أن يؤدّي الضوضاء ذات القيم الصغيرة جدًا إلى ظهور أرقام سلبية، حتى إذا كان ذلك من المستحيل من الناحية الدلالية للاستعلام. للحفاظ على السلوك المُتوقَّع، يتم تلقائيًا ضبط جميع أشكال COUNT وCOUNTIF على القيمة صفر، كي لا تؤدي أبدًا إلى نتائج سلبية. إذا كنت تريد هذا السلوك نفسه مع دالة أخرى، مثل SUM، يمكنك تقييد النتائج يدويًا باستخدام GREATEST(0, SUM(...)).

يكون هذا التغيير عادةً غير محسوس، ولكنه يُحدث تحيزًا إيجابيًا بسيطًا في النتائج الإجمالية. إذا كنت بحاجة إلى تجنُّب ذلك، ننصحك باستخدام ADH.ANON_COUNT بدلاً من COUNT، أو استخدام GROUP BY ROLLUP لحساب إجمالي الأعداد في جميع الصفوف.

---

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

ملاحظة مهمة: لا تزال معظم أفضل الممارسات العادية في "مركز بيانات إعلانات 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_clicks
  GROUP BY 1
)
SELECT * FROM result_1 JOIN result_2 USING(campaign_id)

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

البيانات المجمّعة التي تم دمجها مع بيانات غير مجمّعة

ملاحظة: تتلقّى كل عملية تجميع بيانات عشوائية بشكل مستقل، لذا قد لا تتم مطابقة القيم الإجمالية. في هذه الحالة، قد لا تتطابق القيم المجمّعة لمَعلمة imps لرقم تعريف حملة معيّن مع القيمة المقابلة لمَعلمة campaign_imps.

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

مثال:

WITH campaign_totals AS (
  # Noise applied here to campaign_imps
  SELECT campaign_id, COUNT(*) AS campaign_imps
  FROM adh.google_ads_impressions
  GROUP BY 1
)
# Noise applied here to imps
SELECT campaign_id, demographics, campaign_imps, COUNT(*) AS imps
FROM adh.google_ads_impressions JOIN campaign_totals USING(campaign_id)
GROUP BY 1,2,3

يحظر وضع "التشويش" إعادة تجميع النتائج المجمّعة، مثل AVG(campaign_imps).

---

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

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

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

لا تتيح طلبات البحث في وضع "إزالة الضوضاء" طلب البحث عن بيانات اليوم الحالي. (ننصح بعدم إجراء ذلك في وضع التحقّق من الاختلافات). لا يمكن اختيار التاريخ الحالي لطلبات البحث التي تستخدم ميزة "إدخال الضوضاء".

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

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

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

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

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

في هذه الحالة، يجب تنفيذ طلب البحث على شرائح تواريخ غير متّصلة.

يحدث مثال آخر على التكرار عندما تكون البيانات مستقلة عن التاريخ إلى حدٍ ما. يُنشئ الاستعلام التالي تكرارات عند تنفيذه في تواريخ متداخلة، حيث تغطي كلتا المهمتَين مدة الحملة بالكامل:

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

في هذه الحالة، يجب تنفيذ هذا الطلب مرة واحدة فقط لأنّ النتيجة لن تتغيّر.

يحدث تكرار التجميع عندما يتم تكرار التجميع نفسه متعدد المرات ضمن طلب بحث:

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

في هذه الحالة، عليك إزالة أحد التكرارات.

يُرجى العِلم أنّه حتى إذا كانت عمليات التجميع مختلفة من الناحية النحوية ولكنّها تحتسب القيمة نفسها، سيتم احتسابها على أنّها تكرار. بعبارة أخرى، إذا كانت قيم condition1 وcondition2 متطابقة لجميع المستخدِمين الذين لديهم قيمة معيّنة من key، سيتضمّن الطلب التالي تكرارًا:

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

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

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

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

في هذه الحالة، عليك إعادة هيكلة طلب البحث بحيث يتضمّن bq_table صفًا واحدًا فقط لكل قيمة لمفتاح الربط (campaign_id في هذه الحالة).

يُرجى العِلم أنّ إلغاء تداخل صفيف من جدول Ads Data Hub قد يؤدي إلى التأثير نفسه إذا كان لدى معظم المستخدِمين صفائف القيم نفسها:

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

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

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

يتم تطبيق الضوضاء على الطبقة الأولى من التجميع على مستوى جميع المستخدِمين في طلب البحث. يتم حظر طلبات البحث التي تتضمّن عدّة طبقات من التجميع:

WITH layer_1 AS (
  # Noise applied here to partial_result
  SELECT campaign_id, demographics, location, COUNT(*) AS partial_result
  FROM adh.google_ads_impressions
  GROUP BY 1,2,3
  HAVING partial_result > 5
)
# Reaggregation of partial_result with no user-level data, will be rejected
SELECT campaign_id, SUM(partial_result) AS final_result
FROM layer_1
GROUP BY 1

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

إذا كان ذلك أمرًا لا مفرّ منه، يمكنك إعادة كتابة طلب البحث لتصدير النتائج مباشرةً من الطبقة الأولى بدلاً من ذلك. لإجراء ذلك ضمن وظيفة واحدة بدون تغيير نتائج النص البرمجي، أنشئ جدولًا مؤقتًا (أو جدولًا تم تصديره إلى مشروعك على BigQuery) باستخدام بنية OPTIONS(privacy_checked_export=true). على سبيل المثال:

CREATE TEMP TABLE layer_1 OPTIONS(privacy_checked_export=true) AS (
  # Noise applied here to partial_result
  SELECT campaign_id, demographics, location, COUNT(*) AS partial_result
  FROM adh.google_ads_impressions
  GROUP BY 1,2,3
  HAVING partial_result > 5
);
# Reaggregation of privacy checked data, no noise needed
SELECT campaign_id, SUM(partial_result) AS final_result
FROM layer_1
GROUP BY 1

مزيد من المعلومات حول الجداول المؤقتة

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

أرقام تعريف المستخدمين غير المُدرَجين في أي مجموعات

يجب ألا تجمع طلبات البحث في وضع "الضوضاء" بيانات من مستخدمين منفصلين في صف واحد، إلا عند إجراء تجميع مع ضوضاء. نتيجةً لذلك، يجب إجراء عمليات دمج ل بيانات Ads Data Hub غير المجمّعة من أجل الدمج بشكل صريح في عمود user_id.

لا ينضمّ طلب البحث هذا بشكل صريح إلى عمود user_id، ما يؤدي إلى خطأ في التحقّق:

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

يمكن حلّ هذه المشكلة من خلال تعديل عبارة USING لتضمين user_id بشكل صريح، على سبيل المثال، USING(impression_id, user_id).

يُرجى العلم أنّ هذا القيد لا ينطبق إلا على عمليات الربط بين جداول "مركز بيانات إعلانات Google" (باستثناء جداول السمات). ولا ينطبق ذلك على الطاولات التي يملكها العملاء. على سبيل المثال، يُسمح بما يلي:

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

عمليات الدمج بين Ads Data Hub وBigQuery

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

يؤدي طلب البحث هذا إلى خطأ في التحقّق:

SELECT COUNT(*) FROM (
  SELECT 1 FROM adh.google_ads_impressions
  UNION ALL
  SELECT 1 FROM bigquery_project.dataset.table
)

لحلّ هذه المشكلة، عليك إما دمج جدول BigQuery لزيادة بيانات "مركز بيانات الإعلانات" بدلاً من الدمج، أو فصل البيانات لتجميع كل مصدر بشكل منفصل.

تجدر الإشارة إلى أنّه لا بأس بإجراء عملية دمج بين عدّة جداول في Ads Data Hub مع بيانات المستخدِم، أو عدّة جداول في BigQuery يملكها العميل، ولكن لا يمكنك دمج الجدولَين.

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

يمكن أن تؤدي عمليات الربط الخارجي مع البيانات التي يملكها العميل إلى ظهور صفوف لا تتضمّن معرّفات المستخدمين، ما يمنع المحتوى غير المرغوب فيه من العمل بشكلٍ جيد.

يؤدي كلا الطلبَين إلى أخطاء في التحقّق لأنّهما يسمحان بتسجيل صفوف غير متطابقة لا تتضمّن معرّفات مستخدمين على جانب Ads Data Hub:

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

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

يُرجى العلم أنّ أيّ عملية دمج ستعمل إذا تم عكس ترتيب الجداول.

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

لا تتوفّر مواصفات ملخّص الصفوف التي تمت فلترتها في وضع الضوضاء. لا تكون هذه الميزة ضرورية في أغلب الأحيان مع التشويش بسبب انخفاض معدّلات الفلترة وعدم فلترة عمليات التحقّق من الاختلافات.

إذا لاحظت تصفية بيانات كبيرة في نتيجة تشويش، عليك زيادة البيانات المجمّعة. يمكنك إجراء تجميع موازٍ على مجموعة البيانات الكاملة لمقارنة تقدير للإجمالي، على سبيل المثال:

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

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

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

لا يمكن استخدام الجداول غير المُصدَّرة في Ads Data Hub إلّا باستخدام وضع الخصوصية نفسه الذي تم إنشاؤها فيه. لا يمكنك إنشاء جدول في وضع التجميع العادي واستخدامه في وضع الضوضاء، أو العكس (ما لم يتم أولاً تصدير هذا الجدول إلى BigQuery).