Protected Audience API (المعروفة سابقًا باسم FLEDGE)

كجزء من مبادرة حماية الخصوصية، اقترح Chrome استخدام Protected Audience API، وهي واجهة برمجة تطبيقات داخل المتصفّح تسمح للمعلِنين وشركات تكنولوجيا الإعلان بعرض إعلانات مستهدفة حسب مجموعات الاهتمامات بدون الاعتماد على ملفات تعريف الارتباط التابعة لجهات خارجية، مع حماية المستخدِمين من التتبّع على مستوى المواقع الإلكترونية.

يُجري Chrome مرحلة تجربية لواجهة Protected Audience API. يكون "الشراة المعتمَدون" مؤهّلين للمشاركة في اختبار Protected Audience API على المستودع الإعلاني للناشر في "مدير إعلانات Google" يمكن لمقدّمي عروض الأسعار تحقيق ما يلي من خلال اختبار Protected Audience API:

  • نفِّذ التكرار وتعرَّف على مدى فعالية مسارات Protected Audience API.
  • يمكنك الحصول على ملاحظات حول التحسينات المحتملة لواجهة برمجة التطبيقات في المنتديات العامة، مثل GitHub.
  • الاستعداد لإتاحة الإعلانات المخصّصة من خلال واجهة برمجة التطبيقات بدون الاعتماد على ملفات تعريف الارتباط التابعة لجهات خارجية

على المشترين المعتمَدين المهتمين بالاختبار الاطّلاع على قسم الإعداد للحصول على التفاصيل.

لما يصل إلى %10 من زيارات Chrome.

ملخّص مسار العرض

في ما يلي ملخّص لتدفق عرض الإعلانات في ميزة "الجمهور المحمي" للمشترين المعتمَدين الشركاء:

مخطّط انسيابي

  1. يعمل مقدّم عروض الأسعار مع المعلِنين للحفاظ على مجموعات الاهتمامات لكل معلِن. في كثير من الأحيان، يضيف المعلنون علامة مقدم عرض سعر إلى صفحة المعلن لإضافة متصفّح إلى مجموعات الاهتمامات.
  2. يزور مستخدم نهائي صفحة أحد المعلِنين. قد تحتوي الصفحة على أزرار .
  3. تستدعي علامة مقدّم عروض الأسعار Protected Audience API joinAdInterestGroup(). تطلب هذه الدعوة من المتصفّح إضافة المستخدم إلى مجموعة اهتمامات.
  4. يزور المستخدم النهائي صفحة ويب للناشر. طلبات المتصفِّح التي يطلبها المستخدم علامة إعلان الناشر من Google.
  5. تُرسل علامة إعلان الناشر من Google طلب إعلان مستندًا إلى السياق إلى خادم Google.
  6. تُرسِل Google طلبات عروض الأسعار السياقية إلى مقدِّمي عروض الأسعار المشاركين. اطّلِع على قسم التغييرات في طلبات عروض الأسعار للحصول على مزيد من المعلومات.
  7. يعرض مقدّم عرض السعر استجابة لعرض السعر تشمل InterestGroupBidding. على أنها مطلوبة للمشاركة في مزاد مجموعة الاهتمامات. في OpenRTB، يتم تحديد ذلك باستخدام الحقل BidResponse.ext.igbid، وفي بروتوكول عرض الأسعار في الوقت الفعلي (RTB) من Google الذي تم إيقافه نهائيًا، يتم تحديد ذلك باستخدام الحقل BidResponse.interest_group_bidding. إذا لم يحدّد مقدّم عروض الأسعار هذه المعلومات، لن تُدرِج Google مصدر مقدّم عروض الأسعار في interestGroupBuyers في إعدادات المزاد. يمكن أن يحتوي InterestGroupBidding أيضًا على إشارات اختيارية خاصة بالمشتري ستتمّ تمريرها إلى وظيفة تقديم عروض الأسعار الخاصة بعارض الأسعار أثناء المزاد داخل المتصفّح . في OpenRTB، يتم تحديد ذلك باستخدام الحقل BidResponse.ext.igbid.igbuyer.buyerdata، وفي بروتوكول Google RTB المتوقّف نهائيًا، يتم تحديد ذلك باستخدام الحقل BidResponse.interest_group_bidding.interest_group_buyers.per_buyer_signals . اطّلِع على قسم "تغييرات استجابة عروض الأسعار" للحصول على مزيد من المعلومات.
  8. تُجري Google مزادًا من جهة الخادم وتُرسل استجابة عروض الأسعار إلى المتصفّح. يأخذ المزاد من جهة الخادم بعين الاعتبار عروض الأسعار التقليدية من جهة الخادم. يمكن أن يحتوي ردّ عروض الأسعار على معلومات عن عرض سعر فائِز سياقي (إذا كان هناك أيّ).
  9. تحتوي استجابة عرض السعر على تهيئة لمزاد الإعلانات التي تظهر داخل المتصفح. المزاد. ويمكن أن يشمل ذلك إشارات سياقية من كل مشترٍ مشارك. (التي تم إرسالها من خلال buyerdata في OpenRTB أو عرض الأسعار في الوقت الفعلي (RTB) من Google المتوقّف للبروتوكول per_buyer_signals سابقًا)، ومعلومات الفائز السياقية، إعدادات أهلية عرض الأسعار
  10. تستدعي علامة الناشر من Google Protected Audience API runAdAuction() لبدء مزاد مجموعة الاهتمامات على الجهاز فقط. تتضمن Google فقط المشترون الذين تم تضمينهم كـ InterestGroupBuyer في InterestGroupBidding خلال تهيئة المزاد.
  11. تُرسِل Google الإشارات الاختيارية الخاصة بالمشتري لكل مقدّم عرض مؤهَّل إلى إعدادات المزاد في "شريحة الجمهور المحمية".
  12. إذا حدّدت مجموعات الاهتمامات المشتركة لمقدّم عروض أسعار معيّن trustedBiddingSignalsUrl، يقدّم المتصفّح طلبًا إلى trustedBiddingSignalsUrl لكل مجموعة من أجل جلب إشارات في الوقت الفعلي لكل مجموعة. يمكنك الاطّلاع على المواصفات الخاصة بواجهة برمجة التطبيقات Protected Audience API .
  13. يستدعي المتصفّح generateBid() مقدّم عروض الأسعار لكل مجموعة اهتمامات التي تم تفعيلها وتكون مؤهّلة للمشاركة في المزاد داخل المتصفّح. تُحسِّن هذه الخطوة عرض السعر وتختار تصميم إعلان. يمكن generateBid() الوصول إلى إشارات المشترين الاختيارية التي يقدّمها مقدّم عروض الأسعار وإشارات عروض الأسعار الموثوق بها للمجموعة المحدّدة حسب الاهتمامات.
  14. ويستدعي المتصفّح إذن scoreAd() الخاص بالبائع (في هذه الحالة، Google) من أجل وتعيين ترتيب لكل عرض سعر في مزاد إعلانات مجموعة الاهتمامات. يتم ترتيب عروض الأسعار وتصفيتها استنادًا إلى وسائل حماية الناشرين والسياسات الإعلانية وغيرها القيود.
  15. يُجري المتصفّح مزادًا باستخدام عروض أسعار مجموعات الاهتمامات المؤهَّلة. تشير رسالة الأشكال البيانية يشارك عرض سعر المحتوى الأعلى ترتيبًا في المزاد داخل المتصفح.
  16. بعد المزاد، إذا كان هناك فائز مجموعة الاهتمامات، يستدعي المتصفّح حقل reportResult() لدى البائع وسمة reportWin() الخاصة بمقدّم عرض السعر لإعلام كل حول الفائز في المزاد عبر المتصفح.
  17. إذا فاز إعلان مجموعة الاهتمامات، تعرِض علامة الناشر من Google الإعلان في ملف vimeo.

