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

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

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

Google یک درخواست پیشنهادی را به صورت سریالی در قالب‌های OpenRTB JSON یا Protobuf ارسال می‌کند که به عنوان بار درخواست HTTP POST پیوست شده است. قالب دریافتی به پیکربندی نقطه پایانی شما بستگی دارد. برای نمونه به نمونه درخواست پیشنهاد قیمت مراجعه کنید.

برای دریافت BidRequest سریالی شده باید این درخواست را تجزیه کنید. اگر از فرمت Protobuf استفاده می کنید، باید openrtb.proto و openrtb-adx.proto از صفحه داده های مرجع دانلود کنید و از آنها برای ایجاد کتابخانه ای استفاده کنید که می تواند برای تجزیه پیام BidRequest استفاده شود. به عنوان مثال، کد C++ زیر درخواستی را که یک بار POST در یک رشته داده شده است تجزیه می کند: 

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

هنگامی که BidRequest را دارید، می توانید با آن به عنوان یک شی کار کنید و فیلدهای مورد نیاز خود را استخراج و تفسیر کنید. برای مثال، در C++ تکرار از طریق معاملات در OpenRTB «BidRequest» می‌تواند به شکل زیر باشد: 

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

شناسه های صورتحساب

زمانی که موجودی آگهی ناشر توسط یک یا چند مورد از پیکربندی‌های پیش‌هدف شما هدف قرار می‌گیرد، یک درخواست پیشنهاد دریافت می‌کنید. BidRequest.imp.ext.billing_id با شناسه‌های صورت‌حساب هر خریداران واجد شرایط و پیکربندی‌های پیش هدف‌یابی مرتبط پر می‌شود. علاوه بر این، برای موجودی معامله ، می‌توانید شناسه‌های صورت‌حساب مرتبط با خریدار مربوطه را با استفاده از BidRequest.imp.pmp.deal.ext.billing_id بیابید. تنها شناسه‌های صورت‌حساب خریدارانی که در درخواست مناقصه گنجانده شده‌اند، ممکن است هنگام ارائه پیشنهاد مشخص شوند.

اگر چندین شناسه صورت‌حساب در درخواست مناقصه گنجانده شده است، باید شناسه صورت‌حساب خریداری را که می‌خواهید پیشنهاد خود را به آن نسبت دهید، در قسمت BidResponse.seatbid.bid.ext.billing_id مشخص کنید.

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

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

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

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

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

با شناسه کاربری Google موجود در BidRequest.user.id جایگزین شد. به عنوان مثال، آدرس اینترنتی پیشنهاد دهنده 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%%

با 1 برای نشان دادن اینکه درخواست پیشنهاد از یک دستگاه تلفن همراه است، یا 0 جایگزین شده است. این بر اساس مقدار BidRequest.device.devicetype است که در آن دستگاه های تلفن همراه با HIGHEND_PHONE ( 4 ) یا Tablet ( 5 ) نشان داده می شوند.

%%HAS_VIDEO%%

با 1 برای نشان دادن اینکه درخواست پیشنهاد شامل موجودی ویدیویی است، یا 0 جایگزین شده است. این براساس این است که آیا BidRequest.imp.video در درخواست مناقصه پر شده است یا خیر.

%%HOSTED_MATCH_DATA%%

با یک مقدار بر اساس BidRequest.user.buyeruid جایگزین شد.

%%MOBILE_IS_APP%%

با 1 برای نشان دادن اینکه درخواست پیشنهاد برای موجودی برنامه تلفن همراه است یا 0 جایگزین شده است. این بر اساس پر بودن BidRequest.app است.

شناسه برنامه تلفن همراه را از 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

حاوی کد شبکه Ad Manager ناشر و به دنبال آن سلسله مراتب واحد تبلیغات است که با اسلش های رو به جلو از هم جدا شده اند.

به عنوان مثال، این با قالب بندی شبیه به: /1234/cruises/mars ظاهر می شود.

BidRequest.user.data.segment

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

وقتی 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

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

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

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

بازخورد بی‌درنگ BidRequest.ext.bid_feedback را بر اساس نتیجه یک یا چند پیشنهادی که قبلاً ارائه کرده‌اید پر می‌کند و می‌تواند برای یافتن جزئیاتی مانند اینکه آیا پیشنهاد مزایده برنده شده است یا حداقل پیشنهاد مورد نیاز برای برنده شدن در حراج، مورد استفاده قرار می‌گیرد. برای فعال کردن بازخورد بلادرنگ با مدیر حساب خود تماس بگیرید.

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

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

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

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

  // 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

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

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

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

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

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

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

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

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

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

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

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

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

پس از صاف کردن

معاملات

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

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

مشخصات OpenRTB فیلدهای جداگانه ای برای تعیین حداکثر مدت زمان ویدیوی تبلیغات قابل رد شدن و غیرقابل رد شدن ندارد. پیاده‌سازی Google از صاف کردن پیشنهاد برای تمایز بین این موارد با استفاده از فیلدهای BidRequest.video.maxduration و BidRequest.video.skip استفاده می‌کند.

در زیر نمونه‌ای از نحوه مسطح شدن موجودی ویدیو در زمانی است که حداکثر مدت یک تبلیغ غیرقابل رد شدن 15 و حداکثر مدت زمان یک آگهی قابل رد شدن 60 باشد.

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

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

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

می توانید با تماس با مدیر حساب فنی خود از این نوع صاف کردن انصراف دهید. هنگامی که غیرفعال است و ناشر تبلیغات ویدیویی قابل رد شدن و غیرقابل رد شدن را با حداکثر مدت زمان متفاوت بر اساس قابلیت رد شدن مجاز می‌کند، skip روی true و maxduration مدت زمانی که بین محدودیت‌های تبلیغاتی قابل رد شدن و غیرقابل رد شدن کوتاه‌تر باشد تنظیم می‌شود.

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

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

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

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

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

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

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

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

بنر اپلیکیشن

OpenRTB Protobuf

OpenRTB JSON

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

OpenRTB Protobuf

OpenRTB JSON

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

OpenRTB Protobuf

OpenRTB JSON

بومی برنامه

OpenRTB Protobuf

OpenRTB JSON

ویدئوی وب

OpenRTB Protobuf

OpenRTB JSON

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

OpenRTB Protobuf

OpenRTB JSON

Multiformat Native و Video

OpenRTB Protobuf

OpenRTB JSON