استخدام فلاتر مجموعات بيانات المؤسسات في المهام المجمّعة

عند العمل مع فلاتر مجموعات البيانات في سياق AdGroupCriterion.listing_group أو AssetGroupListingGroupFilter، يجب مراعاة الاعتبارات التالية عند تصميم عملية الدمج.

تقسيم الدفعات

نقطة أساسية: ننصحك بإضافة عمليات AssetGroupListingGroupFilterOperation (create وupdate وremove) التي تستهدف AssetGroup نفسه، وعمليات AdGroupCriterionOperation (create وupdate وremove) لمعايير LISTING_GROUP (AdGroupCriterion.listing_group) التي تستهدف AdGroup نفسه، إلى مهمة مجمّعة على التوالي، حتى يتم التعامل مع مجموعة العمليات بشكل ذري أثناء تقسيم المجموعة.

إذا كانت هناك أي عمليات في مهمة مجمّعة تحتوي على معايير مجموعات إعلانية أو فلاتر مجموعات بيانات في مجموعات مواد العرض، يتم تقسيم العمليات في المهمة المجمّعة إلى عدة دفعات فرعية عند تلقّيها من خادم Google Ads API. على عكس العمليات العادية في وظيفة مجمّعة، يتم التعامل مع كل دفعة فرعية تحتوي على عمليات فلترة مجموعات البيانات بشكل مستقل.

يتم تحديد طريقة تقسيم المهام المجمّعة التي تحتوي على فلاتر مجموعات البيانات إلى مهام فرعية مجمّعة وفقًا للعوامل التالية:

1. نوع فلتر مجموعة بيانات المؤسسة
2. AdGroup أو AssetGroup يستهدف فلتر مجموعة البيانات
3. ترتيب العمليات الحسابية

ضَع في اعتبارك كيفية تجميع العمليات:

• يتم تجميع كل عمليات AssetGroupListingGroupFilterOperation المتتالية (create وupdate وremove) التي تستهدف AssetGroup نفسه معًا في دفعة فرعية ذرية (لا يوجد سلوك فشل جزئي).
• يتم تجميع جميع عمليات AdGroupCriterionOperation المتتالية (create وupdate وremove) لمعايير LISTING_GROUP (AdGroupCriterion.listing_group) التي تستهدف AdGroup نفسه في مجموعة فرعية واحدة (بدون سلوك تعذُّر جزئي).
• يتم تجميع جميع العمليات المتتالية الأخرى معًا في دفعات فرعية غير ذرية (سلوك الفشل الجزئي).

ملاحظة: إذا كنت تُنشئ أيضًا AssetGroup في مهمة الدفعة نفسها، ضَع أي عمليات AssetOperation (create) مطلوبة مسبقًا لموارد Asset الجديدة قبل AssetGroupOperation (create)، متبوعةً مباشرةً بعمليات AssetGroupAssetOperation (create) (التي يتم تنفيذها معًا في دفعة فرعية ذرية سابقة)، ثم عمليات AssetGroupListingGroupFilterOperation المتتالية (التي يتم تنفيذها في الدفعة الفرعية الذرية التالية). بما أنّ هاتين العمليتين تشكّلان دفعتَين فرعيتَين منفصلتَين، يؤدي حدوث خطأ في الدفعة الفرعية AssetGroupListingGroupFilterOperation إلى التراجع عن فلاتر مجموعات البيانات بدون التراجع عن الموردَين AssetGroup وAssetGroupAsset اللذين تم إنشاؤهما حديثًا.

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

يوضّح الرسم البياني التالي هذا المفهوم. يمثّل كل مربّع رمادي مهمة معالجة مجمّعة تم إرسالها باستخدام Google Ads API. داخل المربّعات الرمادية، يتم تجميع العمليات الفردية حسب اللون لتمثيل الدفعات الفرعية التي ينشئها خادم Google Ads API. يتوافق ترتيب العمليات في كلّ من المربّعات الرمادية مع الترتيب الذي تمت به إضافة العمليات إلى مهمة الدفعة.

القيود

عند استخدام فلاتر مجموعات البيانات في سياق مهام الدفعات، تسري القيود التالية:

• لا يمكن أن تتجاوز الدفعة الفرعية الذرية الواحدة من عمليات AdGroupCriterionOperation المتتالية (create وupdate وremove) لمعايير LISTING_GROUP (AdGroupCriterion.listing_group) التي تستهدف AdGroup نفسه 20,000 عملية في الطول. ومع ذلك، ننصح بعدم تجاوز 10,000 عملية. بما أنّ كل AddBatchJobOperationsRequest يقتصر على 10,000 عملية، يجب تحميل دفعة فرعية من AdGroup تتضمّن من 10,001 إلى 20,000 عملية على الأقل من خلال طلبَين متتاليَين من طلبات AddBatchJobOperations.
• لا يمكن أن يتجاوز عدد العمليات في الدفعة الفرعية الذرية الواحدة والمتسلسلة من عمليات AssetGroupListingGroupFilterOperation (create وupdate وremove) التي تستهدف AssetGroup نفسه 10,000 عملية.
• في حال مخالفة أيّ من هذين الحدَّين الأقصيَين لعدد العمليات (أو تجاوز الحدّ الأقصى الداخلي لحجم البايت المتسلسل في الخادم لدفعة فرعية واحدة)، يتم إلغاء مهمة الدفعة في تلك الدفعة الفرعية: تظلّ أيّ دفعات فرعية سابقة تم إكمالها ملتزمة، في حين يتعذّر تنفيذ جميع العمليات في الدفعة الفرعية المخالفة وأيّ دفعات فرعية لاحقة مع ظهور الخطأ InternalError.INTERNAL_ERROR.

تحديد المشاكل وحلّها

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

على سبيل المثال، عند معالجة ردّ من ListBatchJobResults:

• بالنسبة إلى مجموعات بيانات AdGroupCriterionOperation، قد تلاحظ أنّ العمليات المتتالية التي تستهدف AdGroup نفسه قد تعذّر تنفيذها بسبب الخطأ CriterionError.LISTING_GROUP_ERROR_IN_ANOTHER_OPERATION (Product group operations are atomic within the same ad group. This operation failed because another operation targeting the same ad group ID was invalid.).
• بالنسبة إلى عمليات AssetGroupListingGroupFilterOperation، قد تلاحظ أنّ العمليات المتتالية التي تستهدف AssetGroup نفسه تعذّر إكمالها بسبب الخطأ BatchJobError.ASSET_GROUP_LISTING_GROUP_FILTER_TRANSACTION_FAILURE.

تشير هذه الأخطاء إلى أنّه تم التراجع عن العملية في هذا الفهرس لأنّ عملية أخرى في الدفعة الفرعية الذرية نفسها تعذّر تنفيذها. لتحديد السبب الأساسي للمشكلة، يمكنك تكرار رسائل status في كل BatchJobResult، قبل وبعد operation_index خطأ المعاملة، للعمليات التي تشارك معرّف AdGroup أو AssetGroup نفسه.