تفاصيل مسار العرض

قبل عرض الإعلانات

مراجعة المواد الإبداعية

يجب أن تراجع Google تصاميم الإعلانات وتوافق عليها قبل أن يتم عرضها من خلال مزادات Protected Audience ضمن المتصفّحات يمكنك إرسال تصميمات الإعلانات للمراجعة. من خلال واجهة برمجة تطبيقات عروض الأسعار في الوقت الفعلي أو من خلال الفحص التلقائي للمواد الإبداعية: تصميمات لـ يجب أن تتضمن مزادات الإعلانات المستندة إلى مجموعات الاهتمامات ضمن المتصفّح للجمهور المحمي renderUrls للمراجعة

متطلبات renderUrls:

  • يجب أن تتطابق قيمة renderUrl المرسَلة من خلال واجهة برمجة التطبيقات مع renderUrl المستخدَم. في مزاد إعلانات مجموعة الاهتمامات.
  • لا يجوز أن يمثل كل renderUrl سوى معلنًا واحدًا أو إعلانًا واحدًا . لا يمكن استخدام renderUrl معيّن لعرض الإعلانات نيابةً عن مُعلِنين متعددين يجب ربط كل renderUrl بتصميم إعلان واحد.
  • يجب أن تكون renderUrl متاحة ويمكن لأنظمة مراجعة مواد الإبداع التي تعمل بلا إنترنت من Google استرجاعها لمدة تصل إلى 7 أيام بعد آخر مرة تمّ تقديم عرض سعر فيها للإعلان.
Real-time Bidding API

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

الفحص التلقائي لتصميمات الإعلانات

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

في حال إعداد فحص تلقائي لتصميمات الإعلانات، ستعثر Google على تصميمات الإعلانات في المزاد عبر المتصفح وفحصها تلقائيًا، لتكون مؤهلة المزادات المستقبلية.

في ما يلي كيفية تفعيل الفحص التلقائي لتصميمات الإعلانات:

  • إضافة كل أصول renderUrl لتصميم إعلان مجموعة الاهتمامات إلى حساب "المشتري المعتمَد"

  • أضِف عناوين HTTP المخصّصة التالية إلى استجابة HTTP لتصميم الإعلان:

    Authorized-Buyers-Creative-ID

    string

    الرقم التعريفي لتصميم الإعلان الخاص بالمشتري. يبلغ الحد الأقصى لطول معرّف تصميم الإعلان 128 بايت.

    Authorized-Buyers-Click-Through-URLs

    سلسلة

    مجموعة عناوين URL المقصودة المعلَن عنها للتصميم، تم ترميزها وفقًا لـ RFC2396

مثال:

HTTP/1.1 200 OK
Date: Mon, 8 Jan 2022 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Mon, 8 Jan 2022 12:01:53 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed
Authorized-Buyers-Creative-ID:123456
Authorized-Buyers-Click-Through-URLs:https://www.advertiser.com/clickUrl1,https://www.advertiser.com/clickUrl12

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>
انتهاء صلاحية تصميم الإعلان

تتم الموافقة على المواد الإبداعية لمدة 15 يومًا. إذا أرسلت تصميمات إعلانات باستخدام "الوقت الفعلي" Reporting API، ستحتاج إلى إعادة إرسال تصميم الإعلان بعد 15 يومًا. إذا كنت تعتمد على فحص المواد الإبداعية تلقائيًا، تعيد عملية الفحص فحصها تلقائيًا.

رقم تعريف إعداد تقارير المشترين

يمكنك تقسيم مقاييس إعداد التقارير (مثل مرّات الظهور) باستخدام السمات التي يقدّمها المشتري (مثل معرّف الحملة أو معرّف المعلِن). لإضافة بُعد للإنفاق على مستوى مجموعة الاهتمامات، حدِّد buyerAndSellerReportingId إعلانك عند إضافة جهاز المستخدم إلى مجموعة الاهتمامات. يمكنك الاطّلاع على مزيد من المعلومات في مستندات Protected Audience API.

إليك مثال على كيفية إضافة buyerAndSellerReportingId إلى إعدادات مجموعة الاهتمامات:

const myGroup = {
  ...
  'ads': [
    {
      ...
      'buyerAndSellerReportingId':
        '{"google_signals": {"buyer_reporting_id": "12345"}}',
      ...
    }
  ]
}
joinAdInterestGroup(myGroup);

سيظهر buyer_reporting_id كسمة جديدة في "أداة إعداد تقارير المشترين المعتمَدين"، وذلك باسم سمة رقم تعريف تقارير المشترين.

المزاد من جهة الخادم

تغييرات طلبات عروض الأسعار

في ما يلي إصدارات أولية من البروتوكولات المتوافقة للاستخدام في التجربة:

