इस पेज का अनुवाद Cloud Translation API से किया गया है.

Protected Audience API (पहले इसे FLEDGE कहा जाता था)

Chrome ने Privacy Sandbox के तहत, Protected Audience API का सुझाव दिया है. यह ब्राउज़र में काम करने वाला एक एपीआई है. इसकी मदद से, विज्ञापन देने वाले लोग या कंपनियां और विज्ञापन टेक्नोलॉजी कंपनियां, तीसरे पक्ष की कुकी पर निर्भर हुए बिना, दिलचस्पी के हिसाब से टारगेट किए गए विज्ञापन दिखा सकती हैं. साथ ही, उपयोगकर्ताओं को क्रॉस-साइट ट्रैकिंग से सुरक्षित रख सकती हैं.

Chrome, Protected Audience API के लिए ऑरिजिन ट्रायल चला रहा है. अनुमति वाले खरीदार, Ad Manager पब्लिशर इन्वेंट्री पर Protected Audience API की टेस्टिंग में हिस्सा ले सकते हैं. Protected Audience API की टेस्टिंग करके, बिडर ये काम कर सकते हैं:

Protected Audience API के फ़्लो को बेहतर बनाएं और उनकी परफ़ॉर्मेंस के बारे में जानें.
सार्वजनिक फ़ोरम में, एपीआई को बेहतर बनाने के बारे में सुझाव/राय दें या शिकायत करें. उदाहरण के लिए, GitHub.
तीसरे पक्ष की कुकी पर भरोसा किए बिना, एपीआई के ज़रिए लोगों की दिलचस्पी के हिसाब से विज्ञापन दिखाने की सुविधा के लिए तैयारी करें.

अगर Authorized Buyers को इस सुविधा को आज़माना है, तो वे शामिल होने से जुड़ी जानकारी वाले सेक्शन में जाकर ज़्यादा जानकारी पा सकते हैं.

ध्यान दें: जब Protected Audience API (इसका पुराना नाम FLEDGE था) Chrome में सभी के लिए उपलब्ध हो जाएगा, तब Ad Manager धीरे-धीरे टेस्टिंग में शामिल ट्रैफ़िक की मात्रा को बढ़ाना शुरू कर देगा. हम ट्रैफ़िक का प्रतिशत धीरे-धीरे बढ़ाएंगे. साथ ही, पब्लिशर के रेवेन्यू पर पड़ने वाले असर पर नज़र रखेंगे. अगर रेवेन्यू पर कोई बुरा असर पड़ता है, तो हम ट्रैफ़िक का प्रतिशत और नहीं बढ़ाएंगे. हमारा मानना है कि साल 2023 के आखिर तक, Chrome के 10% तक ट्रैफ़िक के लिए Protected Audience API की टेस्टिंग की सुविधा चालू हो जाएगी.

विज्ञापन दिखाने के फ़्लो की खास जानकारी

यहां Authorized Buyers के पार्टनर के लिए, Protected Audience की मदद से विज्ञापन दिखाने के फ़्लो की खास जानकारी दी गई है:

फ़्लो डायग्राम

बिडिंग की सुविधा देने वाली कंपनी, विज्ञापन देने वाले लोगों या कंपनियों के साथ मिलकर काम करती है, ताकि हर विज्ञापन देने वाले व्यक्ति या कंपनी के लिए दिलचस्पी वाले ग्रुप बनाए जा सकें. विज्ञापन देने वाले लोग या कंपनियां, अक्सर विज्ञापन देने वाले व्यक्ति या कंपनी के पेज पर बिडर का टैग जोड़ती हैं, ताकि ब्राउज़र को दिलचस्पी वाले ग्रुप में जोड़ा जा सके.
कोई उपयोगकर्ता, विज्ञापन देने वाले व्यक्ति या कंपनी के पेज पर जाता है. पेज पर बिडर का टैग मौजूद हो सकता है.
बिडर का टैग, Protected Audience API joinAdInterestGroup() को चालू करता है. यह कॉल, ब्राउज़र से उपयोगकर्ता को किसी इंटरेस्ट ग्रुप में जोड़ने का अनुरोध करता है.
असली उपयोगकर्ता, पब्लिशर के वेबपेज पर जाता है. उपयोगकर्ता का ब्राउज़र, Google के पब्लिशर विज्ञापन टैग का अनुरोध करता है.
Google का पब्लिशर विज्ञापन टैग, Google सर्वर को कॉन्टेक्स्ट के हिसाब से विज्ञापन का अनुरोध भेजता है.
Google, बिडिंग में हिस्सा लेने वाले लोगों या कंपनियों को कॉन्टेक्स्ट के हिसाब से बिड अनुरोध भेजता है. ज़्यादा जानकारी के लिए, बिड अनुरोध में किए गए बदलावों का सेक्शन देखें.
बिडर, बिड रिस्पॉन्स में InterestGroupBidding message दिखाता है. यह मैसेज, दिलचस्पी के हिसाब से बनाए गए ग्रुप की नीलामी में हिस्सा लेने के लिए ज़रूरी होता है. OpenRTB में इसे BidResponse.ext.igbid फ़ील्ड के साथ तय किया जाता है. साथ ही, Google आरटीबी प्रोटोकॉल के पुराने वर्शन में इसे BidResponse.interest_group_bidding फ़ील्ड के साथ तय किया जाता है. अगर बिडर यह जानकारी नहीं देता है, तो Google, बिडर के ओरिजन को interestGroupBuyers में शामिल नहीं करता है. ऐसा नीलामी के कॉन्फ़िगरेशन में होता है. InterestGroupBidding में खरीदार के हिसाब से तय किए गए ऐसे सिग्नल भी शामिल हो सकते हैं जो ब्राउज़र में होने वाली नीलामी के दौरान, बिडर के बिडिंग फ़ंक्शन को भेजे जाएंगे. OpenRTB में इसे BidResponse.ext.igbid.igbuyer.buyerdata फ़ील्ड की मदद से तय किया जाता है. साथ ही, Google RTB प्रोटोकॉल के पुराने वर्शन में इसे BidResponse.interest_group_bidding.interest_group_buyers.per_buyer_signals फ़ील्ड की मदद से तय किया जाता है. ज़्यादा जानकारी के लिए, बिड रिस्पॉन्स में हुए बदलावों का सेक्शन देखें.
Google, सर्वर-साइड ऑक्शन चलाता है और ब्राउज़र को बिड रिस्पॉन्स भेजता है. सर्वर-साइड नीलामी में, सर्वर-साइड की पारंपरिक बिड को ध्यान में रखा जाता है. बिड रिस्पॉन्स में, कॉन्टेक्स्ट के हिसाब से सबसे ज़्यादा बिड (अगर कोई हो) के बारे में जानकारी हो सकती है.
बिड रिस्पॉन्स में, ब्राउज़र में होने वाली नीलामी के लिए नीलामी कॉन्फ़िगरेशन शामिल होता है. इसमें, नीलामी में हिस्सा लेने वाले हर खरीदार से मिले कॉन्टेक्स्ट के हिसाब से सिग्नल शामिल हो सकते हैं. ये सिग्नल, OpenRTB के buyerdata या बंद हो चुके Google RTB प्रोटोकॉल के per_buyer_signals के ज़रिए भेजे जाते थे. इसमें, कॉन्टेक्स्ट के हिसाब से सबसे ज़्यादा स्कोर पाने वाले विज्ञापन की जानकारी और बिड के लिए ज़रूरी शर्तें भी शामिल होती हैं.
Google का पब्लिशर टैग, Protected Audience API runAdAuction() को चालू करता है, ताकि डिवाइस पर इंटरेस्ट ग्रुप के आधार पर विज्ञापन दिखाने के लिए नीलामी शुरू की जा सके. Google सिर्फ़ उन खरीदारों को शामिल करता है जिन्हें नीलामी कॉन्फ़िगरेशन के दौरान InterestGroupBidding में InterestGroupBuyer के तौर पर शामिल किया गया था.
Google, ज़रूरी शर्तें पूरी करने वाले हर बिडर के खरीदार से जुड़े वैकल्पिक सिग्नल, Protected Audience की नीलामी के कॉन्फ़िगरेशन को भेजता है.
अगर किसी बिडर के इंटरेस्ट ग्रुप में trustedBiddingSignalsUrl के बारे में बताया गया है, तो ब्राउज़र हर ग्रुप के trustedBiddingSignalsUrl से अनुरोध करता है, ताकि हर ग्रुप के लिए रीयल-टाइम सिग्नल फ़ेच किए जा सकें. ज़्यादा जानकारी के लिए, Protected Audience API की खास जानकारी देखें.
ब्राउज़र, बिडर के generateBid() को हर उस इंटरेस्ट ग्रुप के लिए शुरू करता है जिसने ऑप्ट-इन किया है और जो ब्राउज़र में होने वाली नीलामी में हिस्सा लेने की ज़रूरी शर्तें पूरी करता है. इस चरण में, बिड का हिसाब लगाया जाता है और क्रिएटिव चुना जाता है. generateBid() के पास, बिडर के दिए गए वैकल्पिक खरीदार सिग्नल और दिलचस्पी वाले दिए गए ग्रुप के लिए, भरोसेमंद बिडिंग सिग्नल का ऐक्सेस होता है.
ब्राउज़र, सेलर (इस मामले में, Google) के scoreAd() को कॉल करता है, ताकि इंटरेस्ट ग्रुप के विज्ञापन की नीलामी में हर बिड को रैंक असाइन की जा सके. बिड को पब्लिशर की सुरक्षा, विज्ञापन से जुड़ी नीतियों, और अन्य पाबंदियों के आधार पर रैंक किया जाता है और फ़िल्टर किया जाता है.
ब्राउज़र, ज़रूरी शर्तें पूरी करने वाले इंटरेस्ट ग्रुप की बिड के साथ नीलामी करता है. सबसे ज़्यादा रैंक वाली कॉन्टेक्स्ट के हिसाब से लगाई गई बिड, ब्राउज़र में होने वाली नीलामी में हिस्सा लेती है.
नीलामी के बाद, अगर कोई इंटरेस्ट ग्रुप जीत जाता है, तो ब्राउज़र सेलर के reportResult() और बिडर के reportWin() को कॉल करता है. इससे हर पार्टी को ब्राउज़र में होने वाली नीलामी के विजेता के बारे में सूचना मिलती है.
अगर दिलचस्पी के हिसाब से विज्ञापन दिखाने वाला कोई विज्ञापन जीत जाता है, तो Google का पब्लिशर टैग, विज्ञापन को iframe में रेंडर करता है.

