أفضل الممارسات

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

الخصوصية ودقة البيانات

إنشاء طلبات بحث عن بيانات وضع الحماية

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

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

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

التفكير في النتائج السابقة بعناية

أفضل الممارسات: تقليل احتمالية تداخل مجموعات النتائج بين طلبات البحث التي تم تنفيذها مؤخرًا.

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

بدلاً من ذلك، يمكنك تعديل المَعلمات الرئيسية في طلب البحث، مثل النطاقات الزمنية أو أرقام تعريف الحملات، لتقليل احتمالية حدوث تداخل كبير.

عدم الاستعلام عن بيانات اليوم

أفضل الممارسات: لا تنفِّذ طلبات بحث متعددة يكون تاريخ الانتهاء فيها اليوم.

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

عدم إجراء طلبات بحث عن البيانات نفسها أكثر من اللازم

أفضل الممارسات:

  • اختَر تاريخَي البدء والانتهاء مرتبطَين بإحكام.
  • بدلاً من الاستعلام عن نوافذ متداخلة، قم بتشغيل استعلاماتك على مجموعات منفصلة من البيانات، ثم قم بتجميع النتائج في BigQuery.
  • يمكنك استخدام النتائج المحفوظة بدلاً من إعادة تنفيذ طلب البحث.
  • أنشِئ جداول مؤقتة لكل نطاق زمني تبحث عنه.

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

لا تستخدِم تجميعات أكثر من اللازم في طلب البحث نفسه.

أفضل الممارسات:

  • تقليل عدد التجميعات في طلب بحث
  • إعادة كتابة طلبات البحث لدمج التجميعات إن أمكن

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

SELECT
  COUNTIF(field_1 = a_1 AND field_2 = b_1) AS cnt_1,
  COUNTIF(field_1 = a_2 AND field_2 = b_2) AS cnt_2
FROM
  table

يجب إعادة كتابة طلبات البحث التي تحتسب الأحداث بناءً على مجموعة الحقول نفسها باستخدام عبارة GROUP BY.

SELECT
  field_1,
  field_2,
  COUNT(1) AS cnt
FROM
  table
GROUP BY
  1, 2

يمكن تجميع النتيجة بنفس الطريقة في BigQuery.

يجب إعادة كتابة الاستعلامات التي تنشئ أعمدة من صفيف ثم تجميعها بعد ذلك لدمج هذه الخطوات. 

SELECT
  COUNTIF(a_1) AS cnt_1,
  COUNTIF(a_2) AS cnt_2
FROM
  (SELECT
     1 IN UNNEST(field) AS a_1,
     2 IN UNNEST(field) AS a_2,
   FROM
     table)

يمكن إعادة كتابة الاستعلام السابق على النحو التالي:

SELECT f, COUNT(1) FROM table, UNNEST(field) AS f GROUP BY 1

يمكن إعادة كتابة طلبات البحث التي تستخدم مجموعات مختلفة من الحقول في تجميعات مختلفة إلى عدة طلبات بحث أكثر تركيزًا.

SELECT
  COUNTIF(field_1 = a_1) AS cnt_a_1,
  COUNTIF(field_1 = b_1) AS cnt_b_1,
  COUNTIF(field_2 = a_2) AS cnt_a_2,
  COUNTIF(field_2 = b_2) AS cnt_b_2,
FROM table

يمكن تقسيم الاستعلام السابق إلى:

SELECT
  field_1, COUNT(*) AS cnt
FROM table
GROUP BY 1

و

SELECT
  field_2, COUNT(*) AS cnt
FROM table
GROUP BY 1

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

تحسين عمليات الدمج وفهمها

أفضل الممارسات: استخدِم LEFT JOIN بدلاً من INNER JOIN لربط النقرات أو الإحالات الناجحة بمرّات الظهور.

لا ترتبط جميع مرات الظهور بالنقرات أو الإحالات الناجحة. ولذلك، في حال INNER JOIN من النقرات أو الإحالات الناجحة على مرات الظهور، ستتم فلترة مرات الظهور غير المرتبطة بالنقرات أو الإحالات الناجحة من نتائجك.

صورة تعرض أنواع عمليات دمج متعدّدة من خلال الرسومات التخطيطية المتداخلة

ضم بعض النتائج النهائية في BigQuery

أفضل الممارسات: تجنَّب طلبات بحث Ads Data Hub التي تجمع النتائج المجمّعة. بدلاً من ذلك، اكتب طلبي بحث منفصلين واربط النتائج في BigQuery.

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

يمكنك ضم النتائج (في BigQuery) من طلبات تجميع متعددة (من Ads Data Hub). ستشارك النتائج المحسوبة باستخدام طلبات البحث الشائعة المخططات النهائية.

يأخذ طلب البحث التالي نتائج Ads Data Hub الفردية (campaign_data_123 وcampaign_data_456) ويدمجها في BigQuery:

SELECT t1.campaign_id, t1.city, t1.X, t2.Y
FROM `campaign_data_123` AS t1
FULL JOIN `campaign_data_456` AS t2
USING (campaign_id, city)

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

أفضل الممارسات: أضِف ملخّصات الصفوف التي تمّت فلترتها إلى طلبات البحث.

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

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

أفضل الممارسات: يجب مراعاة أرقام تعريف المستخدمين ذات القيمة الصفرية في نتائجك.

يمكن ضبط رقم تعريف المستخدم النهائي على 0 لعدد من الأسباب، بما في ذلك: إيقاف تخصيص الإعلانات والأسباب التنظيمية وما إلى ذلك. وبالتالي، سيتم ربط البيانات الناشئة من عدة مستخدمين على user_id من 0.

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

يمكنك استبعاد هذه البيانات من نتائجك عن طريق إضافة WHERE user_id != "0" إلى طلبات بحثك.

الأداء

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

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

إنّ طلبات البحث التي تجمع النتائج التي سبق تجميعها، كما هو الحال في حالة طلب البحث الذي يحتوي على GROUP BY متعددة، أو تجميع مُدمَج، تتطلّب المزيد من الموارد لمعالجتها.

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

ويجب تجنُّب الأنماط التالية:

SELECT SUM(count)
FROM
  (SELECT campaign_id, COUNT(0) AS count FROM ... GROUP BY 1)

يجب إعادة كتابة طلبات البحث التي تستخدم طبقات متعددة من التجميع لاستخدام طبقة واحدة من التجميع.

(SELECT ... GROUP BY ... )
JOIN USING (...)
(SELECT ... GROUP BY ... )

يجب تقسيم الطلبات التي يمكن تقسيمها بسهولة. يمكنك ضم النتائج في BigQuery.

التحسين من أجل BigQuery

بوجه عام، كانت طلبات البحث الأقل أداءً أفضل. عند تقييم أداء طلبات البحث، يعتمد مقدار العمل المطلوب على العوامل التالية:

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

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

مستشار طلبات البحث

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

تشمل المشغلات الأنماط التالية:

لاستخدام مستشار طلبات البحث:

  • واجهة المستخدم: ستظهر الاقتراحات في محرِّر طلبات البحث في أعلى نص الاستعلام.
  • واجهة برمجة التطبيقات: استخدِم الطريقة customers.analysisQueries.validate.