Protected Audience API की नीलामी में लगने वाले समय को कम करें

यह पक्का करना सभी के लिए फ़ायदेमंद है कि Protected Audience API बेहतर तरीके से काम करे:

• वेब ब्राउज़ करने वाले लोग चाहते हैं कि साइटें तेज़ी से लोड हों. इसका मतलब है कि डेवलपर को Protected Audience API का इस्तेमाल ज़रूरत के हिसाब से करना चाहिए, ताकि डिवाइस के सीमित रिसॉर्स का ज़्यादा इस्तेमाल न हो. जैसे, कंप्यूट या नेटवर्क रिसॉर्स, जो साइटों और उनमें एम्बेड किए गए विज्ञापनों को लोड करने के लिए ज़रूरी हैं.
• पब्लिशर चाहते हैं कि उनकी साइटें तेज़ी से लोड हों, ताकि उपयोगकर्ताओं को बेहतर और रिस्पॉन्सिव अनुभव मिल सके. पब्लिशर भी अपने रेवेन्यू को बढ़ाने के लिए, असरदार विज्ञापन दिखाना चाहते हैं.
• विज्ञापन देने वाले और विज्ञापन टेक्नोलॉजी कंपनियां, अपने विज्ञापनों को तेज़ी से दिखाना चाहती हैं, ताकि उपयोगकर्ताओं को बेहतर अनुभव मिल सके.

इस दस्तावेज़ में, Protected Audience API को लागू करने के कुछ सबसे सही तरीके बताए गए हैं. इससे यह पक्का किया जा सकता है कि आपकी साइट बेहतर तरीके से काम करे.

खरीदार (बिडर) के लिए सबसे सही तरीके

यह पक्का करने के लिए कि आपने Protected Audience API की नीलामी की परफ़ॉर्मेंस को ऑप्टिमाइज़ किया है, ये सबसे सही तरीके अपनाएं.

एक जैसी दिलचस्पी वाले ग्रुप के कम मालिक

ब्राउज़र, साइट अलगाव का इस्तेमाल करके, वेब पर अलग-अलग ऑरिजिन को सुरक्षित रखता है. इसी तरह, ब्राउज़र Protected Audience API बिडर को भी सुरक्षित रखता है. इसके लिए, ब्राउज़र अलग-अलग इंटरेस्ट ग्रुप के मालिकों को सुरक्षित रखने के लिए, महंगे संसाधनों (जैसे, ऑपरेटिंग सिस्टम प्रोसेस) का इस्तेमाल करता है.

इन बहुत महंगे संसाधनों पर होने वाले खर्च को कम करने के लिए, ज़रूरी है कि आपके पास कम से कम इंटरेस्ट ग्रुप के मालिक हों. अलग-अलग दिलचस्पी वाले ग्रुप के लिए, अलग-अलग सबडोमेन का इस्तेमाल न करें. उदाहरण के लिए, अगर adtech.example के पास cats.adtech.example और dogs.adtech.example के मालिकाना हक वाले इंटरेस्ट ग्रुप हैं, तो ब्राउज़र अपनी बिडिंग स्क्रिप्ट चलाने के लिए, दो अलग-अलग प्रोसेस का इस्तेमाल करेगा.

कम दिलचस्पी वाले ग्रुप बिडिंग कर रहे हैं

ब्राउज़र को खरीदार की generateBid() स्क्रिप्ट को शुरू करने से पहले, ज़रूरी सेटअप और तैयारी करनी होगी. जैसे, एक नया क्लीन JavaScript एक्सीक्यूशन एनवायरमेंट सेट अप करना, generateBid() कोड को पार्स और लोड करना.

