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

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

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

Chrome, Protected Audience API के लिए, ऑरिजिन ट्रायल चला रहा है. Authorized Buyers, 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 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

ब्राउज़र में बोली की ज़्यादा से ज़्यादा कीमत बताएं

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 के जीवीएल में रजिस्टर किए गए वेंडर को पास करें. `XXXX` की जगह, IAB के जीवीएल से रजिस्टर किए गए वेंडर के IAB जीवीएल आईडी का इस्तेमाल करें. अगर टीसी स्ट्रिंग खाली या अमान्य है, तो यह मैक्रो बड़ा नहीं होता है. अगर आपने IAB के जीवीएल आईडी से जुड़े IAB के जीवीएल में रजिस्टर किए गए वेंडर के पास उपयोगकर्ता की सहमति नहीं है, तो `${GDPR_CONSENT_XXXX}` मैक्रो वाले क्रिएटिव को ब्लॉक किया जा सकता है. `${GDPR_CONSENT_XXXX}` मैक्रो `renderUrl` में सिर्फ़ एक बार होना चाहिए.
`${ADDL_CONSENT}`	यह अनुरोध से जुड़ी अन्य सहमति (एसी) वाली स्ट्रिंग तक फैलता है.
`${AD_WIDTH}, ${AD_HEIGHT)`	ये मैक्रो, विज्ञापन स्लॉट की चौड़ाई और ऊंचाई डालते हैं.

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

आरटीबी पार्टनर के साथ 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 एपीआई पर निर्भर करती है.

क्लिक इवेंट

बिडिंग करने वाले लोग, Google को Protected Audience विज्ञापन पर क्लिक इवेंट की रिपोर्ट, Fenced Frame Reporting API का इस्तेमाल करके कर सकते हैं. Google को क्लिक की सूचना देने के लिए, बिडिंग करने वालों को click इवेंट टाइप का इस्तेमाल करना चाहिए. यहां एक उदाहरण दिया गया है:

window.fence.reportEvent({
    'eventType': 'click',
    // Google does not require bidders to send data to Google in 'eventData'.
    // However, 'eventData' must be a non-null value, such as an empty string.
    'eventData': '',
    'destinations': ['direct-seller']
});

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

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

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

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

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

तीसरा चरण: रेंडरिंग का प्रयोग

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