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

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

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

Google एक बोली अनुरोध को एचटीटीपी पीओएसटी अनुरोध का बाइनरी पेलोड. Content-Type इस पर सेट है application/octet-stream. उदाहरण के लिए बोली अनुरोध का उदाहरण देखें.

आपको यह अनुरोध BidRequest के एक इंस्टेंस में पार्स करना होगा दिखाई देगा. BidRequest के बारे में realtime-bidding.proto में बताया गया है, इसे रेफ़रंस डेटा पेज पर देखा जा सकता है. आप संदेश को पार्स कर सकते हैं जनरेट की गई क्लास में ParseFromString() तरीके का इस्तेमाल करके BidRequest. उदाहरण के लिए, नीचे दिया गया C++ कोड एक अनुरोध को पार्स करता है स्ट्रिंग में पीओएसटी पेलोड दिया गया है: 

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

BidRequest मिलने के बाद, आप इसके साथ काम करने के लिए ऑब्जेक्ट बनाने, एक्सट्रैक्ट करने, और समझने में मदद करता है. उदाहरण के लिए, C++:

for (int i = 0; i < bid_request.adslot_size(); ++i) {
  const BidRequest_AdSlot& adslot = bid_request.adslot(i);
  // Decide what to bid on adslot.
}

BidRequest में भेजी गई कुछ जानकारी, जैसे कि Google उपयोगकर्ता आईडी, भाषा या भौगोलिक स्थान, हमेशा उपलब्ध नहीं होते. यदि आपके पास पहले से टारगेट करने वाले विज्ञापन ग्रुप, जो किसी विज्ञापन ग्रुप के बारे में ऐसी जानकारी का इस्तेमाल करते हैं जिसके बारे में कोई जानकारी नहीं है इंप्रेशन नहीं देते, तो वे विज्ञापन समूह मेल नहीं खाएंगे. ऐसे मामलों में जहां प्री-टारगेटिंग की शर्तों के लिए जानकारी कोई मायने नहीं रखती, लेकिन बिड रिक्वेस्ट जानकारी को शामिल नहीं करके भेजा जाता है.

प्री-टारगेटिंग विज्ञापन ग्रुप के बारे में जानकारी इसमें उपलब्ध है हर AdSlot के लिए MatchingAdData ग्रुप. इसमें प्री-टारगेटिंग विज्ञापन ग्रुप का पहला मैच होने वाला विज्ञापन ग्रुप आईडी जिसकी वजह से Google को वह बोली अनुरोध, यानी कि उस विज्ञापन समूह और अभियान को भेजता है, जिनके लिए शुल्क लिया जाता है अगर आपका जवाब इंप्रेशन के लिए नीलामी जीतता है. तय सीमा से कम स्थितियों में, आपकोbilling_id BidResponse.AdSlot में एट्रिब्यूशन का इस्तेमाल किया जाएगा. उदाहरण के लिए, जब BidRequest.AdSlot के पास एक से ज़्यादा matching_ad_data हैं. बोली की सामग्री पर लगी सीमाओं के बारे में ज़्यादा जानकारी के लिए, यह लेख पढ़ें: realtime-bidding.proto.

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

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

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

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

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

google_user_id से बदला गया BidRequest से मिला है. उदाहरण के लिए, बिड करने वाले का यूआरएल 

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 का has_mobile().
%%HAS_VIDEO%%

1 (सही) या 0 (गलत) से बदला गया BidRequest के has_video() पर कॉल करते समय.
%%HOSTED_MATCH_DATA%%

hosted_match_data फ़ील्ड की वैल्यू से बदला गया BidRequest से मिला है.
%%MOBILE_IS_APP%%

1 (सही) या 0 (गलत) से बदला गया BidRequest के mobile.is_app फ़ील्ड से.

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

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

mbappgewtimrzgyytanjyg4888888.com

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

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

इसलिए, इस वैल्यू को डिकोड करने का तरीका: 

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

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

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

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

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

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

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

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

OpenRTB Authorized Buyers ब्यौरा
BidRequest.imp[].ext.dfp_ad_unit_code BidRequest.adslot[].dfp_ad_unit_code

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