• दिलचस्पी के ऐसे ग्रुप जिनमें ऐसे उपयोगकर्ता शामिल हैं जो किसी चालू विज्ञापन कैंपेन के मौजूदा टारगेट नहीं हैं, उनकी विज्ञापन क्रिएटिव सूचियां खाली होनी चाहिए. इससे, Protected Audience API को काम के विज्ञापनों के बिना, इंटरेस्ट ग्रुप के लिए generateBid() को लागू करने से रोका जाता है.
• मिलती-जुलती दिलचस्पी वाले ग्रुप को एक साथ जोड़ने से, generateBid() को चलाने की संख्या कम हो जाएगी. किसी दिलचस्पी के ग्रुप की userBiddingSignals प्रॉपर्टी का इस्तेमाल, उपयोगकर्ता के बारे में ज़्यादा मेटाडेटा सेव करने के लिए किया जा सकता है. इसलिए, दिलचस्पी के कम ग्रुप का मतलब यह नहीं है कि टारगेटिंग कम असरदार होगी.
• Protected Audience API, इंटरेस्ट ग्रुप की संख्या पर सेलर की तय की गई सीमाओं के साथ काम करता है. साथ ही, यह खरीदारों के लिए एक एपीआई है, ताकि वे अपने इंटरेस्ट ग्रुप की प्राथमिकता तय कर सकें. इन सीमाओं का इस्तेमाल, बिडिंग स्क्रिप्ट की संख्या को काफ़ी कम करने के लिए किया जा सकता है.

अपनी की-वैल्यू सेवा में बिडिंग से, दिलचस्पी के ग्रुप को फ़िल्टर करना

अगर कोई खरीदार, रीयल-टाइम भरोसेमंद बिडिंग सिग्नल सर्वर में यह तय कर सकता है कि कुछ इंटरेस्ट ग्रुप को बिड नहीं करनी चाहिए (उदाहरण के लिए, कैंपेन बंद है, रोका गया है या बजट से बाहर है या इस पब्लिशर पर बिड नहीं करनी चाहिए), तो वह priorityVector भरोसेमंद बिडिंग सिग्नल फ़ेच करने के जवाब के साथ ब्राउज़र को यह बता सकता है. अगर priorityVector और prioritySignals के स्पैर्स डॉट प्रॉडक्ट का नतीजा नेगेटिव है, तो ब्राउज़र इस दिलचस्पी के ग्रुप के लिए generateBid() को लागू नहीं करेगा. इस तरीके के बारे में ज़्यादा जानने के लिए, एक्सप्लेनर के"दिलचस्पी के ग्रुप को फ़िल्टर करना और उन्हें प्राथमिकता देना" सेक्शन में जाएं.

JavaScript एक्ज़ीक्यूशन एनवायरमेंट का फिर से इस्तेमाल करना

ब्राउज़र generateBid() को लागू करने से पहले, उसे JavaScript को लागू करने के लिए एक नया एनवायरमेंट शुरू करना होगा. इसमें काफ़ी समय लग सकता है. यह समय, generateBid() को लागू करने में लगने वाले समय के बराबर हो सकता है. ऑरिजिन के हिसाब से ग्रुप करने या फ़्रीज़ किए गए कॉन्टेक्स्ट वाले एक्सीक्यूशन मोड का इस्तेमाल करके, इस समय को बचाया जा सकता है.

group-by-origin मोड, ऐसे मामलों में एक्सीक्यूशन एनवायरमेंट का फिर से इस्तेमाल कर सकता है जहां इंटरेस्ट ग्रुप एक ही ऑरिजिन से जुड़े होते हैं. साथ ही, ऐसा हो सकता है कि आपको अपनी बिडिंग स्क्रिप्ट में बदलाव करने की ज़रूरत न पड़े. ज़्यादा जानने के लिए, एक्सप्लेनर में group-by-origin के बारे में जानकारी देखें. फ़्रीज़ किए गए कॉन्टेक्स्ट मोड में, सभी एक्सीक्यूशन एनवायरमेंट का फिर से इस्तेमाल किया जा सकता है. हालांकि, इसके लिए आपकी बिडिंग स्क्रिप्ट में बदलाव करने पड़ सकते हैं. ज़्यादा जानने के लिए, एक्सप्लेनर में frozen-context ब्यौरा देखें.

बिडिंग स्क्रिप्ट का फिर से इस्तेमाल करना

अगर हो सके, तो इंटरेस्ट ग्रुप के लिए एक ही बिडिंग स्क्रिप्ट का इस्तेमाल करें. इससे ब्राउज़र को कई स्क्रिप्ट डाउनलोड, पार्स, और कंपाइल करने की ज़रूरत नहीं पड़ती. ऐसा करने पर, नेटवर्क के लिए ज़्यादा अनुरोध भेजने पड़ते हैं. बिडिंग करने वाले लोग या कंपनियां, अब भी एक ही स्क्रिप्ट का इस्तेमाल करते हुए, इंटरेस्ट ग्रुप की जानकारी (जैसे, name या userBiddingSignals) के आधार पर बिडिंग में अंतर कर सकती हैं.

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