विज्ञापन दिखाने के फ़्लो की जानकारी

विज्ञापन दिखाने से पहले

क्रिएटिव की समीक्षा

क्रिएटिव की समीक्षा की जानी चाहिए और उन्हें Google से मंज़ूरी मिलनी चाहिए. इसके बाद ही, उन्हें Protected Audience की इन-ब्राउज़र नीलामी में दिखाया जा सकता है. क्रिएटिव की समीक्षा के लिए, उन्हें रीयल-टाइम बिडिंग एपीआई या क्रिएटिव की अपने-आप स्कैनिंग होने की सुविधा के ज़रिए सबमिट किया जा सकता है. ब्राउज़र में मौजूद Protected Audience के इन-ब्राउज़र इंटरेस्ट ग्रुप की विज्ञापन नीलामी के लिए क्रिएटिव में, समीक्षा के लिए renderUrls शामिल होना चाहिए.

renderUrls के लिए ज़रूरी शर्तें:

एपीआई के ज़रिए सबमिट किया गया renderUrl, दिलचस्पी वाले ग्रुप के विज्ञापन की नीलामी में इस्तेमाल किए गए renderUrl से मेल खाना चाहिए.
हर renderUrl सिर्फ़ विज्ञापन देने वाले एक व्यक्ति या कंपनी या विज्ञापन कैंपेन को दिखा सकता है. किसी renderUrl का इस्तेमाल, विज्ञापन देने वाले कई लोगों या कंपनियों की ओर से विज्ञापन दिखाने के लिए नहीं किया जा सकता. हर renderUrl को एक क्रिएटिव से मैप किया जाना चाहिए.
renderUrl को Google के ऑफ़लाइन क्रिएटिव की समीक्षा करने वाले सिस्टम के लिए ऐक्सेस किया जा सकता है. साथ ही, विज्ञापन पर आखिरी बार बोली लगाने के बाद सात दिनों तक इसे फ़ेच किया जा सकता है.

Real-time Bidding API

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

क्रिएटिव की अपने-आप स्कैनिंग

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

क्रिएटिव की अपने-आप स्कैनिंग की सुविधा सेट अप करने पर, Google ब्राउज़र में होने वाली नीलामी में क्रिएटिव ढूंढता है और उन्हें अपने-आप स्कैन करता है. इससे वे आने वाली नीलामियों के लिए ज़रूरी शर्तें पूरी कर पाते हैं.

ऑटोमैटिक क्रिएटिव स्कैनिंग की सुविधा चालू करने का तरीका यहां बताया गया है:

दिलचस्पी के हिसाब से बनाए गए ग्रुप के सभी क्रिएटिव के renderUrl ऑरिजिन को Authorized Buyer खाते में जोड़ें.

क्रिएटिव के एचटीटीपी रिस्पॉन्स में, यहां दिए गए कस्टम एचटीटीपी हेडर जोड़ें:

Authorized-Buyers-Creative-ID

स्ट्रिंग

खरीदार के हिसाब से क्रिएटिव आईडी. क्रिएटिव आईडी की ज़्यादा से ज़्यादा लंबाई 128 बाइट होती है.

Authorized-Buyers-Click-Through-URLs

स्ट्रिंग

क्रिएटिव के लिए, RFC2396 के मुताबिक कोड में बदले गए डेस्टिनेशन यूआरएल का सेट.

उदाहरण:

HTTP/1.1 200 OK
Date: Mon, 8 Jan 2022 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Mon, 8 Jan 2022 12:01:53 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed
Authorized-Buyers-Creative-ID:123456
Authorized-Buyers-Click-Through-URLs:https://www.advertiser.com/clickUrl1,https://www.advertiser.com/clickUrl12

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

क्रिएटिव की समयसीमा खत्म होने की तारीख

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

खरीदार का रिपोर्टिंग आईडी

रिपोर्टिंग मेट्रिक (जैसे, इंप्रेशन) को, खरीदार की ओर से उपलब्ध कराए गए डाइमेंशन के हिसाब से बांटा जा सकता है. उदाहरण के लिए, कैंपेन आईडी या विज्ञापन देने वाले व्यक्ति या कंपनी का आईडी. दिलचस्पी के हिसाब से बनाए गए ग्रुप पर खर्च के लिए डाइमेंशन जोड़ने के लिए, उपयोगकर्ता के डिवाइस को दिलचस्पी के हिसाब से बनाए गए ग्रुप में जोड़ते समय, अपने विज्ञापन के लिए buyerAndSellerReportingId तय करें. ज़्यादा जानकारी के लिए, Protected Audience के दस्तावेज़ देखें.

यहां दिए गए उदाहरण में, दिलचस्पी वाले ग्रुप के कॉन्फ़िगरेशन में buyerAndSellerReportingId जोड़ने का तरीका बताया गया है:

const myGroup = {
  ...
  'ads': [
    {
      ...
      'buyerAndSellerReportingId':
        '{"google_signals": {"buyer_reporting_id": "12345"}}',
      ...
    }
  ]
}
joinAdInterestGroup(myGroup);

