معالجة الطلب

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

تحليل طلب Protobuf

تُرسِل Google طلب عرض سعر كوحدة تخزين مؤقتة متسلسلة للبروتوكول مرفقة كحمولة ثنائية لطلب HTTP POST. تم ضبط Content-Type على application/octet-stream. اطّلِع على مثال على طلب عروض الأسعار للاطّلاع على مثال.

يجب تحليل هذا الطلب في مثيل من BidRequest . استنادًا إلى البروتوكول الذي اخترته، يتم تحديد BidRequest. في إما openrtb.proto أو متوقفة نهائيًا 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++، يمكن أن تبدو عملية التنقّل في الصفقات في عنصر 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 لعروض الأسعار في بروتوكول عرض الأسعار في الوقت الفعلي من Google

يمكن اختياريًا إدراج بعض حقول 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 (true) أو 0 (false) من حقل mobile.is_app في BidRequest.

العثور على رقم تعريف تطبيق الأجهزة الجوّالة من عنوان 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 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. ليس مطلوبًا الإفصاح عن بعض المورّدين. يتم إدراج هؤلاء البائعين في مسؤول خارجي معتمَد من "مدير إعلانات Google" المورّدون:
  2. لا يمكن للمورّدين الآخرين المشاركة إلا إذا تم الإفصاح عنهم في BidRequest:
    • في BidRequest، يحدّد الحقل BidRequest.imp.ext.allowed_vendor_type المورّدين الذين يسمح لهم البائع بالوصول إلى بياناته. يتم إدراج المورّدين الذين سيتم إرسالهم في allowed_vendor_type في ملف القاموس vendors.txt .

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

تمثل الأمثلة التالية عينات يمكن للإنسان قراءتها من Protobuf طلبات JSON.

OpenRTB Protobuf

ملف JSON في OpenRTB

Google (متوقّفة نهائيًا)

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

ملاحظات في الوقت الفعلي

تتوفّر أيضًا الملاحظات في الوقت الفعلي للمشترين المعتمَدين. كتبادلات وشبكات تستخدم "عرض الأسعار المفتوح"

تتوفر ملاحظات الاستجابة لعرض السعر في طلب عرض السعر اللاحق لكليهما بروتوكول OpenRTB وبروتوكول عرض الأسعار في الوقت الفعلي (RTB) المتوقّف عن Google. بالنسبة إلى OpenRTB، يتم إرساله BidRequest.ext.bid_feedback

بالإضافة إلى الحقول التلقائية المرسَلة في "الملاحظات والآراء بشأن الردّ على عرض السعر"، يمكنك إرسال بيانات مخصّصة أيضًا في استجابة عرض السعر باستخدام الحقل "BidResponse.seatbid.bid.ext.event_notification_token". ‫event_notification_token هي بيانات عشوائية لا يعرفها سوى مقدم العروض، وقد تساعد في تصحيح الأخطاء، على سبيل المثال: رقم تعريف استهداف جديد أو رقم تعريف عروض أسعار يمثّل أسلوبًا جديدًا، أو بيانات وصفية مرتبطة بتصميم الإعلان ولا يعرفها سوى مقدّم العروض. للحصول على التفاصيل، يمكنك مراجعة المخزن المؤقت لبروتوكول إضافات OpenRTB لبرنامج OpenRTB أو إصدار تم إيقافه بروتوكول عرض الأسعار في الوقت الفعلي (RTB) من Google.

عندما يرسل "الشراة المعتمَدون" طلب عرض سعر إلى أحد مقدِّمي عروض الأسعار، يردّ مقدّم عرض الأسعار مع 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;

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

  // The minimum bid value necessary to have 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 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 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

Google (متوقّفة نهائيًا)

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

بعد تقديم عرض سعر في مزاد السعر الأول، ستصلك رسالة إلكترونية في الوقت الفعلي بما في ذلك 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) التكلفة لكل ألف ظهور
الفائز في المزاد (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 المبسّط بدون تسطيح ملف تعريف الإعلان مقارنةً بمجموعة مماثلة من الطلبات المسطّحة:

مسطّح مسبقًا

بعد التسوية

العروض

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

الحدّ الأقصى لمدة الفيديو القابل للتخطّي

يتيح تنفيذ بروتوكول Google وبروتوكول OpenRTB استخدام الحقول التالية بالنسبة إلى مدة الفيديو وإمكانية تخطيه:

المدة المدة القابلة للتخطي إمكانية التخطّي
بروتوكول Google max_ad_duration skippable_max_ad_duration video_ad_skippable
OpenRTB maxduration timing fixed in amara skip

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

قبل تسطيح عروض الأسعار، سيتم ضبط maxduration في OpenRTB على أدنى قيمة بين الحقلين max_ad_duration و skippable_max_ad_duration في بروتوكول Google. تم تغيير هذا السلوك الآن إلى إرسال طلبَي عروض أسعار منفصلَين عندما تختلف هذه القيم: أحدهما يمثّل maxduration للفرص الإعلانية القابلة للتخطّي والآخر للفرص الإعلانية غير القابلة للتخطّي .

توضِّح الأمثلة التالية كيفية ترجمة طلب بروتوكول Google إلى OpenRTB قبل تقسيم عروض الأسعار وبعده. يحتوي طلب بروتوكول Google المعادل على max_ad_duration‏15 وskippable_max_ad_duration‏60.

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

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

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

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

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

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

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

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

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

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

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

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

بانر التطبيق

بروتوكول OpenRTB Protobuf

ملف JSON في OpenRTB

Google (متوقّفة نهائيًا)

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

بروتوكول OpenRTB Protobuf

ملف JSON في OpenRTB

Google (متوقّفة نهائيًا)

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

OpenRTB Protobuf

Google (متوقّفة نهائيًا)

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

OpenRTB Protobuf

ملف JSON في OpenRTB

Google (متوقّفة نهائيًا)

فيديو ويب

Google (متوقّفة نهائيًا)

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

بروتوكول OpenRTB Protobuf