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

Privacy Sandbox के तहत, 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 से विज्ञापन दिखाने के फ़्लो की खास जानकारी दी गई है पार्टनर:

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

  1. बिड करने वाला व्यक्ति, विज्ञापन देने वाले लोगों या कंपनियों के साथ मिलकर, हर एक के लिए इंटरेस्ट ग्रुप बनाए रखता है विज्ञापनदाता. अक्सर, विज्ञापन देने वाले बिड करने वाले का टैग रुचि समूहों में ब्राउज़र जोड़ने के लिए विज्ञापनदाता के पेज पर.
  2. कोई असली उपयोगकर्ता, विज्ञापन देने वाले के पेज पर जाता है. पेज में बिड करने वाले की जानकारी हो सकती है टैग के पहले डालना ज़रूरी है.
  3. बिड करने वाले का टैग, Protected Audience API joinAdInterestGroup() को शुरू करता है. इस कॉल में, ब्राउज़र से उपयोगकर्ता को एक इंटरेस्ट ग्रुप में जोड़ने का अनुरोध किया जाता है.
  4. असली उपयोगकर्ता किसी पब्लिशर के वेबपेज पर जाता है. उपयोगकर्ता के ब्राउज़र अनुरोध Google के पब्लिशर विज्ञापन टैग में.
  5. Google का पब्लिशर विज्ञापन टैग, Google सर्वर से कॉन्टेक्स्ट के हिसाब से विज्ञापन दिखाने के लिए अनुरोध करता है.
  6. Google, नीलामी में हिस्सा लेने वाले बिड लगाने वालों को, कॉन्टेक्स्ट के हिसाब से बिड रिक्वेस्ट भेजता है. देखें ज़्यादा जानकारी के लिए, बिड रिक्वेस्ट में बदलाव वाला सेक्शन.
  7. बिड करने वाला व्यक्ति, बिड रिस्पॉन्स दिखाता है. इसमें InterestGroupBidding भी शामिल होता है मैसेज लिखें, जो इंटरेस्ट ग्रुप नीलामी में हिस्सा लेने के लिए ज़रूरी है. OpenRTB में, इसकी जानकारी BidResponse.ext.igbid फ़ील्ड में दी जाती है. साथ ही, अब काम न करने वाले Google आरटीबी प्रोटोकॉल में, इसकी जानकारी BidResponse.interest_group_bidding फ़ील्ड में दी जाती है. अगर बिडर ने यह जानकारी नहीं दी है, तो Google नीलामी कॉन्फ़िगरेशन में interestGroupBuyers में बिडर का ऑरिजिन शामिल नहीं करता. InterestGroupBidding में, खरीदार के हिसाब से वैकल्पिक सिग्नल भी शामिल हो सकते हैं. इन सिग्नल को ब्राउज़र में होने वाली नीलामी के दौरान, बिडर के बिडिंग फ़ंक्शन को भेजा जाएगा. OpenRTB में, यह BidResponse.ext.igbid.igbuyer.buyerdata फ़ील्ड और काम नहीं करने वाले कॉलम में Google आरटीबी प्रोटोकॉल, इसे BidResponse.interest_group_bidding.interest_group_buyers.per_buyer_signals फ़ील्ड. ज़्यादा जानकारी के लिए, बिड रिस्पॉन्स में बदलाव वाला सेक्शन देखें.
  8. Google, सर्वर-साइड नीलामी चलाता है और ब्राउज़र को बिड का जवाब देता है. सर्वर-साइड नीलामी में, सर्वर-साइड की पारंपरिक बिड शामिल होती हैं. बोली प्रक्रिया में एक प्रासंगिक बोली लगाने की बोली के बारे में जानकारी हो सकती है (अगर कोई भी).
  9. बिड रिस्पॉन्स में, ब्राउज़र में होने वाली नीलामी के लिए नीलामी कॉन्फ़िगरेशन शामिल होता है. इसमें, हिस्सा लेने वाले हर खरीदार के संदर्भ के हिसाब से सिग्नल (जिन्हें OpenRTB के buyerdata या पहले इस्तेमाल किए जा रहे Google RTB प्रोटोकॉल के per_buyer_signals के ज़रिए भेजा गया था), संदर्भ के हिसाब से विजेता की जानकारी, और बिड की ज़रूरी शर्तों की सेटिंग शामिल हो सकती हैं.
  10. Google का पब्लिशर टैग, डिवाइस पर इंटरेस्ट ग्रुप की नीलामी शुरू करने के लिए, Protected Audience API runAdAuction() को ट्रिगर करता है. Google सिर्फ़ उन खरीदारों को शामिल करता है जिन्हें ऑक्शन कॉन्फ़िगरेशन के दौरान, InterestGroupBidding में InterestGroupBuyer के तौर पर शामिल किया गया था.
  11. Google, ज़रूरी शर्तें पूरी करने वाले हर बिड लगाने वाले के लिए, खरीदार के हिसाब से उपलब्ध सिग्नल को सुरक्षित ऑडियंस नीलामी कॉन्फ़िगरेशन में भेजता है.
  12. अगर बिड करने वाले के इंटरेस्ट ग्रुप ने trustedBiddingSignalsUrl, ब्राउज़र हर ग्रुप की हर ग्रुप के रीयल-टाइम सिग्नल फ़ेच करने के लिए, trustedBiddingSignalsUrl. Protected Audience API के स्पेसिफ़िकेशन में ज़्यादा जानें.
  13. ब्राउज़र, ऑप्ट-इन करने वाले और ब्राउज़र में होने वाली नीलामी में हिस्सा लेने की ज़रूरी शर्तें पूरी करने वाले हर इंटरेस्ट ग्रुप के लिए, बिडर के generateBid() को ट्रिगर करता है. इस चरण में बिड का हिसाब लगाया जाता है और कोई क्रिएटिव चुना जाता है. generateBid() के पास, बिडर से मिले वैकल्पिक खरीदार सिग्नल और दिए गए इंटरेस्ट ग्रुप के लिए भरोसेमंद बिडिंग सिग्नल का ऐक्सेस होता है.
  14. ब्राउज़र, इंटरेस्ट ग्रुप विज्ञापन नीलामी में हर बिड को रैंक असाइन करने के लिए, सेलर (इस मामले में, Google) के scoreAd() को कॉल करता है. बिड को रैंक किया जाता है और इन्हें पब्लिशर की सुरक्षा, विज्ञापन नीतियों वगैरह के हिसाब से फ़िल्टर किया जा सकता है करना है.
  15. ब्राउज़र, ज़रूरी शर्तें पूरी करने वाले इंटरेस्ट ग्रुप की बिड के साथ नीलामी करता है. कॉन्टेंट बनाने टॉप-रैंक वाली प्रासंगिक बोली, इन-ब्राउज़र नीलामी में हिस्सा लेती है.
  16. नीलामी के बाद, अगर कोई इंटरेस्ट ग्रुप विजेता होता है, तो ब्राउज़र, सेलर के reportResult() और बिडर के reportWin() को कॉल करता है. इससे, दोनों पक्षों को ब्राउज़र में होने वाली नीलामी के विजेता के बारे में सूचना मिलती है.
  17. अगर किसी इंटरेस्ट ग्रुप का विज्ञापन जीतता है, तो Google का पब्लिशर टैग, विज्ञापन को एक 'इंफ़्रेम' में रेंडर करता है.

