درخواست را پردازش کنید

زمانی که Google یک درخواست پیشنهاد برای برنامه شما ارسال می‌کند، تعامل زمان واقعی مناقصه آغاز می‌شود. این راهنما نحوه کدگذاری درخواست خود را برای پردازش درخواست پیشنهاد توضیح می دهد.

درخواست Protobuf را تجزیه کنید

Google یک درخواست پیشنهاد را به عنوان یک بافر پروتکل سریالی که به عنوان بار دودویی یک درخواست HTTP POST پیوست شده است، ارسال می کند. Content-Type روی application/octet-stream تنظیم شده است. برای نمونه به نمونه درخواست پیشنهاد قیمت مراجعه کنید.

شما باید این درخواست را در یک نمونه از پیام BidRequest تجزیه کنید. بسته به پروتکل انتخابی شما، BidRequest در openrtb.proto یا realtime-bidding.proto منسوخ شده تعریف می‌شود که می‌توانید از صفحه داده‌های مرجع دریافت کنید. می توانید پیام را با استفاده از متد ParseFromString() در کلاس تولید شده برای 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 مشخص کنید.

فایل های دیکشنری

درخواست مناقصه از شناسه های تعریف شده در فایل های فرهنگ لغت استفاده می کند که در صفحه داده های مرجع موجود است.

ماکروهای URL پیشنهاد پروتکل Google RTB

به صورت اختیاری، برخی از فیلدهای BidRequest را می توان در URL مورد استفاده در درخواست HTTP POST درج کرد. این مفید است، برای مثال، اگر از یک فرانت اند سبک استفاده می کنید که با استفاده از مقداری از درخواست، روی چندین پشتیبان تعادل بارگذاری می کند. برای درخواست پشتیبانی از ماکروهای جدید، با مدیر حساب فنی خود تماس بگیرید.

ماکرو توضیحات
%%GOOGLE_USER_ID%%

با google_user_id از BidRequest جایگزین شد. به عنوان مثال، URL پیشنهاد دهنده

http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%%
با چیزی شبیه به جایگزین خواهد شد
http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl
در زمان درخواست

اگر شناسه کاربری Google ناشناخته باشد، رشته خالی جایگزین می‌شود و نتیجه مشابهی دارد

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

هنگام فراخوانی has_mobile() با 1 یا 0 BidRequest جایگزین می شود.

%%HAS_VIDEO%%

با 1 (درست) یا 0 (نادرست) در هنگام فراخوانی BidRequest 's has_video() جایگزین می شود.

%%HOSTED_MATCH_DATA%%

با مقدار قسمت hosted_match_data از BidRequest جایگزین شد.

%%MOBILE_IS_APP%%

با 1 (درست) یا 0 (نادرست) از قسمت mobile.is_app BidRequest جایگزین شده است.

شناسه برنامه تلفن همراه را از URL تراکنش پیدا کنید

تراکنش‌های برنامه تلفن همراه نشانی‌های اینترنتی را گزارش می‌کنند که شبیه به این هستند:

mbappgewtimrzgyytanjyg4888888.com

از رمزگشای پایه 32 برای رمزگشایی بخشی از رشته به صورت پررنگ استفاده کنید ( gewtimrzgyytanjyg4888888 ).

می‌توانید از رمزگشای آنلاین استفاده کنید، اما باید حروف را بزرگ بنویسید و 8 ثانیه را با مقادیر = جایگزین کنید.

بنابراین رمزگشایی این مقدار:

GEWTIMRZGYYTANJYG4======
منجر به:
1-429610587
رشته 429610587 شناسه برنامه برای برنامه iOS iFunny است.

در اینجا یک مثال دیگر است. URL گزارش شده این است:

mbappgewtgmjug4ytmmrtgm888888.com
رمزگشایی این مقدار:
GEWTGMJUG4YTMMRTGM======
منجر به:
1-314716233
نتیجه 314716233 شناسه برنامه برای برنامه iOS TextNow است.

نام برنامه تلفن همراه را از URL تراکنش پیدا کنید

در اینجا نمونه ای از دریافت نام برنامه آورده شده است. URL گزارش شده به شرح زیر است:

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
رمزگشایی این مقدار:
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
منجر به:
air.com.hypah.io.slither
نتیجه برابر با برنامه Android slither.io است.

باز کردن زمینه های مناقصه