الإشارة إلى توفّر ميزة "مزاد الإعلانات المستندة إلى مجموعات الاهتمامات"

تحتوي طلبات عروض الأسعار على حقول جديدة للإشارة إلى دعم المزادات على مستوى مجموعات الاهتمامات:

  • OpenRTB:
    • BidRequest.imp.ext.ae
    • BidRequest.imp.ext.igbid
  • بروتوكول عرض الأسعار في الوقت الفعلي من Google (تم إيقافه نهائيًا):
    • BidRequest.adslot.supported_auction_environment
    • BidRequest.adslot.interest_group_bidding_allowed

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

  • SERVER_SIDE_AUCTION (OpenRTB JSON: 0): يتمّ تنفيذ المزاد الذي يحدّد الإعلان الفائز على خوادم التبادل.
  • ON_DEVICE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 1): الطلبات التي تتيح استخدام ميزة "الجمهور المحمي"، والتي يتم فيها تنفيذ مزاد سياقي على ملفّات خادم التبادل وعروض أسعار مجموعات الاهتمامات والمزاد النهائي في المتصفّح.
  • SERVER_SIDE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 3): يتم تنفيذ المزاد السياقي على خوادم التبادل، ويتم تنفيذ منطق عروض أسعار مجموعات الأهتمام ومنطق التسجيل لتحديد الإعلان الفائز النهائي في خوادم عروض الأسعار والمزادات.
الإشارة إلى حجم خانة الإعلانات المخصّصة للجمهور المحمي

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

  • OpenRTB:
    • BidRequest.imp.ext.interest_group_auction.width
    • BidRequest.imp.ext.interest_group_auction.height
  • بروتوكول عرض الأسعار في الوقت الفعلي من Google (تم إيقافه نهائيًا):
    • BidRequest.adslot.interest_group_auction.width
    • BidRequest.adslot.interest_group_auction.height

تشير هذه الحقول إلى حجم خانة الإعلان لمزاد "الجمهور المحمي" بالبكسل.

وقد يختلف هذا الحجم عن تلك الواردة في الطلب المستند إلى السياق، مثل تلك المعروضة. في BidRequest.imp.banner.format.w من OpenRTB حقلان (BidRequest.imp.banner.format.h) أو بروتوكول عرض الأسعار في الوقت الفعلي (RTB) الذي تم إيقافه من Google الحقل "BidRequest.adslot.width" و"BidRequest.adslot.height"

قد يكون للطلب السياقي أحجام متعددة. الفوز بالمزاد على الجهاز فقط يُتوقع أن يملأ الإعلان مساحة إعلانية ثابتة واحدة فقط.

الإشارة إلى إمكانية عرض الإعلانات في Protected Audience

قد يتم أو لا يتم عرض "إعلانات الجمهور المحمي" استنادًا إلى لمرحلة الدمج (راجع عدم العرض) التجربة). render_interest_group_ads في طلب عرض السعر إلى ما إذا كان إعلان Protected Audience API الفائز سيتم عرضه.

  • OpenRTB: BidRequest.imp.ext.interest_group_auction.render_interest_group_ads
  • بروتوكول عرض الأسعار في الوقت الفعلي (RTB) من Google (متوقف): BidRequest.adslot.interest_group_auction.render_interest_group_ads
الحدّ من الاعتماد على معرّفات المستخدمين

يمكن لطلبات عروض الأسعار السياقية التي تقع في نطاق اختبار Protected Audience API أن الاحتفاظ بالمعرّفات التقليدية المستندة إلى ملفات تعريف الارتباط متى توفرت من مثل حقلَي BidRequest.user.id وBidRequest.user.buyerid BidRequest.google_user_id وBidRequest.hosted_match_data بوصة بروتوكول عرض الأسعار في الوقت الفعلي (RTB) المتوقِّف من Google. يخضع توفّر هذه المعرّفات في طلبات عروض الأسعار لسياسات الخصوصية الحالية. ننصحك عدم الاعتماد على المعرّفات المستندة إلى ملفات تعريف الارتباط لأغراض الاستهداف وعروض الأسعار أثناء لإجراء اختبارات للاستعداد بشكل أفضل للشراء الفعّال عندما لا تكون ملفات تعريف الارتباط التابعة لجهات خارجية المتوفرة.

وقد تُجري Google أيضًا تجارب على نطاق صغير عندما تكون المعرّفات المستندة إلى ملفات تعريف الارتباط يتم إخفاؤها من طلبات عروض الأسعار في نطاق اختبار Protected Audience API يهدف ذلك إلى تقييم التأثير المحتمل لإيقاف ملفات تعريف الارتباط التابعة لجهات خارجية نهائيًا.

للاستعداد الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية (3PCD) في عام 2024، يوفّر Chrome الآن الاختبار الذي يسهِّله Chrome

يمكن للمواقع الإلكترونية والمورّدين استخدام الاختبار الذي يوفّره Chrome لاختبار أنظمتهم بموجب مبادرة 3PCD. في الاختبار، يتم تعيين متصفّحات Chrome إلى مجموعة تجربة تستخدم 3PCD. إما الوضع A أو الوضع B. يتم تعيين تصنيف متسق لكل متصفح مطابقة لمجموعة تجريبية محدّدة بشأن الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية والتي يمكنك الوصول إليها من خلال واجهة برمجة تطبيقات Chrome API المضمّنة في المتصفح.

تضبط Google التصنيف غير المعدّل من Chrome API في عرض سعر عرض الأسعار في الوقت الفعلي (RTB). طلبك. نظرًا إلى أن شرائح الزيارات الصغيرة في تصنيف فردي، تتمكّن Google لا تتضمن دائمًا التصنيف في سياقات محدودة الخصوصية.

في ما يلي الحقول التي يمكنك عرض التصنيف فيها:

  • OpenRTB: BidRequest.device.ext.cdep
  • بروتوكول عرض الأسعار في الوقت الفعلي (RTB) من Google (متوقف): BidRequest.device.cookie_deprecation_label

تغييرات استجابة عروض الأسعار

الإشارة إلى المشاركة في مزاد المجموعة ذات الاهتمامات المشتركة

أنت مسؤول عن الإشارة صراحةً إلى رغبتك في المشاركة في المزاد داخل المتصفّح من خلال عرض العنصر InterestGroupBidding في ردّ عرض السعر السياقي:

  • OpenRTB: BidResponse.ext.igbid
  • بروتوكول عرض الأسعار في الوقت الفعلي من Google (تم إيقافه نهائيًا): BidResponse.interest_group_bidding

