प्राइवसी सैंडबॉक्स के हिस्से के तौर पर, Chrome ने Protected Audience API बनाया है. यह एक ब्राउज़र एपीआई है. इसकी मदद से, विज्ञापन देने वाली कंपनियां और विज्ञापन टेक्नोलॉजी से जुड़ी कंपनियां, उपयोगकर्ताओं को क्रॉस-साइट ट्रैकिंग से सुरक्षित रखते हुए, तीसरे पक्ष की कुकी पर निर्भर हुए बिना, दिलचस्पी के हिसाब से टारगेट किए गए विज्ञापन दिखा सकती हैं.
Chrome, Protected Audience API के लिए, ऑरिजिन ट्रायल चला रहा है. Authorized Buyers, Ad Manager पब्लिशर इन्वेंट्री पर Protected Audience API की टेस्टिंग में हिस्सा ले सकते हैं. Protected Audience API की जांच करके, बिड करने वाले लोग ये काम कर सकते हैं:
- Protected Audience API फ़्लो के असर को जांचें और उसके असर के बारे में जानें.
- एपीआई में किए जा सकने वाले सुधारों के बारे में सार्वजनिक फ़ोरम पर सुझाव, शिकायत या राय जनरेट करें. उदाहरण के लिए, GitHub.
- तीसरे पक्ष की कुकी के बिना, एपीआई की मदद से लोगों के हिसाब से विज्ञापन दिखाने की सुविधा दें.
टेस्टिंग में दिलचस्पी रखने वाले Authorized Buyers को, जानकारी के लिए शामिल होने की प्रोसेस वाला सेक्शन देखें.
विज्ञापन दिखाने के फ़्लो की खास जानकारी
Authorized Buyers के लिए, सुरक्षित ऑडियंस के विज्ञापन दिखाने की प्रक्रिया की खास जानकारी यहां दी गई है:
- बिडिंग करने वाला व्यक्ति, हर विज्ञापन देने वाले के लिए इंटरेस्ट ग्रुप बनाए रखने के लिए, विज्ञापन देने वाले लोगों या कंपनियों के साथ काम करता है. अक्सर विज्ञापन देने वाले, इंटरेस्ट ग्रुप में ब्राउज़र जोड़ने के लिए, विज्ञापन देने वाले के पेज पर बिड करने वाले का टैग जोड़ते हैं.
- असली उपयोगकर्ता, विज्ञापन देने वाले के पेज पर जाता है. पेज में बिड करने वाले का टैग हो सकता है.
- बिड करने वाले का टैग, Protected Audience API
joinAdInterestGroup()
को शुरू करता है. यह कॉल, ब्राउज़र से उस उपयोगकर्ता को एक इंटरेस्ट ग्रुप में जोड़ने का अनुरोध करता है. - असली उपयोगकर्ता, पब्लिशर के वेबपेज पर जाता है. उपयोगकर्ता का ब्राउज़र, Google के पब्लिशर विज्ञापन टैग का अनुरोध करता है.
- Google का पब्लिशर विज्ञापन टैग, Google सर्वर से काम के विज्ञापन दिखाने के लिए अनुरोध करता है.
- Google, बिडिंग में हिस्सा लेने वाले लोगों को काम के हिसाब से बिड रिक्वेस्ट भेजता है. ज़्यादा जानकारी के लिए, बिड अनुरोध में बदलाव वाला सेक्शन देखें.
- बिड करने वाला,
interest_group_bidding
फ़ील्ड के साथBidResponse
दिखाता है. अगर बिड करने वाला व्यक्ति,interest_group_bidding
की जानकारी नहीं देता है, तो Google नीलामी के कॉन्फ़िगरेशन में, बिड करने वाले की जगह की जानकारीinterestGroupBuyers
में शामिल नहीं करता. बिड रिस्पॉन्स मेंinterest_group_bidding.per_buyer_signals
भी शामिल हो सकता है. ब्राउज़र में होने वाली नीलामी के दौरान,per_buyer_signals
को बिड करने वाले के बिडिंग फ़ंक्शन में पास कर दिया जाएगा. ज़्यादा जानकारी के लिए, बिड रिस्पॉन्स में बदलाव वाला सेक्शन देखें. - Google, सर्वर साइड नीलामी करता है और ब्राउज़र को बिड रिस्पॉन्स देता है. सर्वर-साइड की नीलामी में, परंपरागत सर्वर-साइड बिड का इस्तेमाल किया जाता है. बिड रिस्पॉन्स में, संदर्भ के हिसाब से जीतने वाली बिड (अगर कोई है) के बारे में जानकारी हो सकती है.
- बिड रिस्पॉन्स में, ब्राउज़र में होने वाली नीलामी के लिए, नीलामी का कॉन्फ़िगरेशन शामिल होता है. इसमें हिस्सा लेने वाले हर खरीदार के
संदर्भ के सिग्नल, (जो
interest_group_bidding.per_buyer_signals
के ज़रिए भेजे गए थे), यानी कि बिड की ज़रूरी शर्तों के हिसाब से, विजेता की जानकारी, और सेटिंग शामिल हो सकती हैं. - Google का पब्लिशर टैग, उपयोगकर्ता के डिवाइस पर मौजूद इंटरेस्ट ग्रुप से जुड़ी नीलामी शुरू करने के लिए, Protected Audience API
runAdAuction()
को शुरू करता है. Google में, सिर्फ़ उन खरीदारों को शामिल किया जाता है जिन्होंने नीलामी के कॉन्फ़िगरेशन में,interest_group_bidding
को पहलेinterestGroupBuyers
के तौर पर लौटाया है. - Google, बिडिंग करने वाले हर व्यक्ति के
per_buyer_signals
को प्रोटेक्टेड ऑडियंस ऑक्शन कॉन्फ़िगरेशन में पास करता है. - अगर बिड करने वाले किसी व्यक्ति के इंटरेस्ट ग्रुप ने
trustedBiddingSignalsUrl
के बारे में बताया है, तो ब्राउज़र हर ग्रुप केtrustedBiddingSignalsUrl
को हर ग्रुप के लिए रीयल-टाइम सिग्नल फ़ेच करने का अनुरोध करता है. Protected Audience API की खास जानकारी में जानकारी देखें. - ब्राउज़र, हर उस इंटरेस्ट ग्रुप के लिए बिड करने वाले के
generateBid()
को शुरू करता है जो ब्राउज़र में होने वाली नीलामी में हिस्सा ले सकता है और उसमें हिस्सा ले सकता है. यह चरण बोली की गणना करता है और एक क्रिएटिव चुनता है.generateBid()
के पास, बिड करने वाले की तरफ़ से उपलब्ध कराए गएper_buyer_signals
और दिए गए इंटरेस्ट ग्रुप के लिए, भरोसेमंद बिडिंग सिग्नल का ऐक्सेस है. - ब्राउज़र, इंटरेस्ट ग्रुप के आधार पर विज्ञापन नीलामी में हर बिड को रैंक देने के लिए, सेलर (इस मामले में, Google के)
scoreAd()
को शुरू करता है. बिड को पब्लिशर की सुरक्षा, विज्ञापन नीतियों, और दूसरी पाबंदियों के आधार पर रैंक और फ़िल्टर किया जाता है. - ब्राउज़र, शर्तें पूरी करने वाले इंटरेस्ट ग्रुप के लिए नीलामी करता है. सबसे ऊपर की रैंक वाली कीवर्ड के हिसाब से बिड, ब्राउज़र में होने वाली नीलामी में हिस्सा लेती है.
- नीलामी के बाद, अगर कोई इंटरेस्ट ग्रुप विजेता होता है, तो ब्राउज़र हर पक्ष को
ब्राउज़र में होने वाली नीलामी के विजेता के बारे में सूचना देने के लिए, सेलर के
reportResult()
और बिड करने वाले केreportWin()
का इस्तेमाल करता है. - अगर कोई इंटरेस्ट ग्रुप विज्ञापन जीतता है, तो Google का पब्लिशर टैग, विज्ञापन को iframe में रेंडर करता है.
विज्ञापन दिखाने के फ़्लो की जानकारी
विज्ञापन दिखाने से पहले
क्रिएटिव समीक्षा
ब्राउज़र में होने वाली नीलामियों में क्रिएटिव को दिखाने से पहले, यह ज़रूरी है कि Google से क्रिएटिव की समीक्षा हो चुकी हो और उन्हें अनुमति मिल गई हो. रीयल-टाइम बिडिंग एपीआई या अपने-आप क्रिएटिव स्कैनिंग की मदद से, क्रिएटिव को समीक्षा के लिए सबमिट किया जा सकता है. सुरक्षित ऑडियंस के लिए, ब्राउज़र में मौजूद इंटरेस्ट ग्रुप से जुड़ी विज्ञापन नीलामियों के क्रिएटिव में, 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 Buyers के रिपोर्टिंग टूल में खरीदार रिपोर्टिंग आईडी डाइमेंशन के तौर पर नए डाइमेंशन के तौर पर दिखेगा.
सर्वर साइड नीलामी
बिड रिक्वेस्ट में बदलाव
प्रयोग में इस्तेमाल करने के लिए, यहां काम करने वाले प्रोटोकॉल के शुरुआती वर्शन दिए गए हैं:
- Google आरटीबी प्रोटोकॉल शुरुआती लिंक
- OpenRTB शुरुआती लिंक
इंटरेस्ट ग्रुप के आधार पर नीलामी की सुविधा के बारे में बताएं
बिड रिक्वेस्ट के लिए, auction_environment
नाम का एक नया फ़ील्ड है.
- Google आरटीबी प्रोटोकॉल:
BidRequest.adslot.auction_environment
- OpenRTB:
BidRequest.imp.ext.auction_environment
इस फ़ील्ड का इस्तेमाल करके, सुरक्षित ऑडियंस की सुविधा वाले ब्राउज़र इंटरेस्ट ग्रुप की नीलामी के साथ काम करने वाले इंप्रेशन के अवसरों के बीच अंतर किया जा सकता है. इसके अलावा, सिर्फ़ पारंपरिक सर्वर साइड एक्सचेंज नीलामी के साथ काम करने वाले इंप्रेशन के अवसरों के बीच भी अंतर किया जा सकता है. auction_environment
एनम में ये वैल्यू हो सकती हैं:
SERVER_SIDE_AUCTION
(OpenRTB JSON:0
): सर्वर साइड नीलामीON_DEVICE_INTEREST_GROUP_AUCTION
(OpenRTB JSON:1
): सुरक्षित ऑडियंस की सहायता टीम से मिलने वाले ऐसे अनुरोध जिनमें एक्सचेंज के सर्वर और इंटरेस्ट ग्रुप बिडिंग पर काम के हिसाब से नीलामी होती है. साथ ही, ब्राउज़र में आखिरी नीलामी होती है
सुरक्षित ऑडियंस विज्ञापन स्लॉट का आकार दिखाएं
बिड रिक्वेस्ट में नीचे दिए गए फ़ील्ड शामिल होते हैं, ताकि आपको सुरक्षित ऑडियंस के विज्ञापन स्लॉट का साइज़ बताया जा सके:
- Google आरटीबी प्रोटोकॉल:
BidRequest.adslot.interest_group_auction.width
BidRequest.adslot.interest_group_auction.height
- OpenRTB:
BidRequest.imp.ext.interest_group_auction
.width
BidRequest.imp.ext.interest_group_auction
.height
ये फ़ील्ड, सुरक्षित ऑडियंस की नीलामी के लिए विज्ञापन स्लॉट के साइज़ को पिक्सल में दिखाते हैं.
यह साइज़, कॉन्टेक्स्ट के हिसाब से किए गए अनुरोध के साइज़ से अलग हो सकता है
(Adslot.width
औरAdslot.height
या OpenRTB में:
BidRequest.imp.banner.format
).
संदर्भ के हिसाब से किए गए अनुरोध के कई साइज़ हो सकते हैं. डिवाइस पर नीलामी जीतने वाले विज्ञापन को सिर्फ़ एक तय स्लॉट साइज़ को भरना चाहिए.
सुरक्षित ऑडियंस की मदद से विज्ञापन को रेंडर करने की क्षमता दिखाता है
मौजूदा इंटिग्रेशन के चरण के आधार पर, Protected Audience विज्ञापन रेंडर हो भी सकते हैं और नहीं भी (नॉन-रेंडरिंग एक्सपेरिमेंट देखें). बिड रिक्वेस्ट में render_interest_group_ads
फ़ील्ड से पता चलता है कि जीतने वाले प्रोटेक्टेड ऑडियंस विज्ञापन को रेंडर किया जाएगा या नहीं.
- Google आरटीबी प्रोटोकॉल:
BidRequest.adslot.interest_group_auction.render_interest_group_ads
- OpenRTB:
BidRequest.imp.ext.interest_group_auction.render_interest_group_ads
उपयोगकर्ता आइडेंटिफ़ायर पर भरोसा कम करें
Protected Audience API की टेस्टिंग के दायरे में आने वाले काम के बिड रिक्वेस्ट के लिए, ब्राउज़र में उपलब्ध कुकी-आधारित आइडेंटिफ़ायर का इस्तेमाल जारी रखा जा सकता है. जैसे, google_user_id
(OpenRTB में BidRequest.user.id
) और
hosted_match_data
(OpenRTB में BidRequest.user.buyerid
) फ़ील्ड. बिड रिक्वेस्ट में ऐसे आइडेंटिफ़ायर की मौजूदगी पर, मौजूदा निजता नीति लागू होगी. हमारा सुझाव है कि आप टेस्टिंग के दौरान टारगेटिंग (विज्ञापन के लिए सही दर्शक चुनना) और बिडिंग के लिए, कुकी के आधार पर आइडेंटिफ़ायर पर भरोसा न करें. इससे तीसरे पक्ष की कुकी उपलब्ध न होने पर भी खरीदारी की बेहतर तरीके से तैयारी की जा सकेगी.
Google छोटे स्तर के प्रयोग भी चला सकता है, जिनमें Protected Audience API की जांच के लिए, कुकी पर आधारित आइडेंटिफ़ायर को बिड रिक्वेस्ट से छिपाया जाता है. इससे तीसरे पक्ष की कुकी के इस्तेमाल को रोकने के संभावित असर का आकलन किया जाता है.
Chrome की मदद से, तीसरे पक्ष की कुकी के इस्तेमाल को रोकने की जांच
साल 2024 में, तीसरे पक्ष की कुकी के बंद होने (3पीसीडी) की तैयारी के लिए, Chrome अब Chrome की मदद से टेस्ट करने की सुविधा उपलब्ध करा रहा है.
साइटें और वेंडर, 3PCD के तहत अपने सिस्टम की जांच करने के लिए, Chrome की सुविधा वाली टेस्टिंग का इस्तेमाल कर सकते हैं. टेस्ट में, Chrome ब्राउज़र को 3PCD एक्सपेरिमेंट ग्रुप के लिए असाइन किया जाता है. इनमें से कोई एक मोड A या मोड B होता है. हर ब्राउज़र को एक खास 3PCD प्रयोग ग्रुप से मेल खाता हुआ एक लेबल असाइन किया जाता है. इस लेबल को ब्राउज़र में मौजूद Chrome API से ऐक्सेस किया जा सकता है.
Google, आरटीबी बिड अनुरोध पर Chrome API से, बिना बदलाव किए गए लेबल पास करता है. किसी लेबल का ट्रैफ़िक छोटा होने की वजह से, Google हमेशा इस लेबल को निजता की सीमा वाले मामलों में शामिल नहीं करता.
यहां वे फ़ील्ड दिए गए हैं जिनमें लेबल देखा जा सकता है:
- Google आरटीबी प्रोटोकॉल:
BidRequest.device.cookie_deprecation_label
- OpenRTB:
BidRequest.device.ext.cdep
बिड रिस्पॉन्स में बदलाव
एक इंटरेस्ट ग्रुप के आधार पर नीलामी में हिस्सा लेने के बारे में जानकारी
यह आपकी ज़िम्मेदारी है कि आप ब्राउज़र में होने वाली नीलामी में हिस्सा लेने के अपने इंटेंट के बारे में साफ़ तौर पर बताएं. इसके लिए, आपको संबंधित बिड रिस्पॉन्स में InterestGroupBidding
ऑब्जेक्ट दिखाना होगा:
- Google आरटीबी प्रोटोकॉल:
BidResponse.interest_group_bidding
- OpenRTB:
BidResponse.ext.igbid
आपको एक प्रासंगिक बोली जवाब देना होगा. जवाब में प्रासंगिक बोली
शामिल करना ज़रूरी नहीं है. InterestGroupBidding
ऑब्जेक्ट में, इंटरेस्ट ग्रुप के मालिक का origin
होना चाहिए. यह उस ऑरिजिन से मेल खाना चाहिए जिसे बिड करने वाले ने अपने खाते के लिए कॉन्फ़िगर किया है. जब Google पब्लिशर टैग, runAdAuction()
को कॉल करता है, तो नीलामी के कॉन्फ़िगरेशन के interestGroupBuyers
में origin
को जोड़ा जाता है.
खरीदार के हिसाब से सिग्नल का इस्तेमाल करना (perBuyerSignals)
काम के हिसाब से बिड के रिस्पॉन्स में, खरीदार के सिग्नल शामिल किए जा सकते हैं. Google, इन्हें perBuyerSignals
आर्ग्युमेंट के ज़रिए, उनके डिवाइस पर बोली लगाने के फ़ंक्शन में एक JSON ऑब्जेक्ट के तौर पर लागू करता है. इसे प्रोटोकॉल के आधार पर, नीचे दिए गए फ़ील्ड के साथ बिड रिस्पॉन्स में शामिल किया जा सकता है:
- Google आरटीबी:
BidResponse.interest_group_bidding.per_buyer_signals
- OpenRTB:
BidResponse.ext.igbid.igbuyer.buyerdata
खरीदार के हिसाब से रेंडरिंग सिग्नल का इस्तेमाल करना
रुचि समूह वाले क्रिएटिव, रेंडरिंग के दौरान प्रासंगिक बोली रिस्पॉन्स के ज़रिए उन सिग्नल को भेजकर और मैक्रो एक्सपैंशन का इस्तेमाल करके उन्हें यूआरएल रेंडर करने के अनुरोध पर पाकर, काम के कुछ सिग्नल का इस्तेमाल कर सकते हैं. उदाहरण के लिए, रेंडरिंग सिग्नल का इस्तेमाल किसी क्रिएटिव के लुक को पसंद के मुताबिक बनाने के लिए किया जा सकता है. इससे दिए गए विज्ञापन स्लॉट या पब्लिशर पेज के हिसाब से, क्रिएटिव की परफ़ॉर्मेंस को बेहतर बनाया जा सकता है.
संदर्भ के हिसाब से बिड के रिस्पॉन्स में, यूआरएल के हिसाब से सुरक्षित स्ट्रिंग के तौर पर क्रम से लगाए गए, खरीदार के रेंडरिंग सिग्नल शामिल किए जा सकते हैं. Google, इन्हें ${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}
मैक्रो बनाकर, जीतने वाले इंटरेस्ट ग्रुप के रेंडर यूआरएल में बदल देगा.
रेंडर करने के सिग्नल की जानकारी, बिड रिस्पॉन्स में प्रोटोकॉल के आधार पर, यहां दिए गए फ़ील्ड के साथ दी जा सकती है:
- Google आरटीबी:
BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals
- OpenRTB:
BidResponse.ext.igbid.igbuyer.rsig
अलग-अलग सिग्नल को पहचानने के लिए, बिड रिस्पॉन्स में अलग-अलग मैक्रो सफ़िक्स वाले रेंडरिंग सिग्नल के ज़्यादा से ज़्यादा तीन सेट शामिल किए जा सकते हैं. उदाहरण के लिए, सफ़िक्स का इस्तेमाल सिर्फ़ क्रिएटिव पर लागू होने वाले सिग्नल के खास सेट को उनके रेंडर यूआरएल में मौजूद मैक्रो से मैच कराने के लिए किया जा सकता है. इससे डेटा ट्रांसफ़र का साइज़ कम हो जाएगा.
अगर इंटरेस्ट ग्रुप यूआरएल के हिसाब से सुरक्षित नहीं हैं, मैक्रो सफ़िक्स यूनीक नहीं हैं या सिग्नल के तीन से ज़्यादा सेट नहीं दिए गए हैं, तो इंटरेस्ट ग्रुप के खरीदार को सुरक्षित ऑडियंस वाली नीलामी में हिस्सा लेने से रोक दिया जाएगा.
ब्राउज़र में बोली की ज़्यादा से ज़्यादा कीमत बताएं
Protected Audience प्रपोज़ल में, बिड का हिसाब लगाने और फ़ाइनल नीलामी को डिवाइस पर ही चलाया जाएगा. इससे गलत इस्तेमाल करने वाले ऐसे फ़ैक्टर बन सकते हैं जो नीलामी के जीतने पर मिलने वाले नतीजों जैसे भरोसे पर असर डाल सकते हैं.
Google अपने आरटीबी पार्टनर के लिए Protected Audience API की टेस्टिंग के दौरान, उसमें कमी ला सकता है. इसलिए, हर बिड रिस्पॉन्स में उम्मीद के हिसाब से ज़्यादा से ज़्यादा बिड वैल्यू तय की जा सकती है. अनुमानित अधिकतम बोली वह अधिकतम बोली मूल्य है, जो आपके बिडिंग फ़ंक्शन से वापस मिलने की उम्मीद होती है. अगर ब्राउज़र में होने वाली नीलामी से रिपोर्ट की गई, जीतने वाली बिड इस रकम से ज़्यादा हो जाती है, तो जीतने वाली बिड को बिल करने लायक इवेंट के तौर पर नहीं गिना जाता. इस तरीके में बदलाव हो सकता है.
बोली जवाब में, आप नीचे दिए गए फ़ील्ड में अनुमानित अधिकतम बोली मान तय कर सकते हैं:
- Google आरटीबी प्रोटोकॉल:
BidResponse.interest_group_bidding.interest_group_buyers.max_bid_cpm_micros
(माइक्रोसीपीएम में दिखाया जाता है) - OpenRTB:
BidResponse.igbid.igbuyer.maxbid
(सीपीएम मुद्रा यूनिट में दिखाया जाता है)
कई खातों को इंप्रेशन का श्रेय देना
बोली लगाने वाले को इन फ़ील्ड का इस्तेमाल करके, अपने इंटरेस्ट ग्रुप की बिड के इंप्रेशन को एट्रिब्यूट करने के लिए बिलिंग आईडी चुनना होगा:
- Google आरटीबी प्रोटोकॉल:
BidResponse.interest_group_bidding.interest_group_buyers.billing_id
- OpenRTB:
BidResponse.igbid.igbuyer.billing_id
चुना गया बिलिंग आईडी, बिड रिक्वेस्ट के लिए चुना गया बिलिंग आईडी होना चाहिए:
- Google आरटीबी प्रोटोकॉल:
BidRequest.adslot.matching_ad_data.billing_id
- OpenRTB:
BidRequest.imp.ext.billing_id
अगर इंटरेस्ट ग्रुप के आधार पर बिडिंग के इंप्रेशन को एट्रिब्यूट करने के लिए बिलिंग आईडी नहीं दी जाती है, तो बिडिंग करने वाला व्यक्ति सुरक्षित ऑडियंस की नीलामी में हिस्सा नहीं ले पाएगा.
चाइल्ड खातों में ज़्यादा से ज़्यादा दो बिलिंग आईडी हो सकते हैं. खरीदार एक बिलिंग आईडी का इस्तेमाल, ज़रूरत के हिसाब से खर्च के लिए और दूसरे का इस्तेमाल इंटरेस्ट ग्रुप के खर्च के लिए कर सकता है. अगर आपको किसी चाइल्ड खाते के लिए दो बिलिंग आईडी कॉन्फ़िगर करने हैं, तो अपने खाता मैनेजर से संपर्क करें.
हर बिलिंग आईडी के लिए रोज़ का बजट सेट किया जा सकता है. चाइल्ड खातों के बिलिंग आईडी का रोज़ का बजट सेट करने के लिए अपने खाता मैनेजर से संपर्क करें.
जिन चाइल्ड खातों के बिलिंग आईडी, इंप्रेशन पर बिड करने की ज़रूरी शर्तें पूरी करते हैं उनके बिलिंग आईडी, खर्च के एट्रिब्यूशन वाले विकल्प के लिए बिड रिक्वेस्ट में दिखते हैं. एक इंटरेस्ट ग्रुप के बिलिंग आईडी के बजट में बदलाव करने के लिए, अपने खाता मैनेजर से संपर्क करें.
ब्राउज़र में होने वाली नीलामी के दौरान
ब्राउज़र में बोलियां जनरेट करें
ब्राउज़र में बिड जनरेट करने के लिए, 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()
फ़ंक्शन के बारे में जानने के लिए, सुरक्षित ऑडियंस की जानकारी देने वाला ऑन-डिवाइस बिडिंग सेक्शन देखें.
बोली की मुद्रा
ब्राउज़र में मौजूद नीलामी के लिए, चुनी गई मुद्रा की सीपीएम की यूनिट में रखा जाता है.
बोली की मुद्रा को प्रासंगिक बोली रिस्पॉन्स और generateBid
की रिटर्न वैल्यू, दोनों में दिखाया जाना चाहिए. साथ ही, यह मान्य ISO 4217 ऐल्फ़ा कोड होना चाहिए, जैसे कि "USD", "EUR" या "JPY".
OpenRTB में, Google के बिड रिस्पॉन्स एक्सटेंशन में मौजूद InterestGroupBuyer
ऑब्जेक्ट में नए cur
फ़ील्ड का इस्तेमाल करें.
यहां एक उदाहरण दिया गया है:
ext {
igbid {
impid: "1"
igbuyer {
origin: "https://examplebuyerorigin.com"
cur: "EUR"
}
}
}
Google आरटीबी प्रोटोकॉल के बिड रिस्पॉन्स में, InterestGroupBuyer
मैसेज में मौजूद नए currency
फ़ील्ड का इस्तेमाल करें.
यहां एक उदाहरण दिया गया है:
interest_group_bidding {
adslot_id: 1
interest_group_buyer {
origin: "https://examplebuyerorigin.com"
currency: "EUR"
}
}
बोली लगाने वाले के generateBid
फ़ंक्शन के लिए, उसी मुद्रा में बिड दिखानी चाहिए जो संदर्भ के हिसाब से बोली के जवाब में दिखाई गई है. generateBid
की रिटर्न वैल्यू में, नई bidCurrency
प्रॉपर्टी डालें:
function generateBid(...) {
...
return {'ad': ad,
'bid': bid,
'bidCurrency': 'EUR',
...};
}
अगर प्रासंगिक बोली जवाब की मुद्रा, generateBid
से दिखाई गई मुद्रा से अलग है या दोनों में से किसी एक अमान्य मुद्रा दिखाती है, तो नीलामी से पहले बोली को फ़िल्टर किया जाएगा.
विज्ञापन क्वालिटी की जांच
आरटीबी पार्टनर के लिए Protected Audience API की टेस्टिंग के दौरान, ब्राउज़र में मौजूद इंटरेस्ट ग्रुप की बिड के लिए, क्रिएटिव नीति और पब्लिशर के कंट्रोल को लागू करने से जुड़ी नीति ज़्यादा पाबंदी वाली हो सकती है.
डिजिटल सर्विसेज़ ऐक्ट के लिए सहायता
डिजिटल सर्विसेज़ ऐक्ट के अनुच्छेद 26 के तहत, पब्लिशरों को "विज्ञापन पारदर्शिता" की जानकारी
देने के लिए खरीदार से कहा जा सकता है. जब "खरीदारों को ईईए में, मेरी साइट या ऐप्लिकेशन पर सिर्फ़ डीएसए की पारदर्शिता जानकारी दिखाने वाले विज्ञापन दिखाने के लिए कहें" कंट्रोल को पब्लिशर ने चालू किया होता है, तो इंटरेस्ट ग्रुप के खरीदार यह तय कर सकते हैं कि उन्हें पारदर्शिता दिखाने के लिए कौनसे ऑपर्च्यूनिटी की ज़रूरत होगी. इसके लिए, उन्हें मिले बिड रिक्वेस्ट के लिए इन फ़ील्ड का ध्यान रखना होगा: Google Authorized Buyers प्रोटोकॉल के लिए BidRequest.dsa.dsa_support
और BidRequest.dsa.publisher_rendering_support
और OpenRTB प्रोटोकॉल के लिए BidRequest.dsa.pubrender
.BidRequest.regs.dsa.required
Protected Audience API से जुड़ी नीलामियों में हिस्सा लेने के लिए, बिड करने वाले को जब बिड रिक्वेस्ट में यह सिग्नल मिलता है कि Protected Audience API की मदद से डिलीवर किए गए विज्ञापनों के लिए, डीएसए की पारदर्शिता दिखानी चाहिए, तब उसे यह तय करना चाहिए कि क्या वह ज़रूरी जानकारी दिखा सकता है. साथ ही, उसे यह भी तय करना चाहिए कि वह Google के Authorized Buyers प्रोटोकॉल या BidResponse.ext.igbid.igbuyer.dsaadrender
को OpenRTB प्रोटोकॉल के लिए सेट कर सकता है या नहीं.BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render
ऐसा न करने पर, खरीदार को Protected Audience API की नीलामी में शामिल नहीं किया जाएगा.
डिजिटल सर्विसेज़ ऐक्ट के विज्ञापन पारदर्शिता के बारे में ज़्यादा जानने के लिए, सहायता केंद्र का यह लेख: डिजिटल सर्विसेज़ ऐक्ट को बढ़ावा देना पढ़ें.
बिड फ़िल्टर करना
डिवाइस पर नीलामी के दौरान, Google पब्लिशर कंट्रोल और विज्ञापन नीतियां लागू करता है.
ब्राउज़र में होने वाली नीलामी के बाद
खरीदार को नीलामी के नतीजे की रिपोर्ट करें: reportWin()
Google इन आर्ग्युमेंट को अपने-आप नहीं भरता:
auctionSignals
sellerSignals
खरीदार को नीलामी के नतीजे की जानकारी देने के लिए, reportWin()
का इस्तेमाल करें.
ज़्यादा जानकारी के लिए, Protected Audience API के बारे में जानकारी देने वाले सेक्शन में, रेंडर और विज्ञापन इवेंट से जुड़ी खरीदार की रिपोर्टिंग सेक्शन देखें.
मैक्रो
Protected Audience API क्रिएटिव का रेफ़रंस देने वाले renderUrl
में, एक या उससे ज़्यादा प्लेसहोल्डर शामिल हो सकते हैं. इन्हें मैक्रो कहा जाता है. इंटरेस्ट ग्रुप की नीलामी खत्म होने के बाद, लेकिन रेंडर करने से पहले, मैक्रो को उनसे जुड़ी वैल्यू से बदल दिया जाता है. डिवाइस पर नीलामी में इस्तेमाल किए जाने वाले renderUrl
में, ये मैक्रो शामिल हो सकते हैं:
${GDPR}
|
अगर जीडीपीआर लागू नहीं होता है, तो वैल्यू 0 हो जाती है. अगर जीडीपीआर लागू होता है, तो वैल्यू 1 हो जाती है. दस्तावेज़ देखें. |
${GDPR_CONSENT_XXXX}
|
यह विकल्प, अनुरोध से जुड़ी पारदर्शिता और सहमति (टीसी) स्ट्रिंग तक पहुंचता है. अगर पारदर्शिता और सहमति (टीसी) स्ट्रिंग खाली या अमान्य है, तो यह मैक्रो बड़ा नहीं होता.
इस मैक्रो का इस्तेमाल करके, यूआरएल में टीसी स्ट्रिंग को IAB के जीवीएल में रजिस्टर किए गए वेंडर को पास करें.
अगर आपने IAB के जीवीएल आईडी से जुड़े IAB के जीवीएल में रजिस्टर किए गए वेंडर के पास उपयोगकर्ता की सहमति नहीं है, तो ${GDPR_CONSENT_XXXX} मैक्रो renderUrl में सिर्फ़ एक बार होना चाहिए.
|
${ADDL_CONSENT}
|
यह अनुरोध से जुड़ी अन्य सहमति (एसी) वाली स्ट्रिंग तक फैलता है. |
${AD_WIDTH}, ${AD_HEIGHT)
|
ये मैक्रो, विज्ञापन स्लॉट की चौड़ाई और ऊंचाई डालते हैं. |
${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}
|
मैक्रो में, बिड रिस्पॉन्स में बताए गए रेंडर-टाइम खरीदार के सिग्नल मौजूद होते हैं.
|
इंप्रेशन की गिनती करना
आरटीबी पार्टनर के साथ Protected Audience API की टेस्टिंग के दौरान, Google इंप्रेशन की गिनती तब करेगा, जब ब्राउज़र reportResult()
फ़ंक्शन को कॉल करेगा. इसके बाद, sendReportTo()
को किए गए कॉल में Google का रिपोर्टिंग यूआरएल फ़ेच करेगा.
Google, ब्राउज़र में सुरक्षित ऑडियंस की नीलामी में इंप्रेशन की गिनती करने के लिए जिस इवेंट का इस्तेमाल करता है वह आरटीबी खरीदार पार्टनर की ओर से इंप्रेशन की गिनती करने के लिए इस्तेमाल होने वाले इवेंट से अलग हो सकता है. इसलिए, इंप्रेशन की संख्या में अंतर हो सकता है.
Protected Audience API की टेस्टिंग के लिए Google का एक मकसद, इन अंतरों का पता लगाना और उन्हें कम करना है.
बिल करने लायक इंप्रेशन का एट्रिब्यूशन
ब्राउज़र में की जाने वाली सुरक्षित ऑडियंस की सुविधा की मदद से, बिड करने वाले व्यक्ति का पूरा खर्च, एक ही बिडर खाते को एट्रिब्यूट किया जाता है. यह खर्च, बिड करने वाले के लिए कॉन्फ़िगर किए गए इंटरेस्ट ग्रुप के मालिक के ऑरिजिन से की गई मैपिंग के आधार पर तय होता है. बोली लगाने वाले लोगों की चाइल्ड सीट के अलग-अलग खातों में खर्च असाइन नहीं किया जा सकता.
रोज़ के बजट की सीमा
Protected Audience API की टेस्टिंग के दौरान, हर खाते के लिए खाता-लेवल पर Protected Audience के लिए रोज़ के बजट की सीमा तय होती है. रोज़ के बजट की सीमा, ब्राउज़र में होने वाली नीलामी के माहौल को सीमित करती है. रोज़ के बजट की सीमा पूरी हो जाने के बाद, खाते को सुरक्षित ऑडियंस के लिए मंज़ूर किए गए बोली अनुरोध नहीं मिलेंगे.
सुरक्षित ऑडियंस की सीमा तक पहुंचने के बाद, खाता, सर्वर साइड के हिसाब से की जाने वाली नीलामियों में हिस्सा ले सकता है. उदाहरण के लिए, Protected Audience की सीमा तक पहुंचने के बाद, बिड करने वाले किसी खाते को auction_environment
= SERVER_SIDE_AUCTION
(OpenRTB: 0
) के साथ बिड रिक्वेस्ट मिल सकती है. भले ही, बिड रिक्वेस्ट, Protected Audience की नीलामी की ज़रूरी शर्तें पूरी करती हो.
रीयल-टाइम में फ़ीडबैक और जीतने के लिए कम से कम बिड लगाएं
बिडिंग करने वाले जिन लोगों ने रीयल-टाइम सुझाव पाने के लिए ऑप्ट-इन किया है उन्हें इंटरेस्ट ग्रुप के उन खरीदारों के बारे में सुझाव/राय दी जाएगी जिन्हें डिवाइस पर सुरक्षित ऑडियंस नीलामी में शामिल होने का अनुरोध किया गया है. बिड रिस्पॉन्स पर बिड करने वाले हर इंटरेस्ट ग्रुप के खरीदार को एक फ़ीडबैक ऑब्जेक्ट मिलेगा. इससे कोई फ़र्क़ नहीं पड़ता कि इंटरेस्ट ग्रुप के खरीदार, प्रोटेक्टेड ऑडियंस नीलामी में कितनी भी बिड लगाते हैं. नीचे दी गई जानकारी, इंटरेस्ट ग्रुप के खरीदार के सुझाव वाले ऑब्जेक्ट पर उपलब्ध होगी:
- सुझाव ऑब्जेक्ट का सुझाव टाइप
INTEREST_GROUP_BUYER_FEEDBACK
होगा. - इंटरेस्ट ग्रुप के खरीदार का ऑरिजिन.
- सभी नीलामी में जीतने के लिए, इंटरेस्ट ग्रुप के खरीदार को जीतने की सबसे कम बिड.
- इंटरेस्ट ग्रुप के खरीदार को जीतने के लिए लगाई जाने वाली कम से कम बिड, जो पूरी नीलामी के सर्वर साइड कॉम्पोनेंट की सबसे ऊंची रैंक वाली बिड को पछाड़ने के लिए होती है.
- इंटरेस्ट ग्रुप के खरीदार का स्टेटस कोड. संभावित स्थिति कोड interest-group-buyer-status-codes.txt में बताए गए हैं.
खास फ़ील्ड के नामों के लिए, Authorized Buyers RTB और OpenRTB एक्सटेंशन का प्रोटोकॉल दस्तावेज़ देखें.
बिड सुझाव की सूचना
Chrome, Protected Audience API के लिए अस्थायी तौर पर डीबग करने का एपीआई उपलब्ध कराता है. इसकी मदद से Ad Manager, सर्वर-टू-सर्वर डीबग की रीयल-टाइम सूचनाएं भेजता है. इनमें सुरक्षित ऑडियंस बिड के बारे में सुझाव, राय या शिकायत शामिल होती है. इस सूचना में, ब्राउज़र में सुरक्षित ऑडियंस की सुविधा की नीलामी में बिड फ़िल्टर होने की वजहें शामिल होंगी. साथ ही, बिड के बारे में नीचे दी गई जानकारी भी शामिल होगी.
बिडिंग करने वाले लोग, अपने खाता मैनेजर से संपर्क करके स्टैटिक यूआरएल कॉन्फ़िगर कर सकते हैं. इस यूआरएल का इस्तेमाल, प्रोटेक्टेड ऑडियंस डीबग करने की सुविधा के लिए बिड के बारे में सुझाव या राय की सूचनाएं भेजने के लिए किया जाएगा. यह स्टैटिक यूआरएल Google के सर्वर से फ़ेच किया जाएगा. साथ ही, सुरक्षित ऑडियंस की नीलामी पूरी होने के बाद, चुने गए मैक्रो बदले जाएंगे. नीचे दिए गए मैक्रो काम करते हैं:
%%GOOGLE_QUERY_ID%%
: इस मैक्रो को Google क्वेरी आईडी (Authorized Buyer प्रोटोकॉल मेंBidRequest.google_query_id
और OpenRTB प्रोटोकॉल मेंBidRequest.ext.google_query_id
) से बदल दिया जाता है, जो Protected Audience की सुविधा वाले कॉन्टेक्स्चुअल बिड रिक्वेस्ट पर भेजा गया है.%%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 (PLTD), Protected Audience API की टेस्टिंग के दौरान Google आरटीबी पार्टनर को काम करते हैं. अगर आपको PLTD की जांच करनी है, तो इंटिग्रेशन के दौरान अपने खाता मैनेजर को इस बारे में बताएं. ऐसा इसलिए, क्योंकि इसके लिए ज़्यादा संसाधन और कॉन्फ़िगरेशन की ज़रूरत होगी.
शामिल होने पर की जाने वाली गतिविधि
Protected Audience API की जांच करने का तरीका यहां बताया गया है:
तरीका
- Protected Audience API एक्सपेरिमेंट में शामिल होने के लिए, अनुरोध फ़ॉर्म भरें.
- अनुरोध फ़ॉर्म सबमिट करने के बाद, अपने खाता मैनेजर से संपर्क करें या Authorized Buyer सहायता केंद्र पर जाकर टिकट फ़ाइल करें.
- खाता कॉन्फ़िगर हो जाने के बाद, Google और पार्टनर, दोनों जांच के चरणों में दिए गए तरीके से इंटिग्रेशन की पुष्टि कर सकते हैं.
क्रिएटिव समीक्षा
Protected Audience API नीलामियों में प्रॉडक्ट-लेवल के विज्ञापनों (एक से ज़्यादा हिस्सों से बने विज्ञापन) के साथ बिडिंग करने के लिए, इन ज़रूरी शर्तों को पूरा करें:
- क्रिएटिव समीक्षा के दौरान टॉप-लेवल
renderUrls
को पहचानने के लिए, कॉम्पोनेंट विज्ञापन के कंटेनर (जिसे टॉप-लेवलrenderUrl
भी कहा जाता है) के लिए,renderUrl
में&pltd=True
क्वेरी पैरामीटर शामिल करें. - जब कॉम्पोनेंट विज्ञापन का कंटेनर, Google से क्रिएटिव समीक्षा के लिए फ़ेच किया जाता है, तो एक प्रतिनिधि क्रिएटिव को रेंडर करें. यह समझने के लिए कि सही विज्ञापन रेंडरिंग कब दिखानी चाहिए,
validation=True
क्वेरी पैरामीटर देखें, जिसे Google के क्रिएटिव रिव्यू सिस्टम ने सेट किया है.
इंटिग्रेशन की चेकलिस्ट
- बिड रिक्वेस्ट का ऐसा एंडपॉइंट सेट अप करें जो कॉन्टेक्स्ट के हिसाब से बिड के रिस्पॉन्स पर, Protected Audience API से जुड़े फ़ील्ड को भरे. उदाहरण के लिए,
interest_group_bidding
. - उपयोगकर्ता के ब्राउज़र को इंटरेस्ट ग्रुप से जोड़ने के लिए, विज्ञापन देने वाले के पेजों पर टैगिंग लागू करें.
generateBid()
औरreportWin()
को लागू करें.- इंटरेस्ट ग्रुप के मालिक का ऑरिजिन चुनें और उन्हें Authorized Buyer खाते में जोड़ें.
- दिलचस्पी ग्रुप के मालिक के ऑरिजिन, उन ऑरिजिन से मेल खाने चाहिए जहां
generateBid()
फ़ंक्शन होस्ट किए गए हैं. - यह चरण पूरा करने के लिए, खाता मैनेजर से संपर्क करें या Authorized Buyers सहायता केंद्र पर जाकर टिकट फ़ाइल करें.
- दिलचस्पी ग्रुप के मालिक के ऑरिजिन, उन ऑरिजिन से मेल खाने चाहिए जहां
- Protected Audience API की टेस्टिंग के लिए काम की इन्वेंट्री के लिए, प्री-टारगेटिंग सेट अप करें.
- क्रिएटिव एपीआई की मदद से, क्रिएटिव को समीक्षा और मंज़ूरी के लिए सबमिट करें.
- (ज़रूरी नहीं) भरोसेमंद बिडिंग सिग्नल एंडपॉइंट सेट अप करें.
- (ज़रूरी नहीं) टेस्ट विज्ञापन देने वाले का पेज सेट अप करने पर, Google के इंजीनियर अपने ब्राउज़र को उस इंटरेस्ट ग्रुप में जोड़ सकते हैं जिसका मालिकाना हक आपके इंटरेस्ट ग्रुप के खरीदार की ऑरिजिन से है. इससे हम, Protected Audience से जुड़ी नीलामियों को मैन्युअल तरीके से ट्रिगर कर सकते हैं.
- (ज़रूरी नहीं) अपने खाते पर रीयल-टाइम सुझाव पाने की सुविधा चालू करें, ताकि इंटरेस्ट ग्रुप के उन खरीदारों के सुझाव मिल सकें जिन्होंने प्रोटेक्टेड ऑडियंस नीलामी में शामिल होने का अनुरोध किया है.
- (ज़रूरी नहीं) सर्वर-टू-सर्वर सूचना पाने के लिए, अपने खाता मैनेजर से संपर्क करें. इससे आपको सर्वर-टू-सर्वर सूचना मिलेगी. इसमें डिवाइस पर मौजूद, सुरक्षित ऑडियंस की नीलामी से बिड की स्थिति के बारे में Protected Audience बिड की जानकारी मिलेगी. इससे अनचाही समस्याओं को डीबग करने में मदद मिलेगी. ज़्यादा जानकारी के लिए, बिड के बारे में सुझाव/राय देने या शिकायत करने की सूचना देखें.
टेस्ट के स्टेज
पहला चरण: मैन्युअल तरीके से जांच करना
सुरक्षित ऑडियंस नीलामी को मैन्युअल तरीके से ट्रिगर करने, विज्ञापन को रेंडर करने, और इंप्रेशन रिकॉर्ड करने का तरीका यहां बताया गया है:
- इसके लिए, Chrome 101 या उसके बाद के वर्शन का इस्तेमाल करें.
chrome://flags/#privacy-sandbox-ads-apis
औरchrome://flags/#enable-fenced-frames
का इस्तेमाल करके, Privacy Sandbox API और Fenced Frame को चालू करें. ज़्यादा जानकारी के लिए, प्राइवसी सैंडबॉक्स की जांच करें पर जाएं.- रीयल-टाइम बिडिंग एपीआई का इस्तेमाल करके, मंज़ूरी के लिए क्रिएटिव सबमिट करें.
- बिड करने वाले के मालिकाना हक वाले इंटरेस्ट ग्रुप में ब्राउज़र जोड़ने के लिए, बिड करने वाले के दिए गए विज्ञापन देने वाले पेज का इस्तेमाल करें.
सुरक्षित ऑडियंस नीलामी को ट्रिगर करने के लिए, Google की ओर से उपलब्ध कराए गए टेस्ट पब्लिशर पेज का इस्तेमाल करें:
https://fledge-testing.uc.r.appspot.com/?nid=allow_all
ब्राउज़र में मौजूद इंटरेस्ट ग्रुप को नीलामी जीतने के लिए काफ़ी ऊंची बिड लगानी चाहिए. ऐसा इसलिए, क्योंकि यह परंपरागत सर्वर साइड बिड से मुकाबला कर सकता है. Google, हर पार्टनर के लिए खास तौर पर टेस्ट पब्लिशर पेज भी उपलब्ध कराता है, जहां सिर्फ़ वह पार्टनर ही नीलामी में हिस्सा ले सकता है. किसी पार्टनर के हिसाब से बनाए गए पेज पर, ब्राउज़र में होने वाली नीलामियों को भरोसेमंद तरीके से जीतना आसान हो सकता है.
इनकी पुष्टि करें:
- अपेक्षित विजेता विज्ञापन को रेंडर किया गया.
- नीलामी के नतीजे को सर्वर-साइड पर भेजा जाता है—इसका मतलब है कि बिडिंग करने वाले व्यक्ति को
reportWin()
से पिंग वापस मिलता है. - टेस्ट पब्लिशर पेज कंसोल, हर बिड के लिए इस जानकारी के साथ एक डीबग मैसेज लॉग करता है:
renderUrl
: बिड का रेंडर यूआरएल.interestGroupOwner
: बिड के इंटरेस्ट ग्रुप का मालिक.accepted
: अगर बोली स्वीकार की गई थी, तो यह फ़ील्डtrue
है. अगरscoreAd()
ने बिड को अस्वीकार किया है, तो यह फ़ील्डfalse
होगा.externalBidStatus
: अगरscoreAd()
में बिड अस्वीकार की गई थी, तो एक स्टेटस कोड. वैल्यू क्रिएटिव स्टेटस कोड हैं.
दूसरा चरण: (ज़रूरी नहीं) नॉन-रेंडरिंग एक्सपेरिमेंट
जब Google और पार्टनर, मैन्युअल तौर पर इस बात की पुष्टि कर लेते हैं कि पार्टनर, Protected Audience ऑक्शन में हिस्सा ले सकता है, तब Google उस पार्टनर को टेस्टिंग के अगले चरण में शामिल होने की अनुमति दे देता है.
Google, सुरक्षित ऑडियंस की नीलामी करने के लिए, लाइव ट्रैफ़िक का कुछ हिस्सा तय करता है. इसके बाद, Google और पार्टनर को अब Protected Audience पर, मैन्युअल तरीके से नीलामी ट्रिगर करने की ज़रूरत नहीं होगी. Protected Audience की नीलामी का नतीजा, रेंडर नहीं किया जाता. इससे हम इंटिग्रेशन की जांच बड़े पैमाने पर कर पाते हैं.
जब आप तैयार हों, तब अपने खाता मैनेजर से संपर्क करें या Authorized Buyer सहायता केंद्र पर जाकर टिकट फ़ाइल करें. Google इस चरण के लिए खाते को चालू कर देगा.
तीसरा चरण: रेंडरिंग का प्रयोग
जब Google और पार्टनर, रेंडर किए बिना बड़े पैमाने पर सुरक्षित ऑडियंस नीलामी की पुष्टि कर लेते हैं, तब Google, पार्टनर को सुरक्षित ऑडियंस को जीतने वाले विज्ञापन को रेंडर करने की अनुमति दे सकता है. Google के पास ट्रैफ़िक कम है, जहां सुरक्षित ऑडियंस नीलामियों को चलाया जा सकता है और जीतने वाले इंटरेस्ट ग्रुप के विज्ञापन रेंडर किए जाते हैं. बिडिंग में हिस्सा लेने वाले लोग, ब्राउज़र में लगाई गई बिड का मुकाबला परंपरागत बिड से करते हैं.
जब आप तैयार हों, तब अपने खाता मैनेजर से संपर्क करें या Authorized Buyer सहायता केंद्र पर जाकर टिकट फ़ाइल करें. Google इस चरण के लिए खाते को चालू कर देगा.
अतिरिक्त सुविधाएं
ये सुविधाएं, मुख्य प्रोटोकॉल के एक्सटेंशन हैं.
साथ मिलकर काम करना
पैरललाइज़ेशन एक ऐसा ऑप्टिमाइज़ेशन है जो trustedBiddingSignalsUrl
में बताए गए खरीदारों के भरोसेमंद सर्वर को दिए गए अनुरोधों के साथ-साथ, संदर्भ के हिसाब से विज्ञापन अनुरोध की प्रोसेस शुरू करके, शुरू से लेकर आखिर तक नीलामी में लगने वाला समय कम करता है.
साथ मिलकर काम करने से, इंतज़ार का समय कम हो जाता है. हालांकि, इससे इंटरेस्ट ग्रुप के खरीदारों की ज़रूरी शर्तों और कोऑर्डिनेटेड प्रयोगों के लिए सहायता पर असर पड़ता है. साथ मिलकर काम करने की सुविधा, बिड करने वाले उन सभी लोगों पर लागू होती है जो डिवाइस पर मौजूद इंटरेस्ट ग्रुप से जुड़ी नीलामी में हिस्सा लेते हैं. बोली लगाने वाले लोगों को साथ-साथ होने वाली नीलामियों में शामिल होने के लिए कोई कार्रवाई करने की ज़रूरत नहीं है. हालांकि, उन्हें इस बात की जानकारी होनी चाहिए कि डिवाइस पर नीलामी में साथ-साथ चलने से, नीलामी में उनकी योग्यता पर किस तरह असर पड़ सकता है. सिंक किए गए प्रयोगों के प्रयोग ग्रुप आईडी, अभी साथ-साथ नीलामियों में काम नहीं करते.
विज्ञापन दिखाने के फ़्लो की खास जानकारी
नीलामी के साथ-साथ चलने वाले फ़्लो की खास जानकारी यहां दी गई है:
उपयोगकर्ता के डिवाइस पर मौजूद इंटरेस्ट ग्रुप से जुड़े खरीदार के लिए ज़रूरी शर्तें
समानांतर नीलामियों के लिए, navigator.runAdAuction
की कॉल, प्रासंगिक विज्ञापन रिस्पॉन्स मिलने से पहले होती है. खरीदार के भरोसेमंद सर्वर कॉल को शुरू करने के लिए, navigator.runAdAuction
के लिए ज़रूरी है कि interestGroupBuyers
पैरामीटर को वैल्यू के तौर पर पास किया जाए, जबकि बाकी नीलामी पैरामीटर JavaScript प्रॉमिस को स्वीकार करते हैं, जिन्हें कॉन्टेक्स्ट के हिसाब से विज्ञापन रिस्पॉन्स के बाद पूरा किया जा सकता है. interestGroupBuyers
को कॉन्टेक्स्ट के हिसाब से विज्ञापन रिस्पॉन्स से पहले पास किया जाता है. इसलिए, कॉन्टेक्स्ट के हिसाब से विज्ञापन रिस्पॉन्स (इसमें बिड रिस्पॉन्स शामिल हैं) का इस्तेमाल यह चुनने के लिए नहीं किया जा सकता कि कौनसे खरीदार दिए गए अनुरोध के लिए, नीलामी में हिस्सा लें. इसके बजाय, Google का पब्लिशर टैग कैश मेमोरी में सेव करता है.
इन पर क्लिक करने से, उपयोगकर्ता के ब्राउज़र में पिछली
navigator.runAdAuction
एक्ज़ीक्यूशन का interestGroupBuyers
पैरामीटर उसी डोमेन पर लागू होता है.
पैरललाइज़ेशन में कई अहम बातों का ध्यान रखा जाता है:
जो नीलामी सिग्नल, जैसे कि
perBuyerSignals
जैसे खरीदार के भरोसेमंद सर्वर के अनुरोधों के लिए ज़रूरी नहीं होते हैं उन्हें आरटीबी बिड रिस्पॉन्स में जिस तरह एक साथ नहीं दिखाया जाता है, ठीक उसी तरह बताया जा सकता है. इन सिग्नल के लिए किए गए वादे पूरे होने के बाद, डिवाइस पर नीलामी के बाकी चरण उसी तरह पूरे होंगे जैसे कि गैर-पैरलल नीलामी फ़्लो के लिए.पैरललाइज़ेशन, इंटरेस्ट ग्रुप के खरीदारों की सूची को कैश मेमोरी में सेव करने पर निर्भर करता है. इसलिए, Google हमेशा पैरलल नीलामी नहीं करता, क्योंकि हो सकता है कि साथ मिलकर काम करने वाली कैश मेमोरी खाली हो या उसकी समयसीमा खत्म हो गई हो. अगर कैश मेमोरी खाली है या उसकी समयसीमा खत्म हो गई है, तो Google एक स्टैंडर्ड नॉन-पैरलल Protected Audience API नीलामी चलाता है. साथ ही, इंटरेस्ट ग्रुप के खरीदारों की कैश मेमोरी बनाने के लिए, गैर-पैरलल नीलामी में हिस्सा लेने के लिए खरीदार के इंटेंट का इस्तेमाल करता है.
अगर मौजूदा पब्लिशर डोमेन के लिए, बिड करने वाले किसी भी व्यक्ति के कम से कम एक खरीदार को कैश मेमोरी में सेव किया जाता है, तो Google एक साथ नीलामी करेगा. इसकी जानकारी बिड रिक्वेस्ट पर दिखाई जाएगी:
- Google आरटीबी प्रोटोकॉल:
BidRequest.adslot.interest_group_auction.parallelized
- OpenRTB:
BidRequest.imp.ext.interest_group_auction.parallelized
- Google आरटीबी प्रोटोकॉल:
किसी खास बिडर के लिए रजिस्टर की गई, दिलचस्पी वाले ग्रुप के हर उस खरीदार ऑरिजिन के लिए
ParallelAuctionBuyer
एंट्री होगी जिसे साथ-साथ नीलामी में शामिल किया गया था:- Google आरटीबी प्रोटोकॉल:
BidRequest.adslot.interest_group_auction.parallel_auction_buyer
- OpenRTB:
BidRequest.imp.ext.interest_group_auction.pbuyer
- Google आरटीबी प्रोटोकॉल:
अगर कोई समानांतर नीलामी की जाती है, लेकिन कैश मेमोरी में खरीदार का कोई खास ऑरिजिन मौजूद नहीं है, तो उस खरीदार को डिवाइस पर होने वाली मौजूदा नीलामी में नहीं जोड़ा जा सकता. यह
parallelized=True
से किए गए अनुरोध से दिखता है. इसमें, इंटरेस्ट ग्रुप के किसी खरीदार के ऑरिजिन के लिए,ParallelAuctionBuyer
की एंट्री नहीं होती. हालांकि, अगर कोई बिड करने वाले लोग या कंपनियां, अपने बिड रिस्पॉन्स में मान्य और शर्तें पूरी करने वालेInterestGroupBuyer
(s) को शामिल करके दिलचस्पी दिखाती हैं, तो उससे जुड़े इंटरेस्ट ग्रुप के खरीदार को कैश मेमोरी में जोड़ दिया जाएगा. साथ ही, वे ऑरिजिन एक ही ब्राउज़र और डोमेन से आने वाले समय में एक साथ अनुरोध कर सकेंगे. एक जैसी दिलचस्पी वाले ग्रुप की नीलामियों में हिस्सा लेने की इच्छा, नीचे दिए गए फ़ील्ड में देखी जा सकती है:- Google आरटीबी प्रोटोकॉल:
BidResponse.adslot.interest_group_bidding.interest_group_buyers
- OpenRTB:
BidResponse.ext.igbid.igbuyer
- Google आरटीबी प्रोटोकॉल:
कैश मेमोरी में सेव किए गए खरीदार के ऑरिजिन (जो पैरलल नीलामी के
interestGroupBuyers
पैरामीटर में शामिल हैं), जिनके लिए बिड करने वाले अपनी बिड रिस्पॉन्स में हिस्सा लेने के इंटेंट को नहीं बताते हैं, तो उन्हें खरीदार के लिए भरोसेमंद सर्वर कॉल मिल सकता है, लेकिन वह पैरलल नीलामी में हिस्सा नहीं ले पाएगा.