درخواست‌های پیشنهادی ارسال شده به مناقصه‌گران مبادله‌ای و شبکه‌ای که در مناقصه آزاد شرکت می‌کنند مشابه درخواست‌های خریداران مجاز شرکت‌کننده در مناقصه استاندارد بلادرنگ است. مشتریان مناقصه باز تعداد کمی فیلد اضافی دریافت خواهند کرد و تعدادی از فیلدهای موجود ممکن است کاربردهای جایگزین داشته باشند. این موارد شامل موارد زیر است:

OpenRTB خریداران مجاز جزئیات
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 آنها را برای مشارکت در تعاملات خریداران مجاز بررسی کرده است.

برای درک 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

Google (منسوخ شده)

برای تبدیل درخواست مناقصه به فرم باینری، همانطور که از بار 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
  }
}

بازخورد در زمان واقعی

بازخورد بلادرنگ برای خریداران مجاز و همچنین مبادلات و شبکه‌ها با استفاده از مناقصه باز در دسترس است.

بازخورد پاسخ پیشنهادی در درخواست پیشنهادی بعدی هم برای OpenRTB و هم برای پروتکل منسوخ شده Google RTB پشتیبانی می‌شود. برای OpenRTB، در BidRequest.ext.bid_feedback ارسال می شود.

علاوه بر فیلدهای پیش‌فرض ارسال شده در بازخورد پاسخ پیشنهادی، می‌توانید با استفاده از فیلد BidResponse.seatbid.bid.ext.event_notification_token ، داده‌های سفارشی را در پاسخ پیشنهاد ارسال کنید. event_notification_token داده‌های دلخواه است که فقط برای پیشنهاد دهنده شناخته می‌شود و ممکن است به اشکال‌زدایی کمک کند، برای مثال: شناسه هدف‌گیری جدید یا شناسه پیشنهادی که نشان‌دهنده یک تاکتیک جدید است، یا ابرداده مرتبط با خلاقیتی که فقط برای پیشنهاد دهنده شناخته شده است. برای جزئیات، به بافر پروتکل برنامه‌های افزودنی OpenRTB برای OpenRTB یا پروتکل منسوخ شده Google RTB مراجعه کنید.

هنگامی که خریداران مجاز درخواست پیشنهادی را برای مناقصه‌دهنده ارسال می‌کنند، مناقصه‌دهنده با یک BidResponse پاسخ می‌دهد. اگر پیشنهاد دهنده بازخورد بلادرنگ را فعال کرده باشد، در یک درخواست پیشنهادی بعدی، خریداران مجاز بازخوردی را در مورد پاسخ در یک پیام 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 پیدا کنید. توجه داشته باشید که در صورت برنده شدن در مناقصه، می توانید از بازخورد قیمت انصراف دهید. برای اطلاعات بیشتر، نحوه انصراف را ببینید.

بازخورد بلادرنگ شامل شناسه درخواست پیشنهاد و یکی از موارد زیر است:

نتیجه حراج بازخورد در زمان واقعی
خریدار پیشنهادی ارائه نکرده است. هیچی.
خریدار پیشنهادی را ارسال کرد که قبل از رسیدن به حراج فیلتر شد. کد وضعیت خلاقیت ( creative-status-codes.txt ).
خریدار پیشنهاد داد اما حراج را باخت. کد وضعیت خلاقیت 79 (بیش از پیش در مزایده).
خریدار پیشنهادی را ارائه کرد که برنده حراج شد. قیمت تسویه و کد وضعیت خلاقیت 1 .

برای نمایش برنامه و کد وضعیت خلاقانه 83 ، ناشر برنامه می‌توانست از یک آبشار میانجی استفاده کند و بنابراین پیشنهاد برنده با سایر تقاضاها در زنجیره آبشار پس‌انداز ناشر رقابت می‌کرد. با نحوه استفاده از sampled_mediation_cpm_ahead_of_auction_winner هنگام مناقصه آشنا شوید .

نمونه

در زیر نمونه ای از بازخورد بلادرنگ همانطور که در پروتکل های پشتیبانی شده دیده می شود، آمده است:

OpenRTB Protobuf

OpenRTB JSON

Google (منسوخ شده)

یک مدل پیشنهادی برای مزایده های قیمت اول بسازید

