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

عند العمل مع فلاتر مجموعات البيانات في سياق 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 نفسه.