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

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

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

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

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

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

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

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 مشخص کنید.

imp {
  ext {
    // The billing IDs of all of your matching pretargeting configs and eligible child seats are
    // stored in a flat list here.
    billing_id: 123
    billing_id: 456
    billing_id: 789
  }
  pmp {
    // All eligible deals are stored in a single flat list.
    deal {
      id: 1000
      ext {
        // The specific billing IDs eligible to bid on this deal are indicated here.
        billing_id: 789
      }
      ...
    }
    deal {
      id: 2000
      ext {
        billing_id: 123
        billing_id: 456
      }
      ...
    }
  }
  ...
}
...

تعیین دسته‌های مسدود شده

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

شما می‌توانید با بررسی فیلد BidRequest.bcat که با دسته‌بندی‌های موجود در طبقه‌بندی پیکربندی‌شده برای حساب شما پر شده است، دسته‌بندی‌های مسدود شده برای نمایش را پیدا کنید.

مثال زیر دسته‌های مسدود شده را بر اساس طبقه‌بندی دسته‌بندی تبلیغات پیکربندی شده نشان می‌دهد:

طبقه‌بندی محتوای IAB نسخه ۱.۰

// Bid request
{
  // Indicates the blocked categories using IAB Content 1.0 Taxonomy.
  "bcat": [
    "IAB9-9",  // Cigars
    "IAB8-18"  // Wine
  ]
  "imp": {
    ...
  }
}
      
// Bid request
{
  // Indicates the blocked categories using Google Ad Category Taxonomy.
  "bcat": [
    "10138",  // Cigar and tobacco collecting
    "10080",  // Tobacco
    "11649",  // Wine
    "10674",  // Wine collecting
    "13008"   // Wine clubs
  ]
  "imp": {
    ...
  }
}
      

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

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

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

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

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

با شناسه کاربری گوگل موجود در BidRequest.user.id جایگزین می‌شود. برای مثال، آدرس اینترنتی پیشنهاد دهنده http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%% در زمان درخواست با چیزی شبیه به http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl جایگزین خواهد شد.

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

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

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

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

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

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

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

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

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

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

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

زمینه‌های مناقصه آزاد

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

OpenRTB جزئیات
BidRequest.imp.ext.dfp_ad_unit_code

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

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

BidRequest.user.data.segment

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

شما می‌توانید تعیین کنید که مقادیر، جفت‌های کلید-مقدار ارسالی توسط ناشر باشند، زمانی که BidRequest.user.data.name روی “Publisher Passed” تنظیم شده باشد.

فروشندگان مجاز را اعلام کنید

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

برای درک BidRequest و ایجاد BidResponse خود، باید از دو امکان مختلف برای اعلام فروشندگان فناوری آگاه باشید:

  1. برخی از فروشندگان نیازی به اعلام ندارند؛ این فروشندگان در فهرست فروشندگان خارجی دارای گواهینامه مدیریت تبلیغات (Ad Manager Certified External Vendors) فهرست شده‌اند.
  2. سایر فروشندگان فقط در صورتی می‌توانند شرکت کنند که در BidRequest اعلام شده باشند:
    • در BidRequest ، فیلد BidRequest.imp.ext.allowed_vendor_type مشخص می‌کند که فروشنده به کدام فروشندگان اجازه می‌دهد. فروشندگانی که در allowed_vendor_type ارسال می‌شوند، در فایل دیکشنری vendors.txt فهرست شده‌اند.

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

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

پروتوباف OpenRTB

OpenRTB JSON

برای تبدیل درخواست پیشنهاد به فرم دودویی، مانند آنچه از POST payload در یک درخواست واقعی دریافت می‌کنید، می‌توانید موارد زیر را (در 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 Extensions Protocol Buffer مراجعه کنید.

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

  // Deprecated. This field will be removed in February 2026.
  // 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 [deprecated = true];

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

  // Deprecated. This field will be removed in February 2026.
  // 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 [deprecated = true];

  // Deprecated. This field will be removed in February 2026.
  // 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 [deprecated = true];

  // Deprecated. This field will be removed in February 2026.
  // 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 [deprecated = true];
}