उदाहरण के लिए, यह इस तरह की फ़ॉर्मैटिंग के साथ दिखेगा: /1234/cruises/mars.
BidRequest.user.data[].segment[] BidRequest.adslot[].exchange_bidding.key_value[]

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

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

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

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

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

  1. कुछ वेंडर के लिए एलान करने की ज़रूरत नहीं होती; इन वेंडर का नाम Authorized Buyers सहायता केंद्र पर होता है.
  2. दूसरे वेंडर सिर्फ़ तब हिस्सा ले सकते हैं, जब उनके बारे में BidRequest और BidResponse:
    • BidRequest में, allowed_vendor_type फ़ील्ड में यह जानकारी दी जाती है कि विक्रेता किन वेंडर को अनुमति देता है. इन वेंडर को भेजा जाएगा BidRequest का allowed_vendor_type फ़ील्ड यह है Vendors.txt में मौजूद सूची में शामिल है शब्दकोश फ़ाइल.
    • BidResponse में, vendor_type फ़ील्ड यह बताता है कि खरीदार, अनुमति वाले किन वेंडर का इस्तेमाल करना चाहता है.

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

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

Google

OpenRTB JSON

ओपनआरटीबी प्रोटोबफ़

बोली अनुरोध को बाइनरी फ़ॉर्म में बदलने के लिए, जैसा कि पीओएसटी पेलोड के लिए, नीचे दिया गया तरीका (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, बिड रिक्वेस्ट के तहत मोबाइल विज्ञापन आईडी पास करते हैं मोबाइल ऐप्लिकेशन पर काम करता है. मोबाइल विज्ञापन आईडी iOS IDFA या Android का विज्ञापन आईडी होता है. इसे JavaScript टैग में %%EXTRA_TAG_DATA%% मैक्रो, जिसे ये मैनेज करता है Authorized Buyers.

%%ADVERTISING_IDENTIFIER%% मैक्रो की मदद से, खरीदारों को इंप्रेशन रेंडरिंग पर iOS IDFA या Android का विज्ञापन आईडी. यह एन्क्रिप्ट (सुरक्षित) किया गया प्रोटो बफ़र MobileAdvertisingId लाइक %%EXTRA_TAG_DATA%%:

message MobileAdvertisingId {
  optional bytes advertising_id = 1;
  optional int32 user_id_type = 2;
}

user_id_type, enum AdxMobileIdType:

enum AdxMobileIdType {
  MOBILE_ID_UNKNOWN = 0,
  IDFA = 1,
  ANDROID_ID = 2,
};

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

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

रीयल-टाइम में सुझाव, शिकायत या राय

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

बिड रिस्पॉन्स का फ़ीडबैक, दोनों के लिए बाद के बिड रिक्वेस्ट पर काम करता है AdX प्रोटोकॉल और OpenRTB. OpenRTB के लिए, इसे इसमें भेजा जाता है: BidRequestExt.

बिड रिस्पॉन्स के सुझाव में भेजे गए डिफ़ॉल्ट फ़ील्ड के अलावा, ये काम किए जा सकते हैं साथ ही, बिड रिस्पॉन्स में कस्टम डेटा भी भेजें (AdX Proto या OpenRTB में) event_notification_token का इस्तेमाल करके, BidResponse. event_notification_token यह है सिर्फ़ बिड करने वाले के पास मौजूद आर्बिट्रेरी डेटा, जो डीबग करने में मदद कर सकता है. उदाहरण: नई रणनीति को दिखाने वाला नया टारगेटिंग आईडी या बिडिंग आईडी, या उस क्रिएटिव से जुड़ा मेटाडेटा जो सिर्फ़ बिड करने वाले के पास है. जानकारी के लिए, OpenRTB देखें आरटीबी और AdX Proto के लिए एक्सटेंशन प्रोटोकॉल बफ़र AdX के लिए.

जब Authorized Buyers, बिड करने वाले किसी व्यक्ति को बिड रिक्वेस्ट भेजते हैं, तो बिड करने वाला उसका जवाब देता है BidResponse के साथ. अगर बिड करने वाले ने रीयल-टाइम फ़ीडबैक की सुविधा चालू की है, तो इसके बाद, अगले बिड रिक्वेस्ट में Authorized Buyers, BidResponseFeedback मैसेज में जवाब दिया गया है, जैसा कि नीचे दिखाया गया है:

message BidResponseFeedback {
  // The unique id from BidRequest.id
  optional bytes request_id = 1;

  // The index of the BidResponse_Ad if there was more than one. The index
  // starts at zero for the first creative.
  optional int32 creative_index = 2;

  // 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 = 3;

  // 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 int64 cpm_micros = 4;

  // The minimum bid value necessary to have won the auction, in micros of
  // 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 did not 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 int64 minimum_bid_to_win = 7;

  // The minimum bid value necessary to have won the server-side component of
  // the overall auction given that there was also an interest group bidding
  // component to the overall auction which ran using the Protected Audience
  // API. The value is expressed in CPM micros of the buyer account currency.
  // The minimum bid to win for the overall auction, including bids from the
  // server-side and the on-device interest group components, is populated in
  // the minimum_bid_to_win field of the same BidResponseFeedback object.
  optional int64 server_side_component_minimum_bid_to_win = 16;

  // 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 = 15 [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 micros of your account currency.
  optional int64 sampled_mediation_cpm_ahead_of_auction_winner = 10;

  // Event notification token that was included in the bid response.
  optional bytes event_notification_token = 5;

  // Buyer creative ID that was included in the bid response.
  optional string buyer_creative_id = 6;

  // Possible types of bid response feedback objects.
  enum FeedbackType {
    FEEDBACK_TYPE_UNSPECIFIED = 0;

    // Feedback for a bid that was submitted on a bid response.
    BID_FEEDBACK = 1;

    // Feedback for an interest group buyer submitted on a bid response to
    // particpate in an interest group bidding component of the auction run
    // using the Protected Audience API.
    INTEREST_GROUP_BUYER_FEEDBACK = 2;
  }

  // The type of the BidResponseFeedback message. Google will send separate
  // BidResponseFeedback objects for:
  // a) Each bid submitted on a bid response
  // b) Each buyer submitted on a bid response to particpate in an interest
  // group bidding component of the auction run using the Protected Audience
  // API.
  optional FeedbackType feedback_type = 17;

  // Origin of an interest group buyer that was included in the bid response.
  // This field is populated only for feedback where a bidder opted in an
  // interest group buyer to participate in the interest group bidding
  // component of the overall auction run using the Protected Audience API.
  // To learn more about origins, see https://www.rfc-editor.org/rfc/rfc6454.
  // To learn more about interest group bidding and the Protected Audience
  // API, see
  // https://developers.google.com/authorized-buyers/rtb/fledge-origin-trial.
  optional string buyer_origin = 18;

  // The status code for the submitted interest group buyer. This field is
  // only populated in the feedback for an interest group buyer that a bidder
  // requested to enter into the interest group auction through the bid
  // response. Individual creative status codes of bids submitted by the buyer
  // in the on-device interest group auction are not available. See
  // https://storage.googleapis.com/adx-rtb-dictionaries/interest-group-buyer-status-codes.txt
  // for a list of interest group buyer status codes.
  optional int32 interest_group_buyer_status_code = 19;
}

इस मैसेज के बाद, आपको पहली फ़ील्ड की जांच करनी होगी: bid_response_feedback.creative_status_code; तो कोड ढूंढने के लिए में मतलब क्रिएटिव-स्टेटस-कोड्स.txt. ध्यान दें कि बिड जीतने पर, आपके पास ऑप्ट आउट करने का विकल्प होता है कीमत के बारे में आपके सुझाव, राय या शिकायत से. ज़्यादा जानकारी के लिए, ऑप्ट-आउट करें.

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

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

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

नमूना

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

Google

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 पर सेट किया जाएगा अगर पब्लिशर SDK टूल का इस्तेमाल नहीं करता है या पब्लिशर, SDK टूल का इस्तेमाल नहीं करता है, तो मध्यस्थता.

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

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

  • यहां दी गई वैल्यू, मीडिएशन चेन में सीपीएम को घटते क्रम में दिखाती है:
    \[C_1, C_2, …, C_n\]
  • नीचे दिए गए फ़ॉर्मैट में सीपीएम के लिए, फ़िल रेट के बारे में जानकारी दी गई है मीडिएशन चेन:
    \[f_1, f_2, …, f_n\]
  • अपेक्षित CPM और इसके दिए गए फ़िल के आधार पर मीडिएशन चेन एलिमेंट \(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\) संभावना के साथ \(\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\}\)

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

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

