معالجة الطلب

يبدأ تفاعل عرض الأسعار في الوقت الفعلي عندما ترسل 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%%

تم استبداله بـ 1 أو 0 عند الاتصال BidRequest الخاص بـ has_mobile().
%%HAS_VIDEO%%

تم الاستبدال بـ 1 (صحيح) أو 0 (خطأ) عند الاتصال برقم has_video() الخاص بـ BidRequest
%%HOSTED_MATCH_DATA%%

تم استبداله بقيمة الحقل hosted_match_data. من BidRequest.
%%MOBILE_IS_APP%%

تم الاستبدال بـ 1 (صحيح) أو 0 (خطأ) من الحقل mobile.is_app في BidRequest.

العثور على رقم تعريف تطبيق الأجهزة الجوّالة من عنوان URL للمعاملة

ستعرض معاملات تطبيقات الأجهزة الجوّالة عناوين URL التي تبدو كما يلي:

mbappgewtimrzgyytanjyg4888888.com

استخدام برنامج فك ترميز base-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

يحتوي على رمز شبكة "مدير الإعلانات" الخاص بالناشر متبوعًا بالإعلان تسلسلاً هرميًا للوحدات، مع الفصل بينها بشرطات مائلة للأمام.

كمثال، سيظهر ذلك بتنسيق مشابه لما يلي: /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.

Google

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%% في علامة JavaScript تتم إدارته من خلال "الشراة المعتمَدون"

تسمح وحدة الماكرو %%ADVERTISING_IDENTIFIER%% للمشترين بتلقي معرّف المعلِنين (IDFA) لنظام التشغيل iOS أو المعرِّف الإعلاني لنظام التشغيل 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

بالإضافة إلى الحقول التلقائية المُرسَلة في القسم "ملاحظات وآراء عن الردّ على عرض السعر"، يمكنك إرسال بيانات مخصّصة أيضًا في استجابة عرض السعر (في AdX Proto أو OpenRTB) باستخدام event_notification_token التي يتم إرجاعها في BidResponse 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 عندما عروض الأسعار.

عيّنة

فيما يلي عينة من الملاحظات في الوقت الفعلي كما هو موضح في الدعم البروتوكولات:

Google

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: إذا كانت هناك الشبكات الأخرى في سلسلة التوسط، يمثل هذا الحقل سعرًا يمثل نموذجًا لعرض سعر من شبكات التوسّط المؤهَّلة التي كانت أعلى من الفائز بالمزاد، والذي كان مرجَّحًا حسب معدل التعبئة المتوقع. سيتم تعيين هذا على 0 إذا لم تكن أي من الشبكات في من المتوقّع أن تملأ سلسلة التوسط، أو إذا كان الناشر لا يستخدم حزمة تطوير البرامج (SDK) والوساطة.

آلية العمل

من أجل وصف العمليات الحسابية المستخدمة لتحديد القيم المحتملة لـ minimum_bid_to_win و sampled_mediation_cpm_ahead_of_auction_winner، نحتاج أولاً إلى تحديد ما يلي:

  • يمثل ما يلي التكاليف لكل ألف ظهور في سلسلة التوسط بترتيب تنازلي:
    \[C_1, C_2, …, C_n\]
  • يمثل ما يلي معدلات التعبئة المقابلة للقيم لكل ألف ظهور في سلسلة التوسط:
    \[f_1, f_2, …, f_n\]
  • فيما يلي دالة تستخدم لتحديد التكلفة المتوقعة لكل ألف ظهور الاحتمالية من عنصر سلسلة التوسط \(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) التكلفة المتوقّعة لكل ألف ظهور معدل التعبئة
الشبكة 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) التكلفة لكل ألف ظهور
الفائز في المزاد (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\%\)

تقسيم عروض الأسعار

يصف تقسيم عروض الأسعار معالجة مركّب واحد. BidRequest إلى طلبات عروض أسعار متعددة يتم إرسالها إلى التطبيق. لأنّها تحتفظ بمعرّفات متطابقة (BidRequest.google_query_id في بروتوكول عرض الأسعار في الوقت الفعلي (RTB) للشراة المعتمَدين أو BidRequestExt.google_query_id في بروتوكول OpenRTB) يمكنك تحديد طلبات عروض الأسعار المرتبطة بعد التسوية.

أشكال الإعلانات

يمكن لبعض فرص الإعلانات قبول أشكال متعددة. من خلال تقسيم عروض الأسعار، في طلب عرض سعر محدد، حيث يتم إرسال سمات مثل سمات معرّفات الفوترة ذات صلة بالتنسيق المحدّد في الطلب.

سيتم تقسيم طلبات عروض الأسعار التي تحتوي على التنسيقات التالية إلى طلبات عروض الأسعار المختلفة:

  • بانر
  • فيديو
  • الصوت
  • مدمجة مع المحتوى

مثال لتسوية أشكال الإعلانات

في ما يلي مثال يعرض طلب عرض سعر OpenRTB مبسَّط بتنسيق JSON بدون إعلان تنظيم التنسيق مقارنةً بمجموعة مكافئة من الطلبات المسطحة:

مسطّح مسبقًا

بعد التسوية

العروض

