बैच जॉब में लिस्टिंग ग्रुप फ़िल्टर का इस्तेमाल करना

AdGroupCriterion.listing_group या AssetGroupListingGroupFilter के संदर्भ में लिस्टिंग ग्रुप फ़िल्टर का इस्तेमाल करते समय, इंटिग्रेशन डिज़ाइन करते समय इन बातों का ध्यान रखें.

बैच को बांटना

अगर किसी बैच जॉब में ऐसे ऑपरेशन हैं जिनमें विज्ञापन ग्रुप के मानदंड या ऐसेट ग्रुप की लिस्टिंग ग्रुप के फ़िल्टर शामिल हैं, तो Google Ads API सर्वर से मिलने पर बैच जॉब के ऑपरेशन को कई सब-बैच में बांट दिया जाता है. बैच जॉब में स्टैंडर्ड कार्रवाइयों के उलट, लिस्टिंग ग्रुप फ़िल्टर करने की कार्रवाइयों वाले हर सब-बैच को एटॉमिक तरीके से प्रोसेस किया जाता है.

लिस्टिंग ग्रुप फ़िल्टर वाले बैच जॉब को सब-बैच में बांटने का तरीका इन बातों से तय होता है:

  1. लिस्टिंग ग्रुप फ़िल्टर का टाइप
  2. AdGroup या AssetGroup लिस्टिंग ग्रुप फ़िल्टर, टारगेट कर रहा है
  3. कार्रवाइयों का क्रम

देखें कि ऑपरेशंस को कैसे ग्रुप किया गया है:

  • एक ही AssetGroup को टारगेट करने वाले सभी लगातार AssetGroupListingGroupFilterOperation ऑपरेशन (create, update, और remove) को एक साथ एक ऐटॉमिक सब-बैच में ग्रुप किया जाता है. इसमें कुछ ऑपरेशन के फ़ेल होने की स्थिति नहीं होती.
  • एक ही AdGroup को टारगेट करने वाले LISTING_GROUP शर्तों (AdGroupCriterion.listing_group) के लिए, लगातार होने वाले सभी AdGroupCriterionOperation ऑपरेशन (create, update, और remove) को एक एटॉमिक सब-बैच में ग्रुप किया जाता है. इसमें, कुछ ऑपरेशन के फ़ेल होने की समस्या नहीं होती.
  • इसके बाद की सभी कार्रवाइयों को नॉन-ऐटॉमिक सब-बैच में एक साथ ग्रुप किया जाता है. इनमें कुछ कार्रवाइयां पूरी नहीं हो पाती हैं.

इस डायग्राम में इस कॉन्सेप्ट के बारे में बताया गया है. हर ग्रे बॉक्स, Google Ads API का इस्तेमाल करके सबमिट किए गए बैच जॉब को दिखाता है. ग्रे बॉक्स में, अलग-अलग कार्रवाइयों को रंग के हिसाब से ग्रुप किया जाता है. इससे उन सब-बैच के बारे में पता चलता है जिन्हें Google Ads API सर्वर बनाता है. हर ग्रे बॉक्स में मौजूद कार्रवाइयों का क्रम, बैच जॉब में कार्रवाइयों को जोड़ने के क्रम से मेल खाता है.

एक साथ कई कार्रवाइयों को सब-बैच में ग्रुप करके दिखाने वाला डायग्राम

सीमाएं

बैच जॉब के संदर्भ में लिस्टिंग ग्रुप फ़िल्टर का इस्तेमाल करते समय, ये सीमाएं लागू होती हैं:

  • एक ही AdGroup को टारगेट करने वाले LISTING_GROUP मानदंड (AdGroupCriterion.listing_group) के लिए, लगातार AdGroupCriterionOperation कार्रवाइयों (create, update, और remove) के एक एटॉमिक सब-बैच में 20,000 से ज़्यादा कार्रवाइयां नहीं हो सकतीं. हालांकि, हमारा सुझाव है कि 10,000 से ज़्यादा ऑपरेशन न करें. हर AddBatchJobOperationsRequest में ज़्यादा से ज़्यादा 10,000 कार्रवाइयां की जा सकती हैं. इसलिए, 10,001 से 20,000 कार्रवाइयों वाले AdGroup सब-बैच को कम से कम दो लगातार AddBatchJobOperations अनुरोधों में अपलोड करना होगा.
  • एक ही AssetGroup को टारगेट करने वाले, लगातार AssetGroupListingGroupFilterOperation कार्रवाइयों (create, update, और remove) के एक एटॉमिक सब-बैच में 10,000 से ज़्यादा कार्रवाइयां नहीं हो सकतीं.
  • इनमें से किसी भी सीमा का उल्लंघन करने पर, उस सब-बैच के लिए बैच जॉब बंद हो जाता है. इसके अलावा, अगर किसी सब-बैच के लिए सर्वर के इंटरनल सीरियलाइज़्ड बाइट साइज़ की सीमा से ज़्यादा डेटा भेजा जाता है, तो भी बैच जॉब बंद हो जाता है. हालांकि, पहले से पूरे हो चुके सब-बैच के लिए, बैच जॉब जारी रहता है. साथ ही, उल्लंघन करने वाले सब-बैच और उसके बाद के सभी सब-बैच के लिए, बैच जॉब बंद हो जाता है. ऐसा होने पर, InternalError.INTERNAL_ERROR गड़बड़ी दिखती है.

समस्या का हल

बैच जॉब में लिस्टिंग ग्रुप फ़िल्टर करने की कार्रवाइयों को एक लेन-देन के तौर पर प्रोसेस किया जाता है. इससे ऐसी स्थितियां पैदा हो सकती हैं जहां कुछ गलत कार्रवाइयों की वजह से, कई कार्रवाइयां पूरी नहीं हो पाती हैं. इसके अलावा, BatchJob कार्रवाइयों को प्रोसेस करने के तरीके की वजह से, गड़बड़ियों की मूल वजह, डाउनस्ट्रीम गड़बड़ियों से पहले या बाद में किसी इंडेक्स पर दिख सकती है.

उदाहरण के लिए, ListBatchJobResults से मिले जवाब को प्रोसेस करते समय:

इन गड़बड़ियों से पता चलता है कि उस इंडेक्स पर मौजूद ऑपरेशन को पहले जैसा कर दिया गया है. ऐसा इसलिए हुआ, क्योंकि एक ही ऐटॉमिक सब-बैच में मौजूद कोई दूसरा ऑपरेशन पूरा नहीं हो सका. समस्या की असल वजह का पता लगाने के लिए, हर BatchJobResult में मौजूद status मैसेज को फिर से करें. ऐसा ट्रांजै़क्शन की गड़बड़ी के operation_index से पहले और बाद में, एक ही AdGroup या AssetGroup आईडी शेयर करने वाले ऑपरेशनों के लिए करें.