यह सभी के लिए फ़ायदेमंद है कि 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 प्रॉमिस का इस्तेमाल करके इन इनपुट को बाद में उपलब्ध कराने की अनुमति देता है. नीलामी में कम से कम देरी हो, इसके लिए interestGroupBuyers इनपुट की जानकारी मिलने पर runAdAuction() को कॉल किया जाना चाहिए. इससे नीलामी के कई हिस्सों को तुरंत शुरू किया जा सकता है. इनमें बिडर के रीयल-टाइम बिडिंग सिग्नल फ़ेच करना भी शामिल है.
नीलामियों पर नज़र रखना
अपनी नीलामी से जुड़ी मेट्रिक इकट्ठा करें. ब्राउज़र, सेलर को लेटेंसी मेट्रिक की per-buyer रिपोर्ट दे सकता है. इससे सेलर को यह अहम जानकारी मिलती है कि उनकी नीलामी में कितना समय लगता है. सेलर इन मेट्रिक का इस्तेमाल करके, अपनी नीलामियों को ऑप्टिमाइज़ करने के तरीके ढूंढ सकते हैं. इनमें, टाइमआउट सेट करने के सबसे असरदार तरीके के बारे में जानकारी देना भी शामिल है. सेलर, खरीदार के साथ खरीदार की लेटेन्सी मेट्रिक शेयर कर सकते हैं, ताकि खरीदार को बेहतर तरीके से ऑप्टिमाइज़ करने में मदद मिल सके.
बिडर को, दिलचस्पी के हिसाब से बनाए गए अपने ग्रुप की बिडिंग परफ़ॉर्मेंस के बारे में अहम जानकारी मिल सकती है. हालांकि, वे इसकी तुलना दूसरे बिडर से नहीं कर सकते. अलग-अलग बिडर के लिए, बिड जीतने की तुलनात्मक दर और बिड अस्वीकार होने की दर की तुलना करने से, उन मामलों की पहचान करने में मदद मिल सकती है जहां बिडिंग के कंप्यूट संसाधनों को बर्बाद किया गया था. ऐसा इसलिए हुआ, क्योंकि दिलचस्पी वाले ग्रुप ने कभी भी काम की बिड नहीं लगाई या बिना मंज़ूरी वाले क्रिएटिव के साथ बहुत ज़्यादा बिडिंग की.
बिड स्क्रिप्ट के धीमे चलने से सुरक्षा
बिडिंग स्क्रिप्ट को पूरा होने में ज़्यादा समय लगने पर, Protected Audience API की नीलामी में शामिल सभी लोगों के लिए, नीलामी की प्रोसेस धीमी हो सकती है. टाइमआउट का इस्तेमाल करके, धीमी नीलामी को रोका जा सकता है. साथ ही, नीलामी धीमी होने पर भी रेवेन्यू वापस पाया जा सकता है.
नीलामी में देरी से बचने के लिए, सेलर को perBuyerCumulativeTimeouts का इस्तेमाल करना चाहिए. साथ ही, नीलामी में देरी होने और टाइम आउट होने पर भी बिड स्वीकार करनी चाहिए. perBuyerTimeouts और perBuyerGroupLimits के बजाय perBuyerCumulativeTimeouts का इस्तेमाल करना बेहतर है.इसकी वजह यह है कि perBuyerCumulativeTimeouts, दिलचस्पी वाले ग्रुप की संख्या या generateBid() की स्पीड के बारे में कोई राय नहीं देता है. उदाहरण के लिए, कई दिलचस्पी वाले ग्रुप जो तेज़ी से बिड करते हैं और कुछ दिलचस्पी वाले ग्रुप जो धीरे-धीरे बिड करते हैं, दोनों टाइम आउट से पहले बिड पूरी कर सकते हैं.
नीलामी के कॉन्फ़िगरेशन signal फ़ील्ड का इस्तेमाल करके, नीलामी के लिए कुल समयसीमा लागू करना भी एक अच्छा तरीका है. इससे उन मामलों में ज़्यादा समय तक चलने वाली नीलामी को रोका जा सकता है जहां भरोसेमंद स्कोरिंग सिग्नल फ़ेच करने और scoreAd() को लागू करने में बहुत ज़्यादा समय लगता है.
आगे क्या करना है?
हम आपके साथ मिलकर ऐसा एपीआई बनाना चाहते हैं जो सभी के काम आ सके.
एपीआई पर चर्चा करें
दूसरे प्राइवसी सैंडबॉक्स एपीआई की तरह, इस एपीआई को भी दस्तावेज़ के तौर पर दिखाया जाता है और सार्वजनिक तौर पर इस पर चर्चा की जाती है.
एपीआई के साथ प्रयोग करें
Protected Audience API के बारे में बातचीत में, एक्सपेरिमेंट किया जा सकता है और इसमें हिस्सा लिया जा सकता है.