يمكن أن تنطبق فرصة الإعلان الخاصة بمقدّم عرض سعر معيّن على صفقات مختلفة المختلفة، بالإضافة إلى المزاد المفتوح. مع تقسيم عروض الأسعار للصفقات، يمكن تقديم عرض سعر واحد سيتم إرسال طلبك للمزاد المفتوح، ونموذج واحد لكل نوع من أنواع الأسعار الثابتة صفقة. من الناحية العملية، يمكن أن تختلف القيود المفروضة على الإعلانات بين المزادات والسعر الثابت. أنواع الصفقات، على سبيل المثال، لفرصة معينة من إعلانات الفيديو والمتاحة في كل من المزاد المفتوح والصفقة ذات السعر الثابت، سيتلقى مقدِّم عرض الأسعار طلبات عروض الأسعار لكل منها قيود مثل الحد الأقصى لمدة الإعلان وما إذا يمكن أن تختلف الإعلانات القابلة للتخطّي المسموح بها. نتيجةً لذلك، يتم تطبيق التقسيم على الإعلان التعرف بسهولة أكبر على قيود الإعلانات المفتوحة المزاد والصفقة ذات السعر الثابت.

الحد الأقصى لمدة الفيديو القابل للتخطي

يتيح تنفيذ بروتوكول Google وبروتوكول OpenRTB استخدام الحقول التالية بالنسبة إلى مدة الفيديو وإمكانية تخطيه:

المدة المدة القابلة للتخطي قابلية التخطّي
بروتوكول Google max_ad_duration skippable_max_ad_duration video_ad_skippable
OpenRTB maxduration timing fixed in amara skip

وهذا يعني أنه على الرغم من أن بروتوكول Google يمكن أن يحتوي على نسبة قابلة للتخطي دقيقة وغير القابلة للتخطي، فإن تنفيذ OpenRTB يتضمن الحد الأقصى للمدة الزمنية.

قبل تقسيم عروض الأسعار، سيتم ضبط maxduration في OpenRTB على الجزء السفلي من max_ad_duration لبروتوكول Google حقلان (skippable_max_ad_duration) وقد تم تغيير هذا السلوك الآن إلى إرسال طلبَي عروض أسعار منفصلَين عند اختلاف هاتَين القيمتَين: أحدهما يمثّل maxduration للإعلانات القابلة للتخطّي والأخرى للإعلانات غير القابلة للتخطّي فرص التحسين.

توضِّح الأمثلة التالية كيفية ترجمة طلب بروتوكول Google إلى OpenRTB قبل تقسيم عروض الأسعار وبعده. بروتوكول Google المكافئ يحتوي الطلب على max_ad_duration من 15 skippable_max_ad_duration من إجمالي 60

مثال max_ad_duration skip (صواب OR خطأ)
الطلب الأصلي بدون تقسيم 15 true
الطلب الثابت رقم 1: إعلان غير قابل للتخطّي 15 false
الطلب الثابت رقم 2: قابل للتخطّي 60 true

لن يتم تطبيق تسوية طلب عرض سعر مدة الفيديو القابل للتخطي إلا عند استيفاء الشروط التالية:

  • يسمح الطلب بتشغيل الفيديو.
  • يُسمح بكل من فيديوهات التخطّي وعدم التخطّي، بالإضافة إلى الحد الأقصى تختلف المدد في القيمة.
  • هذا الطلب مؤهَّل للمزاد الخاص أو المزاد المفتوح.
  • يحتوي حساب مقدِّم عروض الأسعار على نقاط نهاية OpenRTB نشطة.

يمكنك إيقاف هذا النوع من التسوية من خلال التواصل مع فريق مدير الحساب.

مجموعات الفيديوهات المتسلسلة

يتم تقسيم طلبات عروض الأسعار للوحة فيديو تتضمّن فرص إعلانات متعددة بحيث يكون كل طلب عرض سعر مخصصًا لفرصة إعلان فردية من هذه المجموعة الإعلانية. ويتيح لك ذلك تقديم عروض أسعار لفرص إعلانات متعددة لمجموعة معيّنة.

فتح القياس

تسمح لك أداة "القياس المفتوح" بتحديد مورّدين تابعين لجهات خارجية يوفرون خدمات القياس والتحقق المستقلة للإعلانات التي يتم عرضها على تطبيق الأجهزة الجوّالة البيئات.

يمكنك تحديد ما إذا كان الناشر يوفّر القياس المفتوح في عرض السعر طلب من خلال التحقق مما إذا كانت فرصة الإعلان تستبعد السمة OmsdkType: OMSDK 1.0 الموجودة في السمة غير قابلة للاستبعاد من الناشر سمات تصاميم الإعلانات. بالنسبة إلى بروتوكول "الشراة المعتمَدون"، سيكون هذا تم العثور عليها ضمن BidRequest.adslot[].excluded_attribute. بالنسبة إلى بروتوكول OpenRTB، يمكن العثور على هذا ضمن السمة battr بانر أو الفيديو، استنادًا إلى التنسيق.

لمزيد من المعلومات عن كيفية تفسير طلبات عروض الأسعار التي تحتوي على "عرض مفتوح" إشارات القياس، راجِع مقالة القياس المفتوح. مقالة مركز مساعدة حزمة تطوير البرامج (SDK)

نماذج طلبات عروض الأسعار

تعرض الأقسام التالية نماذج طلبات عروض أسعار لأنواع إعلانات مختلفة.

بانر التطبيق

Google

OpenRTB JSON

بروتوكول OpenRTB Protobuf

الإعلان البيني للتطبيق

Google

OpenRTB JSON

بروتوكول OpenRTB Protobuf

الفيديو البيني للتطبيق

Google

بروتوكول OpenRTB Protobuf

إعلان مدمج مع المحتوى للتطبيق

Google

OpenRTB JSON

بروتوكول OpenRTB Protobuf

فيديو ويب

Google

بانر الويب على الأجهزة الجوّالة لمقدّم عروض أسعار Exchange

بروتوكول OpenRTB Protobuf