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

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

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

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

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

الإصدار التجريبي: قد يتغيّر السلوك الموضّح هنا في المستقبل استنادًا إلى المعلومات التي نتلقّاها منك. الاختبار وجمع الملاحظات من الناشرين والشراة المعتمَدين.

ملاحظة: يتوفّر اختبار Protected Audience API ضمن ميزة "الشراة المعتمَدون" فقط. لا يمكن استخدام عروض الأسعار من Exchange والشبكة الإعلانية المشارِكة في "عرض الأسعار المفتوح" حتى الآن

ملاحظة: عندما تصبح واجهة برمجة التطبيقات Protected Audience API (المعروفة سابقًا باسم FLEDGE) متوفّرة للجمهور العام في Chrome، سيبدأ "مدير الإعلانات" تدريجيًا بزيادة عدد الزيارات المضمنة في الاختبار. سنراقب تأثير ذلك على الناشرين في الأرباح، لأنّنا نزيد ببطء نسبة الزيارات، ولن نزيد كذلك إذا كان هناك تأثير سلبي ملحوظ. نتوقع أنه بنهاية في عام 2023، سيتم تفعيل ما يصل إلى% 10 من زيارات Chrome من خلال Protected Audience API. للاختبار.

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

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

1. يعمل نظام عروض الأسعار مع المعلنين للحفاظ على مجموعات اهتمامات لكل منهم المعلن. في كثير من الأحيان، يضيف المعلنون علامة مقدم عرض سعر إلى صفحة المعلن لإضافة متصفّح إلى مجموعات الاهتمامات.
2. يزور أحد المستخدمين صفحة المعلن. قد تحتوي الصفحة على أزرار .
3. تستدعي علامة مقدِّم عرض السعر Protected Audience API joinAdInterestGroup(). تطلب هذه المكالمة من المتصفّح إضافة المستخدم إلى مجموعة اهتمامات.
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 يومًا. إذا أرسلت تصميمات إعلانات باستخدام "الوقت الفعلي" Reporting API، ستحتاج إلى إعادة إرسال تصميم الإعلان بعد 15 يومًا. إذا كنت تعتمد على فحص المواد الإبداعية تلقائيًا، تعيد عملية الفحص فحصها تلقائيًا.

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

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

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

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

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

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

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

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

• رابط مبكر لبروتوكول عرض الأسعار في الوقت الفعلي (RTB) من Google
• الرابط السابق لـ OpenRTB

الإشارة إلى دعم المزادات على مستوى مجموعة الاهتمامات

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

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

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

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

الإشارة إلى حجم الشريحة الإعلانية في Protected Audience

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

• بروتوكول عرض الأسعار في الوقت الفعلي (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

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

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

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

الإشارة إلى قابلية عرض الإعلانات في Protected Audience

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

• بروتوكول عرض الأسعار في الوقت الفعلي (RTB) من Google: 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 هذا النمط هو تقييم التأثير المحتمل للإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية.

اختبار الإيقاف النهائي لملفات تعريف الارتباط التابعة لجهات خارجية والتي يسهِّلها Chrome

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

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

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

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

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

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

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

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

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

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

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

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

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

نشر إشارات العرض السياقي للمشتري

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

تحذير: تعتمد هذه الميزة على التوافق مع متصفِّح deprecatedRenderURLReplacements.

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

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

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

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

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

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

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

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

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

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

إسناد مرات الظهور إلى حسابات متعددة

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

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

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

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

إذا لم يكن معرّف الفوترة المرتبط بمرات ظهور عروض أسعار مجموعة الاهتمامات: لن يشارك مقدّم عرض السعر في مزاد Protected Audience API

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

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

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

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

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

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

دعم قانون الخدمات الرقمية

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

عندما يريد مقدّم عرض سعر يريد المشاركة في مزادات Protected Audience API إشارة في طلب عرض السعر بضرورة عرض شفافية قانون الخدمات الرقمية (DSA) الإعلانات التي يتم عرضها من خلال 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 للحصول على المزيد من المعلومات

وحدات ماكرو

ملاحظة: تم تصميم وحدات الماكرو لاستخدامها في اختبار Protected Audience API قد لا يكون متاحًا في المستقبل.

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

${GDPR}	يتم التوسيع إلى 0 في حال عدم سريان اللائحة العامة لحماية البيانات أو 1 إذا كانت اللائحة العامة لحماية البيانات سارية. يُرجى الاطّلاع على المستندات.
${GDPR_CONSENT_XXXX}	توسيع النطاق ليشمل الشفافية و سلسلة الموافقة (TC) المرتبطة بالطلب إذا لم تتوافق الشفافية سلسلة الموافقة (TC) فارغة أو غير صالحة، ولا يتم توسيع وحدة الماكرو هذه. استخدِم وحدة الماكرو هذه لتمرير سلسلة الموافقة والشفافية إلى مورّد مسجَّل في "قائمة المورّدين العالميين" في مكتب 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)	تُدرج وحدات الماكرو هذه عرض الشريحة الإعلانية وارتفاعها.
${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، يتضمّن كلّ حساب مستوى حساب. الحد الأقصى للميزانية اليومية لإنفاق الجمهور المحمي يحد الحد الأقصى للميزانية اليومية من المخاطر في بيئة المزاد داخل المتصفح. وعند بلوغ الحد الأقصى للميزانية اليومية، لن يتلقى طلبات عروض أسعار مؤهّلة من Protected Audience API

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

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

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

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

يُرجى الرجوع إلى وثائق البروتوكول عرض الأسعار في الوقت الفعلي للشراة المعتمَدين وإضافات OpenRTB لأسماء الحقول المحددة.

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

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

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

• %%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 المؤقتة.

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

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

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

في ما يلي كيفية بدء مزاد يستخدم Protected Audience API يدويًا، وذلك للتأكّد من إمكانية تسجيل مرة الظهور وتسجيل مرة الظهور:

1. استخدام الإصدار 101 من Chrome أو إصدار أحدث
2. تفعيل Privacy Sandbox API وFenced Frame باستخدام chrome://flags/#privacy-sandbox-ads-apis و chrome://flags/#enable-fenced-frames اطّلِع على مزيد من المعلومات في صفحة اختبار الخصوصية. وضع الحماية.
3. إرسال تصميم إعلان للموافقة عليه باستخدام عرض الأسعار في الوقت الفعلي API.
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 عددًا قليلاً من الزيارات المباشرة لتنفيذ Protected Audience المزادات. بعد ذلك، لا تحتاج Google والشريك إلى تشغيل مزاد يستخدم Protected Audience API نتيجة مزاد Protected Audience ليست المعروضة. وهذا يتيح لنا اختبار عملية الدمج على نطاق واسع.

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

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

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

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

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

الميزات التالية هي امتدادات للبروتوكول الأساسي.

التوازي

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

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

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

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

أهلية المشترين استنادًا إلى مجموعة الاهتمامات على الجهاز فقط

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

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

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

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

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

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

4. كل مصدر مشتري ضمن مجموعة اهتمامات مسجّلة للمقدّم عرض سعر تم تحديده في المزاد الموازي إدخال ParallelAuctionBuyer:

   • بروتوكول عرض الأسعار في الوقت الفعلي (RTB) من 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) التي لا يشير فيها مقدِّم عرض سعر إلى النية بالشراء بالمشاركة في استجابة عرض السعر الخاص بهم، قد يتلقّى مكالمة بخادم موثوق به من المشترين ولكن لن تشارك في المزاد الموازي