معالجة الطلب

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

طلب التحليل

ترسل Google طلب عرض أسعار بتنسيق OpenRTB JSON أو Protobuf، ويتم إرفاقه كحمولة لطلب POST عبر HTTP. يعتمد التنسيق المستلَم على إعدادات نقطة النهاية. يمكنك الاطّلاع على مثال على طلب عرض سعر.

يجب تحليل هذا الطلب لتلقّي BidRequest المتسلسل. إذا كنت تستخدم تنسيق Protobuf، عليك تنزيل openrtb.proto وopenrtb-adx.proto من صفحة البيانات المرجعية واستخدامهما لإنشاء مكتبة يمكن استخدامها لتحليل الرسالة BidRequest. على سبيل المثال، تحلّل تعليمات C++ البرمجية التالية طلبًا معيّنًا باستخدام حمولة POST في سلسلة: 

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

بعد الحصول على BidRequest، يمكنك التعامل معه ككائن واستخراج الحقول التي تحتاج إليها وتفسيرها. على سبيل المثال، في لغة C++، يمكن أن يبدو تكرار الصفقات في OpenRTB `BidRequest` على النحو التالي:

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

معرّفات الفوترة

تتلقّى طلب عرض سعر عندما يستهدف واحد أو أكثر من إعدادات الاستهداف المُسبَق المساحة المتوفّرة للإعلانات لدى الناشر. سيتم ملء الحقل BidRequest.imp.ext.billing_id بمعرّفات الفوترة الخاصة بأي مشترين مؤهّلين، بالإضافة إلى إعدادات الاستهداف المُسبَق ذات الصلة. بالإضافة إلى ذلك، بالنسبة إلى مستودع الصفقات، يمكنك العثور على معرّفات الفوترة المرتبطة بالمشترين المعنيين باستخدام BidRequest.imp.pmp.deal.ext.billing_id. لا يمكن تحديد سوى معرّفات الفوترة الخاصة بالمشترين المضمّنين في طلب عروض الأسعار عند تقديم عرض سعر.

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

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، الذي تتم تعبئته بالفئات في التصنيف الذي تم إعداده لحسابك.

يوضّح المثال التالي الفئات المحظورة استنادًا إلى تصنيف فئات الإعلانات الذي تم إعداده:

الإصدار 1.0 من تصنيف 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%%

تم استبداله بمعرّف مستخدم 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

استخدِم أداة فك ترميز base-32 لفك ترميز جزء السلسلة المكتوب بخط غليظ (gewtimrzgyytanjyg4888888).

يمكنك استخدام برنامج فك ترميز على الإنترنت، ولكن عليك كتابة الأحرف بأحرف كبيرة واستبدال علامات 8 اللاحقة بقيم =.

وبالتالي، يمكن فك ترميز هذه القيمة على النحو التالي: 

GEWTIMRZGYYTANJYG4======
 نتائج: 
1-429610587
 السلسلة 429610587 هي معرّف التطبيق iFunny على iOS.

إليك مثالاً آخر. عنوان URL الذي تم الإبلاغ عنه هو: 

mbappgewtgmjug4ytmmrtgm888888.com
 فك ترميز هذه القيمة: 
GEWTGMJUG4YTMMRTGM======
 نتائج: 
1-314716233
 النتيجة 314716233 هي معرّف التطبيق TextNow على iOS.

العثور على اسم تطبيق الأجهزة الجوّالة من عنوان 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;

  // 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، من المحتمل أنّ ناشر التطبيق كان يستخدم عرضًا إعلانيًا بدون انقطاع للتوسّط، وبالتالي كان عرض السعر الفائز يتنافس مع طلبات أخرى في سلسلة العرض الإعلاني بدون انقطاع لرمز الخطأ passback الخاص بالناشر. تعرَّف على كيفية استخدام 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\%\)
Network 4 \(C_4 = $0.10\) \(f_4 = 85\%\)

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

مزاد عروض الأسعار في الوقت الفعلي التكلفة لكل ألف ظهور
الفائز في المزاد (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.ext.google_query_id.

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

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

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

سيتم تنظيم طلبات عروض الأسعار التي تتضمّن التنسيقات التالية في طلبات عروض أسعار منفصلة:

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

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

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

Pre-flatten

ما بعد التسطيح

العروض

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

إمكانية تخطّي الإعلان ومدة الفيديو

لا يتضمّن مواصفات OpenRTB حقولاً منفصلة لتحديد الحد الأقصى لمدد إعلانات الفيديو القابلة للتخطّي وغير القابلة للتخطّي. تستخدم عملية التنفيذ التي تجريها Google تسوية عروض الأسعار للتمييز بين هذه الحالات باستخدام الحقلَين الحاليَين BidRequest.video.maxduration وBidRequest.video.skip.

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

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

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

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

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

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

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

Open Measurement

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

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

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

أمثلة على طلبات عروض الأسعار

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

بانر التطبيق

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