buyer_reporting_id, Authorized Buyer के Reporting Tool में एक नए डाइमेंशन के तौर पर दिखेगा. इसे खरीदार का रिपोर्टिंग आईडी डाइमेंशन के तौर पर दिखाया जाएगा.

सर्वर-साइड ऑक्शन

बिड अनुरोध में बदलाव

एक्सपेरिमेंट में इस्तेमाल किए जा सकने वाले प्रोटोकॉल के शुरुआती वर्शन यहां दिए गए हैं:

OpenRTB अर्ली लिंक
Google आरटीबी प्रोटोकॉल (अब काम नहीं करता) अर्ली लिंक

दिलचस्पी के मुताबिक ग्रुप को टारगेट करने की सुविधा के लिए नीलामी से जुड़ी सहायता के बारे में जानकारी दें

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

OpenRTB:
- BidRequest.imp.ext.ae
- BidRequest.imp.ext.igbid
Google आरटीबी प्रोटोकॉल (अब इस्तेमाल नहीं किया जाता):
- BidRequest.adslot.supported_auction_environment
- BidRequest.adslot.interest_group_bidding_allowed

इस फ़ील्ड का इस्तेमाल करके, उन इंप्रेशन ऑपर्च्यूनिटी के बीच अंतर किया जा सकता है जो ब्राउज़र में Protected Audience की इंटरेस्ट ग्रुप नीलामी के साथ काम करती हैं. साथ ही, उन इंप्रेशन ऑपर्च्यूनिटी के बीच अंतर किया जा सकता है जो सिर्फ़ सर्वर-साइड एक्सचेंज की पारंपरिक नीलामी के साथ काम करती हैं. AuctionEnvironment enum में ये वैल्यू हो सकती हैं:

SERVER_SIDE_AUCTION (OpenRTB JSON: 0): सबसे ज़्यादा बिड वाले विज्ञापन का फ़ैसला करने वाली नीलामी, एक्सचेंज के सर्वर पर होती है.
ON_DEVICE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 1): Protected Audience की सुविधा के साथ अनुरोध किए जाते हैं. इनमें कॉन्टेक्स्ट के हिसाब से नीलामी, एक्सचेंज के सर्वर पर होती है. साथ ही, इंटरेस्ट ग्रुप के आधार पर बिडिंग और फ़ाइनल नीलामी, ब्राउज़र में होती है.
SERVER_SIDE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 3): कॉन्टेक्स्ट के हिसाब से होने वाली नीलामी, एक्सचेंज के सर्वर पर होती है. साथ ही, दिलचस्पी के ग्रुप की बिड के लिए बिडिंग लॉजिक और सबसे ज़्यादा स्कोर वाले विज्ञापन का पता लगाने के लिए स्कोरिंग लॉजिक, बिडिंग और नीलामी वाले सर्वर में चलता है.

Protected Audience API के विज्ञापन स्लॉट का साइज़ बताना

बिड अनुरोध में ये फ़ील्ड शामिल होते हैं, ताकि आपको Protected Audience के विज्ञापन स्लॉट का साइज़ मिल सके:

OpenRTB:
- BidRequest.imp.ext.interest_group_auction.width
- BidRequest.imp.ext.interest_group_auction.height
Google आरटीबी प्रोटोकॉल (अब इस्तेमाल नहीं किया जाता):
- BidRequest.adslot.interest_group_auction.width
- BidRequest.adslot.interest_group_auction.height

इन फ़ील्ड से, Protected Audience ऑक्शन के लिए विज्ञापन स्लॉट के साइज़ के बारे में पता चलता है. यह साइज़ पिक्सल में होता है.

यह साइज़, कॉन्टेक्स्ट के हिसाब से किए गए अनुरोध में मौजूद साइज़ से अलग हो सकता है. जैसे, OpenRTB के BidRequest.imp.banner.format.w और BidRequest.imp.banner.format.h फ़ील्ड या बंद किए जा चुके Google आरटीबी प्रोटोकॉल के BidRequest.adslot.width और BidRequest.adslot.height फ़ील्ड में दिखने वाले साइज़.

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

Protected Audience की मदद से दिखाए जाने वाले विज्ञापन को रेंडर करने की सुविधा के बारे में जानकारी देना

Protected Audience API के विज्ञापन, इंटिग्रेशन के मौजूदा चरण के आधार पर रेंडर हो सकते हैं या नहीं भी हो सकते हैं. इसके बारे में जानने के लिए, रेंडर न होने वाला एक्सपेरिमेंट देखें. बिड अनुरोध पर मौजूद render_interest_group_ads फ़ील्ड से पता चलता है कि Protected Audience की मदद से दिखाया जाने वाला विज्ञापन रेंडर होगा या नहीं.

OpenRTB: BidRequest.imp.ext.interest_group_auction.render_interest_group_ads
Google आरटीबी प्रोटोकॉल (अब इस्तेमाल नहीं किया जाता): BidRequest.adslot.interest_group_auction.render_interest_group_ads

उपयोगकर्ता आइडेंटिफ़ायर पर कम से कम निर्भर रहना

Protected Audience API की टेस्टिंग के दायरे में आने वाले कॉन्टेक्स्ट के हिसाब से बिड के अनुरोधों में, कुकी पर आधारित पारंपरिक आइडेंटिफ़ायर का इस्तेमाल जारी रखा जा सकता है. ऐसा तब किया जा सकता है, जब ये आइडेंटिफ़ायर ब्राउज़र से उपलब्ध हों. जैसे, BidRequest.user.id और BidRequest.user.buyerid फ़ील्ड या Google RTB प्रोटोकॉल में बंद किए गए BidRequest.google_user_id और BidRequest.hosted_match_data. बिड अनुरोधों में ऐसे आइडेंटिफ़ायर मौजूद होने पर, मौजूदा निजता नीतियां लागू होती हैं. हमारा सुझाव है कि टेस्टिंग के दौरान, टारगेटिंग और बिडिंग के लिए कुकी पर आधारित आइडेंटिफ़ायर का इस्तेमाल न करें. इससे, तीसरे पक्ष की कुकी उपलब्ध न होने पर, बेहतर तरीके से खरीदारी करने की तैयारी की जा सकेगी.

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

Chrome की मदद से तीसरे पक्ष की कुकी का इस्तेमाल बंद होने की टेस्टिंग

साल 2024 में, तीसरे पक्ष की कुकी का इस्तेमाल बंद हो जाएगा (3PCD). इसके लिए, Chrome अब Chrome की मदद से होने वाली टेस्टिंग की सुविधा उपलब्ध कराता है.

साइटें और वेंडर, Chrome की मदद से टेस्टिंग की सुविधा का इस्तेमाल करके, 3PCD के तहत अपने सिस्टम की जांच कर सकते हैं. इस टेस्ट में, Chrome ब्राउज़र को 3PCD एक्सपेरिमेंट ग्रुप में असाइन किया जाता है. यह ग्रुप, मोड A या मोड B में से कोई एक होता है. हर ब्राउज़र को एक जैसा लेबल असाइन किया जाता है. यह लेबल, 3PCD के किसी खास एक्सपेरिमेंट ग्रुप से जुड़ा होता है. इसे ब्राउज़र में मौजूद Chrome API के ज़रिए ऐक्सेस किया जा सकता है.

Google, Chrome API से मिले लेबल को आरटीबी बिड अनुरोध में बिना बदलाव किए पास करता है. किसी लेबल के ट्रैफ़िक स्लाइस छोटे होने की वजह से, Google हमेशा निजता से जुड़े सीमित कॉन्टेक्स्ट में लेबल को शामिल नहीं करता है.

यहां दिए गए फ़ील्ड में लेबल देखा जा सकता है:

OpenRTB: BidRequest.device.ext.cdep
Google आरटीबी प्रोटोकॉल (अब इस्तेमाल नहीं किया जाता): BidRequest.device.cookie_deprecation_label