يجب تقديم استجابة عرض أسعار سياقية. ولا يُشترط أن يحتوي الردّ على عرض سعر سياقي. يجب أن يحتوي الكائن InterestGroupBidding على السمة origin لكل InterestGroupBuyer، والذي يجب أن يتطابق مع أحد المصادر التي يضبطها مقدِّم عرض السعر لحسابه تتم إضافة origin إلى المزاد. interestGroupBuyers من الإعدادات عند استدعاء "علامة ناشر Google" runAdAuction()

نشر الإشارات السياقية للمشترين

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

  • OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
  • عرض الأسعار في الوقت الفعلي (RTB) من Google (متوقف نهائيًا): BidResponse.interest_group_bidding.per_buyer_signals
نشر إشارات العرض السياقي للمشتري

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

يمكنك تضمين إشارات عرض المشتري المتسلسلة كسلسلة آمنة لعنوان URL في استجابة عرض السعر حسب السياق، والتي ستحل محلها Google في الفائدة الفائزة عنوان URL لعرض المجموعة من خلال إنشاء ماكرو ${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}.

يمكن تحديد إشارات العرض في استجابة عرض السعر باستخدام الحقلَين التاليَين، وذلك استنادًا إلى البروتوكول:

  • OpenRTB: BidResponse.ext.igbid.igbuyer.rsig
  • عرض الأسعار في الوقت الفعلي (RTB) من Google (متوقف نهائيًا): BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals

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

سيتم رفض مشاركي مجموعة الاهتمامات من المشاركة في مزاد "الجمهور المحمي" إذا لم تكن الإشارات متوافقة مع عناوين URL أو لم تكن لاحقات العلامات الكبيرة فريدة أو إذا تم تقديم أكثر من 3 مجموعات من الإشارات.

تحديد الحد الأقصى لسعر عرض السعر داخل المتصفّح

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

يتم دعم إجراءات التخفيف من خلال اختبار Protected Audience API من Google. لشركاء عرض الأسعار في الوقت الفعلي، يمكنك تحديد قيمة عرض السعر الأقصى المتوقعة في كل استجابة عرض الأسعار السياقية. الحد الأقصى المتوقّع لعرض السعر هو الحد الأقصى لسعر عرض السعر الذي من المتوقّع أن تعرِضَه دالة عروض الأسعار. إذا تجاوز عرض الأسعار الفائز الذي تم الإبلاغ عنه من المزاد داخل المتصفّح هذا المبلغ، لا يتم احتساب عرض الأسعار الفائز كحدث قابل للفوترة. هذا النهج عرضة للتغيير.

في استجابة عرض السعر، يمكنك تحديد قيمة عرض السعر الأقصى المتوقعة في الحقول التالية:

  • OpenRTB: BidResponse.igbid.igbuyer.maxbid(يتم التعبير عنها بوحدات عملة التكلفة لكل ألف ظهور)
  • بروتوكول عرض الأسعار في الوقت الفعلي من Google (تم إيقافه نهائيًا): BidResponse.interest_group_bidding.interest_group_buyers.max_bid_cpm_micros (يتم التعبير عنه بالتكلفة الفعلية لكل ألف ظهور على مستوى الميكرو)
إسناد مرات الظهور إلى حسابات متعددة

يجب أن يختار مقدِّم عرض السعر معرّف فوترة لتحديد مصدر اهتمامه. مرات ظهور عروض الأسعار باستخدام الحقول التالية:

  • OpenRTB: BidResponse.igbid.igbuyer.billing_id
  • بروتوكول عرض الأسعار في الوقت الفعلي من Google (تم إيقافه نهائيًا): BidResponse.interest_group_bidding.interest_group_buyers.billing_id

يجب أن يكون معرّف الفوترة المحدّد هو معرّف فوترة مؤهّل من طلب عروض الأسعار:

  • OpenRTB: BidRequest.imp.ext.billing_id
  • بروتوكول عرض الأسعار في الوقت الفعلي (RTB) من Google (متوقف): BidRequest.adslot.matching_ad_data.billing_id

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

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

من الممكن ضبط ميزانية يومية لكل رقم تعريف فوترة. تواصل مع مدير الحساب لتعيين الميزانية اليومية لأرقام تعريف الفوترة للحسابات الفرعية.

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

أثناء المزاد داخل المتصفّح

إنشاء عروض أسعار داخل المتصفّح

استخدام generateBid() لإنشاء عروض أسعار داخل المتصفح.

توفّر Google المَعلمات التالية:

  • auctionSignals: فارغ
  • perBuyerSignals: كائن JavaScript من الإشارات نفسها التي يوفّرها تقديم عرض سعر في الاستجابة السياقية

يتم عرض المَعلمات التالية:

  • ad: يتجاهل محرّك بحث Google هذا الحقل.
  • bid: عرض سعر رقمي يدخل المزاد يجب أن تكون بوحدات تكلفة الألف ظهور (وليس بالوحدات المجهرية).
  • render: عنوان URL الذي يتم عرضه لعرض تصميم الإعلان إذا فازت عرض السعر في المزاد على Google مراجعة عنوان URL هذا والموافقة عليه، وإلا سيتمّ فلترته من المزاد.
  • allowComponentAuction: يجب أن يكون true. تتيح Google حاليًا اختبار المزادات التي ينظّمها بائعون متعدّدون.

وفي ما يلي مثال لذلك:

function generateBid(...) {
  ...
  return {'ad': 'example',
          'bid': ad.metadata.bid,
          'render': ad.renderUrl,
          'allowComponentAuction': true};
}

اطّلع على مواصفات Protected Audience على الجهاز عروض الأسعار للحصول على شرح لدالة generateBid().

عملة عرض السعر

يتم وضع عروض أسعار المزاد داخل المتصفح بوحدات التكلفة لكل ألف ظهور بعملة عرض السعر المحدّدة.

ويجب تحديد عملة عرض السعر في كل من استجابة عرض السعر حسب السياق تكون القيمة المعروضة generateBid ويجب أن تكون رمز ألفا ISO 4217 صالحًا، مثل مثل "USD" أو "EUR" أو "JPY"

