استفاده از فیلترهای گروه فهرست‌بندی در کارهای دسته‌ای

وقتی با فیلترهای گروه فهرست‌بندی در چارچوب AdGroupCriterion.listing_group یا AssetGroupListingGroupFilter کار می‌کنید، ملاحظات زیر را هنگام طراحی یکپارچه‌سازی خود در نظر بگیرید.

تقسیم دسته‌ای

اگر در یک کار دسته‌ای عملیاتی وجود داشته باشد که حاوی معیارهای گروه تبلیغاتی یا فیلترهای گروه فهرست دارایی‌ها باشد، عملیات موجود در کار دسته‌ای هنگام دریافت توسط سرور API گوگل ادز به چندین زیرگروه تقسیم می‌شوند. برخلاف عملیات استاندارد در یک کار دسته‌ای، با هر زیرگروه حاوی عملیات فیلتر گروه فهرست‌بندی به صورت اتمی رفتار می‌شود.

نحوه تقسیم کارهای دسته‌ای حاوی فیلترهای گروه فهرست به زیردسته‌ها توسط عوامل زیر تعیین می‌شود:

  1. نوع فیلتر گروه آگهی
  2. گروه AdGroup یا AssetGroup فیلتر گروه فهرست‌بندی هدف قرار می‌دهد
  3. ترتیب عملیات

نحوه گروه بندی عملیات را در نظر بگیرید:

  • تمام عملیات متوالی AssetGroupListingGroupFilterOperation ( create ، update و remove ) که AssetGroup یکسانی را هدف قرار می‌دهند، در یک زیرگروه اتمی (بدون رفتار خرابی جزئی) گروه‌بندی می‌شوند.
  • تمام عملیات متوالی AdGroupCriterionOperation ( create ، update و remove ) برای معیارهای LISTING_GROUP ( AdGroupCriterion.listing_group ) که AdGroup یکسانی را هدف قرار می‌دهند، در یک زیرگروه اتمی (بدون رفتار خرابی جزئی) گروه‌بندی می‌شوند.
  • تمام عملیات متوالی دیگر در زیرگروه‌های غیر اتمی (رفتار خرابی جزئی) گروه‌بندی می‌شوند.

نمودار زیر این مفهوم را نشان می‌دهد. هر یک از کادرهای خاکستری نشان‌دهنده یک کار دسته‌ای است که با استفاده از API گوگل ادز ارسال می‌شود. در داخل کادرهای خاکستری، عملیات‌های جداگانه بر اساس رنگ گروه‌بندی شده‌اند تا زیردسته‌هایی را که سرور 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 :

این خطاها نشان می‌دهند که عملیات در آن شاخص به دلیل شکست عملیات دیگری در همان زیرگروه اتمی، به حالت قبل برگشته است. برای شناسایی علت اصلی مشکل، پیام‌های status در هر BatchJobResult - قبل و بعد از operation_index خطای تراکنش - را برای عملیاتی که شناسه AdGroup یا AssetGroup یکسانی دارند، بررسی کنید.