बिड रिस्पॉन्स में हुए बदलाव

इससे, दिलचस्पी के हिसाब से बनाए गए ग्रुप की नीलामी में हिस्सा लेने की जानकारी मिलती है

आपको ब्राउज़र में होने वाली नीलामी में हिस्सा लेने के अपने इरादे के बारे में साफ़ तौर पर बताना होगा. इसके लिए, कॉन्टेक्स्ट के हिसाब से बिड रिस्पॉन्स में InterestGroupBidding ऑब्जेक्ट को वापस भेजें:

OpenRTB: BidResponse.ext.igbid
Google आरटीबी प्रोटोकॉल (अब इस्तेमाल नहीं किया जाता): BidResponse.interest_group_bidding

आपको कॉन्टेक्स्ट के हिसाब से बिड रिस्पॉन्स देना होगा. जवाब में, कॉन्टेक्स्ट के हिसाब से बोली शामिल करना ज़रूरी नहीं है. InterestGroupBidding ऑब्जेक्ट में, हर InterestGroupBuyer के लिए origin होना चाहिए. यह बिडर के खाते के लिए कॉन्फ़िगर किए गए किसी एक ऑरिजिन से मेल खाना चाहिए. Google पब्लिशर टैग, runAdAuction() को कॉल करता है, तब origin को नीलामी कॉन्फ़िगरेशन के interestGroupBuyers में जोड़ दिया जाता है.

खरीदार के कॉन्टेक्स्ट के हिसाब से सिग्नल भेजना

कॉन्टेक्स्ट के हिसाब से बिड के रिस्पॉन्स में, खरीदार के सिग्नल शामिल किए जा सकते हैं. Google, perBuyerSignals आर्ग्युमेंट के ज़रिए, इन सिग्नल को डिवाइस पर बिडिंग करने की सुविधा के लिए JSON ऑब्जेक्ट के तौर पर भेजता है. इसे बिड रिस्पॉन्स में शामिल किया जा सकता है. इसके लिए, प्रोटोकॉल के हिसाब से यहाँ दिए गए फ़ील्ड इस्तेमाल किए जा सकते हैं:

OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
Google RTB (अब काम नहीं करता): BidResponse.interest_group_bidding.per_buyer_signals

खरीदार के कॉन्टेक्स्ट के हिसाब से रेंडरिंग के सिग्नल को आगे बढ़ाना

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

आपके पास, कॉन्टेक्स्ट के हिसाब से बिड के रिस्पॉन्स में खरीदार के रेंडरिंग सिग्नल शामिल करने का विकल्प होता है. इन्हें यूआरएल के लिए सुरक्षित स्ट्रिंग के तौर पर क्रम से लगाया जाता है. Google, जीतने वाले इंटरेस्ट ग्रुप के रेंडर यूआरएल में इन्हें बदल देगा. इसके लिए, वह ${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]} मैक्रो बनाएगा.

प्रोटोकॉल के आधार पर, बिड रिस्पॉन्स में रेंडरिंग सिग्नल के बारे में यहाँ दिए गए फ़ील्ड की मदद से बताया जा सकता है:

OpenRTB: BidResponse.ext.igbid.igbuyer.rsig
Google RTB (अब काम नहीं करता): BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals

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

अगर सिग्नल, यूआरएल के लिए सुरक्षित नहीं हैं, मैक्रो सफ़िक्स यूनीक नहीं हैं या सिग्नल के तीन से ज़्यादा सेट दिए गए हैं, तो दिलचस्पी के हिसाब से खरीदार को Protected Audience ऑक्शन में हिस्सा लेने से रोक दिया जाएगा.

ब्राउज़र में दिखने वाले विज्ञापन के लिए, बिडिंग की ज़्यादा से ज़्यादा कीमत तय करना

Protected Audience API के प्रस्ताव में, बिड का हिसाब लगाने और नीलामी को आखिर तक ले जाने की प्रोसेस, उपयोगकर्ता के डिवाइस पर ही पूरी की जाएगी. इससे, गलत इस्तेमाल के संभावित तरीके बन सकते हैं. इनसे नीलामी के फ़ाइनल नतीजों की इंटिग्रिटी पर असर पड़ सकता है. जैसे, जीतने वाली बिड की कीमत.

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

बिड रिस्पॉन्स में, यहां दिए गए फ़ील्ड में बिड की ज़्यादा से ज़्यादा वैल्यू तय की जा सकती है:

OpenRTB: BidResponse.igbid.igbuyer.maxbid(CPM की मुद्रा इकाइयों में दिखाया गया है)
Google आरटीबी प्रोटोकॉल (समर्थित नहीं है या समर्थन रोक दिया गया है): BidResponse.interest_group_bidding.interest_group_buyers.max_bid_cpm_micros (माइक्रो सीपीएम में दिखाया गया है)

एक से ज़्यादा खातों को इंप्रेशन एट्रिब्यूट करना

बिडर को बिलिंग आईडी चुनना होगा, ताकि वह इन फ़ील्ड का इस्तेमाल करके, दिलचस्पी के हिसाब से बनाए गए ग्रुप के लिए लगाई गई बिड के इंप्रेशन एट्रिब्यूट कर सके:

OpenRTB: BidResponse.igbid.igbuyer.billing_id
Google आरटीबी प्रोटोकॉल (अब इस्तेमाल नहीं किया जाता): BidResponse.interest_group_bidding.interest_group_buyers.billing_id

चुना गया बिलिंग आईडी, बिड अनुरोध में शामिल ज़रूरी शर्तें पूरी करने वाला बिलिंग आईडी होना चाहिए:

OpenRTB: BidRequest.imp.ext.billing_id
Google आरटीबी प्रोटोकॉल (अब इस्तेमाल नहीं किया जाता): BidRequest.adslot.matching_ad_data.billing_id

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

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

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

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

ब्राउज़र में होने वाली नीलामी के दौरान

ब्राउज़र में बिड जनरेट करना

ब्राउज़र में बिड जनरेट करने के लिए, generateBid() का इस्तेमाल करें.

Google ये पैरामीटर उपलब्ध कराता है:

auctionSignals: खाली है
perBuyerSignals: यह JavaScript ऑब्जेक्ट, बिडर की ओर से कॉन्टेक्स्ट के हिसाब से दिए गए जवाब में शामिल सिग्नल जैसा ही होता है

ये पैरामीटर दिखाए जाते हैं:

ad: Google इस फ़ील्ड को अनदेखा करता है.
bid: यह एक संख्यात्मक बिड होती है, जो नीलामी में शामिल होती है. यह सीपीएम यूनिट में होना चाहिए, न कि माइक्रो में.
render: अगर बिड, नीलामी जीत जाती है, तो क्रिएटिव दिखाने के लिए रेंडर किया गया यूआरएल. Google को इस यूआरएल की समीक्षा करनी होगी और इसे मंज़ूरी देनी होगी. ऐसा न होने पर, इसे नीलामी से हटा दिया जाएगा.
allowComponentAuction: true होना चाहिए. फ़िलहाल, Google मल्टी-सेलर ऑक्शन की टेस्टिंग की सुविधा देता है.

यहां एक उदाहरण दिया गया है:

function generateBid(...) {
  ...
  return {'ad': 'example',
          'bid': ad.metadata.bid,
          'render': ad.renderUrl,
          'allowComponentAuction': true};
}

generateBid() फ़ंक्शन के बारे में जानने के लिए, Protected Audience स्पेसिफ़िकेशन का डिवाइस पर बिडिंग सेक्शन देखें.

बिड की मुद्रा

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

बिड की मुद्रा को कॉन्टेक्स्ट के हिसाब से बिड के रिस्पॉन्स और generateBid की रिटर्न वैल्यू, दोनों में बताया जाना चाहिए. साथ ही, यह एक मान्य ISO 4217 ऐल्फ़ा कोड होना चाहिए. जैसे, "USD", "EUR" या "JPY".

