अनुरोध प्रोसेस करें

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

पार्स करने का अनुरोध

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

सीरियलाइज़ किए गए BidRequest को पाने के लिए, आपको इस अनुरोध को पार्स करना होगा. अगर Protobuf फ़ॉर्मैट का इस्तेमाल किया जा रहा है, तो आपको रेफ़रंस डेटा पेज से openrtb.proto और openrtb-adx.proto डाउनलोड करने होंगे. साथ ही, इनका इस्तेमाल करके एक ऐसी लाइब्रेरी जनरेट करनी होगी जिसका इस्तेमाल BidRequest मैसेज को पार्स करने के लिए किया जा सकता है. उदाहरण के लिए, यहां दिया गया C++ कोड, स्ट्रिंग में दिए गए POST पेलोड से अनुरोध को पार्स करता है:

string post_payload = /* the payload from the POST request */;
BidRequest bid_request;
if (bid_request.ParseFromString(post_payload)) {
  // Process the request.
}

BidRequest मिलने के बाद, इसे ऑब्जेक्ट के तौर पर इस्तेमाल किया जा सकता है. साथ ही, इसमें से अपनी ज़रूरत के फ़ील्ड निकाले जा सकते हैं और उनका विश्लेषण किया जा सकता है. उदाहरण के लिए, C++ में OpenRTB `BidRequest` में मौजूद डील को दोहराने का तरीका कुछ ऐसा दिख सकता है:

for (const BidRequest::Imp::Pmp::Deal& deal : pmp.deals()) {
  DoSomething(deal.id(), deal.wseat());
}

बिलिंग आईडी

जब किसी पब्लिशर की विज्ञापन इन्वेंट्री को आपके एक या उससे ज़्यादा प्री-टारगेटिंग कॉन्फ़िगरेशन से टारगेट किया जाता है, तब आपको बिड रिक्वेस्ट मिलती है. BidRequest.imp.ext.billing_id फ़ील्ड में, ज़रूरी शर्तें पूरी करने वाले खरीदारों के बिलिंग आईडी और प्रीटारगेटिंग से जुड़े कॉन्फ़िगरेशन की जानकारी अपने-आप भर जाएगी. इसके अलावा, डील इन्वेंट्री के लिए, BidRequest.imp.pmp.deal.ext.billing_id का इस्तेमाल करके, काम के खरीदारों से जुड़े बिलिंग आईडी ढूंढे जा सकते हैं. बिड लगाने के दौरान, बिड के अनुरोध में शामिल खरीदारों के सिर्फ़ बिलिंग आईडी दिए जा सकते हैं.

अगर बिड रिक्वेस्ट में एक से ज़्यादा बिलिंग आईडी शामिल हैं, तो आपको उस खरीदार का बिलिंग आईडी बताना होगा जिसे आपको BidResponse.seatbid.bid.ext.billing_id फ़ील्ड के साथ अपनी बिड एट्रिब्यूट करनी है.

imp {
  ext {
    // The billing IDs of all of your matching pretargeting configs and eligible child seats are
    // stored in a flat list here.
    billing_id: 123
    billing_id: 456
    billing_id: 789
  }
  pmp {
    // All eligible deals are stored in a single flat list.
    deal {
      id: 1000
      ext {
        // The specific billing IDs eligible to bid on this deal are indicated here.
        billing_id: 789
      }
      ...
    }
    deal {
      id: 2000
      ext {
        billing_id: 123
        billing_id: 456
      }
      ...
    }
  }
  ...
}
...

ब्लॉक की गई कैटगरी तय करना

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

किसी इंप्रेशन के लिए ब्लॉक की गई कैटगरी देखने के लिए, BidRequest.bcat फ़ील्ड की समीक्षा करें. इस फ़ील्ड में, आपके खाते के लिए कॉन्फ़िगर की गई टैक्सोनॉमी की कैटगरी दिखती हैं.

यहां दिए गए उदाहरण में, कॉन्फ़िगर की गई विज्ञापन कैटगरी की टैक्सोनॉमी के आधार पर ब्लॉक की गई कैटगरी दिखाई गई हैं:

IAB कॉन्टेंट टैक्सनॉमी 1.0

// Bid request
{
  // Indicates the blocked categories using IAB Content 1.0 Taxonomy.
  "bcat": [
    "IAB9-9",  // Cigars
    "IAB8-18"  // Wine
  ]
  "imp": {
    ...
  }
}
      