في OpenRTB، استخدِم الحقل الجديد cur في عنصر InterestGroupBuyer في إضافة استجابة عرض السعر من Google.

وفي ما يلي مثال لذلك:

ext {
  igbid {
    impid: "1"
    igbuyer {
      origin: "https://examplebuyerorigin.com"
      cur: "EUR"
    }
  }
}

في بروتوكول عرض الأسعار في الوقت الفعلي (RTB) من Google، استخدم الحقل currency الجديد في رسالة واحدة (InterestGroupBuyer) في الردّ على عرض السعر.

وفي ما يلي مثال لذلك:

interest_group_bidding {
  adslot_id: 1
  interest_group_buyer {
    origin: "https://examplebuyerorigin.com"
    currency: "EUR"
  }
}

نظام عروض الأسعار يجب أن تعرض دوال generateBid عروض الأسعار بالعملة نفسها تتم الإشارة إليها في استجابة عرض السعر حسب السياق. املأ السمة bidCurrency الجديدة في قيمة الإرجاع generateBid:

function generateBid(...) {
  ...
  return {'ad': ad,
          'bid': bid,
          'bidCurrency': 'EUR',
          ...};
}

إذا كانت العملة الواردة في استجابة عرض السعر حسب السياق مختلفة عن العملة الذي إرجاعه generateBid، أو في حال عرض أي منهما عملة غير صالحة، سيتم عرض السعر قبل المزاد.

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

قد يكون فرض سياسة المواد الإبداعية وعناصر تحكّم الناشر أكثر تقييدًا ل عروض أسعار مجموعات الاهتمامات داخل المتصفّح أثناء اختبار Protected Audience API لشركاء RTB .

الدعم بشأن "قانون الخدمات الرقمية"

بموجب المادة 26 من "قانون الخدمات الرقمية"، يجوز للناشرين أن يطلبوا من المشترين عرض بيانات الإفصاح عن الشفافية داخل الإعلانات. عندما يفعّل الناشر عنصر التحكّم "الطلب من المشترين عرض الإعلانات التي تتضمّن معلومات الشفافية حسب قانون الخدمات الرقمية فقط على موقعي الإلكتروني أو تطبيقي في المنطقة الاقتصادية الأوروبية"، يمكن لمشتري مجموعات الاهتمامات تحديد الفرص التي سيُطلب منهم عرض شفافية المشترين لها من خلال ملاحظة قيم BidRequest.regs.dsa.required وBidRequest.dsa.pubrender في طلب عرض السعر (BidRequest.dsa.dsa_support و BidRequest.dsa.publisher_rendering_support على التوالي في بروتوكول RTB المنتهي الصلاحية من Google).

عندما يتلقّى مقدّم عرض السعر الذي يريد المشاركة في مزادات Protected Audience API إشارة في طلب عرض السعر بضرورة عرض معلومات الشفافية المتوافقة مع "قانون الخدمات الرقمية" ل الإعلانات التي يتم عرضها من خلال Protected Audience API، يجب عليه تقييم ما إذا كان بإمكانه عرض المعلومات المطلوبة بشكل مناسب وتحديد ذلك من خلال ضبط القيمة BidResponse.ext.igbid.igbuyer.dsaadrender (BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render في بروتوكول Google RTB المتوقّف نهائيًا). بخلاف ذلك، لن يتم تضمين المشتري في مزاد Protected Audience API.

لمزيد من المعلومات حول شفافية الإعلانات بموجب "قانون الخدمات الرقمية"، يُرجى الاطّلاع على مقالة مركز المساعدة: الامتثال لـ "قانون الخدمات الرقمية".

فلترة عروض الأسعار

تفرض Google عناصر التحكّم التي يوفّرها الناشر وسياسات الإعلانات أثناء المزاد على الجهاز.

بعد المزاد داخل المتصفّح

الإبلاغ عن نتيجة المزاد للمشتري: reportWin()

لا يملأ محرّك بحث Google الوسيطات التالية:

  • auctionSignals
  • sellerSignals

استخدِم reportWin() للإبلاغ عن نتيجة المزاد للمشتري.

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

وحدات ماكرو

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

${GDPR} يتمّ توسيعها إلى 0 إذا لم تنطبق "اللائحة العامّة لحماية البيانات" أو 1 إذا كانت تنطبق. اطّلِع على المستندات.
${GDPR_CONSENT_XXXX} توسيع النطاق ليشمل الشفافية و سلسلة الموافقة (TC) المرتبطة بالطلب إذا لم تتوافق الشفافية سلسلة الموافقة (TC) فارغة أو غير صالحة، ولا يتم توسيع وحدة الماكرو هذه.

استخدِم وحدة الماكرو هذه لتمرير سلسلة الشفافية والموافقة إلى مورّد مسجّل في قائمة المورّدين العالميين (GVL) في مكتب IAB في عنوان URL. استبدِل XXXX بمعرّف قائمة المورّدين العالميين (GVL) في IAB للمورّد المسجّل في قائمة المورّدين العالميين (GVL) في IAB. إذا كانت سلسلة الشفافية والموافقة فارغة أو غير صالحة، لا يتم توسيع هذه الماكرو.

يمكن أن تصبح تصاميم الإعلانات التي تحتوي على وحدة ماكرو ${GDPR_CONSENT_XXXX} إذا كان المورِّد المسجَّل في "قائمة المورّدين العالميين" (GVL) في IAB والمرتبط بمعرّف قائمة المورّدين العالميين (GVL) لمكتب IAB المدرج لا يحتوي على موافقة المستخدم.

يجب أن يظهر الماكرو ${GDPR_CONSENT_XXXX} مرة واحدة فقط في renderUrl.
${ADDL_CONSENT} يتمّ توسيعها إلى سلسلة "الموافقة الإضافية" المرتبطة بالطلب.
${AD_WIDTH}, ${AD_HEIGHT) تُدرج وحدات الماكرو هذه عرض الشريحة الإعلانية وارتفاعها.
${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}

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

استبدِل العنصر النائب buyer.origin.example بمصدر مشتري مجموعة الاهتمامات، والذي يجب أن يتطابق مع interest_group_buyers.origin في ردّ عرض السعر. يمكنك عليك تضمين _OPTIONAL_SUFFIX لتوفير ما يصل إلى ثلاثة رموز قيم إشارات العرض

