संग्रह की मदद से व्यवस्थित रहें
अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.
रीयल-टाइम बिडिंग इंटरैक्शन तब शुरू होता है, जब Google आपके ऐप्लिकेशन को बिड का अनुरोध भेजता है. इस गाइड में, बिड रिक्वेस्ट को प्रोसेस करने के लिए, अपने ऐप्लिकेशन को कोड करने का तरीका बताया गया है.
प्रोटोबफ़ अनुरोध को पार्स करना
Google एक बोली अनुरोध को
एचटीटीपी पीओएसटी अनुरोध का बाइनरी पेलोड. Content-Type को application/octet-stream पर सेट किया गया है. उदाहरण के लिए, बिड रिक्वेस्ट का उदाहरण देखें.
आपको इस अनुरोध को BidRequest मैसेज के इंस्टेंस में पार्स करना होगा. आपके चुने गए प्रोटोकॉल के आधार पर, BidRequest को openrtb.proto या अब इस्तेमाल में न होने वाले realtime-bidding.proto में से किसी एक में तय किया जाता है. इसे रेफ़रंस डेटा पेज से पाया जा सकता है. BidRequest के लिए जनरेट की गई क्लास में, ParseFromString() तरीके का इस्तेमाल करके मैसेज को पार्स किया जा सकता है. उदाहरण के लिए, नीचे दिया गया 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 फ़ील्ड.
डिक्शनरी फ़ाइलें
बिड रिक्वेस्ट, डिक्शनरी फ़ाइलों में तय किए गए आइडेंटिफ़ायर का इस्तेमाल करता है. ये आइडेंटिफ़ायर, रेफ़रंस डेटा पेज पर उपलब्ध होते हैं.
Google आरटीबी प्रोटोकॉल बिड यूआरएल मैक्रो
विकल्प के तौर पर, BidRequest के कुछ फ़ील्ड को
इसका इस्तेमाल एचटीटीपी पोस्ट अनुरोध में किया गया यूआरएल होता है. यह उपयोगी होता है, उदाहरण के लिए, अगर
एक लाइटवेट फ़्रंटएंड, जो एक वैल्यू का इस्तेमाल करके कई बैकएंड पर बैलेंस लोड करता है
अनुरोध से. नए मैक्रो के लिए सहायता पाने का अनुरोध करने के लिए, अपने तकनीकी खाता मैनेजर से संपर्क करें.
मैक्रो
ब्यौरा
%%GOOGLE_USER_ID%%
BidRequest से google_user_id पर बदला गया. उदाहरण के लिए, बिड करने वाले का यूआरएल
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
इस वैल्यू को डिकोड करना:
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 बनाने के लिए, आपको टेक्नोलॉजी वेंडर को एलान करने के दो अलग-अलग तरीकों के बारे में पता होना चाहिए:
दूसरे वेंडर सिर्फ़ तब हिस्सा ले सकते हैं, जब उनके बारे में
BidRequest:
BidRequest में,
BidRequest.imp.ext.allowed_vendor_type फ़ील्ड के बारे में जानकारी
कि विक्रेता अनुमति देता है. allowed_vendor_type में भेजे जाने वाले वेंडर,
vendors.txt
डिकशनरी फ़ाइल में मौजूद होते हैं.
बिड रिक्वेस्ट का उदाहरण
यहां दिए गए उदाहरणों में, Protobuf और JSON अनुरोधों के ऐसे सैंपल दिए गए हैं जिन्हें कोई भी व्यक्ति आसानी से पढ़ सकता है.
बिड रिक्वेस्ट को बाइनरी फ़ॉर्म में बदलने के लिए, C++ में यह तरीका अपनाएं. ऐसा करने पर, आपको रीयल रिक्वेस्ट में POST पेलोड जैसा ही डेटा मिलेगा. हालांकि, ध्यान दें कि यह तरीका 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 के लिए भी उपलब्ध है
ओपन बिडिंग का इस्तेमाल, एक्सचेंज और नेटवर्क के तौर पर किया जा सकता है.
बिड रिस्पॉन्स फ़ीडबैक, OpenRTB और अब काम न करने वाले Google आरटीबी प्रोटोकॉल, दोनों के लिए अगले बिड रिक्वेस्ट पर काम करता है. OpenRTB के लिए, इसे
BidRequest.ext.bid_feedback.
बिड रिस्पॉन्स के सुझाव में भेजे गए डिफ़ॉल्ट फ़ील्ड के अलावा, ये काम किए जा सकते हैं
आपको कस्टम डेटा भी भेजना है. इसके लिए,
BidResponse.seatbid.bid.ext.event_notification_token फ़ील्ड. कॉन्टेंट बनाने
event_notification_token आर्बिट्रेरी डेटा है, जो केवल
बिडर जो डीबग करने में मदद कर सकते हैं, उदाहरण के लिए: एक नया टारगेटिंग आईडी या
नई रणनीति या क्रिएटिव से जुड़े मेटाडेटा को दिखाने वाला बिडिंग आईडी
जानकारी सिर्फ़ बोली लगाने वाले को मिलती है. ज़्यादा जानकारी के लिए, OpenRTB या अब इस्तेमाल में न होने वाले Google आरटीबी प्रोटोकॉल के लिए, 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;
// 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;
// The minimum bid value necessary to have 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 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 double minimum_bid_to_win = 6;
// 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 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 BidFeedback object.
optional double sscminbidtowin = 14;
// 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;
// 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 BidFeedback message. Google will send separate
// BidFeedback 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 feedbacktype = 15;
// 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 buyerorigin = 16;
// 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 igbuyerstatus = 17;
}
इस मैसेज में, आपको सबसे पहले bid_feedback.creative_status_code फ़ील्ड की जांच करनी चाहिए. कोड का मतलब,
creative-status-codes.txt में देखा जा सकता है. ध्यान दें कि अगर बिड जीत जाती है, तो कीमत के सुझाव से ऑप्ट आउट किया जा सकता है. ज़्यादा जानकारी के लिए,
ऑप्ट-आउट करें.
रीयल-टाइम फ़ीडबैक में बिड रिक्वेस्ट आईडी और इनमें से कोई एक जानकारी शामिल होती है:
नीलामी का नतीजा
रीयल-टाइम में सुझाव, राय या शिकायतें पाना
खरीदार ने बिड सबमिट नहीं की.
कुछ नहीं.
खरीदार ने एक ऐसी बोली सबमिट की, जिसे पहुंचने से पहले फ़िल्टर करके बाहर कर दिया गया था
को नहीं चुना है.
फ़र्स्ट-प्राइस ऑक्शन मॉडल के लिए बिडिंग मॉडल बनाएं
फ़र्स्ट-प्राइस ऑक्शन मॉडल में बिड लगाने के बाद, आपको रीयल-टाइम में
सुझाव, राय या शिकायत. इसमें minimum_bid_to_win और
अगर बोली लगाना है, तो sampled_mediation_cpm_ahead_of_auction_winner फ़ील्ड
नीलामी से फ़िल्टर नहीं किया गया. इन सिग्नल का इस्तेमाल करके,
आपकी बिड कितनी ज़्यादा या कम हो सकती थी, इस आधार पर बिडिंग का लॉजिक
इंप्रेशन जीतते हैं.
minimum_bid_to_win: रीयल-टाइम बिडिंग नीलामी में जीतने के लिए, कम से कम इतनी बिड लगाई जा सकती थी. अगर आप नीलामी जीत जाते हैं, तो
यह सबसे कम बिड होगी जो जीतते हुए भी लगाई जा सकती थी. अगर आपने नीलामी में हिस्सा नहीं लिया है, तो यह बिड जीतने वाली बिड होगी.
sampled_mediation_cpm_ahead_of_auction_winner: अगर मीडिएशन चेन में अन्य नेटवर्क हैं, तो इस फ़ील्ड की वैल्यू, ज़रूरी शर्तें पूरी करने वाले किसी एक मीडिएशन नेटवर्क की सैंपल बिड की कीमत होती है. यह बिड, नीलामी में जीतने वाली बिड से ज़्यादा होती है और इसे अनुमानित फ़िल दर के हिसाब से तय किया जाता है. अगर मीडिएशन चेन में मौजूद कोई भी नेटवर्क, विज्ञापन नहीं दिखाता है या पब्लिशर, SDK टूल के ज़रिए मीडिएशन का इस्तेमाल नहीं करता है, तो यह वैल्यू 0 पर सेट हो जाएगी.
यह कैसे काम करता है
संभावित वैल्यू तय करने के लिए इस्तेमाल की जाने वाली कैलकुलेशन के बारे में बताने के लिए
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\) with probability \(f_i\); \(0\) with probability \(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 टूल मीडिएशन चेन
अनुमानित सीपीएम
फ़िल रेट
पहला नेटवर्क
\(C_1 = $3.00\)
\(f_1 = 5\%\)
दूसरा नेटवर्क
\(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 और 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 बिड रिक्वेस्ट को दिखाया गया है:
किसी बिडिंग करने वाले को विज्ञापन दिखाने का अवसर कई डील के लिए लागू किया जा सकता है
खुली नीलामी के अलावा टाइप के बारे में भी बताएँ. डील के लिए बिड को एक जैसा करने की सुविधा चालू होने पर, एक बिड का अनुरोध ओपन ऑक्शन के लिए और एक अनुरोध हर तरह के तय कीमत वाले डील के लिए भेजा जाएगा. व्यावहारिक तौर पर, नीलामी और तय कीमत के बीच विज्ञापन की सीमाएं अलग-अलग हो सकती हैं
डील टाइप: उदाहरण के लिए, किसी वीडियो विज्ञापन के अवसर के लिए जो
खुली नीलामी और फ़िक्स्ड प्राइस डील, दोनों के लिए बिड करने वाले व्यक्ति को
बिड रिक्वेस्ट के लिए बिड रिक्वेस्ट
स्किप किए जा सकने वाले विज्ञापनों के विकल्प अलग-अलग हो सकते हैं. इस वजह से, विज्ञापन अवसर पर फ़्लैट करने की सुविधा लागू करने से, आपको ओपन बिडिंग और तय कीमत वाले ऑफ़र के लिए, विज्ञापन की पाबंदियों को आसानी से समझने में मदद मिलती है.
स्किप किए जा सकने वाले वीडियो की ज़्यादा से ज़्यादा अवधि
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 एंडपॉइंट हों.
अपने तकनीकी खाता मैनेजर से संपर्क करके, इस तरह के फ़्लैट करने की सुविधा से ऑप्ट आउट किया जा सकता है.
वीडियो पॉड
एक से ज़्यादा विज्ञापन अवसरों वाले वीडियो पॉड के लिए बिड रिक्वेस्ट को फ़्लैट किया जाता है,
ताकि हर बिड रिक्वेस्ट उस पॉड के किसी एक विज्ञापन अवसर के लिए हो.
इससे, किसी पॉड के लिए विज्ञापन दिखाने के एक से ज़्यादा अवसरों पर बिडिंग की जा सकती है.
Open Measurement
Open Measurement की मदद से, तीसरे पक्ष के उन वेंडर की जानकारी दी जा सकती है जो मोबाइल ऐप्लिकेशन के एनवायरमेंट में दिखाए जाने वाले विज्ञापनों के लिए, मेज़रमेंट और पुष्टि करने की सेवाएं स्वतंत्र तौर पर उपलब्ध कराते हैं.
यह पता लगाया जा सकता है कि कोई पब्लिशर, बिड रिक्वेस्ट में ओपन मेज़रमेंट की सुविधा देता है या नहीं. इसके लिए, यह देखें कि विज्ञापन अवसर में, पब्लिशर के लिए उपलब्ध क्रिएटिव एट्रिब्यूट में मौजूद OmsdkType:
OMSDK 1.0 एट्रिब्यूट को शामिल किया गया है या नहीं. यह जानकारी, फ़ॉर्मैट के आधार पर battrबैनर या वीडियो एट्रिब्यूट में दिखेगी.
Open Measurement सिग्नल वाले बिड रिक्वेस्ट का विश्लेषण करने के तरीके के बारे में ज़्यादा जानने के लिए, Open Measurement SDK के सहायता केंद्र का लेख पढ़ें.
बिड रिक्वेस्ट के सैंपल
नीचे दिए गए सेक्शन में, अलग-अलग तरह के विज्ञापनों के लिए बिड रिक्वेस्ट के सैंपल दिखाए गए हैं.
[[["समझने में आसान है","easyToUnderstand","thumb-up"],["मेरी समस्या हल हो गई","solvedMyProblem","thumb-up"],["अन्य","otherUp","thumb-up"]],[["वह जानकारी मौजूद नहीं है जो मुझे चाहिए","missingTheInformationINeed","thumb-down"],["बहुत मुश्किल है / बहुत सारे चरण हैं","tooComplicatedTooManySteps","thumb-down"],["पुराना","outOfDate","thumb-down"],["अनुवाद से जुड़ी समस्या","translationIssue","thumb-down"],["सैंपल / कोड से जुड़ी समस्या","samplesCodeIssue","thumb-down"],["अन्य","otherDown","thumb-down"]],["आखिरी बार 2024-10-16 (UTC) को अपडेट किया गया."],[],[]]