// Bid request
{
  // Indicates the blocked categories using Google Ad Category Taxonomy.
  "bcat": [
    "10138",  // Cigar and tobacco collecting
    "10080",  // Tobacco
    "11649",  // Wine
    "10674",  // Wine collecting
    "13008"   // Wine clubs
  ]
  "imp": {
    ...
  }
}
      

कॉन्टेक्स्ट के हिसाब से कैटगरी तय करना

बिड रिक्वेस्ट में, संदर्भ के हिसाब से कैटगरी के फ़ील्ड शामिल हो सकते हैं. इनसे उस वेबसाइट या ऐप्लिकेशन के बारे में जानकारी मिलती है जहां इंप्रेशन मिलता है. इन फ़ील्ड में विज्ञापन कैटगरी के टैक्सोनॉमी का भी इस्तेमाल किया जाता है. हालांकि, ये क्रिएटिव पर पाबंदियों के बजाय, इंप्रेशन के कॉन्टेक्स्ट को दिखाते हैं. ऐसा हो सकता है कि इन फ़ील्ड में, BidRequest.bcat फ़ील्ड वाली टैक्सोनॉमी का इस्तेमाल न किया गया हो. Google या पब्लिशर, कॉन्टेंट के हिसाब से विज्ञापन दिखाने की ये कैटगरी उपलब्ध करा सकते हैं. कॉन्टेक्स्ट के हिसाब से कैटगरी का इस्तेमाल करने से, इंप्रेशन का आकलन, संदर्भ के हिसाब से टारगेटिंग, और ब्रैंड की सुरक्षा को बेहतर बनाया जा सकता है.

Google की ओर से पहचानी गई कॉन्टेक्स्ट के हिसाब से कैटगरी

Google, साइट, ऐप्लिकेशन या पेज के लिए, IAB की जिन कॉन्टेंट कैटगरी का पता लगाता है उनके हिसाब से इन फ़ील्ड में जानकारी भरता है:

फ़ील्ड ब्यौरा
BidRequest.site.cat साइट के बारे में जानकारी देने वाले कॉन्टेंट की कैटगरी के आईडी का कलेक्शन.
BidRequest.site.pagecat कॉन्टेंट कैटगरी के आईडी का एक ऐसा कलेक्शन जो साइट के मौजूदा पेज या व्यू के बारे में बताता है.
BidRequest.app.cat कॉन्टेंट कैटगरी आईडी का एक ऐसा कलेक्शन जो ऐप्लिकेशन के बारे में बताता है.
BidRequest.app.pagecat कॉन्टेंट कैटगरी आईडी का कलेक्शन, जो ऐप्लिकेशन के मौजूदा पेज या व्यू के बारे में बताता है.

किसी बिड अनुरोध के लिए, इन फ़ील्ड में इस्तेमाल की गई टैक्सोनॉमी की सटीक जानकारी, BidRequest.site.cattax या BidRequest.app.cattax फ़ील्ड में देखी जा सकती है. ऐसा हो सकता है कि पब्लिशर की प्राथमिकताओं या कानूनी समस्याओं की वजह से, कॉन्टेक्स्ट के हिसाब से कैटगरी के फ़ील्ड हमेशा न भरे जाएं. ज़्यादा जानकारी के लिए, Google Ad Manager में OpenRTB स्पेसिफ़िकेशन के हिसाब से कॉन्टेक्स्ट से जुड़ी कैटगरी लेख पढ़ें.

पब्लिशर से मिले सिग्नल

Google की ओर से पहचानी गई कॉन्टेक्स्ट के हिसाब से बनाई गई कैटगरी के अलावा, बिड रिक्वेस्ट में पब्लिशर से मिले सिग्नल भी शामिल हो सकते हैं. इनसे इंप्रेशन के कॉन्टेक्स्ट के बारे में भी जानकारी मिलती है. Google की ओर से पहचानी गई कॉन्टेक्स्ट के हिसाब से कैटगरी के उलट, ये सिग्नल सिर्फ़ तब दिखते हैं, जब पब्लिशर इन्हें उपलब्ध कराता है. ये सिग्नल, BidRequest.site.content और BidRequest.app.content ऑब्जेक्ट में भेजे जाते हैं. जैसे, content.data.segment और content.genre. content.data.segment एंट्री के लिए इस्तेमाल की गई टैक्सोनॉमी को content.data.ext.segtax में रिपोर्ट किया जाता है. ज़्यादा जानकारी के लिए, रीयल-टाइम बिडिंग (आरटीबी) के लिए, पब्लिशर से मिले सिग्नल (पीपीएस) लेख पढ़ें.