احتساب عدد مرّات الظهور

أثناء اختبار Protected Audience API مع شركاء عروض الأسعار في الوقت الفعلي، ستحصي Google مرّات الظهور عندما يستدعي المتصفّح دالة reportResult() ثم تسترجع عنوان URL لإعداد تقارير Google في طلب موجَّه إلى sendReportTo().

بما أنّ الحدث الذي استخدمته Google لاحتساب مرّات الظهور في Protected Audience قد تختلف المزادات عبر المتصفّح عن الحدث المستخدَم لاحتساب مرات الظهور من قِبل شركاء المشترين لعرض الأسعار في الوقت الفعلي (RTB)، قد يختلف عدد مرات الظهور.

إنّ أحد أهداف Google لاختبار Protected Audience API هو تحديد هذه الاختلافات والحدّ منها.

تحديد مرات الظهور القابلة للفوترة

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

الحد الأقصى للميزانية اليومية

أثناء اختبار Protected Audience API، يتضمّن كلّ حساب مستوى حساب. الحد الأقصى للميزانية اليومية لإنفاق الجمهور المحمي يحد الحد الأقصى للميزانية اليومية من المخاطر في بيئة المزاد داخل المتصفح. بعد بلوغ الحدّ الأقصى للميزانية اليومية، لن يتلقّى الحساب طلبات عروض أسعار مؤهّلة للجمهور المحمي.

يمكن أن يستمر الحساب في المشاركة في المزادات السياقية من جهة الخادم بعد الوصول إلى الحدّ الأقصى لعدد المستخدمين المحمي على سبيل المثال، يصل حساب مقدِّم عرض السعر الذي يصل قد يتلقّى تحديد الحدّ الأقصى لميزة "الجمهور المحمي" طلب عرض سعر مع auction_environment = SERVER_SIDE_AUCTION (OpenRTB JSON: 0)، حتى إذا كان طلب عرض السعر مؤهَّلاً. لإنشاء مزاد يستخدم Protected Audience API

ملاحظات في الوقت الفعلي والحد الأدنى لعرض السعر للفوز

مقدّمو عروض الأسعار الذين وافقوا على تلقّي ملاحظات في الوقت الفعلي ملاحظات بشأن المشترين ضمن مجموعة المصالح الذين يطلبون تضمينهم في مزاد يستخدم Protected Audience API على الجهاز فقط سيتلقّى كلّ مشتري مجموعة اهتمامات يحدّده مقدّم عروض أسعار في ردّ عرض سعر عنصر ملاحظات واحدًا، بغضّ النظر عن عدد عروض الأسعار التي يقدّمها مشتري مجموعة الاهتمامات في مزاد "الجمهور المحمي". ستتوفّر العميل التالية في عنصر ملاحظات المشترين في المجموعة ذات الاهتمامات المشتركة:

  • سيكون نوع الملاحظات لكائن الملاحظات INTEREST_GROUP_BUYER_FEEDBACK
  • أصل المشتري ضمن مجموعة الاهتمامات.
  • الحد الأدنى لعرض السعر للفوز الذي يجب أن يقدّمه مشتري مجموعة الاهتمامات من أجل الفوز بالمزاد العام.
  • الحد الأدنى لعرض السعر للفوز بالمشتري ضمن مجموعة الاهتمامات من أجل التغلب على عرض السعر الأعلى ترتيبًا من مكوّن جانب الخادم في المزاد العام.
  • رمز حالة مشتري المجموعة ذات الاهتمامات المشتركة. رموز الحالة المحتملة هي محددة في interest-group-buyer-status-codes.txt.

راجِع مستندات البروتوكول المتعلّقة ببروتوكول RTB للمشترين المعتمَدين وإضافات OpenRTB لمعرفة أسماء الحقول المحدّدة.

إشعار الملاحظات والآراء بشأن عرض السعر

يقدّم Chrome واجهة برمجة تطبيقات مؤقتة لتحديد الأخطاء وإصلاحها لـ Protected Audience API تتيح لـ "مدير إعلانات Google" إرسال إشعارات تحديد أخطاء وإصلاحها في الوقت الفعلي من خادم إلى خادم تحتوي على ملاحظات حول عرض سعر "شريحة الجمهور المحمية". سيتضمن هذا الإشعار أسبابًا لتحديد عروض الأسعار بعد فلترته في مزاد Protected Audience ضمن المتصفح بالإضافة إلى معلومات عن عرض السعر الموضح أدناه.

يمكن لمقدّمي عروض الأسعار التواصل مع مدير حساباتهم لضبط عنوان URL ثابت سيتم استخدامه لإرسال إشعارات الملاحظات بشأن عروض الأسعار لتحديد المشاكل وحلّها في ميزة "شرائح الجمهور المحمية". هذا النمط سيتم استرجاع عنوان URL الثابت من خوادم Google مع استبدال وحدات الماكرو المحدّدة. بعد اكتمال مزاد Protected Audience API وحدات الماكرو التالية مدعوم:

  • %%GOOGLE_QUERY_ID%%: تم استبدال وحدة الماكرو هذه برقم تعريف طلب بحث Google التي تمّ إرسالها في طلب عرض السعر السياقي الذي تم تفعيل ميزة "الوصول إليه من خلال Protected Audience" في بروتوكول OpenRTB، يتم تحديد ذلك باستخدام BidRequest.ext.google_query_id، في حين يستخدم بروتوكول عرض الأسعار في الوقت الفعلي (RTB) من Google الذي تم إيقافه نهائيًاBidRequest.google_query_id.
  • %%INTEREST_GROUP_OWNER%%: أصل مالك مجموعة الاهتمامات.
  • %%BID_CPM%%: سعر عرض السعر بنظام التكلفة لكل ألف ظهور الذي حدّده المشتري في الدالة generateBid().
  • %%RENDER_URL%%: عنوان URL لعرض تصميم الإعلان.
  • %%STATUS%%: رمز حالة في حال رفض عرض السعر خلال scoreAd() القيم هي حالة تصميم الإعلان الرموز البرمجية.

في ما يلي نموذج لعنوان URL ثابت قد يقدّمه مقدّم عروض الأسعار إلى مدير الحساب:

https://dsp.example/debug?google_query_id=%%GOOGLE_QUERY_ID%%&ig_owner=%%INTEREST_GROUP_OWNER%%&render_url=%%RENDER_URL%%&bid=%%BID_CPM%%&status=%%STATUS%%