SDK टूल की मीडिएशन चेन अनुमानित सीपीएम फ़िल रेट
नेटवर्क 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\%\)

आरटीबी नीलामी के नतीजे के रूप में नीचे दिया गया मान मान लें:

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

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

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

नीचे दिए गए फ़ॉर्मैट वाले बिड रिक्वेस्ट के तहत अलग-अलग बोली अनुरोध:

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

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

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

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

पोस्ट-फ़्लैटन

डील

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

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

Google का प्रोटोकॉल और OpenRTB लागू करने की प्रक्रिया, इन फ़ील्ड के साथ काम करती है वीडियो की अवधि और स्किप किए जा सकने की अवधि के लिए:

कुल समय स्किप किए जा सकने वाले वीडियो की अवधि स्किप किए जा सकने की सुविधा
Google प्रोटोकॉल max_ad_duration skippable_max_ad_duration video_ad_skippable
OpenRTB maxduration लागू नहीं skip

इसका मतलब है कि Google प्रोटोकॉल में विस्तृत स्किप किया जा सकता है और स्किप न किए जा सकने वाले कुल समय के लिए, OpenRTB लागू करने पर सिर्फ़ एक अवधि के लिए ज़्यादा से ज़्यादा वैल्यू.

बिड को फ़्लैट करने से पहले, OpenRTB का maxduration इस पर सेट होगा: Google प्रोटोकॉल के max_ad_duration और skippable_max_ad_duration फ़ील्ड. यह व्यवहार अब इसमें बदल गया है इन मानों के बीच अंतर होने पर दो अलग बोली अनुरोध भेजना: एक स्किप किए जा सकने वाले के लिए maxduration और स्किप न किए जा सकने वाले के लिए दूसरा अवसर.

