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

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

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

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

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

ملخّص تدفق العرض

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

الرسم التخطيطي للانسياب

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

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

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

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

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

متطلبات "renderUrls":

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

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

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

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

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

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

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

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

    Authorized-Buyers-Creative-ID

    سلسلة

    رقم تعريف تصميم الإعلان الخاص بالمشتري. الحد الأقصى لطول رقم تعريف تصميم الإعلان هو 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 يومًا. إذا أرسلت تصميمات الإعلانات باستخدام واجهة برمجة التطبيقات في الوقت الفعلي لعروض الأسعار، عليك إعادة إرسال تصميم الإعلان بعد 15 يومًا. إذا كنت تعتمد على الفحص التلقائي لتصميمات الإعلانات، ستؤدي عملية الفحص إلى إعادة فحصها تلقائيًا.

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

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

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

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

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

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

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

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

تحديد إتاحة مزاد مجموعات الاهتمامات

تحتوي طلبات عروض الأسعار على حقل جديد، وهو auction_environment.

  • بروتوكول Google RTB: BidRequest.adslot.auction_environment
  • OpenRTB: BidRequest.imp.ext.auction_environment

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

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

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

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

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

قد يختلف هذا الحجم عن أحجام الطلب السياقي (Adslot.widthوAdslot.height، أو في OpenRTB: BidRequest.imp.banner.format).

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

تحديد إمكانية عرض إعلانات الجمهور المحمي

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

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

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

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

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

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

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

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

  • بروتوكول Google RTB: BidRequest.device.cookie_deprecation_label
  • OpenRTB: BidRequest.device.ext.cdep

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

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

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

  • بروتوكول Google RTB: BidResponse.interest_group_bidding
  • OpenRTB: BidResponse.ext.igbid

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

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

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

  • عرض الأسعار في الوقت الفعلي (RTB) من Google: BidResponse.interest_group_bidding.per_buyer_signals
  • OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
تحديد الحد الأقصى لسعر عرض السعر داخل المتصفح

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

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

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

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

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

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

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

  • بروتوكول عرض الأسعار في الوقت الفعلي من Google: BidRequest.adslot.matching_ad_data.billing_id
  • OpenRTB: BidRequest.imp.ext.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};
}

راجِع قسم عروض الأسعار على الأجهزة في مواصفات الجمهور المحمي للاطّلاع على شرح لوظيفة generateBid().

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

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

يجب الإشارة إلى عملة عرض السعر في كلّ من استجابة عرض السعر السياقي وفي القيمة المعروضة التي تبلغ generateBid، ويجب أن تكون رمز ألفا صالحًا وفقًا لمعيار ISO 4217، مثل USD أو EUR أو JPY.

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

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

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

في بروتوكول "عرض الأسعار في الوقت الفعلي" من 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.dsa.dsa_support وBidRequest.dsa.publisher_rendering_support لبروتوكول "الشراة المعتمَدون من Google" وBidRequest.regs.dsa.required وBidRequest.dsa.pubrender لبروتوكول OpenRTB.

عندما يتلقّى مقدّم عروض الأسعار الذي يريد المشاركة في مزادات Protected Audience API إشارة في طلب عرض الأسعار تفيد بأنّه يجب عرض شفافية الإعلانات الديناميكية على شبكة البحث للإعلانات التي يتم عرضها من خلال Protected Audience API، عليه تقييم ما إذا كان بإمكانه عرض المعلومات المطلوبة بشكل مناسب وتحديدها من خلال ضبط BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render لبروتوكول "الشراة المعتمَدون من Google" أو BidResponse.ext.igbid.igbuyer.dsaadrenderلبروتوكول OpenRTB. وبخلاف ذلك، لن يتم تضمين المشتري في مزاد 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} يتم توسيع النطاق وصولاً إلى سلسلة الموافقة الإضافية (AC) المرتبطة بالطلب.
${AD_WIDTH}, ${AD_HEIGHT) تُدرِج وحدات الماكرو هذه عرض الشريحة الإعلانية وارتفاعها.

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

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

قد يختلف عدد مرّات الظهور لأنّ الحدث الذي تستخدمه Google لاحتساب عدد مرات الظهور في المزادات المستندة إلى "الجمهور المحمي" في المتصفِّح قد يكون مختلفًا عن الحدث المستخدَم لاحتساب عدد مرات الظهور من قِبل شركائها في عروض الأسعار في الوقت الفعلي (RTB).

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

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

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

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

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

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

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

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

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

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

إشعار بالملاحظات على عروض الأسعار

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

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

  • %%GOOGLE_QUERY_ID%%: تم استبدال وحدة الماكرو هذه برقم تعريف طلب بحث Google (BidRequest.google_query_id في بروتوكول "الشراة المعتمَدون"، وBidRequest.ext.google_query_id في بروتوكول OpenRTB) الذي تم إرساله في طلب عرض السعر السياقي الذي تم تفعيل ميزة "الجمهور المحمي" عليه.
  • %%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.

أحداث النقر

يمكن لمقدّمي عروض الأسعار إبلاغ Google بأحداث النقرات على إعلانات Protected Audience باستخدام واجهة برمجة التطبيقات Fenced Frame Reporting API. على مقدِّمي عروض الأسعار استخدام نوع الحدث "click" لإشعار Google بالنقرات. إليك مثال:

window.fence.reportEvent({
    'eventType': 'click',
    // Google does not require bidders to send data to Google in 'eventData'.
    // However, 'eventData' must be a non-null value, such as an empty string.
    'eventData': '',
    'destinations': ['direct-seller']
});

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.
  • إرسال تصميمات الإعلانات للمراجعة والموافقة عليها من خلال واجهة برمجة التطبيقات لتصميمات الإعلانات.
  • (اختياري) إعداد نقاط نهاية إشارات عروض الأسعار الموثوق بها
  • (اختياري) يمكنك إعداد صفحة معلن اختبارية تسمح لمهندسي Google بإضافة متصفّحهم إلى مجموعات الاهتمامات التي يملكها أصل مشتري مجموعة الاهتمامات. يتيح لنا ذلك بدء مزادات "الجمهور المحمي" يدويًا.
  • (اختياري) فعِّل الملاحظات في الوقت الفعلي على حسابك لتلقّي الملاحظات من المشترين من مجموعات الاهتمامات الذين طلبوا إدراجهم في مزاد جمهور محمي.
  • (اختياري) يمكنك التواصل مع مدير حسابك لضبط عنوان URL ثابت من أجل تلقّي إشعار من خادم إلى خادم يقدّم ملاحظات عن حالة عرض سعر من خلال "مزاد جمهور محمي" على الجهاز للمساعدة في تصحيح المشاكل غير المتوقّعة. راجع إشعار الملاحظات حول عروض الأسعار للحصول على التفاصيل.

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

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

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

  1. استخدِم الإصدار 101 من Chrome أو إصدارًا أحدث.
  2. تفعيل Privacy Sandbox API وFenced Frame باستخدام 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 والشريك يدويًا من أنّه بإمكانها المشاركة في مزاد الجمهور المحمي، سيُتاح للشريك المرحلة التالية من الاختبار.

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

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

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

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

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