OpenRTB में, Google के बिड रिस्पॉन्स एक्सटेंशन में मौजूद InterestGroupBuyer ऑब्जेक्ट में नया cur फ़ील्ड इस्तेमाल करें.

यहां एक उदाहरण दिया गया है:

ext {
  igbid {
    impid: "1"
    igbuyer {
      origin: "https://examplebuyerorigin.com"
      cur: "EUR"
    }
  }
}

Google RTB प्रोटोकॉल में, बिड रिस्पॉन्स में InterestGroupBuyer मैसेज में मौजूद नए currency फ़ील्ड का इस्तेमाल करें.

यहां एक उदाहरण दिया गया है:

interest_group_bidding {
  adslot_id: 1
  interest_group_buyer {
    origin: "https://examplebuyerorigin.com"
    currency: "EUR"
  }
}

बिडर के generateBid फ़ंक्शन को, बिड को उसी मुद्रा में दिखाना होगा जो कॉन्टेक्स्ट के हिसाब से बिड के जवाब में दिखाई गई है. bidCurrency की दिखाई गई वैल्यू में, नई bidCurrency प्रॉपर्टी की वैल्यू भरें:generateBid

function generateBid(...) {
  ...
  return {'ad': ad,
          'bid': bid,
          'bidCurrency': 'EUR',
          ...};
}

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

विज्ञापन की क्वालिटी की जांच करना

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

डिजिटल सर्विसेज़ ऐक्ट से जुड़ी सहायता

डिजिटल सर्विसेज़ ऐक्ट के अनुच्छेद 26 के तहत, पब्लिशर खरीदारों से विज्ञापन में पारदर्शिता के लिए जानकारी दिखाने का अनुरोध कर सकते हैं. जब "खरीदारों को ईईए में, मेरी साइट या ऐप्लिकेशन पर सिर्फ़ डीएसए की पारदर्शिता के मकसद से दिखाई जाने वाली जानकारी वाले विज्ञापन दिखाने के लिए कहें" कंट्रोल को किसी पब्लिशर ने चालू किया है, तो दिलचस्पी वाले ग्रुप के खरीदार यह तय कर सकते हैं कि उन्हें किन अवसरों के लिए, खरीदार की पारदर्शिता से जुड़ी जानकारी दिखानी होगी. इसके लिए, उन्हें बिड अनुरोध में BidRequest.regs.dsa.required और BidRequest.dsa.pubrender की वैल्यू नोट करनी होंगी. (Google के बंद हो चुके आरटीबी प्रोटोकॉल में, ये वैल्यू BidRequest.dsa.dsa_support और BidRequest.dsa.publisher_rendering_support थीं).

जब Protected Audience API की नीलामी में हिस्सा लेने वाले किसी बिडर को बिड रिक्वेस्ट में यह सिग्नल मिलता है कि Protected Audience API के ज़रिए दिखाए जाने वाले विज्ञापनों के लिए, डीएसए के तहत पारदर्शिता के लिए विज्ञापन में उससे जुड़ी जानकारी को दिखाना ज़रूरी है, तो उसे यह आकलन करना होगा कि वह ज़रूरी जानकारी सही तरीके से दिखा सकता है या नहीं. साथ ही, BidResponse.ext.igbid.igbuyer.dsaadrender (BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render को डिप्रेकेट किए गए Google RTB प्रोटोकॉल में सेट करके) यह जानकारी देनी होगी. ऐसा न करने पर, खरीदार को Protected Audience API की नीलामी में शामिल नहीं किया जाएगा.

डिजिटल सेवा अधिनियम के तहत, विज्ञापन की पारदर्शिता के बारे में ज़्यादा जानने के लिए, सहायता केंद्र का लेख: डिजिटल सेवा अधिनियम का पालन करना पढ़ें.

बिड फ़िल्टर करना

Google, डिवाइस पर होने वाली नीलामी के दौरान पब्लिशर के कंट्रोल और विज्ञापन से जुड़ी नीतियों को लागू करता है.

ब्राउज़र में होने वाली नीलामी के बाद

खरीदार को नीलामी के नतीजे की जानकारी देना: reportWin()

Google इन तर्कों को नहीं भरता:

auctionSignals
sellerSignals

खरीदार को नीलामी के नतीजे की जानकारी देने के लिए, reportWin() का इस्तेमाल करें.

ज़्यादा जानकारी के लिए, Protected Audience API के बारे में बताने वाले लेख का रेंडर और विज्ञापन इवेंट पर खरीदार की रिपोर्टिंग सेक्शन देखें.

मैक्रो

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

`${GDPR}`	अगर जीडीपीआर लागू नहीं होता है, तो इसकी वैल्यू 0 होती है. अगर जीडीपीआर लागू होता है, तो इसकी वैल्यू 1 होती है. दस्तावेज़ देखें.
`${GDPR_CONSENT_XXXX}`	यह अनुरोध से जुड़ी पारदर्शिता और सहमति (टीसी) स्ट्रिंग के तौर पर दिखता है. अगर पारदर्शिता और सहमति (टीसी) स्ट्रिंग खाली है या अमान्य है, तो यह मैक्रो नहीं फैलता. इस मैक्रो का इस्तेमाल करके, यूआरएल में IAB GVL में रजिस्टर किए गए वेंडर को टीसी स्ट्रिंग पास करें. `XXXX` की जगह, IAB GVL में रजिस्टर किए गए वेंडर का IAB GVL आईडी डालें. अगर टीसी स्ट्रिंग खाली है या अमान्य है, तो यह मैक्रो काम नहीं करता. अगर आपने जिस IAB GVL आईडी को डाला है उससे जुड़ा IAB GVL में रजिस्टर वेंडर, उपयोगकर्ता की सहमति नहीं लेता है, तो `${GDPR_CONSENT_XXXX}` मैक्रो वाले क्रिएटिव ब्लॉक किए जा सकते हैं. `${GDPR_CONSENT_XXXX}` मैक्रो, `renderUrl` में सिर्फ़ एक बार होना चाहिए.
`${ADDL_CONSENT}`	यह अनुरोध से जुड़ी अन्य सहमति (एसी) वाली स्ट्रिंग के तौर पर दिखता है.
`${AD_WIDTH}, ${AD_HEIGHT)`	ये मैक्रो, विज्ञापन स्लॉट की चौड़ाई और ऊंचाई डालते हैं.
`${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}`	इस मैक्रो में, बिड रिस्पॉन्स में बताए गए रेंडर-टाइम खरीदार के सिग्नल शामिल होते हैं. `buyer.origin.example` प्लेसहोल्डर को, दिलचस्पी वाले ग्रुप के खरीदार की ओरिजन आईडी से बदलें. यह बिड रिस्पॉन्स में मौजूद `interest_group_buyers.origin` से मेल खाना चाहिए. रेंडरिंग सिग्नल की ज़्यादा से ज़्यादा तीन अलग-अलग वैल्यू देने के लिए, `_OPTIONAL_SUFFIX` शामिल किया जा सकता है.

इंप्रेशन की गिनती

आरटीबी पार्टनर के साथ Protected Audience API की टेस्टिंग के दौरान, Google इंप्रेशन तब गिनेगा, जब ब्राउज़र अपने reportResult() फ़ंक्शन को कॉल करेगा. इसके बाद, sendReportTo() को कॉल करके Google के रिपोर्टिंग यूआरएल को फ़ेच करेगा.

Google, Protected Audience की इन-ब्राउज़र नीलामी में इंप्रेशन की गिनती के लिए जिस इवेंट का इस्तेमाल करता है वह, आरटीबी खरीदार पार्टनर के इंप्रेशन की गिनती के लिए इस्तेमाल किए जाने वाले इवेंट से अलग हो सकता है. इसलिए, इंप्रेशन की संख्या अलग-अलग हो सकती है.