फ़्लो की जानकारी दिखाना

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

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

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

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

  • एपीआई की मदद से सबमिट किया गया renderUrl, इस्तेमाल किए गए renderUrl से मेल खाना चाहिए जो इंटरेस्ट ग्रुप वाली विज्ञापन नीलामी में दिखते हैं.
  • हो सकता है कि हर renderUrl सिर्फ़ एक विज्ञापन देने वाले या विज्ञापन को दिखाता हो कैंपेन बनाएं. किसी दिए गए renderUrl का इस्तेमाल, एक से ज़्यादा विज्ञापन देने वालों की ओर से विज्ञापन दिखाने के लिए नहीं किया जा सकता. हर renderUrl को किसी एक क्रिएटिव से मैप करना ज़रूरी है.
  • विज्ञापन के लिए आखिरी बार बिड करने के सात दिन बाद तक, Google के ऑफ़लाइन क्रिएटिव की समीक्षा करने वाले सिस्टम को renderUrl ऐक्सेस और फ़ेच करने की अनुमति होनी चाहिए.
Real-time Bidding API

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

क्रिएटिव की अपने-आप स्कैन होने की सुविधा

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

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

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

  • इंटरेस्ट ग्रुप क्रिएटिव के सभी renderUrl ऑरिजिन इसमें जोड़ें Authorized Buyers खाता.

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

    Authorized-Buyers-Creative-ID

    स्ट्रिंग

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

    स्ट्रिंग

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

उदाहरण:

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, आधिकारिक खरीदार के रिपोर्टिंग टूल में एक नए डाइमेंशन के तौर पर दिखेगा. इसे खरीदार रिपोर्टिंग आईडी डाइमेंशन के तौर पर दिखाया जाएगा.

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

