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

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

ملاحظة مهمة: لا يشمل اعتماد مجلس أبحاث السوق (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%	برتقالي	تأثير عالٍ
أكثر من %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 سيضيف تلقائيًا تشويشًا إلى دوال التجميع هذه، لن تتغيّر تواقيع الدوال. بما أنّ الدوال مثل 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)

قد لا تعمل عمليات الربط هذه على النحو المتوقّع لأنّه سيتم الربط فقط بين الصفوف التي تتضمّن القيمة نفسها في 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 أولاً).