Protected Audience API की टेस्टिंग के लिए, Google के लक्ष्यों में से एक यह है कि इन अंतरों का पता लगाया जाए और इन्हें कम किया जाए.

बिल करने लायक इंप्रेशन का एट्रिब्यूशन

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

रोज़ के बजट की सीमा

Protected Audience API की टेस्टिंग के दौरान, हर खाते के लिए खाता-लेवल पर, Protected Audience पर खर्च किए जाने वाले रोज़ के बजट की सीमा तय होती है. रोज़ के बजट की सीमा से, ब्राउज़र में होने वाली नीलामी के माहौल में जोखिम कम होता है. रोज़ के बजट की सीमा पूरी होने के बाद, खाते को Protected Audience के लिए ज़रूरी शर्तें पूरी करने वाली बिड रिक्वेस्ट नहीं मिलती हैं.

Protected Audience की सीमा तक पहुंचने के बाद भी, खाता सर्वर-साइड कॉन्टेक्स्ट के हिसाब से होने वाली नीलामी में हिस्सा ले सकता है. उदाहरण के लिए, Protected Audience की सीमा तक पहुंचने वाले बिडर खाते को auction_environment = SERVER_SIDE_AUCTION (OpenRTB JSON: 0) के साथ बिड का अनुरोध मिल सकता है. भले ही, बिड का अनुरोध Protected Audience की नीलामी के लिए ज़रूरी शर्तें पूरी करता हो.

रीयल-टाइम में फ़ीडबैक और बिड जीतने के लिए सबसे कम बिड

जिन बिडर ने रीयल-टाइम फ़ीडबैक पाने के लिए ऑप्ट-इन किया है उन्हें दिलचस्पी वाले ग्रुप के उन खरीदारों के लिए फ़ीडबैक मिलेगा जिन्होंने डिवाइस पर Protected Audience की नीलामी में शामिल होने का अनुरोध किया है. बिड रिस्पॉन्स में बिडर की ओर से तय किए गए एक जैसी दिलचस्पी वाले ग्रुप के हर खरीदार को एक फ़ीडबैक ऑब्जेक्ट मिलेगा. भले ही, खरीदार ने Protected Audience ऑक्शन में कितनी भी बिड लगाई हों. एक जैसी दिलचस्पी वाले ग्रुप के खरीदार की राय वाले ऑब्जेक्ट में यह जानकारी उपलब्ध होगी:

सुझाव, शिकायत या राय वाले ऑब्जेक्ट का टाइप INTEREST_GROUP_BUYER_FEEDBACK होगा.
दिलचस्पी के हिसाब से बनाए गए ग्रुप के खरीदार का ऑरिजिन.
नीलामी जीतने के लिए, दिलचस्पी वाले ग्रुप के खरीदार की कम से कम बिड.
नीलामी में सबसे ज़्यादा रैंक वाली बिड को हराने के लिए, दिलचस्पी वाले ग्रुप के खरीदार को कम से कम इतनी बिड लगानी होगी. यह बिड, नीलामी के सर्वर साइड कॉम्पोनेंट से लगाई गई बिड से ज़्यादा होनी चाहिए.
एक जैसी दिलचस्पी वाले ग्रुप के खरीदार का स्टेटस कोड. interest-group-buyer-status-codes.txt में, स्टेटस कोड के बारे में बताया गया है.

फ़ील्ड के नामों के बारे में जानने के लिए, Authorized Buyers RTB और OpenRTB एक्सटेंशन के प्रोटोकॉल दस्तावेज़ देखें.

बिड के बारे में सुझाव देने वाली सूचना

Chrome, Protected Audience API के लिए कुछ समय के लिए डीबग करने वाला एपीआई उपलब्ध कराता है. इसकी मदद से Ad Manager, रीयल-टाइम में सर्वर-टू-सर्वर डीबग सूचनाएं भेज सकता है. इन सूचनाओं में, Protected Audience बिड के बारे में सुझाव/राय दी जाती है या शिकायत की जाती है. इस सूचना में यह जानकारी शामिल होगी कि ब्राउज़र में होने वाली Protected Audience की नीलामी में, बिड को फ़िल्टर क्यों किया गया. साथ ही, बिड के बारे में यहां दी गई अन्य जानकारी भी शामिल होगी.

बिडर, अपने खाता मैनेजर से संपर्क करके, एक स्टैटिक यूआरएल कॉन्फ़िगर कर सकते हैं. इसका इस्तेमाल, Protected Audience की डीबग करने से जुड़ी बिड फ़ीडबैक सूचनाएँ देने के लिए किया जाएगा. इस स्टैटिक यूआरएल को Google सर्वर से फ़ेच किया जाएगा. साथ ही, Protected Audience ऑक्शन पूरा होने के बाद, चुने गए मैक्रो को बदल दिया जाएगा. ये मैक्रो काम करते हैं:

%%GOOGLE_QUERY_ID%%: इस मैक्रो को Google Query ID से बदल दिया जाता है. यह आईडी, Protected Audience की सुविधा चालू होने पर, कॉन्टेक्स्ट के हिसाब से बिड के अनुरोध पर भेजा गया था. OpenRTB प्रोटोकॉल में इसे BidRequest.ext.google_query_id के साथ तय किया जाता है, जबकि बंद किए जा चुके Google आरटीबी प्रोटोकॉल में BidRequest.google_query_id का इस्तेमाल किया जाता है.
%%INTEREST_GROUP_OWNER%%: दिलचस्पी वाले ग्रुप के मालिक का ऑरिजिन.
%%BID_CPM%%: सीपीएम के हिसाब से बिड की वह कीमत जिसे खरीदार ने generateBid() फ़ंक्शन में तय किया था.
%%RENDER_URL%%: क्रिएटिव का रेंडर यूआरएल.
%%STATUS%%: अगर बिड को scoreAd() में अस्वीकार कर दिया गया था, तो स्टेटस कोड. वैल्यू, क्रिएटिव स्टेटस कोड होती हैं.

यहां एक सैंपल स्टैटिक यूआरएल दिया गया है, जिसे बिडर अपने खाता मैनेजर को दे सकता है:

https://dsp.example/debug?google_query_id=%%GOOGLE_QUERY_ID%%&ig_owner=%%INTEREST_GROUP_OWNER%%&render_url=%%RENDER_URL%%&bid=%%BID_CPM%%&status=%%STATUS%%

बिड के बारे में सुझाव देने वाली सूचना, कुछ समय के लिए उपलब्ध सुविधा है. यह Chrome के कुछ समय के लिए उपलब्ध ForDebuggingOnly एपीआई पर निर्भर करती है.

प्रॉडक्ट-लेवल का TURTLEDOVE

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

शामिल होने के बारे में जानकारी

Protected Audience API की जांच करने का तरीका यहां दिया गया है:

चरण

Protected Audience API के एक्सपेरिमेंट में शामिल होने के लिए, अनुरोध फ़ॉर्म भरें.
अनुरोध फ़ॉर्म सबमिट करने के बाद, अपने खाता मैनेजर से संपर्क करें या Authorized Buyer के सहायता केंद्र का इस्तेमाल करके टिकट फ़ाइल करें.
खाता कॉन्फ़िगर हो जाने के बाद, Google और पार्टनर, दोनों जांच के चरण में दिए गए तरीके से इंटिग्रेशन की पुष्टि कर सकते हैं.

क्रिएटिव की समीक्षा

Protected Audience API की नीलामी में, प्रॉडक्ट-लेवल के विज्ञापनों (कई हिस्सों से बने विज्ञापन) के साथ बिड करने के लिए, इन ज़रूरी शर्तों को पूरा करें:

क्रिएटिव की समीक्षा के दौरान टॉप-लेवल renderUrls की पहचान करने के लिए, कॉम्पोनेंट विज्ञापन के कंटेनर (इसे टॉप-लेवल renderUrl भी कहा जाता है) के लिए renderUrl में &pltd=True क्वेरी पैरामीटर शामिल करें.
जब Google, कॉम्पोनेंट विज्ञापन के कंटेनर को क्रिएटिव की समीक्षा के लिए फ़ेच करता है, तब एक प्रतिनिधि क्रिएटिव रेंडर करें. यह समझने के लिए कि विज्ञापन रेंडरिंग कब दिखनी चाहिए, Google के क्रिएटिव की समीक्षा करने वाले सिस्टम की ओर से सेट किए गए validation=True क्वेरी पैरामीटर को देखें.

इंटिग्रेशन की चेकलिस्ट

बिड अनुरोध एंडपॉइंट सेट अप करें. यह कॉन्टेक्स्ट के हिसाब से बिड के जवाब में, Protected Audience API से जुड़े फ़ील्ड को अपने-आप भर देगा. उदाहरण के लिए, interest_group_bidding.
विज्ञापन देने वाले व्यक्ति या कंपनी के पेजों पर टैगिंग लागू करें, ताकि उपयोगकर्ता के ब्राउज़र को इंटरेस्ट ग्रुप से जोड़ा जा सके.
generateBid() और reportWin() को लागू करें.
दिलचस्पी वाले ग्रुप के मालिक के ऑरिजिन चुनें और उन्हें Authorized Buyer खाते में जोड़ें.
- दिलचस्पी के हिसाब से बनाए गए ग्रुप के मालिक के ऑरिजिन, उन ऑरिजिन से मेल खाने चाहिए जहां generateBid() फ़ंक्शन होस्ट किए जाते हैं.
- यह चरण पूरा करने के लिए, खाता मैनेजर से संपर्क करें या Authorized Buyer के सहायता केंद्र का इस्तेमाल करके टिकट सबमिट करें.
Protected Audience API की टेस्टिंग से जुड़ी इन्वेंट्री के लिए, प्रीटारगेटिंग सेट अप करें.
Creatives API के ज़रिए, क्रिएटिव को समीक्षा और मंज़ूरी के लिए सबमिट करें.
(ज़रूरी नहीं) भरोसेमंद बिडिंग सिग्नल के एंडपॉइंट सेट अप करें.
(ज़रूरी नहीं) विज्ञापन देने वाले व्यक्ति या कंपनी के लिए एक टेस्ट पेज सेट अप करें. इससे Google के इंजीनियर, अपने ब्राउज़र को आपके इंटरेस्ट ग्रुप के खरीदार के मालिकाना हक वाले इंटरेस्ट ग्रुप में जोड़ पाएंगे. इससे हम Protected Audience API से जुड़ी नीलामी को मैन्युअल तरीके से ट्रिगर कर सकते हैं.
(ज़रूरी नहीं) अपने खाते में रीयल-टाइम में सुझाव पाने की सुविधा चालू करें, ताकि आपको उन खरीदारों के लिए सुझाव मिल सकें जिन्होंने Protected Audience नीलामी में शामिल होने का अनुरोध किया है.
(ज़रूरी नहीं) अपने खाता मैनेजर से संपर्क करके, एक स्टैटिक यूआरएल कॉन्फ़िगर करें. इससे आपको सर्वर-टू-सर्वर सूचना मिलेगी. इसमें, डिवाइस पर की गई सुरक्षित ऑडियंस की नीलामी की बिड की स्थिति के बारे में सुरक्षित ऑडियंस की बिड का फ़ीडबैक मिलेगा. इससे, अचानक आने वाली समस्याओं को डीबग करने में मदद मिलेगी. ज़्यादा जानकारी के लिए, बिड के बारे में सुझाव देने वाली सूचना देखें.

टेस्ट के चरण

पहला चरण: मैन्युअल तरीके से जांच करना

Protected Audience API की नीलामी को मैन्युअल तरीके से ट्रिगर करने, यह पक्का करने कि विज्ञापन रेंडर किया जा सकता है, और इंप्रेशन रिकॉर्ड करने का तरीका यहां बताया गया है:

Chrome 101 या इसके बाद के वर्शन का इस्तेमाल करें.
chrome://flags/#privacy-sandbox-ads-apis और chrome://flags/#enable-fenced-frames का इस्तेमाल करके, Privacy Sandbox API और फ़ेंस किए गए फ़्रेम को चालू करें. ज़्यादा जानकारी के लिए, Privacy Sandbox को टेस्ट करें पर जाएं.
रीयल-टाइम बिडिंग एपीआई का इस्तेमाल करके, अनुमति पाने के लिए क्रिएटिव सबमिट करें.
विज्ञापन देने वाले व्यक्ति या कंपनी के लिए, बिडर के उपलब्ध कराए गए पेज का इस्तेमाल करके, बिडर के मालिकाना हक वाले दिलचस्पी वाले ग्रुप में ब्राउज़र जोड़ें.
Google की ओर से उपलब्ध कराए गए इस टेस्ट पब्लिशर पेज का इस्तेमाल करके, Protected Audience ऑक्शन को ट्रिगर करें:

https://fledge-testing.uc.r.appspot.com/?nid=allow_all

ब्राउज़र में मौजूद इंटरेस्ट ग्रुप को नीलामी जीतने के लिए, ज़्यादा बिड करनी होगी. ऐसा इसलिए, क्योंकि यह सर्वर-साइड की पारंपरिक बिड के साथ प्रतिस्पर्धा कर सकता है. Google, हर पार्टनर के लिए एक टेस्ट पब्लिशर पेज भी उपलब्ध कराता है. इस पेज पर, सिर्फ़ वह पार्टनर नीलामी में हिस्सा ले सकता है जिसे यह पेज दिया गया है. किसी पार्टनर के खास पेज पर, ब्राउज़र में होने वाली नीलामी में जीत हासिल करना आसान हो सकता है.
इनकी पुष्टि करें:
1. नीलामी जीतने वाले विज्ञापन को रेंडर किया जाता है.
2. नीलामी के नतीजे को सर्वर-साइड पर भेजा जाता है. इसका मतलब है कि बिड जीतने वाले व्यक्ति को reportWin() से पिंग बैक मिलता है.
3. टेस्ट पब्लिशर पेज, कंसोल में हर बिड के लिए डीबग मैसेज लॉग करता है. इसमें यह जानकारी शामिल होती है:
  - renderUrl: बिड का रेंडर यूआरएल.
  - interestGroupOwner: बिड के लिए, दिलचस्पी वाले ग्रुप का मालिक.
  - accepted: अगर बिड स्वीकार कर ली गई है, तो इस फ़ील्ड की वैल्यू true होती है. अगर बिड को scoreAd() ने अस्वीकार कर दिया है, तो इस फ़ील्ड की वैल्यू false होती है.
  - externalBidStatus: अगर बिड को scoreAd() में अस्वीकार कर दिया गया था, तो स्टेटस कोड. वैल्यू, क्रिएटिव स्टेटस कोड होती हैं.

दूसरा चरण: (ज़रूरी नहीं) रेंडर न करने वाला एक्सपेरिमेंट

Google और पार्टनर, दोनों मैन्युअल तरीके से यह पुष्टि करते हैं कि पार्टनर, Protected Audience ऑक्शन में हिस्सा ले सकता है. इसके बाद, Google पार्टनर को टेस्टिंग के अगले चरण के लिए चालू करता है.

Google, Protected Audience से जुड़ी नीलामियों को चलाने के लिए, लाइव ट्रैफ़िक का कुछ हिस्सा असाइन करता है. इसके बाद, Google और पार्टनर को Protected Audience ऑक्शन को मैन्युअल तरीके से ट्रिगर करने की ज़रूरत नहीं होती. Protected Audience API से जुड़ी नीलामी का नतीजा रेंडर नहीं किया गया है. इससे हमें बड़े पैमाने पर इंटिग्रेशन की जांच करने में मदद मिलती है.

