معالجة الطلب

يبدأ تفاعل عروض الأسعار في الوقت الفعلي عندما ترسل 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، مثل User ID أو اللغة أو الموقع الجغرافي من 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 عند الاتصال بـ has_mobile() BidRequest.
%%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
ينتج عن فك ترميز هذه القيمة: 
1-314716233
النتيجة 314716233 هي رقم تعريف تطبيق iOS TextNow.
GEWTGMJUG4YTMMRTGM======

العثور على اسم تطبيق الأجهزة الجوّالة من عنوان 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) التكلفة لكل ألف ظهور (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\%\)

تسوية عروض الأسعار

يصف تسوية عروض الأسعار معالجة مركّب واحد 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 وskippable_max_ad_duration في بروتوكول Google. لقد تغيَّر هذا السلوك الآن إلى إرسال طلبَين منفصلَين لعروض الأسعار عندما تختلف هذه القيم: أحدهما يمثّل 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

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

نموذج OpenRTB Protobuf