कोटा ऑप्टिमाइज़ेशन

Display & Video 360 API का इस्तेमाल करने वाले किसी भी ऐप्लिकेशन के लिए, कोटा ऑप्टिमाइज़ेशन ज़रूरी है. कोटा के इस्तेमाल को ऑप्टिमाइज़ करने से परफ़ॉर्मेंस बेहतर होती है. इसके लिए, एपीआई अनुरोधों को व्यवस्थित किया जाता है. साथ ही, तय की गई दर की सीमा पार करने पर होने वाली गड़बड़ियों से बचने में मदद मिलती है.

इस पेज पर, सबसे सही तरीकों की जानकारी दी गई है. साथ ही, Display & Video 360 API में कुछ ऐसी सहायक सुविधाओं को भी हाइलाइट किया गया है जो आपके कोटा के इस्तेमाल को कम करने में मदद कर सकती हैं.

अलग-अलग विज्ञापन देने वालों से एक साथ अनुरोध करना

Display & Video 360 API के ज़्यादातर तरीकों से, यूआरएल में विज्ञापन देने वाले की जानकारी मिलती है. प्रोजेक्ट-वाइड कोटा के अलावा, एक ही विज्ञापन देने वाले के बारे में कॉल करने पर इन तरीकों के लिए, "हर प्रोजेक्ट के लिए हर प्रोजेक्ट के हिसाब से" दर की ज़्यादा सीमित सीमाएं लागू की जाती हैं.

इस कोटा के लिए ऑप्टिमाइज़ करने के लिए, एक साथ किए जाने वाले अनुरोधों को सिर्फ़ अलग-अलग विज्ञापन देने वालों को सीमित करें.

filter और orderBy पैरामीटर का इस्तेमाल करें

एक से ज़्यादा संसाधन वापस पाने के लिए, get तरीकों के बजाय list तरीकों का इस्तेमाल करें. हालांकि, पेज के साइज़ की सीमाओं की वजह से, list कॉल अब भी बहुत ज़्यादा कोटा इस्तेमाल कर सकते हैं. अगर आपको पूरी सूची के जवाब का सिर्फ़ एक सबसेट पाना है, तो वैकल्पिक filter और orderBy पैरामीटर का इस्तेमाल करके, कोटा के इस्तेमाल को ऑप्टिमाइज़ किया जा सकता है.

filter पैरामीटर की मदद से, list कॉल से मिले रिसॉर्स को उन लोगों तक सीमित किया जा सकता है जिनकी प्रॉपर्टी दिए गए एक्सप्रेशन के मुताबिक होती हैं. यह पैरामीटर फिर से पाने की कोशिश करते समय काम आता है:

  • यह ऐसा संसाधन है जिसमें मौजूद आईडी की जानकारी नहीं है, लेकिन प्रॉपर्टी के बारे में जानकारी है. किसी खास संसाधन को खोजने पर, आपको उस संसाधन की प्रॉपर्टी की जानकारी के आधार पर सूची को फ़िल्टर करने की सुविधा मिलती है. उदाहरण के लिए, इनमें किसी जाने-माने displayName के हिसाब से लाइन आइटम, अनुमानित creativeType के हिसाब से क्रिएटिव, और exchange के हिसाब से इन्वेंट्री के सोर्स के हिसाब से फ़िल्टर करने की सुविधा शामिल है.
  • इसी विषय से जुड़े लिंक. Display & Video 360 में मौजूद संसाधन अक्सर एक-दूसरे से जुड़े होते हैं. फ़िल्टर का इस्तेमाल करके, लौटाए गए रिसॉर्स को उन संसाधनों तक सीमित किया जा सकता है जिनका किसी दूसरे यूआरएल के साथ खास संबंध है. उदाहरण के लिए, किसी खास campaignId और लाइन आइटम को असाइन किए गए सभी क्रिएटिव के नीचे मौजूद सभी शामिल करने के ऑर्डर वापस पाना.
  • सिर्फ़ ऐसे संसाधन जिनमें कार्रवाई करने वाली प्रॉपर्टी हैं. एपीआई के काम करने के तरीके से, आपको संसाधनों की स्थिति आसानी से देखने और प्रोग्राम के हिसाब से कार्रवाई करने में मदद मिलती है. फ़िल्टर का इस्तेमाल करके, list कॉल का इस्तेमाल सिर्फ़ ऐसे संसाधन पाने के लिए किया जा सकता है जहां किसी कार्रवाई की ज़रूरत होती है. उदाहरण के लिए, इनमें ऐसे सभी लाइन आइटम को फिर से शामिल करना शामिल है जो कार्रवाई करने लायक lineItemWarningMessage दिखाते हैं, सभी शामिल करने के ऑर्डर जिन्हें दिए गए तारीख और समय के बाद अपडेट किया गया है या ऐसे सभी क्रिएटिव को फिर से लाना जो कार्रवाई नहीं कर सके approvalStatus.