ध्यान दें कि ब्राउज़र, बिडिंग के समय (generateBid() के लिए) और रिपोर्टिंग के समय (reportWin() के लिए) बिडिंग स्क्रिप्ट लोड करता है. अगर कैश मेमोरी कंट्रोल हेडर सेट नहीं हैं, तो ब्राउज़र एक ही स्क्रिप्ट को दो बार फ़ेच करेगा. हर समयावधि के लिए एक बार.

इसलिए, हमारा सुझाव है कि आप अपनी सभी स्क्रिप्ट पर कैश कंट्रोल हेडर सेट करें.

trustedBiddingSignalsUrls का फिर से इस्तेमाल करना

नेटवर्क के इंतज़ार का समय और संसाधनों का इस्तेमाल बहुत ज़्यादा हो सकता है. रीयल-टाइम में कम भरोसेमंद बिडिंग सिग्नल फ़ेच करने से, इस इंतज़ार को कम किया जा सकता है.

जब trustedBiddingSignalsUrl को कई दिलचस्पी वाले ग्रुप में फिर से इस्तेमाल किया जाता है, तो भरोसेमंद बिडिंग सिग्नल फ़ेच को जोड़ा जा सकता है. अगर हो सके, तो सभी इंटरेस्ट ग्रुप के लिए एक ही trustedBiddingSignalsUrl का इस्तेमाल करें.

सही एचटीटीपी कैश कंट्रोल हेडर तय करें, ताकि यह पक्का किया जा सके कि किसी वेब पेज पर मौजूद सभी विज्ञापन स्लॉट में, भरोसेमंद बिडिंग सिग्नल फ़ेच कैश मेमोरी में सेव हो जाएं. trustedBiddingSignalsSlotSizeMode को slot-size पर सेट करने से बचें. ऐसा करने पर, विज्ञापन स्लॉट के साइज़ अलग-अलग होने पर, सभी विज्ञापन स्लॉट में कैश मेमोरी में सेव नहीं किया जा सकेगा. ऐसा इसलिए होगा, क्योंकि अनुरोध किया गया यूआरएल अलग-अलग होगा.

रीयल-टाइम में भरोसेमंद बिडिंग सिग्नल फ़ेच करने की सुविधा

नेटवर्क के इंतज़ार का समय बहुत ज़्यादा हो सकता है. इस पर, रीयल-टाइम भरोसेमंद बिडिंग सिग्नल फ़ेच करने के दौरान, कितना डेटा ट्रांसफ़र किया जाता है, इसका सीधा असर पड़ता है.

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

जो सिग्नल हर दिन या उससे ज़्यादा समय पर अपडेट किए जा सकते हैं उन्हें दिलचस्पी के ग्रुप में सेव किया जाना चाहिए. साथ ही, हर दिन के अपडेट का इस्तेमाल करके उन्हें अपडेट किया जाना चाहिए.

"अपनी कुंजी/वैल्यू सेवा में बिडिंग से दिलचस्पी के ग्रुप को फ़िल्टर करें" सेक्शन में बताए गए तरीके से फ़िल्टर किए गए दिलचस्पी के ग्रुप के लिए, भरोसेमंद बिडिंग सिग्नल न दिखाएं.

एक जैसी दिलचस्पी वाले ग्रुप को प्राथमिकता देना

