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

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

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

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

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

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

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

البيانات التي تتضمّن مقدارًا متوقعًا من الضوضاء	لون المؤشر	التأثير
>95%	بالأخضر	تأثير منخفض
85%-95%	أصفر	تأثير متوسط
75%-85%	Orange	تأثير عالٍ
أقل من %75	أحمر	تأثير عالٍ جدًا

للاطّلاع على معلومات تفصيلية عن تأثير التشويش:

انقر على التقارير.
اختَر تقريرًا من القائمة. يشير تلميح ملخّص الخصوصية إلى النسبة المئوية للنتائج التي تتضمّن مقدار التشويش المتوقّع، والتي يقابلها مقدار تشويش أكبر من 5% من النتيجة.
للاطّلاع على مزيد من المعلومات، انقر على الوظائف > التفاصيل.
اطّلِع على رسائل الخصوصية في تفاصيل الوظيفة. تندرج النتائج في إحدى الفئات المدرجة.
يمكنك تعديل الطلب لتحسين النتيجة، إذا لزم الأمر.

تكييف طلبات البحث

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

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

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

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

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

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

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

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

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.

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

ملاحظة مهمّة: لا تزال معظم أفضل الممارسات العادية في 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_clicks
  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

الاطّلاع على أفضل الممارسات الأخرى المتعلّقة بطلبات البحث

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

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

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).

تجدر الإشارة إلى أنّ هذا القيد لا ينطبق إلا على عمليات الدمج بين جداول Ads Data Hub (باستثناء جداول السمات). ولا ينطبق على الجداول التي يمتلكها العملاء. على سبيل المثال، يُسمح بما يلي:

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

اتحاد Ads Data Hub-BigQuery

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

ينتج عن هذا الاستعلام خطأ في التحقق من الصحة:

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

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

تجدر الإشارة إلى أنّه لا بأس في الدمج بين جداول متعدّدة في 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 أولاً).