orderBy पैरामीटर की मदद से, वापस लाए गए संसाधनों को खास प्रॉपर्टी के हिसाब से, बढ़ते या घटते क्रम में लगाया जा सकता है. orderBy का इस्तेमाल, खास तौर पर जब filter के साथ किया जाता है, तो इसका इस्तेमाल ऐसे पेजों की संख्या को सीमित करने के लिए किया जा सकता है जिन्हें किसी खास संसाधन को ढूंढने से पहले, अलग से देखना होता है. इससे आपको संसाधन सूची की ऊपरी और निचली सीमाएं आसानी से हासिल करने में भी मदद मिलती है. उदाहरण के लिए, updateTime से ऑर्डर करके, विज्ञापन देने वाले के सबसे हाल ही में अपडेट किए गए लाइन आइटम या इंसर्शन ऑर्डर को तुरंत ढूंढा जा सकता है.

बल्क और संसाधन-वाइड फ़ंक्शन का इस्तेमाल करना

Display & Video 360 API में कई सारे फ़ंक्शन एक साथ कई काम करने की सुविधा देते हैं. इनकी मदद से, एक ही अनुरोध पर कई कार्रवाइयां की जा सकती हैं. इस तरह के फ़ंक्शन के उदाहरण में शामिल हैं:

  • एक ही चैनल से जुड़ी साइटों में एक साथ कई बदलाव करना. चैनलों को हज़ारों साइटें असाइन की जा सकती हैं. अलग-अलग create या delete अनुरोधों वाले चैनल की साइट सूची को मैनेज करने के बजाय, कई साइटों को जोड़ने और हटाने या पूरे कॉन्टेंट को बदलने के लिए, एक bulkEdit या replace अनुरोध का इस्तेमाल किया जा सकता है.
  • विज्ञापन देने वाले के पूरे टारगेटिंग सुइट को मैनेज करना. संसाधन के टारगेटिंग सुइट को कई तरह की टारगेटिंग में असाइन किया जाता है. advertisers की सेवा में मौजूद रिसॉर्स-लेवल टारगेटिंग फ़ंक्शन, जैसे कि listAssignedTargetingOptions और editAssignedTargetingOptions की मदद से, एक ही अनुरोध में अलग-अलग तरह की टारगेटिंग को वापस लाया जा सकता है, बनाया जा सकता है, और हटाया जा सकता है. इससे, विज्ञापन देने वाले के टारगेटिंग सुइट को एक ही अनुरोध पर सेट करने का कोटा खर्च कम हो जाता है.
  • एक से ज़्यादा लाइन आइटम में, टारगेटिंग की एक जैसी पाबंदी सेट करना. अगर आपको कई लाइन आइटम में एक ही तरह की टारगेटिंग से एक साथ बदलाव करने हैं, तो एक ही advertisers.lineItems.bulkEditAssignedTargetingOptions अनुरोध का इस्तेमाल करके ऐसा किया जा सकता है.
  • एक से ज़्यादा लाइन आइटम चालू करना या रोकना. लाइन आइटम बनाए जाने के बाद, उन्हें दिखाना शुरू करने से पहले ऐक्टिवेट किया जाना चाहिए. अगर एक के बाद एक कई लाइन आइटम बनाए जा रहे हैं, तो उन सभी को एक ही advertisers.lineItems.bulkUpdate अनुरोध से चालू किया जा सकता है. एक ही तरीके का इस्तेमाल, एक से ज़्यादा लाइन आइटम को दिखने से रोकने के लिए किया जा सकता है.

नियमित तौर पर इस्तेमाल किए जाने वाले आईडी को कैश मेमोरी में सेव करें और उनकी जांच करें

Display & Video 360 API की कई कार्रवाइयों के लिए, ऐसे संसाधन आईडी का इस्तेमाल करना ज़रूरी होता है जो एपीआई से ही फिर से पाए जाते हैं. इनमें टारगेटिंग विकल्प आईडी, Google ऑडियंस आईडी वगैरह शामिल हैं. हर बार इस्तेमाल करने पर एपीआई के आईडी को वापस पाने से बचने के लिए, हमारा सुझाव है कि आप इन आईडी को स्थानीय तौर पर सेव करें.