सेलर, टाइम आउट का इस्तेमाल करके यह तय करेंगे कि पब्लिशर पेजों पर ब्राउज़र के संसाधनों का इस्तेमाल कैसे किया जाए. जब perBuyerCumulativeTimeouts का इस्तेमाल यह तय करने के लिए किया जाता है कि खरीदारों को अपने भरोसेमंद बिडिंग सिग्नल फ़ेच करने और बिडिंग स्क्रिप्ट को लागू करने में कितना समय लगेगा, तो खरीदारों के लिए यह पक्का करना ज़रूरी है कि वे अपनी दिलचस्पी के ग्रुप को प्राथमिकता दें, ताकि नीलामी जीतने की सबसे ज़्यादा संभावना वाले ग्रुप पहले लागू हों. उदाहरण के लिए, अगर perBuyerCumulativeTimeouts को 100 मि॰से॰ पर सेट किया गया है और बिडर के भरोसेमंद बिडिंग सिग्नल को फ़ेच करने में 50 मि॰से॰ लगते हैं, हर generateBid() को कॉल करने में 10 मि॰से॰ लगते हैं, और उनके पास किसी डिवाइस पर 10 इंटरेस्ट ग्रुप मौजूद हैं, तो उनके सिर्फ़ आधे इंटरेस्ट ग्रुप के पास बिड का हिसाब लगाने का मौका होगा. इस उदाहरण में, खरीदार को अपने इंट्रेस्ट ग्रुप को प्राथमिकता देनी चाहिए. इसमें, सबसे ज़्यादा संभावना वाले ग्रुप को सबसे पहले और सबसे कम संभावना वाले ग्रुप को सबसे आखिर में रखा जाना चाहिए.

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

ध्यान दें कि जब ब्राउज़र, सबसे ज़्यादा प्राथमिकता से लेकर सबसे कम प्राथमिकता तक के इंटरेस्ट ग्रुप को लागू करता है, तो हो सकता है कि अलग-अलग ऑरिजिन से जुड़े इंटरेस्ट ग्रुप आपस में मिल जाएं. इससे group-by-origin ऑप्टिमाइज़ेशन पर असर पड़ सकता है.

सेलर के लिए सबसे सही तरीके

पक्का करें कि आप Protected Audience API की नीलामी की परफ़ॉर्मेंस को मॉनिटर और ऑप्टिमाइज़ कर रहे हों.

नीलामियों को एक साथ चलाना

आधुनिक नेटवर्क कनेक्शन और मल्टी-कोर प्रोसेसर, एक साथ कई गतिविधियां करने में बेहतरीन तरीके से काम करते हैं. ब्राउज़र, अन्य गतिविधियों के साथ-साथ Protected Audience नीलामी को भी चला सकता है. इस समस्या को हल करने के लिए, runAdAuction() पर जल्द से जल्द कॉल करें. हो सकता है कि runAdAuction() के लिए कुछ इनपुट पहले से उपलब्ध न हों. उदाहरण के लिए, वे इनपुट जो संदर्भ के हिसाब से दिए गए जवाब में ब्राउज़र को वापस भेजे जाते हैं. इसलिए, ब्राउज़र इनपुट उपलब्ध होने से पहले ही runAdAution() को कॉल करने की अनुमति देता है. साथ ही, JavaScript Promises का इस्तेमाल करके इन इनपुट को बाद में उपलब्ध कराता है. नीलामी में लगने वाले समय को कम से कम करने के लिए, interestGroupBuyers इनपुट के पता चलने पर runAdAuction() को कॉल किया जाना चाहिए. इससे ऑक्शन के कई हिस्से तुरंत शुरू हो जाते हैं. इनमें बिड लगाने वाले के रीयल-टाइम बिडिंग सिग्नल फ़ेच करना भी शामिल है.

अपनी नीलामियों पर नज़र रखना

अपनी नीलामियों की मेट्रिक इकट्ठा करें. ब्राउज़र, सेलर को इंटरनेट कनेक्शन के इंतज़ार का समय बताने वाली मेट्रिक per-buyer की रिपोर्ट दे सकता है. इससे सेलर को यह जानकारी मिलती है कि नीलामी में कितना समय बीतता है. सेलर इन मेट्रिक का इस्तेमाल करके, अपनी नीलामियों को ऑप्टिमाइज़ करने के तरीके खोज सकते हैं. इनमें, टाइम आउट सेट करने के सबसे असरदार तरीके के बारे में जानकारी भी शामिल है. सेलर, किसी खरीदार के इंतज़ार का समय दिखाने वाली मेट्रिक को खरीदार के साथ शेयर कर सकते हैं, ताकि वह उसे ऑप्टिमाइज़ कर सके.

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

धीमी बिडिंग स्क्रिप्ट से सुरक्षा

बिडिंग स्क्रिप्ट में ज़्यादा समय लगने पर, Protected Audience API की नीलामी में हिस्सा लेने वाले सभी लोगों के लिए नीलामी धीमी हो सकती है. टाइम आउट का इस्तेमाल करके, नीलामी में लगने वाले समय को कम किया जा सकता है. साथ ही, नीलामी में लगने वाले समय के दौरान भी आय हासिल की जा सकती है.

