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 सेकंड + मिलीसेकंड की किसी भी संख्या तक इंतज़ार करें और फिर से अनुरोध करने की कोशिश करें.
- अगर
- इस पैटर्न को तब तक जारी रखें, जब तक क्वेरी ऑब्जेक्ट अपडेट न हो जाए या तय सीमा तक न पहुंच जाए.