बिड रिक्वेस्ट में बदलाव

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

इंटरेस्ट ग्रुप नीलामी के लिए सहायता दिखाना

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

  • 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 सहायता, जिसमें कॉन्टेक्स्ट के हिसाब से नीलामी Exchange के सर्वर और इंटरेस्ट ग्रुप के लिए बिडिंग और आखिरी नीलामी ब्राउज़र में चलता है.
  • SERVER_SIDE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 3): कॉन्टेक्स्ट के हिसाब से ऑक्शन, एक्सचेंज के सर्वर पर चलता है. साथ ही, बिडिंग और ऑक्शन सर्वर में, दिलचस्पी के ग्रुप बिड के लिए बिडिंग लॉजिक और फ़ाइनल विज्ञापन तय करने के लिए स्कोरिंग लॉजिक चलाया जाता है.
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

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

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

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

Protected Audience के लिए विज्ञापन रेंडर होने की जानकारी देना

इंटिग्रेशन के मौजूदा चरण के आधार पर, हो सकता है कि Protected Audience के विज्ञापन रेंडर हों या न हों. नहीं रेंडर होने वाले विज्ञापनों के लिए एक्सपेरिमेंट देखें. 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 फ़ील्ड या BidRequest.google_user_id और BidRequest.hosted_match_data इंच अब काम नहीं करता है. बोली में ऐसे आइडेंटिफ़ायर की मौजूदगी अनुरोध मौजूदा निजता नीतियों के तहत आते हैं. हमारा सुझाव है कि आप जांच के दौरान, टारगेटिंग और बिडिंग के लिए कुकी पर आधारित आइडेंटिफ़ायर का इस्तेमाल न करें. इससे, तीसरे पक्ष की कुकी उपलब्ध न होने पर, बेहतर तरीके से खरीदारी की जा सकती है.

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

तैयारी करने के लिए तीसरे पक्ष की कुकी का इस्तेमाल बंद होना (3PCD) साल 2024 में, 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 JSON ऑब्जेक्ट के रूप में, उसके ऑन-डिवाइस बिडिंग फ़ंक्शन में लागू होता है. इसके लिए perBuyerSignals आर्ग्युमेंट. इसे बिड रिस्पॉन्स में, प्रोटोकॉल के हिसाब से ये फ़ील्ड शामिल करें:

  • OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
  • Google आरटीबी (इस्तेमाल नहीं किया जा रहा): BidResponse.interest_group_bidding.per_buyer_signals
खरीदार के काम के रेंडरिंग सिग्नल को प्रसारित करना

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

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

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

  • OpenRTB: BidResponse.ext.igbid.igbuyer.rsig
  • Google आरटीबी (इस्तेमाल नहीं किया जा रहा): BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals

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

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

ब्राउज़र में ज़्यादा से ज़्यादा बिड की कीमत तय करना

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

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};
}

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

बिड की मुद्रा

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

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

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

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

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

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

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

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

बिडिंग करने वाले लोगों या कंपनियों के generateBid फ़ंक्शन, बिड को उसी मुद्रा में दिखाते हैं जो संदर्भ के हिसाब से बिड के जवाब में बताई गई है. नई 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 आरटीबी प्रोटोकॉल का इस्तेमाल नहीं किया जा सकता). ऐसा न करने पर, खरीदार को शामिल नहीं किया जाएगा 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 की जगह, आईएबी जीवीएल में रजिस्टर किए गए वेंडर का आईएबी जीवीएल आईडी डालें. अगर टीसी स्ट्रिंग खाली या अमान्य है, तो यह मैक्रो बड़ा नहीं होता.