नीलामी में देरी होने से रोकने के लिए, सेलर को perBuyerCumulativeTimeouts का इस्तेमाल करना चाहिए. साथ ही, नीलामी में देरी होने और टाइम आउट होने पर भी बिड स्वीकार करने के लिए, सेलर को perBuyerCumulativeTimeouts का इस्तेमाल करना चाहिए. perBuyerTimeouts और perBuyerGroupLimits के बजाय, perBuyerCumulativeTimeouts का इस्तेमाल करना बेहतर होता है.इसकी वजह यह है कि perBuyerCumulativeTimeouts, इंटरेस्ट ग्रुप की संख्या या generateBid() की स्पीड के बारे में कोई राय नहीं देता. उदाहरण के लिए, ज़्यादा बिड करने वाले कई इंटरेस्ट ग्रुप और कम बिड करने वाले कुछ इंटरेस्ट ग्रुप, टाइम आउट से पहले ही बिडिंग पूरी कर सकते हैं.

नीलामी के लिए कुल टाइम आउट लागू करने के लिए, नीलामी कॉन्फ़िगरेशन signal फ़ील्ड का इस्तेमाल करना भी एक अच्छा तरीका है. इससे उन मामलों में नीलामियों को बहुत लंबा होने से रोका जा सकता है जहां भरोसेमंद स्कोरिंग सिग्नल को फ़ेच करने और scoreAd() को लागू करने में बहुत ज़्यादा समय लगता है.

अहम जानकारी: नीलामी के समय के बारे में जानकारी - लोग अक्सर पूछते हैं कि "सुरक्षित ऑडियंस की नीलामी में कितना समय लगता है?", "सेलर को टाइम आउट किस पर सेट करना चाहिए?" या "खरीदार को किस लेटेंसी के लिए ऑप्टिमाइज़ करना चाहिए?". इन सवालों के जवाब इस बात पर निर्भर करते हैं कि ऑक्शन के नतीजे के लिए, लोग किस चीज़ को ऑप्टिमाइज़ कर रहे हैं. सेलर, वेबसाइट पर विज्ञापन दिखाकर होने वाली आय को बढ़ाना चाहते हैं. ऐसे में, उन्हें रेवेन्यू बढ़ाने वाली सेटिंग ढूंढने के लिए, अलग-अलग टाइम आउट आज़माने चाहिए. डेस्कटॉप और मोबाइल के लिए अलग-अलग टाइम आउट सेट करना फ़ायदेमंद हो सकता है. समय के साथ, सुरक्षित ऑडियंस के इस्तेमाल में बदलाव हो सकता है. ऐसा इसलिए, क्योंकि इसका इस्तेमाल बढ़ रहा है, नीलामी में हिस्सा लेने वाले लोग अपने लॉजिक को ऑप्टिमाइज़ कर रहे हैं या कंप्यूटर बेहतर हो रहे हैं. इसलिए, प्रयोग जारी रखना फ़ायदेमंद हो सकता है. अगर खरीदार ज़्यादा से ज़्यादा नीलामियों में जीतने के लिए ऑप्टिमाइज़ कर रहे हैं, तो उन्हें अपने भरोसेमंद बिडिंग सिग्नल के इंतज़ार का समय और generateBid() के इंतज़ार का समय मॉनिटर और ऑप्टिमाइज़ करना चाहिए. साथ ही, अपने इंटरेस्ट ग्रुप को प्राथमिकता देनी चाहिए, ताकि जब सेलर सख्त टाइम आउट सेट करें, तो वे सबसे पहले अपनी सबसे अच्छी बिड जनरेट कर सकें.

आगे क्या करना है?

हम आपके साथ मिलकर ऐसा एपीआई बनाना चाहते हैं जो सभी के काम आ सके.

एपीआई पर चर्चा करें

दूसरे प्राइवसी सैंडबॉक्स एपीआई की तरह, इस एपीआई को भी दस्तावेज़ के तौर पर दिखाया जाता है और सार्वजनिक तौर पर इस पर चर्चा की जाती है.

एपीआई के साथ प्रयोग करें

Protected Audience API के बारे में बातचीत में, एक्सपेरिमेंट किया जा सकता है और इसमें हिस्सा लिया जा सकता है.