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

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

تجزیه درخواست

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

شما باید این درخواست را در یک نمونه از پیام BidRequest تجزیه کنید. BidRequest در 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++: 

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

اطلاعات مربوط به گروه تبلیغاتی پیش هدفمند در گروه MatchingAdData برای هر AdSlot موجود است. این شامل اولین شناسه گروه آگهی منطبق از گروه تبلیغاتی پیش‌هدف‌سازی است که از Google خواسته بود درخواست پیشنهاد را ارسال کند، یعنی گروه آگهی و کمپینی که در صورت برنده شدن پاسخ شما در حراج برای نمایش، هزینه دریافت می‌شود. تحت شرایط خاص، باید به صراحت billing_id برای انتساب در BidResponse.AdSlot مشخص کنید، برای مثال، زمانی که BidRequest.AdSlot بیش از یک matching_ad_data دارد. برای کسب اطلاعات بیشتر در مورد محدودیت‌های محتوای پیشنهاد، به realtime-bidding.proto مراجعه کنید.

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

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

پیشنهاد ماکروهای URL

به صورت اختیاری، برخی از فیلدهای 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. برخی از فروشندگان نیازی به اعلام ندارند. این فروشندگان در راهنمای خریداران مجاز فهرست شده اند.
  2. سایر فروشندگان تنها در صورتی می توانند شرکت کنند که در BidRequest و BidResponse اعلام شده باشند:
    • در BidRequest ، فیلد allowed_vendor_type مشخص می‌کند که فروشنده به کدام فروشنده اجازه می‌دهد. فروشندگانی که در قسمت allowed_vendor_type BidRequest ارسال می شوند در فایل فرهنگ لغت Vendors.txt فهرست شده اند.
    • در BidResponse ، فیلد vendor_type مشخص می‌کند که خریدار قصد استفاده از کدام یک از فروشندگان مجاز را دارد.

نمونه درخواست مناقصه

نمونه‌های زیر نمونه‌های قابل خواندن توسط انسان از درخواست‌های Protobuf و JSON را نشان می‌دهند.

گوگل

OpenRTB JSON

OpenRTB Protobuf

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

بازاریابی مجدد

خریداران مجاز شناسه تبلیغات تلفن همراه را در درخواست های پیشنهادی از یک برنامه تلفن همراه ارسال می کنند. شناسه تبلیغات تلفن همراه می‌تواند IDFA iOS یا شناسه تبلیغاتی Android باشد که از طریق %%EXTRA_TAG_DATA%% ماکرو در برچسب جاوا اسکریپت مدیریت شده توسط خریداران مجاز ارسال می‌شود.

ماکرو %%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 می توانید از امکانات آپلود انبوه ما استفاده کنید.

وقتی شناسه تبلیغات تلفن همراه با فهرست کاربران مطابقت دارد، می‌توانید از آن برای اجرای بازاریابی مجدد استفاده کنید.

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

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

بازخورد پاسخ پیشنهادی در درخواست پیشنهادی بعدی برای پروتکل AdX و OpenRTB پشتیبانی می‌شود. برای OpenRTB، در BidRequestExt ارسال می شود.

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

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

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

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

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

نمونه

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

گوگل

OpenRTB JSON

OpenRTB Protobuf

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

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

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

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

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

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

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

در زیر مثالی نشان می‌دهد که یک درخواست پیشنهادی 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 موجود در ویژگی‌های خلاق قابل استثناء ناشر را در نظر نمی‌گیرد، تعیین کنید که آیا ناشر از اندازه‌گیری باز در درخواست پیشنهاد قیمت پشتیبانی می‌کند یا خیر. برای پروتکل خریداران مجاز، این مورد در زیر BidRequest.adslot[].excluded_attribute یافت می شود. برای پروتکل OpenRTB، این بسته به فرمت، در زیر ویژگی battr برای بنر یا ویدیو یافت می شود.

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

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

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

بنر اپلیکیشن

گوگل

OpenRTB JSON

OpenRTB Protobuf

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

گوگل

OpenRTB JSON

OpenRTB Protobuf

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

گوگل

OpenRTB Protobuf

بومی برنامه

گوگل

OpenRTB JSON

OpenRTB Protobuf

ویدئوی وب

گوگل

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

OpenRTB Protobuf