डिक्शनरी फ़ाइलें

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

बिडर यूआरएल मैक्रो

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

मैक्रोब्यौरा
%%GOOGLE_USER_ID%%

इसे BidRequest.user.id में मौजूद Google यूज़र आईडी से बदल दिया गया है. उदाहरण के लिए, बिडर यूआरएल http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%% को अनुरोध के समय, http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl जैसे किसी यूआरएल से बदल दिया जाएगा.

अगर Google User ID की जानकारी नहीं है, तो खाली स्ट्रिंग को बदल दिया जाता है. इसका नतीजा,

http://google.bidder.com/path?gid=
%%HAS_MOBILE%%

इसे 1 से बदल दिया जाता है, ताकि यह पता चल सके कि बिड रिक्वेस्ट किसी मोबाइल डिवाइस से है. अगर ऐसा नहीं है, तो इसे 0 से बदल दिया जाता है. यह BidRequest.device.devicetype की वैल्यू पर आधारित होता है. इसमें मोबाइल डिवाइसों को HIGHEND_PHONE (4) या Tablet (5) से दिखाया जाता है.

%%HAS_VIDEO%%

इसे 1 से बदल दिया गया है, ताकि यह पता चल सके कि बिड रिक्वेस्ट में वीडियो इन्वेंट्री है या नहीं. अगर बिड रिक्वेस्ट में वीडियो इन्वेंट्री नहीं है, तो इसे 0 से बदल दिया गया है. यह इस बात पर निर्भर करता है कि बिड रिक्वेस्ट में BidRequest.imp.video मौजूद है या नहीं.

%%IS_CTV%%

इसे 1 से बदल दिया गया है, ताकि यह पता चल सके कि बिड रिक्वेस्ट किसी सीटीवी डिवाइस से आई है या नहीं. अगर बिड रिक्वेस्ट किसी सीटीवी डिवाइस से नहीं आई है, तो इसे 0 से बदल दिया जाता है. यह BidRequest.device.devicetype की वैल्यू पर आधारित होता है. Protobuf के लिए, सीटीवी डिवाइस CONNECTED_TV, CONNECTED_DEVICE या SET_TOP_BOX होते हैं. ये JSON के लिए, पूर्णांक वैल्यू 3, 6 या 7 से मैच करते हैं.

%%HOSTED_MATCH_DATA%%

BidRequest.user.buyeruid के आधार पर, वैल्यू को बदला गया.

%%MOBILE_IS_APP%%

इसे 1 से बदल दिया गया है, ताकि यह पता चल सके कि बिड रिक्वेस्ट, मोबाइल ऐप्लिकेशन इन्वेंट्री के लिए है या 0 के लिए. यह इस बात पर निर्भर करता है कि BidRequest.app में जानकारी भरी गई है या नहीं.

लेन-देन के यूआरएल से मोबाइल ऐप्लिकेशन का आईडी ढूंढना

मोबाइल ऐप्लिकेशन के लेन-देन में, इस तरह के यूआरएल रिपोर्ट किए जाएंगे:

mbappgewtimrzgyytanjyg4888888.com

बोल्ड में मौजूद स्ट्रिंग के हिस्से (gewtimrzgyytanjyg4888888) को डिकोड करने के लिए, base-32 डिकोडर का इस्तेमाल करें.

ऑनलाइन डिकोडर का इस्तेमाल किया जा सकता है. हालांकि, आपको अक्षरों को कैपिटल लेटर में लिखना होगा और आखिर में मौजूद 8 को = वैल्यू से बदलना होगा.

इस वैल्यू को डिकोड करने पर:

GEWTIMRZGYYTANJYG4======
नतीजे:
1-429610587
स्ट्रिंग 429610587, iOS ऐप्लिकेशन iFunny का ऐप्लिकेशन आईडी है.

यहां एक और उदाहरण दिया गया है. शिकायत किया गया यूआरएल यह है:

mbappgewtgmjug4ytmmrtgm888888.com
इस वैल्यू को डिकोड करने पर:
GEWTGMJUG4YTMMRTGM======
नतीजे:
1-314716233
नतीजा 314716233, iOS ऐप्लिकेशन TextNow का ऐप्लिकेशन आईडी है.

लेन-देन के यूआरएल से मोबाइल ऐप्लिकेशन का नाम ढूंढना