إشعار الملاحظات بشأن عروض الأسعار هو ميزة مؤقتة تعتمد على واجهة برمجة التطبيقات ForDebuggingOnly المؤقتة في Chrome.

TURTLEDOVE على مستوى المنتج

الإعلانات المكوّنة من عدة أجزاء أو التصنيف على مستوى المنتج TURTLEDOVE (PLTD) متاح لشركاء عرض الأسعار في الوقت الفعلي من Google أثناء اختبار Protected Audience API . يُرجى إبلاغ مدير حسابك أثناء عملية الدمج إذا كنت تنوي اختبار PLTD، لأنّه يجب توفّر موارد وإعدادات إضافية.

الإعداد

إليك كيفية اختبار Protected Audience API:

الخطوات

  1. املأ نموذج الطلب للانضمام إلى تجربة Protected Audience API
  2. بعد إرسال نموذج الطلب، يُرجى التواصل مع مدير حسابك أو إرسال طلب باستخدام مركز مساعدة المشترين المعتمَدين .
  3. وبعد إعداد الحساب، يمكن لكل من Google والشريك التحقّق من الدمج من خلال الخطوات الواردة في مراحل الاختبار.

مراجعة تصميمات الإعلانات

لتقديم عروض أسعار باستخدام إعلانات على مستوى المنتج (الإعلانات التي تتألف من عدة أجزاء) في مزادات Protected Audience API، اتّبِع المتطلبات التالية:

  • يجب تضمين معلَمة طلب البحث &pltd=True في renderUrl حاوية الإعلان المكون (ويُطلق عليها أيضًا renderUrl ذات المستوى الأعلى) إلى لتمييز renderUrls المستوى الأعلى أثناء مراجعة تصميم الإعلان.
  • عرض تصميم إعلان تمثيلي عند جلب حاوية الإعلان المكوّن لمراجعة تصميم الإعلان من قِبل Google من أجل فهم متى عرض الإعلانات التمثيلية، يمكنك الرجوع إلى معلمة طلب البحث validation=True التي حددها نظام مراجعة تصميمات الإعلانات في Google.

قائمة التحقّق من الدمج

  • إعداد نقطة نهاية لطلب عرض السعر من أجل تعبئة Protected Audience API ذات الصلة في استجابة عرض السعر حسب السياق - مثل interest_group_bidding
  • تنفيذ وضع العلامات على صفحات المعلِن للانضمام إلى متصفّح المستخدِم في مجموعة الاهتمامات
  • نفِّذ generateBid() وreportWin().
  • اختَر مصادر مالك مجموعة الاهتمامات وأضِفها إلى المشتري المعتمَد. الحساب.
    • يجب أن تتطابق أصول مالكي مجموعات الاهتمامات مع الأصول التي يتم فيها استضافة وظائف generateBid().
    • يمكنك التواصل مع مدير الحساب أو تقديم طلب دعم باستخدام نظام مركز مساعدة المشترين من أجل لإكمال هذه الخطوة.
  • إعداد ميزة "الاستهداف المُسبَق" للمستودع الإعلاني ذي الصلة باختبار Protected Audience API
  • أرسِل تصميمات الإعلانات للمراجعة والموافقة عليها من خلال Creatives API.
  • (اختياري) إعداد نقاط نهاية إشارات عروض الأسعار الموثوق بها.
  • (اختياري) إعداد صفحة اختبارية للمعلن تتيح لمهندسي Google إضافة من متصفحه إلى المجموعات ذات الاهتمامات المشتركة التي يملكها المشترين ضمن مجموعة الاهتمامات المشتركة، المصدر. يتيح لنا ذلك بدء مزادات Protected Audience يدويًا.
  • (اختياري) تفعيل التعليقات في الوقت الفعلي على حسابك لتلقي التعليقات على طلب المشترون ضمن مجموعة الاهتمامات لإدراجهم في شريحة جمهور محمية المزاد.
  • (اختياري) يمكنك التواصل مع مدير حسابك لضبط عنوان URL ثابت تلقّي إشعار من خادم إلى خادم يقدّم عرض سعر Protected Audience ملاحظات عن حالة عرض سعر من "جمهور محمي على الجهاز فقط" المزاد للمساعدة في تصحيح الأخطاء غير المتوقعة. اطّلِع على إشعار ملاحظات بشأن عروض الأسعار لمعرفة التفاصيل.

مراحل الاختبار

المرحلة 1: الاختبار اليدوي

في ما يلي كيفية بدء مزاد "شريحة الجمهور المحمية" يدويًا، والتأكّد من إمكانية عرض الإعلان، وتسجيل مرّة الظهور:

  1. استخدام الإصدار 101 من Chrome أو إصدار أحدث
  2. فعِّل Privacy Sandbox API و"الإطار المحدود" باستخدام علامتَي HTML chrome://flags/#privacy-sandbox-ads-apis و chrome://flags/#enable-fenced-frames. اطّلِع على مزيد من المعلومات في صفحة اختبار الخصوصية. وضع الحماية.
  3. أرسِل تصميم إعلان للموافقة عليه باستخدام واجهة برمجة التطبيقات لعرض الأسعار في الوقت الفعلي .
  4. استخدِم صفحة المعلِن المقدَّمة من مقدّم عروض الأسعار لإضافة متصفّح إلى مجموعة الاهتمامات التي يملكها مقدّم عروض الأسعار.
  5. استخدِم صفحة الناشر الاختبارية التالية التي تقدّمها Google لبدء مزاد "شريحة الجمهور المحمية":

    https://fledge-testing.uc.r.appspot.com/?nid=allow_all

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

  6. تحقَّق مما يلي:

    1. ويتم عرض الإعلان الفائز المتوقع.
    2. يتم إرسال نتيجة المزاد من جهة الخادم، ما يعني أنّ مقدّم عرض السعر الفائز يتلقّى إشعارًا من reportWin().
    3. تسجِّل وحدة تحكم صفحة الناشر التجريبية رسالة تصحيح أخطاء لكل عرض سعر المعلومات التالية:
      • renderUrl: عنوان URL لعرض عرض السعر.
      • interestGroupOwner: مالك مجموعة الاهتمامات لعرض السعر.
      • accepted: قيمة هذا الحقل true إذا تم قبول عرض السعر وfalse في حالة رفض عرض السعر من قبل scoreAd().
      • externalBidStatus: رمز حالة في حال رفض عرض السعر خلال scoreAd(). القيم هي حالة تصميم الإعلان الرموز البرمجية.