در این پیام، اولین فیلدی که باید بررسی کنید bid_feedback.creative_status_code است؛ می‌توانید معنی کد را در creative-status-codes.txt پیدا کنید. توجه داشته باشید که اگر در پیشنهاد برنده شوید، می‌توانید از بازخورد قیمت انصراف دهید. برای اطلاعات بیشتر، به نحوه انصراف مراجعه کنید.

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

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

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

نمونه

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

پروتوباف OpenRTB

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 استفاده نکند، این مقدار روی ۰ تنظیم خواهد شد.

چگونه کار می‌کند؟

برای توصیف محاسبات مورد استفاده برای تعیین مقادیر ممکن برای 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 مورد انتظار نرخ پر کردن
شبکه ۱ \(C_1 = $3.00\)\(f_1 = 5\%\)
شبکه ۲ \(C_2 = $2.00\)\(f_2 = 45\%\)
شبکه ۳ \(C_3 = $0.50\)\(f_3 = 80\%\)
شبکه ۴ \(C_4 = $0.10\)\(f_4 = 85\%\)

نتیجه حراج RTB را به صورت زیر در نظر بگیرید:

حراج RTB سی پی ام
برنده مزایده (W) ۱.۰۰ دلار
نایب قهرمان حراج (R) ۰.۰۵ دلار
قیمت رزرو / طبقه (F) ۰ دلار
پیشنهادی که برنده مزایده شد

در ادامه مثالی از نحوه محاسبه مقادیر و احتمالات برای minimum_bid_to_win و sampled_mediation_cpm_ahead_of_auction_winner برای پیشنهادی که برنده شده است، آمده است.

minimum_bid_to_win احتمال
\(max(F, R, C_3) = $0.50\)\(f_3 = 80\%\)
\(max(F, R, C_4) = $0.10\)\((1-f_3) \cdot f_4 = 17\%\)
\(max(F, R, 0) = $0.05\)\((1-f_3) \cdot (1-f_4) = 3\%\)
sampled_mediation_cpm_
ahead_of_auction_winner
احتمال
\(C_1 = $3.00\)\(f_1 \div (1-(1-f_1) \cdot (1-f_2)) =~ 10.5\%\)
\(C_2 = $2.00\)\(((1-f_1) \cdot f_2) \div (1-(1-f_1) \cdot (1-f_2)) =~ 89.5\%\)
پیشنهادهایی که در مزایده شکست خوردند

در ادامه مثالی از نحوه محاسبه مقادیر و احتمالات برای minimum_bid_to_win و sampled_mediation_cpm_ahead_of_auction_winner برای پیشنهادهایی که باخته شده‌اند، آمده است.

minimum_bid_to_win احتمال
\(max(F, W) = $1.00\)\(100\%\)
sampled_mediation_cpm_
ahead_of_auction_winner
احتمال
\(C_1 = $3.00\)\(f_1 = 5\%\)
\(C_2 = $2.00\)\((1-f_1) \cdot f_2 =~ 42.8\%\)
\(0\)\((1-f_1) \cdot (1-f_2) =~ 52.2\%\)

مسطح‌سازی پیشنهاد قیمت

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

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

قالب‌های تبلیغاتی

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

درخواست‌های پیشنهادی که شامل قالب‌های زیر باشند، به درخواست‌های پیشنهادی مجزا تبدیل می‌شوند:

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

مثال مسطح‌سازی قالب آگهی

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

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

پس از صاف کردن

معاملات

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

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

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

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

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

مسطح‌سازی پیشنهاد مدت زمان ویدیوی قابل رد شدن، تنها زمانی انجام می‌شود که این شرایط برآورده شوند:

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

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

پادهای ویدیویی

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

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

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

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

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

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

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

بنر برنامه

پروتوباف OpenRTB

OpenRTB JSON

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

پروتوباف OpenRTB

OpenRTB JSON

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

پروتوباف OpenRTB

OpenRTB JSON

برنامه بومی

پروتوباف OpenRTB

OpenRTB JSON

ویدیوی وب

پروتوباف OpenRTB

OpenRTB JSON

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

پروتوباف OpenRTB

OpenRTB JSON

چند فرمتی بومی و ویدیویی

پروتوباف OpenRTB

OpenRTB JSON