यहां ऐप्लिकेशन का नाम पाने का एक उदाहरण दिया गया है. जिस यूआरएल की शिकायत की गई है वह यह है:

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
इस वैल्यू को डिकोड करना:
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
नतीजे:
air.com.hypah.io.slither
यह नतीजा, Android ऐप्लिकेशन slither.io के बराबर है.

ओपन बिडिंग के फ़ील्ड

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

OpenRTB विवरण
BidRequest.imp.ext.dfp_ad_unit_code

इसमें पब्लिशर का Ad Manager नेटवर्क कोड होता है. इसके बाद, विज्ञापन यूनिट की हैरारकी होती है. इसे फ़ॉरवर्ड स्लैश से अलग किया जाता है.

उदाहरण के लिए, यह इस तरह के फ़ॉर्मैट के साथ दिखेगा: /1234/cruises/mars.

BidRequest.user.data.segment

पब्लिशर से एक्सचेंज बिडर को भेजे गए, बार-बार इस्तेमाल होने वाले की-वैल्यू पेयर.

यह तय किया जा सकता है कि वैल्यू, पब्लिशर की ओर से भेजे गए की-वैल्यू पेयर हैं. ऐसा तब होता है, जब BidRequest.user.data.name को “Publisher Passed” पर सेट किया जाता है.

अनुमति वाले वेंडर के बारे में एलान करना

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

BidRequest को समझने और अपना BidResponse बनाने के लिए, आपको टेक्नोलॉजी वेंडर के बारे में जानकारी देने के दो अलग-अलग तरीकों के बारे में पता होना चाहिए:

  1. कुछ वेंडर के बारे में जानकारी देने की ज़रूरत नहीं होती. इन वेंडर को Ad Manager से सर्टिफ़ाइड बाहरी वेंडर की सूची में शामिल किया गया है.
  2. अन्य वेंडर सिर्फ़ तब हिस्सा ले सकते हैं, जब उन्हें BidRequest में शामिल किया गया हो:
    • BidRequest में, BidRequest.imp.ext.allowed_vendor_type फ़ील्ड से पता चलता है कि विक्रेता ने किन वेंडर को अनुमति दी है. allowed_vendor_type में भेजे जाने वाले वेंडर, vendors.txt डिक्शनरी फ़ाइल में लिस्ट किए गए हैं.

बिड रिक्वेस्ट का उदाहरण

यहां दिए गए उदाहरणों में, Protobuf और JSON अनुरोधों के ऐसे सैंपल दिखाए गए हैं जिन्हें कोई भी व्यक्ति आसानी से पढ़ सकता है.

OpenRTB Protobuf

OpenRTB JSON

बिड अनुरोध को बाइनरी फ़ॉर्म में बदलने के लिए, यहां दिया गया तरीका अपनाएं. यह तरीका, आपको असली अनुरोध में POST पेलोड से मिलता है. यह तरीका C++ में उपलब्ध है. हालांकि, ध्यान दें कि यह OpenRTB JSON पर लागू नहीं होता.

string text_format_example = /* example from above */;
BidRequest bid_request;
if (TextFormat::ParseFromString(text_format_example, &bid_request)) {
  string post_payload;
  if (bid_request.SerializeToString(&post_payload)) {
    // post_payload is a binary serialization of the protocol buffer
  }
}

रीयल-टाइम में विश्लेषण और आकलन

रीयल-टाइम फ़ीडबैक, Authorized Buyers के साथ-साथ ओपन बिडिंग का इस्तेमाल करने वाले एक्सचेंज और नेटवर्क के लिए भी उपलब्ध है.

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

बिड रिस्पॉन्स के सुझाव, शिकायत या राय में भेजे गए डिफ़ॉल्ट फ़ील्ड के अलावा, BidResponse.seatbid.bid.ext.event_notification_token फ़ील्ड का इस्तेमाल करके बिड रिस्पॉन्स में कस्टम डेटा भी भेजा जा सकता है. event_notification_token एक ऐसा डेटा है जिसके बारे में सिर्फ़ बिडर को पता होता है. इससे डीबग करने में मदद मिल सकती है. उदाहरण के लिए: नया टारगेटिंग आईडी या नई रणनीति को दिखाने वाला बिडिंग आईडी या क्रिएटिव से जुड़ा मेटाडेटा, जिसके बारे में सिर्फ़ बिडर को पता होता है. ज़्यादा जानकारी के लिए, OpenRTB एक्सटेंशन प्रोटोकॉल बफ़र फ़ाइल देखें.