ये उदाहरण बताते हैं कि Google प्रोटोकॉल के अनुरोध का अनुवाद कैसे होता है तय करें कि आपका बिड फ़्लैट होने से पहले और बाद में OpenRTB तक पहुंच गया है या नहीं. इससे मिलता-जुलता Google प्रोटोकॉल अनुरोध में 15 का max_ad_duration और 60 में से skippable_max_ad_duration.

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

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

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

आप अपने तकनीकी विज्ञापन देने वालों से संपर्क करके, इस तरह के बदलाव से ऑप्ट आउट कर सकते हैं खाता मैनेजर.

वीडियो पॉड

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

'मेज़रमेंट' खोलें

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

यह तय किया जा सकता है कि कोई पब्लिशर, बिड में ओपन मेज़रमेंट की सुविधा देता है या नहीं अनुरोध करने के लिए, यह पता करें कि विज्ञापन के अवसर में, प्रकाशक के लिए उपलब्ध नहीं है" में मिले OmsdkType: OMSDK 1.0 एट्रिब्यूट को शामिल नहीं किया गया है क्रिएटिव एट्रिब्यूट का इस्तेमाल करें. Authorized Buyers प्रोटोकॉल के लिए, यह BidRequest.adslot[].excluded_attribute के अंतर्गत मिले. OpenRTB प्रोटोकॉल, यह battr एट्रिब्यूट में मिलेगा बैनर के लिए या वीडियो, इसके आधार पर फ़ॉर्मैट.

'ओपन' कीवर्ड को शामिल करने वाले बिड रिक्वेस्ट को समझने के तरीके के बारे में ज़्यादा जानकारी के लिए मेज़रमेंट सिग्नल, ओपन मेज़रमेंट देखें SDK टूल के बारे में सहायता केंद्र का लेख.

बोली अनुरोधों के नमूने

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

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

Google

OpenRTB JSON

ओपनआरटीबी प्रोटोबफ़

ऐप्लिकेशन मध्यवर्ती

Google

OpenRTB JSON

ओपनआरटीबी प्रोटोबफ़

ऐप्लिकेशन पर अचानक दिखने वाला वीडियो

Google

ओपनआरटीबी प्रोटोबफ़

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

Google

OpenRTB JSON

ओपनआरटीबी प्रोटोबफ़

वेब वीडियो

Google

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

ओपनआरटीबी प्रोटोबफ़