معالجة الطلب

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

التكيّف مع الحقول التي تم إيقافها

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

الحقول التي تم إيقافها (تم التعديل في 1 أيار (مايو) 2013)

لم يعد يتم إرسال الحقول في الجدول التالي:

الرسالة الحقل
BidRequest protocol_version
excluded_click_through_url
company_name
country
region
city
metro
الرسالة الفرعية Mobile من BidRequest (كانت تُعرف سابقًا باسم MobileApp الرسالة الفرعية) app_name
company_name
carrier_name
carrier_country
الرسالة الفرعية MatchingAdData من BidRequest campaign_id

ويوضّح الجدول التالي الحقول في BidRequest التي تم إيقافها:

الرسالة الحقل
الرسالة الفرعية MatchingAdData من BidRequest buyer_minimum_cpm
fixed_cpm_micros
رسالة فرعية واحدة (Ad) من BidRequest allowed_attribute
publisher_settings
excluded_click_through_url
BidRequest protocol_version
click_tracking_url
cookie
hashed_cookie
excluded_click_through_url
seller_network
publisher_settings
MatchingNetwork network_id
google_user_id

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

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

mbappgewtimrzgyytanjyg4888888.com

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

يمكنك استخدام Online decoder على الأقل، ولكن عليك استخدام الأحرف الكبيرة بدلاً من الأحرف 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.

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

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

عرض الأسعار في الوقت الفعلي (RTB) الشراة المعتمَدون التفاصيل
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 Extension Protocol Buffer (طريقة عمل بروتوكولات RTB) لكل من RTB وAdX Proto لبرنامج AdX.

عندما يرسل الشراة المعتمَدون طلب عرض سعر إلى أحد مقدّمي عروض الأسعار، يردّ نظام عروض الأسعار باستخدام BidResponse. في حال تفعيل ميزة عروض الأسعار في الوقت الفعلي لمقدّم عروض الأسعار، في طلب عرض سعر لاحق، يُرسِل "الشراة المعتمَدون" ملاحظات حول الاستجابة في رسالة BidResponseFeedback، كما هو موضّح في ما يلي:

// Feedback on bids submitted in previous responses. This is only set if
// real-time feedback is enabled for your bidder. Contact your account
// manager if you want to enable real-time feedback.
//
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;

  // 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;
}
repeated BidResponseFeedback bid_response_feedback = 44;

من هذه الرسالة، يجب أن يكون الحقل الأول هو bid_response_feedback.creative_status_code، ويمكنك العثور على الرمز المعنى في creative-status-codes.txt. وتجدر الإشارة إلى أنّه في حال فوزك بعرض السعر، يمكنك إيقاف ذلك من ملاحظاتك. للمزيد من المعلومات حول كيفية إيقاف الاشتراك.

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

نتيجة المزاد ملاحظات في الوقت الفعلي
لم يقدّم المشتري عرض سعر. لا شيء.
أرسل المشتري عرض سعر تمت فلترته قبل الوصول إلى المزاد. رمز حالة تصميم الإعلان (راجِع creative-status-codes.txt).
أرسل المشتري عرض سعر ولكنه خسر المزاد. رمز حالة تصميم الإعلان 79 (تقديم عرض سعر في المزاد).
أرسل المشتري عرض سعر فاز بالمزاد. سعر المقاصة ورمز حالة تصميم الإعلان 1.

بالنسبة إلى مرات ظهور التطبيق ورمز حالة تصميم الإعلان 53، يمكن أن يكون ناشر التطبيق يستخدم عرضًا إعلانيًا بدون انقطاع للتوسّط، وبالتالي كان من الممكن أن يتنافس عرض السعر الفائز مع الطلب الآخر في سلسلة العرض الإعلاني بدون انقطاع الخاصة بالناشر. اطّلِع على كيفية استخدام 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
عرض الأسعار في الوقت الفعلي (RTB) maxduration لا تنطبق 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 (صحيح أو خطأ)
الطلب الأصلي بدون مسطحة 15 true
الطلب الثابت رقم 1: غير قابل للتخطي 15 false
الطلب الثابت رقم 2: قابل للتخطي 60 true

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

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

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

لوحات إعلانات الفيديو

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

فتح القياس

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

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

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

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

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

بانر التطبيق

Google

ملف OpenRTB JSON

OpenRTB Protobuf

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

Google

ملف OpenRTB JSON

OpenRTB Protobuf

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

Google

ملف OpenRTB JSON

OpenRTB Protobuf

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

Google

ملف OpenRTB JSON

OpenRTB Protobuf

فيديو ويب

Google

ملف OpenRTB JSON

OpenRTB Protobuf

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

OpenRTB Protobuf