المرحلة 2: (اختيارية) تجربة عدم العرض

بعد أن تتحقّق Google والشريك يدويًا من إمكانية المشاركة في مزاد Protected Audience، تتيح Google للشريك المرحلة التالية من الاختبار.

تخصص Google قدرًا صغيرًا من الزيارات المباشرة لعرض مزادات "الجمهور المحمي". بعد ذلك، لن تحتاج Google والشريك إلى تفعيل هجمة علنية لمزاد "شرائح الجمهور المحمية" يدويًا. لا يتم عرض نتيجة مزاد "الجمهور المحمي". وهذا يتيح لنا اختبار عملية الدمج على نطاق واسع.

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

المرحلة 3: تجربة العرض

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

يمكنك التواصل مع مدير حسابك أو تقديم طلب دعم من خلال الشراة المعتمَدون. مركز المساعدة عندما تكون مستعدًا. ستفعّل Google الحساب لهذه المرحلة.

الميزات الإضافية

الميزات التالية هي إضافات للبروتوكول الأساسي.

موازاة

ويُعدّ "التشغيل المتوازي" عملية تحسين تقلّل من وقت استجابة المزاد من البداية إلى النهاية من خلال بدء طلب الإعلان السياقي بالتوازي مع الطلبات المرسَلة إلى الخوادم الموثوق بها للمشتري المُحدَّدة في trustedBiddingSignalsUrl.

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

ملخّص عملية عرض الإعلانات

في ما يلي ملخّص لمسار المزاد الموازي: المخطّط البياني للمسار

أهلية المشترين في مجموعات الاهتمامات على الجهاز

في المزادات الموازية، يتم إجراء مكالمة "navigator.runAdAuction" قبل. سيتم عرض استجابة الإعلان السياقية. لبدء طلبات navigator.runAdAuction التي يثق بها المشترون، يجب تمرير المَعلمة interestGroupBuyers كقيمة، في حين أنّ مَعلمات المزاد المتبقية تقبل navigator.runAdAuctionJavaScript التي يمكن حلّها بعد استجابة الإعلان السياقي. بما أنّه يتم تمرير interestGroupBuyers قبل استجابة الإعلان السياقي، لا يمكن استخدام استجابة الإعلان السياقي (بما في ذلك استجابات عروض الأسعار) لاختيار المشترين الذين يشاركون في المزاد المجمّع للطلب المحدّد. وبدلاً من ذلك، تخزّن علامة ناشر Google في ذاكرة التخزين المؤقت في متصفّح المستخدم، المَعلمة interestGroupBuyers من navigator.runAdAuction عملية تنفيذ على النطاق نفسه

هناك العديد من الاعتبارات المهمة لعملية التوازي:

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

  2. وبما أن عملية الموازية تعتمد على التخزين المؤقت لقائمة المشترون ضمن مجموعة الاهتمامات، لا تُجري Google دائمًا مزادًا موازيًا، مثل ذاكرة التخزين المؤقت للموازاة قد تكون فارغة أو منتهية الصلاحية. إذا كانت ذاكرة التخزين المؤقت فارغة أو منتهية الصلاحية، يُشغل Google مزاد عادي غير متوازٍ في Protected Audience API ويستخدم نية الشراء بغرض المشاركة في المزاد غير المتوازي لإنشاء ذاكرة التخزين المؤقت الخاصة بالمشترين ضمن مجموعة الاهتمامات.

  3. في حال تم تخزين مشترٍ واحد على الأقل لأي نظام عرض أسعار مؤقتًا للناشر الحالي مجال، فعندئذٍ ستشغل Google جدولاً موازيًا المزاد، الذي ستتم الإشارة إليه في طلب عرض السعر:

    • بروتوكول عرض الأسعار في الوقت الفعلي من Google: BidRequest.adslot.interest_group_auction.parallelized
    • OpenRTB: BidRequest.imp.ext.interest_group_auction.parallelized
  4. كل مصدر مشتري ضمن مجموعة اهتمامات مسجّلة للمقدّم عرض سعر تم تحديده في المزاد الموازي إدخال ParallelAuctionBuyer:

    • بروتوكول عرض الأسعار في الوقت الفعلي من Google: BidRequest.adslot.interest_group_auction.parallel_auction_buyer
    • OpenRTB: BidRequest.imp.ext.interest_group_auction.pbuyer
  5. في حال إجراء مزاد موازٍ، ولكن لم يكن مصدر مشترٍ محدَّدًا متاحًا في ذاكرة التخزين المؤقت، فلا يمكن إضافة هذا المشتري المحدد إلى الجهاز الحالي المزاد. ويُشار إلى ذلك من خلال طلب يتضمّن parallelized=True لا يتضمّن إدخالًا ParallelAuctionBuyer لمصدر مشترين معيّن من مجموعة الاهتمامات. مع ذلك، يمكن أن يُظهر مقدّمو عروض الأسعار اهتمامهم من خلال إدراج عروض أسعار صالحة ومؤهّلة InterestGroupBuyer في الاستجابة لعرض السعر سيكون للمشتري المقابل لمجموعة الاهتمامات التي تمت إضافتها إلى ذاكرة التخزين المؤقت، وستكون هذه المصادر مؤهلة الطلبات المستقبلية الموازية من المتصفح والنطاق نفسيهما. يمكن الإشارة إلى نية المشاركة في مزادات مجموعات الاهتمامات في الحقول التالية:

    • بروتوكول عرض الأسعار في الوقت الفعلي (RTB) من Google: BidResponse.adslot.interest_group_bidding.interest_group_buyers
    • OpenRTB: BidResponse.ext.igbid.igbuyer
  6. أصول المشترين المخزنين مؤقتًا (والتي يتم تضمينها في المزاد الموازي مَعلمة interestGroupBuyers) التي لا يشير فيها مقدِّم عرض سعر إلى النية بالشراء بالمشاركة في استجابة عرض السعر الخاص بهم، قد يتلقّى مكالمة بخادم موثوق به من المشترين ولكن لن تشارك في المزاد الموازي