معالجة الطلب

يبدأ تفاعل عروض الأسعار في الوقت الفعلي عندما تُرسِل 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 المستخدَم في طلب POST لبروتوكول HTTP. يكون ذلك مفيدًا، على سبيل المثال، إذا كنت تستخدم واجهة أمامية خفيفة الوزن تعمل على توزيع الحمل على عدة خدمات خلفية باستخدام قيمة من الطلب. تواصَل مع مدير الحساب الفني لطلب الدعم بشأن الوحدات التحليلية الجديدة.

وحدة الماكروالوصف
%%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 (true) أو 0 (false) عند استدعاء 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;

  // Deprecated. This field is not populated and will be removed after March,
  // 2025. If the bid won the auction, this is the price paid in your account
  // currency. If the bid participated in the auction but was out-bid, this
  // is the CPM that should have been exceeded in order to win. This is not
  // set if the bid was filtered prior to the auction, if the publisher or
  // winning bidder has opted out of price feedback or if your account has
  // opted out of sharing winning prices with other bidders. For first-price
  // auctions, minimum_bid_to_win is populated instead of this field.
  optional double price = 3 [deprecated = true];

  // The minimum bid value necessary to have won the auction, in your account
  // currency. If your bid won the auction, this is the second highest bid
  // that was not filtered (including the floor price). If your bid didn't win
  // the auction, this is the winning candidate's bid. This field will only be
  // populated if your bid participated in a first-price auction, and will not
  // be populated if your bid was filtered prior to the auction.
  optional double minimum_bid_to_win = 6;

  // The minimum bid value necessary to have won the server-side component of
  // the overall auction given that there was also an interest group bidding
  // component to the overall auction which ran using the Protected Audience
  // API. The value is expressed in CPM of the buyer account currency. The
  // minimum bid to win for the overall auction, including bids from the
  // server-side and the on-device interest group components, is populated in
  // the minimum_bid_to_win field of the same BidFeedback object.
  optional double sscminbidtowin = 14;

  // Billable event rate multiplier that was applied to this bid during
  // ranking. The adjustment reflects the likelihood that your bid would
  // generate a billable event (namely, the ad renders successfully) if it won
  // the auction, relative to the probability that other bids generate a
  // billable event if they won the auction. This adjustment can be larger or
  // smaller than 1. This affects the final ranking in the auction only; in
  // particular, this multiplier does not affect the payment or whether the
  // bid clears any floor price.
  optional float billable_event_rate_bid_adjustment = 13 [default = 1];

  // When a publisher uses an RTB auction and waterfall-based SDK mediation on
  // the same query, the winner of the real-time auction must also compete in
  // a mediation waterfall (which is ordered by price) to win the impression.
  // If the bid participated in the auction and there was no waterfall, the
  // value of this field is 0. If the bid participated in the auction and
  // there was a waterfall, the value of this field is a price representing a
  // sample bid from the eligible mediation networks that were higher than the
  // auction winner, weighted by expected fill rate. This field can be used
  // in conjunction with minimum_bid_to_win to train bidding models. The CPM
  // is in your account currency.
  optional double sampled_mediation_cpm_ahead_of_auction_winner = 8;

  message EventNotificationToken {
    // The contents of the token.
    optional string payload = 1;
  }

  // The token included in the corresponding bid.
  optional EventNotificationToken event_notification_token = 4;

  // The creative ID included in the corresponding bid.
  optional string buyer_creative_id = 5;

  // Possible types of bid response feedback objects.
  enum FeedbackType {
    FEEDBACK_TYPE_UNSPECIFIED = 0;

    // Feedback for a bid that was submitted on a bid response.
    BID_FEEDBACK = 1;

    // Feedback for an interest group buyer submitted on a bid response to
    // particpate in an interest group bidding component of the auction run
    // using the Protected Audience API.
    INTEREST_GROUP_BUYER_FEEDBACK = 2;
  }

  // The type of the BidFeedback message. Google will send separate
  // BidFeedback objects for:
  // a) Each bid submitted on a bid response
  // b) Each buyer submitted on a bid response to particpate in an interest
  // group bidding component of the auction run using the Protected Audience
  // API.
  optional FeedbackType feedbacktype = 15;

  // Origin of an interest group buyer that was included in the bid response.
  // This field is populated only for feedback where a bidder opted in an
  // interest group buyer to participate in the interest group bidding
  // component of the overall auction run using the Protected Audience API.
  // To learn more about origins, see https://www.rfc-editor.org/rfc/rfc6454.
  // To learn more about interest group bidding and the Protected Audience
  // API, see
  // https://developers.google.com/authorized-buyers/rtb/fledge-origin-trial.
  optional string buyerorigin = 16;

  // The status code for the submitted interest group buyer. This field is
  // only populated in the feedback for an interest group buyer that a bidder
  // requested to enter into the interest group auction through the bid
  // response. Individual creative status codes of bids submitted by the buyer
  // in the on-device interest group auction are not available. See
  // https://storage.googleapis.com/adx-rtb-dictionaries/interest-group-buyer-status-codes.txt
  // for a list of interest group buyer status codes.
  optional int32 igbuyerstatus = 17;
}

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

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

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

بالنسبة إلى مرّة ظهور في تطبيق ورمز حالة تصميم الإعلان 83، من المحتمَل أنّ ناشر التطبيق كان يستخدم عرضًا بدون انقطاع للتوسّط، وبالتالي كان العرض الفائز سيتنافس مع طلب آخر في سلسلت العرض بدون انقطاع لإعادة الإحالة الناجحة لدى الناشر. تعرَّف على كيفية استخدام sampled_mediation_cpm_ahead_of_auction_winner عند تقديم عروض الأسعار.

عيّنة

في ما يلي عيّنة من الملاحظات في الوقت الفعلي كما تظهر في بروتوكولات المتوافقة:

OpenRTB Protobuf

ملف JSON في OpenRTB

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:

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

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

minimum_bid_to_win الاحتمالية
\(max(F, R, C_3) = $0.50\) \(f_3 = 80\%\)
\(max(F, R, C_4) = $0.10\) \((1-f_3) \cdot f_4 = 17\%\)
\(max(F, R, 0) = $0.05\) \((1-f_3) \cdot (1-f_4) = 3\%\)
sampled_mediation_cpm_
ahead_of_auction_winner
الاحتمالية
\(C_1 = $3.00\) \(f_1 \div (1-(1-f_1) \cdot (1-f_2)) =~ 10.5\%\)
\(C_2 = $2.00\) \(((1-f_1) \cdot f_2) \div (1-(1-f_1) \cdot (1-f_2)) =~ 89.5\%\)
عروض الأسعار التي خسرت المزاد

في ما يلي مثال على كيفية احتساب القيم واحتمالات minimum_bid_to_win و sampled_mediation_cpm_ahead_of_auction_winner لمحاولة biddings التي خسرت.

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_duration15 وskippable_max_ad_duration60.

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

ملف JSON في OpenRTB

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

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

OpenRTB Protobuf

ملف JSON في OpenRTB

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

فيديو ويب

OpenRTB Protobuf

ملف OpenRTB بتنسيق JSON

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

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

OpenRTB Protobuf

ملف JSON في OpenRTB

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

OpenRTB Protobuf

ملف JSON في OpenRTB

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