जब Authorized Buyers, बिड करने वाले व्यक्ति या कंपनी को बिड रिक्वेस्ट भेजता है, तो वह BidResponse के साथ जवाब देता है. अगर बिडर ने रीयल-टाइम में सुझाव, शिकायत या राय पाने की सुविधा चालू की है, तो बाद के बिड रिक्वेस्ट में, Authorized Buyers BidFeedback मैसेज में रिस्पॉन्स पर सुझाव, शिकायत या राय भेजता है:

message BidFeedback {
  // The unique id from BidRequest.id.
  optional string request_id = 1;

  // The status code for the ad. See creative-status-codes.txt in the
  // technical documentation for a list of ids.
  optional int32 creative_status_code = 2;

  // Deprecated. This field is not populated and will be removed after March,
  // 2025. If the bid won the auction, this is the price paid in your account
  // currency. If the bid participated in the auction but was out-bid, this
  // is the CPM that should have been exceeded in order to win. This is not
  // set if the bid was filtered prior to the auction, if the publisher or
  // winning bidder has opted out of price feedback or if your account has
  // opted out of sharing winning prices with other bidders. For first-price
  // auctions, minimum_bid_to_win is populated instead of this field.
  optional double price = 3 [deprecated = true];

  // The minimum bid value necessary to have won the auction, in your account
  // currency. If your bid won the auction, this is the second highest bid
  // that was not filtered (including the floor price). If your bid didn't win
  // the auction, this is the winning candidate's bid. This field will only be
  // populated if your bid participated in a first-price auction, and will not
  // be populated if your bid was filtered prior to the auction.
  optional double minimum_bid_to_win = 6;

  // Billable event rate multiplier that was applied to this bid during
  // ranking. The adjustment reflects the likelihood that your bid would
  // generate a billable event (namely, the ad renders successfully) if it won
  // the auction, relative to the probability that other bids generate a
  // billable event if they won the auction. This adjustment can be larger or
  // smaller than 1. This affects the final ranking in the auction only; in
  // particular, this multiplier does not affect the payment or whether the
  // bid clears any floor price.
  optional float billable_event_rate_bid_adjustment = 13 [default = 1];

  // When a publisher uses an RTB auction and waterfall-based SDK mediation on
  // the same query, the winner of the real-time auction must also compete in
  // a mediation waterfall (which is ordered by price) to win the impression.
  // If the bid participated in the auction and there was no waterfall, the
  // value of this field is 0. If the bid participated in the auction and
  // there was a waterfall, the value of this field is a price representing a
  // sample bid from the eligible mediation networks that were higher than the
  // auction winner, weighted by expected fill rate. This field can be used
  // in conjunction with minimum_bid_to_win to train bidding models. The CPM
  // is in your account currency.
  optional double sampled_mediation_cpm_ahead_of_auction_winner = 8;

  message EventNotificationToken {
    // The contents of the token.
    optional string payload = 1;
  }

  // The token included in the corresponding bid.
  optional EventNotificationToken event_notification_token = 4;

  // The creative ID included in the corresponding bid.
  optional string buyer_creative_id = 5;
}

इस मैसेज में, आपको सबसे पहले bid_feedback.creative_status_code फ़ील्ड की जांच करनी चाहिए. आपको creative-status-codes.txt में कोड का मतलब मिल सकता है. ध्यान दें कि बिड जीतने पर, कीमत के सुझाव से ऑप्ट आउट किया जा सकता है. ज़्यादा जानकारी के लिए, ऑप्ट-आउट करने का तरीका देखें.

रीयल-टाइम में मिलने वाले सुझाव में, बिड रिक्वेस्ट आईडी और इनमें से कोई एक शामिल होता है:

नीलामी का नतीजा रीयल-टाइम में सुझाव/राय या शिकायतें
खरीदार ने बिड सबमिट नहीं की. कुछ नहीं.
खरीदार ने ऐसी बिड सबमिट की जिसे नीलामी में शामिल होने से पहले ही फ़िल्टर कर दिया गया. क्रिएटिव स्टेटस कोड (creative-status-codes.txt).
खरीदार ने बिड सबमिट की, लेकिन नीलामी में हार गया. क्रिएटिव स्टेटस कोड 79 (नीलामी में ज़्यादा बिड की गई).
खरीदार ने ऐसी बिड सबमिट की है जिसने नीलामी जीत ली है. क्लियरिंग प्राइस और क्रिएटिव स्टेटस कोड 1.

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

नमूना

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

OpenRTB प्रोटोबफ़

OpenRTB JSON

