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

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

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

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

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

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

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

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

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

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

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

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

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

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

لا تطلب البيانات نفسها أكثر من اللازم

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

  • اختَر تاريخَي بدء وانتهاء متقاربَين.
  • بدلاً من طلب البحث عن نوافذ متداخلة، نفِّذ طلبات البحث على مجموعات بيانات منفصلة، ثم اجمع النتائج في 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) من طلبات بحث متعددة للتجميع (من "مركز بيانات الإعلانات"). ستتم مشاركة المخططات النهائية للنتائج التي يتم احتسابها باستخدام طلبات البحث الشائعة.

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

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

لاستخدام "مستشار الاستعلام"، اتّبِع الخطوات التالية:

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