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) के आधार पर बिडिंग में अब भी अंतर कर सकते हैं.

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

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

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

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

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

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

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

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

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

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

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

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

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

विक्रेता के लिए सबसे सही तरीके

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

नीलामियों को साथ-साथ लोड करना

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

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

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

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

धीमी बोली स्क्रिप्ट से सुरक्षित रहें

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

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

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

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

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

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

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

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

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

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