फ़र्स्ट-प्राइस ऑक्शन के लिए बिडिंग मॉडल बनाना

फ़र्स्ट-प्राइस ऑक्शन में बिड लगाने के बाद, आपको रीयल-टाइम में फ़ीडबैक मिलेगा. इसमें minimum_bid_to_win और sampled_mediation_cpm_ahead_of_auction_winner फ़ील्ड शामिल होंगे. हालांकि, ऐसा तब होगा, जब बिड को नीलामी से फ़िल्टर न किया गया हो. इन सिग्नल का इस्तेमाल, बिडिंग लॉजिक को यह बताने के लिए किया जा सकता है कि इंप्रेशन पाने के लिए, आपकी बिड कितनी ज़्यादा या कम हो सकती थी.

  • minimum_bid_to_win: रीयल-टाइम बिडिंग की नीलामी जीतने के लिए, कम से कम इतनी बिड लगानी पड़ सकती थी. अगर आपने नीलामी जीत ली है, तो यह वह सबसे कम बिड होगी जो आपने नीलामी जीतने के दौरान लगाई होगी. अगर आपने नीलामी नहीं जीती, तो यह जीतने वाली बिड होगी.
  • sampled_mediation_cpm_ahead_of_auction_winner: अगर मीडिएशन चेन में अन्य नेटवर्क हैं, तो इस फ़ील्ड की वैल्यू, ज़रूरी शर्तें पूरी करने वाले किसी मीडिएशन नेटवर्क की सैंपल बिड की कीमत होती है. यह कीमत, नीलामी जीतने वाले नेटवर्क की बिड से ज़्यादा होती है. साथ ही, इसे विज्ञापन दिखाए जाने की अनुमानित दर के हिसाब से तय किया जाता है. अगर मीडिएशन चेन में मौजूद किसी भी नेटवर्क से विज्ञापन नहीं मिलने की उम्मीद है या पब्लिशर, एसडीके मीडिएशन का इस्तेमाल नहीं करता है, तो इसे 0 पर सेट किया जाएगा.

यह कैसे काम करता है

minimum_bid_to_win और sampled_mediation_cpm_ahead_of_auction_winner की संभावित वैल्यू तय करने के लिए, इस्तेमाल किए गए कैलकुलेशन के बारे में बताने के लिए, हमें सबसे पहले इन्हें तय करना होगा:

  • यहां मीडिएशन चेन में मौजूद सीपीएम को घटते हुए क्रम में दिखाया गया है:
    \[C_1, C_2, …, C_n\]
  • यहां मीडिएशन चेन में सीपीएम के लिए, फ़िल रेट की जानकारी दी गई है:
    \[f_1, f_2, …, f_n\]
  • यहां दिया गया फ़ंक्शन, मीडिएशन चेन एलिमेंट \(i\)से अनुमानित सीपीएम और उसकी संभावना का पता लगाने के लिए इस्तेमाल किया जाता है. यह फ़ंक्शन, दिए गए फ़िल रेट पर आधारित होता है:
    \(X_i = \{C_i\) की संभावना \(f_i\); \(0\) की संभावना \(1 - f_i\}\)
  • इसलिए, मीडिएशन चेन में सबसे ज़्यादा रेवेन्यू देने वाला विज्ञापन नेटवर्क यह होगा:
    \[\{C_1, C_2, …, C_K, W\}\]
    जहां \(W\) जीतने वाली बिड है और \(C_K > W >= C_{K+1}\)
  • रिज़र्व प्राइस या फ़्लोर को \(F\)के तौर पर दिखाया जाता है.
  • दूसरी सबसे ऊंची बिड को \(R\)के तौर पर दिखाया जाता है.
