معالجة الطلب

يبدأ تفاعل عروض الأسعار في الوقت الفعلي عندما تُرسِل 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++، يمكن أن تبدو عملية التنقّل في الصفقات في 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.

ملفات القاموس

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

وحدات ماكرو عناوين URL لمقدّمي عروض الأسعار

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

وحدة الماكروالوصف
%%GOOGLE_USER_ID%%

تم استبداله بمعرّف مستخدم Google المتوفّر في BidRequest.user.id. على سبيل المثال، سيتم استبدال عنوان 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.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 للمعاملة

ستحدّد معاملات التطبيقات المتوافقة مع الأجهزة الجوّالة عناوين 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

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

على سبيل المثال، سيظهر هذا الرمز بتنسيق مشابه لما يلي: /1234/cruises/mars.
BidRequest.user.data.segment

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

يمكنك تحديد أنّ القيم هي أزواج مفتاح/قيمة يرسلها الناشر عند ضبط BidRequest.user.data.name على “Publisher Passed”.

الإفصاح عن المورّدين المسموح بهم

يمكن أن يلعب مورّدو التكنولوجيا الذين يوفّرون خدمات مثل الأبحاث وإعادة التسويق و عرض الإعلانات دورًا في التفاعل بين المشترين والبائعين. لا يُسمح إلا بالمورّدين الذين تحقّقت Google من أهليتهم للمشاركة في تفاعلات "المشترين المعتمَدين".

لفهم BidRequest وإنشاء BidResponse، عليك معرفة المرحلتَين مختلفتَين لإدراج مورّدي التكنولوجيا:

  1. لا يلزم الإفصاح عن بعض المورّدين، ويتم إدراج هؤلاء المورّدين في المورّدون الخارجيون الحائزون على شهادة "مدير إعلانات Google".
  2. لا يمكن لبائعي الخدمات الآخرين المشاركة إلا إذا تم الإفصاح عنهم في BidRequest:
    • في الحقل BidRequest، يحدّد الحقل BidRequest.imp.ext.allowed_vendor_type المورّدين الذين يسمح لهم البائع بالبيع. يتم إدراج المورّدين الذين سيتم إرسالهم في allowed_vendor_type في ملف القاموس vendors.txt.

مثال على طلب عرض السعر

تمثّل الأمثلة التالية عيّنات قابلة للقراءة من طلبات Protobuf و JSON.

OpenRTB Protobuf

ملف JSON في OpenRTB

لتحويل طلب عروض الأسعار إلى تنسيق ثنائي، مثل ما ستحصل عليه من حمولة 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 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;

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

ملف JSON في OpenRTB

إنشاء نموذج عروض أسعار للمزادات ذات السعر الأول

بعد تقديم عرض سعر في مزاد السعر الأول، ستتلقّى ملاحظات في الوقت الفعلي، بما في ذلك الحقلَين 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:

مزاد "عروض الأسعار في الوقت الفعلي" التكلفة لكل ألف ظهور
الفائز في المزاد (W) $1,00
المركز الثاني في المزاد (R) ‫0.05 دولار أمريكي
السعر الاحتياطي / الحد الأدنى (F) $0
عرض السعر الذي فاز بالمزاد

في ما يلي مثال على كيفية احتساب القيم واحتمالات minimum_bid_to_win و sampled_mediation_cpm_ahead_of_auction_winner لمحاولة bidding التي فازت.

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 حقولًا منفصلة لتحديد الحد الأقصى لمدّة إعلانات الفيديو القابلة للتخطّي وغير القابلة للتخطّي. في عملية التنفيذ التي تتّبعها Google، تتم معالجة عروض الأسعار لتتمكّن من التمييز بين هذه العروض باستخدام الحقلَين الحاليَين BidRequest.video.maxduration و BidRequest.video.skip.

في ما يلي مثال على كيفية تسطيح مستودع الفيديو عندما يكون الحد الأقصى لمدة الإعلان غير القابل للتخطي هو 15 والحد الأقصى لمدة الإعلان القابل للتخطي هو 60.

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

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

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

يمكنك إيقاف هذا النوع من التسطيح من خلال التواصل مع مدير حسابك الفني. عند إيقاف هذه الميزة، إذا سمح الناشر بعرض كلٍّ من إعلانات الفيديو القابلة للتخطّي وغير القابلة للتخطّي بحدّ أقصى مختلف للمدّة استنادًا إلى إمكانية التخطّي، سيتم ضبط skip على true و سيتم ضبط maxduration على المدّة الأقصر بين قيود الإعلانات القابلة للتخطّي وغير القابلة للتخطّي.

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

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

القياس المفتوح

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

يمكنك تحديد ما إذا كان الناشر يتيح ميزة "القياس المفتوح" في طلب مزايدة من خلال التحقّق مما إذا كانت فرصة الإعلان تستبعد سمة OmsdkType: OMSDK 1.0 المتوفّرة في سمات مواد العرض التي يمكن للناشر استبعادها. يمكن العثور على هذه السمة ضمن battr Banner أو Video، وذلك استنادًا إلى التنسيق.

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

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

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

بانر التطبيق

OpenRTB Protobuf

ملف JSON في OpenRTB

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

OpenRTB Protobuf

ملف JSON في OpenRTB

إعلان فيديو بيني داخل التطبيق

OpenRTB Protobuf

ملف JSON في OpenRTB

التطبيق الأصلي

OpenRTB Protobuf

ملف JSON في OpenRTB

فيديو ويب

OpenRTB Protobuf

ملف JSON في OpenRTB

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

OpenRTB Protobuf

ملف JSON في OpenRTB

الإعلانات المدمجة مع المحتوى والفيديو بتنسيقات متعدّدة

OpenRTB Protobuf

ملف JSON في OpenRTB