پس از ارائه یک پیشنهاد در یک حراج قیمت اول، در صورتی که پیشنهاد از حراج فیلتر نشده باشد، بازخورد بلادرنگی از جمله فیلدهای 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 ، ابتدا باید موارد زیر را تعریف کنیم:

  • موارد زیر CPM ها را در زنجیره میانجی به ترتیب نزولی نشان می دهد:
    \[C_1, C_2, …, C_n\]
  • موارد زیر نرخ پر شدن مربوطه را برای CPM ها در زنجیره میانجی نشان می دهد:
    \[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
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
sampled_mediation_cpm_ahead_ of_auction_winner
\(max\{X_1, …, X_K\}\)

مثال با یک زنجیره میانجی ساده

فرض کنید یک ناشر از مناقصه بلادرنگ و زنجیره میانجی SDK به شرح زیر استفاده می کند:

زنجیره میانجی SDK CPM مورد انتظار نرخ پر کردن
شبکه 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\%\)

موارد زیر را به عنوان نتیجه حراج RTB فرض کنید:

حراج RTB CPM
برنده حراج (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
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
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\%\)

مسطح کردن پیشنهاد

Bid Flattening پردازش یک BidRequest منفرد را به چندین درخواست پیشنهادی که به درخواست شما ارسال می شود، توصیف می کند. هنگامی که یک درخواست پیشنهاد مسطح می‌شود، می‌توانید تشخیص دهید که کدام درخواست‌های پیشنهادی بخشی از نسخه اصلی بوده‌اند، زیرا در فیلد BidRequest.ext.google_query_id مقدار یکسانی دارند.

Bid Flattening به طور پیش فرض فعال است، اما اگر ترجیح می دهید آن را غیرفعال کنید، می توانید با مدیر حساب خود تماس بگیرید.

فرمت های تبلیغاتی

برخی از فرصت های تبلیغاتی می توانند چندین قالب را بپذیرند. با یکنواخت کردن پیشنهاد، هر قالب در یک درخواست پیشنهادی مجزا ارسال می‌شود که در آن ویژگی‌هایی مانند شناسه‌های صورت‌حساب واجد شرایط با قالب مشخص‌شده در درخواست مرتبط هستند.

درخواست‌های پیشنهادی حاوی فرمت‌های زیر به درخواست‌های پیشنهادی مجزا تبدیل می‌شوند:

  • بنر
  • ویدئو
  • صوتی
  • بومی

مثال صاف کردن قالب تبلیغات

در زیر مثالی نشان می‌دهد که یک درخواست پیشنهادی OpenRTB JSON ساده شده را بدون صاف کردن قالب آگهی در مقایسه با مجموعه‌ای معادل از درخواست‌های مسطح نشان می‌دهد:

از قبل صاف کنید

پس از صاف کردن

معاملات

یک فرصت تبلیغاتی برای یک مناقصه‌دهنده می‌تواند برای انواع مختلف معاملات، علاوه بر حراج آزاد، قابل استفاده باشد. با یکنواخت شدن پیشنهاد برای معاملات، یک درخواست پیشنهاد برای حراج آزاد و یک درخواست برای هر نوع معامله با قیمت ثابت ارسال می شود. در عمل، محدودیت‌های تبلیغاتی می‌تواند بین انواع حراج‌ها و انواع معاملات با قیمت ثابت متفاوت باشد، به عنوان مثال، برای یک فرصت تبلیغ ویدیویی معین که هم برای حراج آزاد و هم برای یک معامله با قیمت ثابت در دسترس است، یک پیشنهاد دهنده درخواست‌های پیشنهادی مجزایی را برای هر جایی دریافت می‌کند. محدودیت‌هایی مانند حداکثر مدت زمان تبلیغ و اینکه آیا تبلیغات قابل رد شدن مجاز هستند یا نه، می‌توانند متفاوت باشند. در نتیجه، هموارسازی اعمال شده در فرصت تبلیغات به شما امکان می‌دهد به راحتی محدودیت‌های تبلیغاتی برای حراج آزاد و معامله با قیمت ثابت را تشخیص دهید.

حداکثر مدت زمان ویدیو قابل رد شدن

پروتکل Google و اجرای OpenRTB از فیلدهای زیر برای مدت زمان و قابلیت رد شدن ویدیو پشتیبانی می کند:

مدت زمان مدت زمان قابل رد شدن قابلیت پرش
پروتکل گوگل max_ad_duration skippable_max_ad_duration video_ad_skippable
OpenRTB maxduration n/a skip

این به این معنی است که در حالی که پروتکل Google می تواند یک مدت زمان گرانول قابل پرش و غیرقابل رد شدن داشته باشد، پیاده سازی OpenRTB تنها دارای یک مقدار حداکثر مدت زمان است.

قبل از صاف کردن قیمت پیشنهادی، maxduration OpenRTB روی قسمت پایین‌ترین قسمت max_ad_duration و skippable_max_ad_duration پروتکل Google تنظیم می‌شود. این رفتار اکنون به ارسال دو درخواست پیشنهاد جداگانه در زمانی که این مقادیر متفاوت هستند تغییر کرده است: یکی نشان دهنده maxduration برای فرصت های قابل رد شدن و دیگری برای فرصت های غیر قابل رد شدن است.

مثال‌های زیر نشان می‌دهند که چگونه یک درخواست پروتکل Google قبل و بعد از صاف کردن پیشنهاد به OpenRTB ترجمه می‌شود. درخواست پروتکل معادل Google دارای max_ad_duration 15 و skippable_max_ad_duration 60 است.

مثال max_ad_duration skip (درست یا نادرست)
درخواست اصلی بدون صاف کردن 15 true
درخواست مسطح شماره 1: غیر قابل رد شدن 15 false
درخواست مسطح شماره 2: قابل گذشت 60 true

صاف کردن درخواست مدت زمان ویدیوی قابل رد شدن فقط زمانی انجام می شود که این شرایط رعایت شود:

  • درخواست اجازه ویدیو را می دهد.
  • هر دو ویدیوی پرش و بدون پرش مجاز هستند و دو مدت زمان حداکثر مربوطه از نظر ارزش متفاوت هستند.
  • این درخواست برای حراج خصوصی یا حراج باز واجد شرایط است.
  • حساب پیشنهاد دهنده دارای نقاط پایانی OpenRTB فعال است.

می توانید با تماس با مدیر حساب فنی خود از این نوع صاف کردن انصراف دهید.

غلاف های ویدیویی

درخواست‌های پیشنهاد برای یک غلاف ویدیویی با فرصت‌های تبلیغاتی متعدد، مسطح می‌شوند، به‌طوری‌که هر درخواست پیشنهاد برای یک فرصت آگهی جداگانه از آن غلاف است. این به شما امکان می‌دهد برای یک پاد خاص برای چندین فرصت تبلیغاتی پیشنهاد دهید.

باز کردن اندازه‌گیری

Open Measurement به شما امکان می‌دهد فروشنده‌های شخص ثالثی را مشخص کنید که خدمات اندازه‌گیری و تأیید مستقلی را برای تبلیغات ارائه‌شده در محیط‌های برنامه تلفن همراه ارائه می‌کنند.

می‌توانید با بررسی اینکه آیا فرصت آگهی ویژگی OmsdkType: OMSDK 1.0 موجود در ویژگی‌های خلاق قابل استثناء ناشر را در نظر نمی‌گیرد، تعیین کنید که آیا ناشر از اندازه‌گیری باز در درخواست پیشنهاد قیمت پشتیبانی می‌کند یا خیر. بسته به فرمت، این مورد در زیر ویژگی battr برای بنر یا ویدیو یافت می شود.

برای اطلاعات بیشتر درباره نحوه تفسیر درخواست‌های پیشنهادی حاوی سیگنال‌های اندازه‌گیری باز، به مقاله مرکز راهنمای Open Measurement SDK مراجعه کنید.

نمونه درخواست های پیشنهادی

بخش های زیر نمونه درخواست های پیشنهادی برای انواع مختلف تبلیغات را نشان می دهد.

بنر اپلیکیشن

OpenRTB Protobuf

OpenRTB JSON

Google (منسوخ شده)

برنامه بینابینی

OpenRTB Protobuf

OpenRTB JSON

Google (منسوخ شده)

ویدیوی بینابینی برنامه

OpenRTB Protobuf

Google (منسوخ شده)

بومی برنامه

OpenRTB Protobuf

OpenRTB JSON

Google (منسوخ شده)

ویدئوی وب

Google (منسوخ شده)

بنر وب موبایل برای پیشنهاد دهنده مبادله

OpenRTB Protobuf