जब आप तैयार हों, तब अपने खाता मैनेजर से संपर्क करें या Authorized Buyer के सहायता केंद्र में जाकर टिकट सबमिट करें. Google, इस चरण के लिए खाते को चालू करेगा.

तीसरा चरण: रेंडरिंग की परफ़ॉर्मेंस जांच

जब Google और पार्टनर, बिना रेंडर किए बड़े पैमाने पर Protected Audience ऑक्शन की पुष्टि कर लेते हैं, तब Google, पार्टनर को Protected Audience की मदद से जीते गए विज्ञापन को रेंडर करने की अनुमति दे सकता है. Google के पास कम ट्रैफ़िक होता है, जहां Protected Audience की नीलामियां की जा सकती हैं. साथ ही, दिलचस्पी वाले ग्रुप के विज्ञापन दिखाए जा सकते हैं. बिडिंग में हिस्सा लेने वाले लोगों या कंपनियों की ब्राउज़र में की गई बिड, पारंपरिक बिड के साथ प्रतिस्पर्धा करती हैं.

अतिरिक्त सुविधाएं

ये सुविधाएं, मुख्य प्रोटोकॉल के एक्सटेंशन हैं.

साथ-साथ लोड करना

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

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

विज्ञापन दिखाने के फ़्लो की खास जानकारी

यहां पैरलल ऑक्शन के फ़्लो की खास जानकारी दी गई है: फ़्लो डायग्राम

डिवाइस पर मौजूद दिलचस्पी के हिसाब से बनाए गए ग्रुप के खरीदार के लिए ज़रूरी शर्तें

पैरलल ऑक्शन के लिए, navigator.runAdAuction का कॉल, कॉन्टेक्स्ट के हिसाब से विज्ञापन का जवाब मिलने से पहले होता है. खरीदार के भरोसेमंद सर्वर कॉल शुरू करने के लिए, navigator.runAdAuction को यह ज़रूरी है कि navigator.runAdAuction पैरामीटर को वैल्यू के तौर पर पास किया जाए. वहीं, नीलामी के बाकी पैरामीटर, JavaScript प्रॉमिस स्वीकार करते हैं. इन्हें कॉन्टेक्स्ट के हिसाब से विज्ञापन के जवाब के बाद हल किया जा सकता है.interestGroupBuyers interestGroupBuyers को कॉन्टेक्स्ट के हिसाब से विज्ञापन दिखाने के अनुरोध से पहले पास किया जाता है. इसलिए, कॉन्टेक्स्ट के हिसाब से विज्ञापन दिखाने के अनुरोध (बिड रिस्पॉन्स भी शामिल हैं) का इस्तेमाल यह चुनने के लिए नहीं किया जा सकता कि दिए गए अनुरोध के लिए, पैरलल ऑक्शन में कौनसे खरीदार हिस्सा लें. इसके बजाय, Google का पब्लिशर टैग, उपयोगकर्ता के ब्राउज़र में, उसी डोमेन पर interestGroupBuyers पैरामीटर के पिछले navigator.runAdAuction एक्ज़ीक्यूशन को कैश मेमोरी में सेव करता है.

पैरललाइज़ेशन के लिए, इन बातों का ध्यान रखना ज़रूरी है:

नीलामी के ऐसे सिग्नल जो खरीदार के भरोसेमंद सर्वर के अनुरोधों के लिए ज़रूरी नहीं हैं, जैसे कि perBuyerSignals, उन्हें आरटीबी बिड रिस्पॉन्स में उसी तरह से शामिल किया जा सकता है जिस तरह से पैरलल न की गई नीलामियों के लिए किया जाता है. इन सिग्नल के लिए प्रॉमिस पूरे होने के बाद, डिवाइस पर होने वाली नीलामी के बाकी चरण उसी तरह पूरे होंगे जैसे पैरलल नीलामी के फ़्लो के लिए होते हैं.
पैरललाइज़ेशन, दिलचस्पी वाले ग्रुप के खरीदारों की सूची को कैश मेमोरी में सेव करने पर निर्भर करता है. इसलिए, Google हमेशा पैरलल ऑक्शन नहीं चलाता, क्योंकि पैरललाइज़ेशन की कैश मेमोरी खाली हो सकती है या उसकी समयसीमा खत्म हो सकती है. अगर कैश मेमोरी खाली है या उसकी समयसीमा खत्म हो गई है, तो Google, Protected Audience API की स्टैंडर्ड नॉन-पैरलल नीलामी करता है. साथ ही, खरीदार की दिलचस्पी का इस्तेमाल करके, नॉन-पैरलल नीलामी में हिस्सा लेता है, ताकि खरीदार की दिलचस्पी वाले ग्रुप की कैश मेमोरी बनाई जा सके.
अगर मौजूदा पब्लिशर डोमेन के लिए, किसी भी बिडर के लिए कम से कम एक खरीदार को कैश मेमोरी में सेव किया जाता है, तो Google एक पैरलल ऑक्शन चलाएगा. इसकी जानकारी बिड अनुरोध में दी जाएगी:
- Google आरटीबी प्रोटोकॉल: BidRequest.adslot.interest_group_auction.parallelized
- OpenRTB: BidRequest.imp.ext.interest_group_auction.parallelized
किसी बिडर के लिए, दिलचस्पी के हिसाब से चुने गए हर उस खरीदार के लिए ParallelAuctionBuyer एंट्री होगी जिसे पैरलल ऑक्शन में शामिल किया गया था:
- Google आरटीबी प्रोटोकॉल: BidRequest.adslot.interest_group_auction.parallel_auction_buyer
- OpenRTB: BidRequest.imp.ext.interest_group_auction.pbuyer
अगर पैरलल ऑक्शन चलाया जाता है, लेकिन कैश मेमोरी में खरीदार का कोई खास ओरिजिन मौजूद नहीं है, तो उस खरीदार को डिवाइस पर चल रही मौजूदा ऑक्शन में नहीं जोड़ा जा सकता. इसे parallelized=True वाले अनुरोध से पता चलता है. इसमें, किसी इंटरेस्ट ग्रुप के खरीदार के ओरिजन के लिए ParallelAuctionBuyer एंट्री मौजूद नहीं होती है. हालांकि, बिडिंग की प्रोसेस में हिस्सा लेने वाले ऐसे लोग या कंपनियां जो बिड रिस्पॉन्स में मान्य और ज़रूरी InterestGroupBuyer(s) शामिल करके दिलचस्पी दिखाती हैं उनके लिए, दिलचस्पी वाले ग्रुप के खरीदार के ऑरिजिन को कैश मेमोरी में जोड़ दिया जाएगा. साथ ही, वे ऑरिजिन उसी ब्राउज़र और डोमेन से, आने वाले समय में पैरलल किए गए अनुरोधों के लिए ज़रूरी शर्तें पूरी करेंगे. दिलचस्पी के हिसाब से बनाए गए ग्रुप की नीलामी में हिस्सा लेने के लिए, इन फ़ील्ड में जानकारी दी जा सकती है:
- Google आरटीबी प्रोटोकॉल: BidResponse.adslot.interest_group_bidding.interest_group_buyers
- OpenRTB: BidResponse.ext.igbid.igbuyer
खरीदार के उन ऑरिजिन के लिए, बिडर को खरीदार के भरोसेमंद सर्वर से कॉल मिल सकता है जिनके लिए बिडर ने बिड रिस्पॉन्स में, पैरलल ऑक्शन के interestGroupBuyers पैरामीटर में शामिल होने का इरादा नहीं बताया है. हालांकि, बिडर पैरलल ऑक्शन में हिस्सा नहीं लेगा.