अगर आपने जो आईएबी जीवीएल आईडी डाला है उससे जुड़े आईएबी जीवीएल में रजिस्टर किए गए वेंडर के पास उपयोगकर्ता की सहमति नहीं है, तो ${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 शामिल करने का विकल्प है.

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

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

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

Protected Audience API की टेस्टिंग के लिए, Google का एक मकसद है कि हम को कम करने में मदद मिलती है.

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

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

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

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

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

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

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

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

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

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

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

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

  • %%GOOGLE_QUERY_ID%%: इस मैक्रो की जगह Google क्वेरी आईडी ले ली गई है जो 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

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

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

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

चरण

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

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

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

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

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

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

टेस्ट के चरण

पहला चरण: मैन्युअल टेस्ट

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

  1. Chrome 101 या इसके बाद के वर्शन का इस्तेमाल करें.
  2. इसका इस्तेमाल करके, Privacy Sandbox API और Fenced Frame को चालू करें chrome://flags/#privacy-sandbox-ads-apis और chrome://flags/#enable-fenced-frames. ज़्यादा जानकारी के लिए, निजता की जांच करें सैंडबॉक्स के तौर पर दिखते हैं.
  3. रीयल-टाइम बिडिंग का इस्तेमाल करके क्रिएटिव को मंज़ूरी के लिए सबमिट करें एपीआई.
  4. बिड लगाने वाले के मालिकाना हक वाले इंटरेस्ट ग्रुप में ब्राउज़र जोड़ने के लिए, बिड लगाने वाले के दिए गए विज्ञापन देने वाले पेज का इस्तेमाल करें.

  5. एक सुरक्षित ऑडियंस नीलामी:

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

    नीलामी में जीतने के लिए, इन-ब्राउज़र इंटरेस्ट ग्रुप को ऊंची बोली लगानी होगी. परंपरागत सर्वर-साइड बिड के साथ मुकाबला कर सकते हैं. Google, हर पार्टनर के लिए एक खास टेस्ट पब्लिशर पेज भी उपलब्ध कराता है. इस पेज पर, सिर्फ़ वह पार्टनर ही नीलामी में हिस्सा ले सकता है. भरोसे के साथ जीत हासिल करना आसान हो सकता है पार्टनर के पेज पर इन-ब्राउज़र नीलामियां.

  6. इनकी पुष्टि करें:

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

दूसरा चरण: (ज़रूरी नहीं) रेंडर न करने की प्रक्रिया का प्रयोग

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

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

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

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

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

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

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

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

साथ-साथ लोड होना

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

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

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

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

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

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

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

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

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

  3. अगर मौजूदा पब्लिशर डोमेन के लिए, किसी भी बिडर के लिए कम से कम एक खरीदार को कैश मेमोरी में सेव किया गया है, तो Google एक पैरलल ऑक्शन चलाएगा. इसकी जानकारी बिड रिक्वेस्ट पर दी जाएगी:

    • Google आरटीबी प्रोटोकॉल: BidRequest.adslot.interest_group_auction.parallelized
    • OpenRTB: BidRequest.imp.ext.interest_group_auction.parallelized

  4. किसी बिडर के लिए, रजिस्टर किए गए इंटरेस्ट ग्रुप के खरीदार की शुरुआत समानांतर नीलामी में शामिल ParallelAuctionBuyer एंट्री:

    • Google आरटीबी प्रोटोकॉल: BidRequest.adslot.interest_group_auction.parallel_auction_buyer
    • OpenRTB: BidRequest.imp.ext.interest_group_auction.pbuyer

  5. अगर समानांतर नीलामी चलती है, लेकिन खास खरीदार का ऑरिजिन मौजूद नहीं है कैश मेमोरी का इस्तेमाल करता है, तो उस खरीदार को मौजूदा डिवाइस में नहीं जोड़ा जा सकता नीलामी. यह parallelized=True के साथ किए गए उस अनुरोध से पता चलता है जिसमें एक दिए गए इंटरेस्ट ग्रुप के खरीदार की शुरुआत के लिए, ParallelAuctionBuyer की एंट्री. हालांकि, बिड करने वाले ऐसे लोग जो मान्य और ज़रूरी शर्तें पूरी करके, दिलचस्पी दिखाते हैं InterestGroupBuyer के बिड रिस्पॉन्स से मिले नतीजों में एक इंटरेस्ट ग्रुप से जुड़ा, संबंधित खरीदार होगा ऑरिजिन, कैश मेमोरी में जोड़े गए हैं और उन ऑरिजिन को कैश मेमोरी में सेव किया जा सकता है साथ ही, आने वाले समय में एक ही ब्राउज़र और डोमेन से किए जाने वाले अनुरोध शामिल करें. इंटरेस्ट ग्रुप की नीलामियों में हिस्सा लेने की इच्छा को नीचे दिए गए फ़ील्ड में दिखाया जा सकता है:

    • Google आरटीबी प्रोटोकॉल: BidResponse.adslot.interest_group_bidding.interest_group_buyers
    • OpenRTB: BidResponse.ext.igbid.igbuyer

  6. कैश मेमोरी में सेव किए गए उन खरीदार ऑरिजिन (जो पैरलल नीलामी के interestGroupBuyers पैरामीटर में शामिल होते हैं) के लिए, जिन्हें बिडिंग करने वाला व्यक्ति अपने बिड रिस्पॉन्स में शामिल नहीं करता है, उन्हें खरीदार के भरोसेमंद सर्वर से कॉल मिल सकता है. हालांकि, वे पैरलल नीलामी में हिस्सा नहीं लेंगे.