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

تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

صورة تعرض أنواعًا متعدّدة من عمليات الربط من خلال مخطّطات Venn البيانية

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

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

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

يمكنك دمج النتائج (في BigQuery) من طلبات بحث تجميع متعدّدة (من "مركز بيانات إعلانات Google"). ستتشارك المخططات النهائية النتائج التي يتم احتسابها باستخدام طلبات البحث الشائعة.

يأخذ طلب البحث التالي نتائج فردية من "مركز بيانات الإعلانات" (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

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

قد يتم ضبط رقم تعريف المستخدِم النهائي على 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

بشكل عام، تحقّق طلبات البحث التي تؤدي إلى نتائج أقل أداءً أفضل. عند تقييم أداء طلبات البحث، يعتمد حجم العمل المطلوب على العوامل التالية:

بيانات الإدخال ومصادر البيانات (I/O): كم عدد البايتات التي يقرأها طلب البحث؟
التواصل بين العقد (الترتيب العشوائي): كم عدد البايتات التي ينقلها طلب البحث إلى المرحلة التالية؟
المعالجة: ما هو مقدار معالجة وحدة المعالجة المركزية التي يتطلبها طلب البحث؟
النواتج (التجسيد): كم عدد وحدات البايت التي يكتبها طلبك؟
أنماط الاستعلامات غير المرغوب فيها: هل تستخدِم استعلاماتك أفضل ممارسات لغة الاستعلامات البنيوية (SQL)؟

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

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

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

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

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

دمج طلبات البحث الفرعية المجمَّعة
دمج البيانات غير المجمّعة مع مستخدمين يُحتمل أن يكونوا مختلفين
جداول مؤقتة محدّدة بشكل متكرّر

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

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