नीलामी जीतने वाले व्यक्ति के लिए कैलकुलेशन
फ़ील्ड कैलकुलेशन
minimum_bid_to_win
\(max\{F, R, X_{K+1}, …, X_n\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(\{C_i\) with probability \(\prod_{j=1}^{i-1}(1-f_j) \cdot f_i \div \prod_{j=1}^{K}(1-f_j)\}\)
\(1 <= i <= K\)के लिए.

नीलामी हारने वाले व्यक्ति के लिए कैलकुलेशन
फ़ील्ड कैलकुलेशन
minimum_bid_to_win
\(max\{F, W\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(max\{X_1, …, X_K\}\)

एक सामान्य मीडिएशन चेन का उदाहरण

मान लें कि कोई पब्लिशर, रीयल-टाइम बिडिंग और एसडीके मीडिएशन चेन, दोनों का इस्तेमाल इस तरह करता है:

एसडीके मीडिएशन चेन अनुमानित सीपीएम फ़िल रेट
नेटवर्क 1 \(C_1 = $3.00\) \(f_1 = 5\%\)
नेटवर्क 2 \(C_2 = $2.00\) \(f_2 = 45\%\)
नेटवर्क 3 \(C_3 = $0.50\) \(f_3 = 80\%\)
नेटवर्क 4 \(C_4 = $0.10\) \(f_4 = 85\%\)

मान लें कि आरटीबी नीलामी का नतीजा यह है:

आरटीबी नीलामी सीपीएम
नीलामी जीतने वाला (W) 1.00 डॉलर
नीलामी में दूसरे नंबर पर रहने वाला खरीदार (R) 0.05 डॉलर
आरक्षित कीमत / कम से कम कीमत (F) $0
नीलामी जीतने वाली बिड

यहां एक उदाहरण दिया गया है, जिसमें बताया गया है कि जीतने वाली बिड के लिए, minimum_bid_to_win और sampled_mediation_cpm_ahead_of_auction_winner की वैल्यू और संभावनाओं का हिसाब कैसे लगाया जाता है.

minimum_bid_to_win प्रॉबेबिलिटी
\(max(F, R, C_3) = $0.50\) \(f_3 = 80\%\)
\(max(F, R, C_4) = $0.10\) \((1-f_3) \cdot f_4 = 17\%\)
\(max(F, R, 0) = $0.05\) \((1-f_3) \cdot (1-f_4) = 3\%\)
sampled_mediation_cpm_
ahead_of_auction_winner
प्रॉबेबिलिटी
\(C_1 = $3.00\) \(f_1 \div (1-(1-f_1) \cdot (1-f_2)) =~ 10.5\%\)
\(C_2 = $2.00\) \(((1-f_1) \cdot f_2) \div (1-(1-f_1) \cdot (1-f_2)) =~ 89.5\%\)
नीलामी में हारी हुई बिड

नीचे दिए गए उदाहरण में, उन बोलियों के लिए minimum_bid_to_win और sampled_mediation_cpm_ahead_of_auction_winner की वैल्यू और संभावनाओं का हिसाब लगाने का तरीका बताया गया है जो नहीं जीती जा सकीं.

minimum_bid_to_win प्रॉबेबिलिटी
\(max(F, W) = $1.00\) \(100\%\)
sampled_mediation_cpm_
ahead_of_auction_winner
प्रॉबेबिलिटी
\(C_1 = $3.00\) \(f_1 = 5\%\)
\(C_2 = $2.00\) \((1-f_1) \cdot f_2 =~ 42.8\%\)
\(0\) \((1-f_1) \cdot (1-f_2) =~ 52.2\%\)

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

बिड फ़्लैटनिंग का मतलब है कि एक मुश्किल BidRequest को प्रोसेस करके, कई बिड अनुरोधों में बदला जाता है. ये अनुरोध आपके ऐप्लिकेशन को भेजे जाते हैं. बिड रिक्वेस्ट को फ़्लैट करने पर, यह पता लगाया जा सकता है कि कौनसी बिड रिक्वेस्ट ओरिजनल रिक्वेस्ट का हिस्सा थीं. ऐसा इसलिए, क्योंकि BidRequest.ext.google_query_id फ़ील्ड में उनकी वैल्यू एक जैसी होगी.

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

विज्ञापन फ़ॉर्मैट

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

इन फ़ॉर्मैट वाली बिड रिक्वेस्ट को अलग-अलग बिड रिक्वेस्ट में बांट दिया जाएगा:

  • बैनर
  • वीडियो
  • ऑडियो
  • मूल भाषा वाला

विज्ञापन फ़ॉर्मैट को फ़्लैट करने का उदाहरण

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

प्री-फ़्लैटन

फ़्लैटन करने के बाद

डील

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

स्किप किए जा सकने वाले वीडियो और वीडियो की अवधि

OpenRTB स्पेसिफ़िकेशन में, स्किप किए जा सकने वाले और स्किप न किए जा सकने वाले विज्ञापनों की ज़्यादा से ज़्यादा वीडियो की अवधि बताने के लिए अलग-अलग फ़ील्ड नहीं होते. Google, बिड को फ़्लैट करने की सुविधा का इस्तेमाल करके, इन दोनों के बीच अंतर करता है. इसके लिए, वह पहले से मौजूद BidRequest.video.maxduration और BidRequest.video.skip फ़ील्ड का इस्तेमाल करता है.

यहां एक उदाहरण दिया गया है, जिससे पता चलता है कि वीडियो इन्वेंट्री को फ़्लैट कैसे किया जाता है. इसमें, स्किप न किए जा सकने वाले विज्ञापन की ज़्यादा से ज़्यादा अवधि 15 और स्किप किए जा सकने वाले विज्ञापन की ज़्यादा से ज़्यादा अवधि 60 है.

उदाहरण max_ad_duration skip (true या false)
फ़्लैट किए बिना ओरिजनल अनुरोध 15 true
फ़्लैट किया गया पहला अनुरोध: स्किप न किया जा सकने वाला विज्ञापन 15 false
फ़्लैट किया गया दूसरा अनुरोध: स्किप किया जा सकने वाला 60 true

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

  • अनुरोध में वीडियो की अनुमति है.
  • स्किप किए जा सकने वाले और स्किप न किए जा सकने वाले, दोनों तरह के वीडियो दिखाए जा सकते हैं. साथ ही, दोनों तरह के वीडियो की ज़्यादा से ज़्यादा अवधि अलग-अलग होती है.
  • यह अनुरोध, निजी नीलामी या खुली नीलामी की ज़रूरी शर्तें पूरी करता है.

अपने तकनीकी खाता मैनेजर से संपर्क करके, इस तरह के फ़्लैटनिंग से ऑप्ट आउट किया जा सकता है. इस सुविधा के बंद होने पर, अगर पब्लिशर ने स्किप किए जा सकने वाले और स्किप न किए जा सकने वाले, दोनों तरह के वीडियो विज्ञापनों को अनुमति दी है, तो स्किप करने की सुविधा के आधार पर उनकी ज़्यादा से ज़्यादा अवधि अलग-अलग होगी. ऐसे में, skip को true पर सेट किया जाएगा. साथ ही, maxduration को स्किप किए जा सकने वाले और स्किप न किए जा सकने वाले विज्ञापन की शर्तों के हिसाब से, कम अवधि पर सेट किया जाएगा.

वीडियो पॉड

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

ओपन मेज़रमेंट

ओपन मेज़रमेंट की मदद से, तीसरे पक्ष के उन वेंडर की जानकारी दी जा सकती है जो मोबाइल ऐप्लिकेशन पर दिखाए जाने वाले विज्ञापनों के लिए, स्वतंत्र रूप से मेज़रमेंट और पुष्टि करने की सेवाएं देते हैं.

यह पता लगाया जा सकता है कि पब्लिशर, बिड अनुरोध में ओपन मेज़रमेंट का इस्तेमाल करता है या नहीं. इसके लिए, यह देखें कि विज्ञापन दिखाने के लिए उपलब्ध जगह में, पब्लिशर के लिए उपलब्ध क्रिएटिव एट्रिब्यूट में मौजूद OmsdkType: OMSDK 1.0 एट्रिब्यूट शामिल नहीं है. यह फ़ॉर्मैट के आधार पर, बैनर या वीडियो के लिए, battr एट्रिब्यूट में मिलेगा.

Open Measurement के सिग्नल वाली बिड के अनुरोधों को समझने के बारे में ज़्यादा जानने के लिए, Open Measurement SDK के सहायता केंद्र में मौजूद लेख पढ़ें.

बिड रिक्वेस्ट के सैंपल

यहां दिए गए सेक्शन में, अलग-अलग तरह के विज्ञापनों के लिए बिड अनुरोध के सैंपल दिखाए गए हैं.

ऐप्लिकेशन बैनर

OpenRTB प्रोटोबफ़

OpenRTB JSON

ऐप्लिकेशन पर अचानक दिखने वाला विज्ञापन

OpenRTB Protobuf

OpenRTB JSON

ऐप्लिकेशन में अचानक दिखने वाला वीडियो विज्ञापन

OpenRTB प्रोटोबफ़

OpenRTB JSON

ऐप्लिकेशन नेटिव

OpenRTB प्रोटोबफ़

OpenRTB JSON

वेब वीडियो

OpenRTB प्रोटोबफ़

OpenRTB JSON

एक्सचेंज बिडर के लिए मोबाइल वेब बैनर

OpenRTB Protobuf

OpenRTB JSON

अलग-अलग फ़ॉर्मैट वाले नेटिव और वीडियो विज्ञापन

OpenRTB प्रोटोबफ़

OpenRTB JSON