معالجة الطلب

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

يتم استبدالها بالقيمة 1 للإشارة إلى أنّ طلب عرض السعر وارد من جهاز تلفزيون متّصل، أو بالقيمة 0 في الحالات الأخرى. ويستند ذلك إلى قيمة BidRequest.device.devicetype. بالنسبة إلى Protobuf، تكون أجهزة التلفزيون المتّصلة CONNECTED_TV أو CONNECTED_DEVICE أو SET_TOP_BOX، وهو ما يتوافق مع القيم الصحيحة 3 أو 6 أو 7 لتنسيق JSON.
%%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 هي معرّف تطبيق iOS TextNow.

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

في ما يلي مثال على الحصول على اسم التطبيق. عنوان URL الذي تم الإبلاغ عنه هو: 

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
 فك ترميز هذه القيمة: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 نتائج: 
air.com.hypah.io.slither
 تتطابق النتيجة مع تطبيق Android slither.io.

حقول "عرض الأسعار المفتوح"

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

OpenRTB التفاصيل
BidRequest.imp.ext.dfp_ad_unit_code

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

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

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

من هذه الرسالة، الحقل الأول الذي يجب التحقّق منه هو 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\%\)
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.

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

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

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

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

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

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

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

Pre-flatten

Post-flatten

العروض

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

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

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

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

مثال max_ad_duration skip (صحيح OR خطأ)
الطلب الأصلي بدون تسوية 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

App native

OpenRTB Protobuf

ملف JSON بتنسيق OpenRTB

فيديو ويب

OpenRTB Protobuf

ملف JSON بتنسيق OpenRTB

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

OpenRTB Protobuf

ملف JSON بتنسيق OpenRTB

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

OpenRTB Protobuf

ملف JSON بتنسيق OpenRTB