हालांकि, कुछ संसाधनों को रोका जा सकता है, मिटाया जा सकता है या किसी और तरीके से इस्तेमाल के लिए उपलब्ध नहीं कराया जा सकता. इन संसाधनों के लिए आईडी का इस्तेमाल करने की कोशिश करने पर गड़बड़ी दिख सकती है. इसलिए, हमारा सुझाव है कि आप कैश मेमोरी में सेव किए गए सभी आईडी की हर हफ़्ते जांच करें. इसके लिए, सही get या फ़िल्टर किए गए list तरीके का इस्तेमाल करें, ताकि यह पक्का किया जा सके कि उन्हें अब भी वापस पाया जा सकता है और उनकी स्थिति उम्मीद के मुताबिक है.

लंबे समय तक चलने वाली कार्रवाइयों के लिए, एक्सपोनेन्शियल बैकऑफ़ लागू करें

अगर आपको यह पता लगाना है कि लंबे समय से चल रही कार्रवाई, जैसे कि एसडीएफ़ डाउनलोड टास्क पूरी हुई है या नहीं, तो भेजे गए अनुरोधों की फ़्रीक्वेंसी और कुल संख्या को कम करने के लिए, एक्सपोनेन्शियल बैकऑफ़ रणनीति का इस्तेमाल करें.

एक्सपोनेंशियल बैकऑफ़, नेटवर्क ऐप्लिकेशन के लिए गड़बड़ी को मैनेज करने की स्टैंडर्ड रणनीति है. इसमें क्लाइंट, समय-समय पर बढ़ते हुए अनुरोध करता रहता है. सही तरीके से इस्तेमाल किए जाने पर, एक्सपोनेन्शियल बैकऑफ़, बैंडविथ के इस्तेमाल को बेहतर बनाता है. साथ ही, एक सफल रिस्पॉन्स पाने के लिए ज़रूरी अनुरोधों की संख्या कम करता है और एक साथ चलने वाले एनवायरमेंट में अनुरोधों की क्षमता बढ़ाता है.

क्लाइंट लाइब्रेरी की मदद से लागू की गई एक्सपोनेन्शियल बैकऑफ़ रणनीति जानने के लिए, एसडीएफ़ डाउनलोड कोड के उदाहरण देखें. सामान्य एक्सपोनेन्शियल बैकऑफ़ लागू करने के लिए सिलसिलेवार निर्देश इस तरह से हैं:

  • एपीआई को sdfdownloadtasks.operations.get अनुरोध भेजें.
  • ऑपरेशन ऑब्जेक्ट वापस पाएं.
    • अगर done फ़ील्ड सही नहीं है, तो इसका मतलब है कि आपको फिर से अनुरोध करना चाहिए.
    • 5 सेकंड + मिलीसेकंड की किसी भी संख्या तक इंतज़ार करें और फिर से अनुरोध करने की कोशिश करें.
  • ऑपरेशन ऑब्जेक्ट वापस पाएं.
    • अगर done फ़ील्ड सही नहीं है, तो इसका मतलब है कि आपको फिर से अनुरोध करना चाहिए.
    • 10 सेकंड + मिलीसेकंड की किसी भी संख्या तक इंतज़ार करें और फिर से अनुरोध करने की कोशिश करें.
  • ऑपरेशन ऑब्जेक्ट वापस पाएं.
    • अगर done फ़ील्ड सही नहीं है, तो इसका मतलब है कि आपको फिर से अनुरोध करना चाहिए.
    • 20 सेकंड और मिलीसेकंड की एक तय संख्या तक इंतज़ार करें और फिर से अनुरोध करने की कोशिश करें.
  • ऑपरेशन ऑब्जेक्ट वापस पाएं.
    • अगर done फ़ील्ड सही नहीं है, तो इसका मतलब है कि आपको फिर से अनुरोध करना चाहिए.
    • 40 सेकंड और मिलीसेकंड की एक तय संख्या तक इंतज़ार करें और फिर से अनुरोध करने की कोशिश करें.
  • ऑपरेशन ऑब्जेक्ट वापस पाएं.
    • अगर done फ़ील्ड सही नहीं है, तो इसका मतलब है कि आपको फिर से अनुरोध करना चाहिए.
    • 80 सेकंड + मिलीसेकंड की किसी भी संख्या तक इंतज़ार करें और फिर से अनुरोध करने की कोशिश करें.
  • इस पैटर्न को तब तक जारी रखें, जब तक क्वेरी ऑब्जेक्ट अपडेट न हो जाए या तय सीमा तक न पहुंच जाए.