توفير ميزة استهداف الجمهور المخصّص باستخدام Protected Audience API

تقديم ملاحظات

أجدد التحديثات

• تمت إضافة معلومات حول جدولة تعديلات الجمهور المخصّص.
• تمت إضافة دمج تقارير تحديد المصدر مع Protected Audiences.
• تم نشر مخطّط زمني لميزات Protected Audience.
• تمت إعادة تسمية FLEDGE إلى Protected Audience API.
• تمت إضافة اقتراح لتفويض الجمهور المخصّص.
• تمت إزالة شرط "المجهوليّة من النوع k" لعنوان URL الخاص بالتحديث اليومي .

لا تزال ميزة Protected Audience في المرحلة التجريبية ويمكن اختبارها على الأجهزة العامة.

باستخدام Protected Audience، يمكنك إجراء ما يلي:

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

للبدء، يُرجى قراءة دليل المطوّر بشأن ميزة "الجمهور المحمي". إنّ ونحن نقدّر الملاحظات والآراء بينما نواصل تطوير ميزة Protected Audience.

المخطط الزمني

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

نظرة عامة

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

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

تتضمّن Protected Audience API على Android (المعروفة سابقًا باسم FLEDGE) واجهات برمجة التطبيقات التالية للمنصات التي تستخدم تكنولوجيا الإعلانات والمعلنين من أجل إتاحة حالات الاستخدام المشترَكة المستندة إلى التفاعل بطرق تحدّ من مشاركة كلا المعرّفَين على مستوى التطبيقات ومعلومات تفاعل المستخدم مع التطبيقات مع جهات خارجية:

1. Custom Audience API: تتمحور حول "جمهور مخصص" التجريد، الذي يمثل معلنًا يحدده وجمهور ذو نوايا مشتركة. يتم تخزين معلومات الجمهور على الجهاز فقط يمكن ربطها بإعلانات المرشحين ذات الصلة بشكل عشوائي للجمهور البيانات الوصفية مثل إشارات عروض الأسعار يمكن استخدام المعلومات لإبلاغ وعروض أسعار المعلنين وتصفية الإعلانات والعرض.
2. واجهة برمجة تطبيقات اختيار الإعلانات: توفر هذه الواجهة إطار عمل تنسيق منصات تكنولوجيا الإعلان وحالات سير العمل التي تستفيد من الإشارات على الجهاز لتحديد "الفوز" من خلال مراعاة الإعلانات المرشحة التي يتم تخزينها محليًا وإجراء معالجة إضافية للإعلانات المرشحة التي تستخدمها إحدى إلى الجهاز.

وعلى مستوى عالٍ، تعمل عملية الدمج على النحو التالي:

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

2. وعندما يشغِّل المستخدم لعبة الفريسبي على الجهاز نفسه، قد يظهر له إعلان. لتذكيرهم بإكمال عملية شراء المنتجات المتبقية في تطبيق SportingGoodsApp. سلة التسوق. ويمكن تحقيق ذلك من خلال لعبة FrisbeeGame (التي تحتوي على إعلانات مدمجة) SDK) استدعاء واجهة برمجة تطبيقات اختيار الإعلانات لتحديد إعلان فائز للمستخدم استنادًا إلى أي قائمة مستخدمين قد يكون جزءًا منها (في هذا مثال: "المنتجات في عربة التسوق" جمهور مخصّص تم إنشاؤه بواسطة SportingGoodsApp). يمكن إعداد سير عمل اختيار الإعلانات للنظر في الإعلانات التي تم استردادها من الإعلان والمنصات التكنولوجية والخوادم، بالإضافة إلى الإعلانات على الجهاز فقط وشرائح الجمهور المخصّصة، بالإضافة إلى إشارات أخرى على الجهاز فقط. يمكن أيضًا أن يكون سير العمل تم تخصيصها من خلال منصّة تكنولوجيا الإعلان وحزمة تطوير البرامج (SDK) لعرض الإعلانات باستخدام عروض الأسعار المخصّصة أسلوب التقييم لتحقيق الأهداف الإعلانية المناسبة. يمكّن هذا النهج بيانات اهتمامات المستخدِم أو تفاعلاته مع التطبيق لتوجيه اختيار الإعلانات، مع للحد من مشاركة هذه البيانات مع أطراف ثالثة.

3. جدير بالذكر أنّ حزمة تطوير البرامج (SDK) الخاصة بتطبيق عرض الإعلانات أو منصّة تكنولوجيا الإعلان تعرض الإعلان المحدّد.

4. تسهّل المنصة إعداد تقارير مرّات الظهور واختيار الإعلانات نتائجك. تعتبر إمكانية إعداد التقارير هذه إضافةً إلى تقارير تحديد المصدر API. يمكن لمنصات تكنولوجيا الإعلان على أساس احتياجات إعداد التقارير لديها.

الوصول إلى Protected Audience على واجهات برمجة التطبيقات في Android

تحتاج منصّات تكنولوجيا الإعلان إلى التسجيل للوصول إلى Protected Audience API. عرض يُرجى التسجيل للحصول على حساب "مبادرة حماية الخصوصية" للحصول على مزيد من المعلومات.

إدارة الجمهور المخصّص

جمهور مخصّص

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

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

البيانات الوصفية لشريحة الجمهور المخصّصة

يحتوي كل جمهور مخصّص على البيانات الوصفية التالية:

• المالك: اسم حزمة تطبيق المالك وقد يتم تعيينه ضمنيًا على اسم حزمة تطبيق المتصل.
• المشتري: شبكة إعلانات المشترين التي تدير إعلانات هذا الجمهور المخصّص. يمثل المشتري أيضًا الطرف الذي يمكنه الوصول إلى الجمهور المخصّص والجلب معلومات الإعلان ذات الصلة. تم تحديد المشتري وفقًا لتنسيق eTLD+1.
• الاسم: هو اسم عشوائي أو معرّف عشوائي جمهور مخصّص، مثل مستخدم لديه "تاركو سلة التسوّق". يمكن استخدام هذه السمة كإحدى معايير الاستهداف مثلاً في الحملات الإعلانية للمعلِن أو سلسلة طلب بحث في عنوان URL لجلبها رمز عروض الأسعار.
• وقت التفعيل ووقت انتهاء الصلاحية: تحدِّد هذين الحقلَين الإطار الزمني الذي سيكون فيه شريحة الجمهور المخصّصة هذه فعّالة. تستخدم المنصة هذه المعلومات لسحب العضوية من جمهور مخصص. لا يمكن أن تتجاوز مهلة انتهاء الصلاحية الحد الأقصى لمدة المدة من أجل الحد من مدة استخدام شريحة جمهور مخصّصة .
• عنوان URL للتحديث اليومي: هو عنوان URL الذي تستخدمه المنصة لجلب الإعلانات المرشحة والبيانات الوصفية الأخرى المحددة في "عروض أسعار المستخدم" الإشارات" و"إشارات عروض الأسعار الموثوق بها" الحقول على أساس متكرر. لمزيد من المعلومات، يُرجى الاطّلاع على القسم المتعلّق بكيفية جلب الإعلانات المرشّحة للإعلانات المخصَّصة الجماهير.
• إشارات عروض أسعار المستخدم: إشارات خاصة بمنصة تكنولوجيا الإعلان لأي عروض الأسعار لإعلانات تجديد النشاط التسويقي. ومن أمثلة الإشارات ما يلي: الموقع التقريبي للمستخدم، واللغة المفضلة، وما إلى ذلك.
• بيانات عروض الأسعار الموثوقة: تعتمد منصّات تكنولوجيا الإعلان على البيانات في الوقت الفعلي. لتقديم معلومات عن استرجاع الإعلانات وتقييمها على سبيل المثال، قد تنفد ميزانية الإعلان ويجب أن يتوقف عن العرض فورًا يمكن لتقنية الإعلان تحديد عنوان URL نقطة نهاية من أين يمكن استرجاع هذه البيانات في الوقت الفعلي ومجموعة المفاتيح الذي يجب إجراء البحث في الوقت الفعلي عليه. الخادم الذي يتولى معالجة هذه المشكلة سيكون طلبك موثوقًا به تديره لتكنولوجيا الإعلان.
• عنوان URL لمنطق عروض الأسعار: عنوان URL الذي تستخدمه المنصة لجلب عروض الأسعار الرمز من منصة جانب الطلب. تُجري المنصة هذه الخطوة عند بدء مزاد إعلاني.
• الإعلانات: قائمة بالإعلانات المُرشّحة للجمهور المخصّص. وتشمل هذه المعلومات ما يلي: البيانات الوصفية للإعلان وعنوان URL الخاص بمنصة تكنولوجيا الإعلان لعرض الإعلان عند بدء مزاد للجمهور المخصّص، سيتم مراعاة قائمة البيانات الوصفية للإعلانات هذه. ستتم إعادة تحميل قائمة الإعلانات هذه باستخدام نقطة نهاية عنوان URL للتحديث اليومي عندما يكون ذلك ممكنًا. نظرًا لقيود الموارد على الأجهزة المحمولة، هناك حدّ لعدد الإعلانات التي يمكن تخزينها في شريحة جمهور مخصّصة

تفويض الجمهور المخصّص

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

الانضمام إلى شريحة جمهور مخصّصة

يمكن الانضمام إلى جمهور مخصّص بطريقتين:

joinCustomAudience()

يمكن لتطبيق أو حزمة تطوير برامج (SDK) طلب الانضمام إلى جمهور مخصّص من خلال الاتصال joinCustomAudience() بعد إنشاء مثيل للكائن CustomAudience باستخدام المعاملات المتوقعة. في ما يلي مثال توضيحي لمقتطف الرمز:

CustomAudience audience = new CustomAudience(
    Buyer = "example-dsp.com",
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    DailyUpdateURL = Uri.parse("https://..."),
    UserBiddingSignals = new JSONObject("{...}"),
    TrustedBiddingURL = Uri.parse("https://..."),
    TrustedBiddingKeys = {'key1","key2", ...,"key n"},
    BiddingLogicURL =  Uri.parse("https://..."),
    Ads = [new AdData(renderUrl = Uri.parse("https://..."),
           metadata = new JSONObject("{...}"), ...];

// Invoke ad services API to join a custom audience.
joinCustomAudience(audience);

fetchAndJoinCustomAudience()

يمكن لتطبيق أو حزمة تطوير برامج (SDK) طلب الانضمام إلى جمهور مخصّص نيابةً عن تقنية إعلان لا تتضمّن البيانات المتاحة على الجهاز فقط من خلال الاتصال بالرقم fetchAndJoinCustomAudience(). بالمعلمات المتوقعة، كما في المثال التالي:

FetchAndJoinCustomAudienceRequest fetchRequest = new FetchAndJoinCustomAudienceRequest(
    // Example: Optional verification token passed inside the fetch URL
    FetchURI = Uri.parse("https://example-dsp.com/...?mytoken=arbitrary1234"),
    // All the following parameters are optional
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    UserBiddingSignals = new JSONObject("{...}")
);

fetchAndJoinCustomAudience(fetchRequest);

تردّ نقطة نهاية عنوان URL التي يملكها المشتري باستخدام ملف JSON يتضمّن CustomAudience. في نص الاستجابة. يتم تجاهل حقلَي "المشتري" و"المالك" في شريحة الجمهور المخصّصة (وتتم تعبئتهما تلقائيًا من خلال واجهة برمجة التطبيقات). تفرض واجهة برمجة التطبيقات أيضًا تنفيذ عمليات في حال تعديل عنوان URL، سيتطابق أيضًا مع نطاق eTLD+1 للمشتري.

{
 "name": "running-shoes",
 "activation_time": 1680603133000,
 "expiration_time": 1680803133000,
 "user_bidding_signals" : {"signal1": "value"},
 "trusted_bidding_data": {
    "trusted_bidding_uri": "https://example-dsp.com/.."
    "trusted_bidding_keys": ["k1", "k2"],
 },
 "bidding_logic_uri": "https://example-dsp.com/...",
 "daily_update_uri": "https://example-dsp.com/...",
 "ads": [
   {
     "render_uri": "https://example-dsp.com/...",
     "metadata": {},
     "ad_filters": {
       "frequency_cap": {
         "win": [
           {
             "ad_counter_key": 1,
             "max_count": 2,
             "interval_in_seconds": 60
           },
         ],
         "view": [
           {
             "ad_counter_key": 2,
             "max_count": 10,
             "interval_in_seconds": 3600
           },
         ]
       },
       "app_install": {
         "package_names": [
           "package.name.one",
           "package.name.two", ...
         ]
       }
     }
   },
   ...
 ]
}

تحدِّد واجهة برمجة التطبيقات fetchAndJoinCustomAudience() هوية المشتري من eTLD+1 في fetchUri. تُستخدم هوية المشتري CustomAudience لتنفيذ عمليات الفحص نفسها التي تتم من خلال "joinCustomAudience()" للتسجيل وتفويض التطبيق. ولا يمكن تغييرها من خلال استجابة الجلب. مالك CustomAudience هو اسم حزمة التطبيق المُرسِل. لا يوجد تحقق آخر من fetchUri بخلاف فحص eTLD+1، وعلى وجه الخصوص، لا تتوفّر قيمة k-anon. شيك. تصدر واجهة برمجة التطبيقات fetchAndJoinCustomAudience() طلب HTTP GET إلى fetchUri ويتوقع وجود كائن JSON يمثل الجمهور المخصص. يتم تطبيق القيود المفروضة والاختيارية والقيم التلقائية نفسها لحقول عنصر الجمهور المخصّص على الاستجابة. التعرّف على المعلومات الحالية المتطلبات والقيود الواردة في دليل المطوِّر.

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

يتيح الكائن CustomAudienceFetchRequest لمتصل واجهة برمجة التطبيقات تحديد بعض للجمهور المخصص باستخدام الخصائص الاختيارية الموضحة في المثال أعلاه. إذا تم ضبطها في الطلب، لا يمكن استبدال هذه القيم بما يلي: ردّ المشتري الذي تلقّته المنصة تتجاهل Protected Audience API الحقول في الرد. وإذا لم يتم ضبطها في الطلب، يجب أن تكون معينة في الرد، حيث تكون هذه الحقول مطلوبة لإنشاء قاعدة جمهورك. تمثيل JSON لمحتوى CustomAudience بتنسيق يتم تضمين المحدد جزئيًا من خلال متصل واجهة برمجة التطبيقات في طلب GET إلى fetchUri في عنوان خاص X-CUSTOM-AUDIENCE-DATA. حجم النموذج المتسلسل تقتصر البيانات المحدّدة للجمهور المخصّص على 8 كيلوبايت. إذا كان الحجم تجاوز طلب البيانات من واجهة برمجة التطبيقات fetchAndJoinCustomAudience.

في حال عدم توفّر فحص k-anon، يمكنك استخدام fetchUri للتحقّق من المشترين. ولتفعيل مشاركة المعلومات بين المشتري وحزمة تطوير البرامج (SDK). لتسهيل عملية إثبات ملكية قاعدة الجمهور المخصّصة، يمكن للمشتري تقديم رمز إثبات ملكية. يجب أن تتضمّن حزمة SDK على الجهاز هذا الرمز المميّز في fetchUri كي نقطة النهاية التي يستضيفها المشتري يمكنها جلب محتويات الجمهور المخصص استخدام الرمز المميّز لإثبات ملكية النطاق fetchAndJoinCustomAudience() العملية تقابل المشتري والتي نشأت من جهاز موثوق به على الجهاز شريك. لمشاركة المعلومات، يمكن للمشتري الاتفاق مع المتصل على الجهاز. من المعلومات التي سيتم استخدامها لإنشاء الجمهور المخصص تمّت إضافتها كمعلَمات طلب بحث في fetchUri. وهذا يتيح للمشتري تدقيق واكتشاف ما إذا تم استخدام رمز مميز للتحقُّق من قِبل تكنولوجيا إعلانات ضارة إنشاء عدّة شرائح جمهور مخصّصة مختلفة

ملاحظة حول تعريف الرمز المميّز لإثبات الملكية ومساحة التخزين

• لا يستخدم "الجمهور المحمي" الرمز المميّز لإثبات ملكية النطاق لأي أغراض. واجهة برمجة التطبيقات وهي اختيارية.

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

مغادرة جمهور مخصّص

قد يختار مالك شريحة جمهور مخصّصة المغادرة من خلال الاتصال leaveCustomAudience()، كما هو موضّح في مقتطف الرمز التوضيحي أدناه:

// Invoke ad services API to leave a custom audience.
leaveCustomAudience(buyer, name);

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

التحكّم في المستخدم

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

ولا يزال تصميم هذه الإمكانية قيد التطوير، وستظهر تضمينها في تحديث لاحق.

التحديثات المجدوَلة

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

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

/**
* API To schedule delayed update events for Custom Audience
*
* @param request Criteria that determine when and where to trigger a call to a
* DSP endpoint to update one or more Custom Audiences
*/

public void scheduleCustomAudienceUpdate(
    @NonNull ScheduleCustomAudienceUpdateRequest request,
    @NonNull @CallBackExecutor Executor executor,
    @NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)

ScheduleCustomAudienceUpdateRequest

public final class ScheduleCustomAudienceUpdateRequest {
  // Required Field
  @NonNull public Uri getUpdateUri() {
    return mUpdateUri;
  }

  // Required Field
  @NonNull public Duration getMinDelay() {
    return mMinDelay;
  }

  //  Required Field
  @NonNull public List<PartialCustomAudience> getPartialCustomAudienceList() {
    return mPartialCustomAudiences;
  }

  //  Optional Field (default false)
  public boolean shouldReplacePendingUpdates () {
    return mShouldReplacePendingUpdates;
  }
}

يحتوي ScheduleCustomAudienceUpdateRequest على المعلومات اللازمة تسجيل وظيفة متأخرة لتشغيلها على المنصة. بعد التأخير المحدد، لمهمة خلفية سيتم إجراؤها بشكل دوري وإرسال الطلبات. تشير رسالة الأشكال البيانية يمكن أن يحتوي ScheduleCustomAudienceUpdateRequest على المعلومات التالية:

• UpdateUri: نقطة نهاية معرف الموارد المنتظم (URI) التي سيتم إرسالها لطلب GET لجلب التحديث. يمكن استنتاج هوية المشتري بشكلٍ أساسي من النطاق العلوي للمستوى 2 (eTLD+1) ولا يلزم تقديمها صراحةً ولا يمكن تغييرها من خلال استجابة التعديل. زر GET يتوقع الطلب كائن JSON يحتوي على قائمة بكائنات customAudience في إرجاع.
• ‫DelayTime: الوقت الذي يشير إلى التأخير من وقت إجراء طلب بيانات scheduleCustomAudienceUpdate() من واجهة برمجة التطبيقات إلى جدولة التحديث.

• PartialCustomAudience: تسمح واجهة برمجة التطبيقات أيضًا لحزمة تطوير البرامج (SDK) على الجهاز بإرسال قائمة من الجماهير المخصّصة التي تم إنشاؤها جزئيًا. يسمح ذلك لحِزم تطوير البرامج (SDK) داخل التطبيق بعرض للدور المزدوج، من التحكّم الكامل إلى الجزئي في إدارة الجمهور المخصّص بناءً على شراكتهم مع DSP.

  • ويحافظ ذلك أيضًا على توافق واجهة برمجة التطبيقات هذه مع fetchAndJoinCustomAudience(). واجهة برمجة تطبيقات تتيح مشاركة المعلومات المماثلة.

• ‫ShouldReplacePendingUpdates: قيمة منطقية تحدِّد ما إذا كان يجب إلغاء أي تعديلات مُجدوَلة في انتظار المراجعة واستبدالها بالتعديل الموضَّح في ScheduleCustomAudienceUpdateRequest الحالي. إذا تم ضبط هذا الخيار على false و كانت هناك تعديلات تطلبت سابقًا الانتظار للمراجعة للمشتري نفسه في التطبيق نفسه، ستتعذّر الدعوة إلى scheduleCustomAudienceUpdate باستخدام ScheduleCustomAudienceUpdateRequest هذا. وتكون القيمة التلقائية هي false.

أذونات التطبيقات والتحكّم فيها

يهدف الاقتراح إلى منح التطبيقات إمكانية التحكّم في شرائح الجمهور المخصَّصة لها:

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

لا يزال تصميم هذه الميزة قيد التطوير، وسيتم تضمين التفاصيل في تعديل لاحق.

التحكّم في منصّة تكنولوجيا الإعلان

يوضّح هذا الاقتراح طرق تحكّم تقنيات الإعلان في شرائح الجمهور المخصّصة:

• يتم التسجيل في تقنيات الإعلان في "مبادرة حماية الخصوصية" وتقديم نطاق eTLD+1 تتطابق مع جميع عناوين URL لشريحة جمهور مخصّصة.
• يمكن أن تتعاون تكنولوجيات الإعلان مع التطبيقات أو حِزم تطوير البرامج (SDK) لتوفير الرموز المميّزة لإثبات الهوية التي يتم استخدامها لإثبات إنشاء شريحة جمهور مخصّصة. عند تفويض هذه العملية إلى أحد الشركاء، يمكن ضبط عملية إنشاء شرائح الجمهور المخصّصة لتطلب تأكيدًا من تكنولوجيا الإعلان.
• يمكن لتقنية إعلان اختيار إيقاف مكالمات joinCustomAudience نيابةً عن هذه التكنولوجيا. وتسمح لـ fetchAndJoinCustomAudience API فقط بتفعيل جميع المكالمات المخصصة الجماهير. يمكن تعديل عناصر التحكّم أثناء التسجيل في "مبادرة حماية الخصوصية". لاحظ أو لا يسمح بجميع تقنيات الإعلان أو لا يسمح بأي منهما بسبب القيود التي تفرضها المنصة، لا يمكن منح أذونات التفويض على أساس تكنولوجيا الإعلان.

استجابة إعلانات المرشحين والبيانات الوصفية

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

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

سير عمل اختيار الإعلانات

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

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

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

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

ينظّم سير عمل اختيار الإعلانات هذا تنفيذ رمز JavaScript يوفّره تكنولوجيا الإعلان استنادًا إلى التسلسل التالي:

1. تنفيذ منطق عروض الأسعار من جهة الشراء
2. فلترة الإعلانات من جهة الشراء ومعالجتها
3. تنفيذ منطق القرار من جهة البيع

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

إنّ تصميم اختيارات الإعلانات التي لا تتضمّن جماهير مخصّصة قيد التشغيل. التصميم.

بدء سير عمل اختيار الإعلانات

عندما يحتاج تطبيق إلى عرض إعلان، يمكن لحزمة تطوير البرامج (SDK) لمنصّة تكنولوجيا الإعلان بدء عرض الإعلان سير عمل الاختيار من خلال استدعاء طريقة selectAds() بعد إنشاء مثيل الكائن AdSelectionConfig بالمعلمات المتوقعة:

• البائع: معرّف منصّة عرض الإعلانات لجهة البيع، بعد eTLD+1 التنسيق
• عنوان URL لمنطق القرار: عند بدء مزاد إعلانات، ستستخدم المنصة عنوان URL هذا لجلب رمز JavaScript من النظام الأساسي لجهة البيع الإعلان الفائز.
• المشترون أمام شرائح الجمهور المخصّصة: قائمة بمنصّات جهة الشراء مع منتجات الطلب المستند إلى الجمهور في هذا المزاد، وفقًا لتنسيق eTLD+1.
• إشارات اختيار الإعلانات: معلومات عن المزاد (حجم الإعلان وشكله وما إلى ذلك)
• إشارات البائع: إشارات محدَّدة لمنصّة العرض من جهة أخرى.
• عنوان URL لإشارات النتائج الموثوق بها: نقطة نهاية عنوان URL لإشارة موثوق بها من جهة البيع من المعلومات في الوقت الفعلي الخاصة بتصميمات الإعلانات التي يمكن استرجاعها
• الإشارات حسب المشترين: قد تستخدم جوانب الطلب المشاركة هذه المَعلمة لتنفيذ تقديم مدخلات للمزاد. على سبيل المثال، قد تتضمن هذه المعلمة معلومات سياقية شاملة مفيدة لتحديد عروض الأسعار.

يعرض المقتطف التوضيحي التالي من الرمز البرمجي حزمة تطوير برامج (SDK) لمنصّة تقنية عرض الإعلانات تبدأ عملية اختيار الإعلان من خلال تحديد AdSelectionConfig أولاً ثم استدعاء selectAds للحصول على الإعلان الفائز:

AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig {
    Seller = "example-ssp1.com",
    DecisionLogicURL = Uri.parse("https://..."),
    CustomAudienceBuyerList = Arrays.asList("example-dsp1.com","bexample-dsp2.com"),
    AdSelectionSignals = "{"min_price": 10,"auction_attempts": 3}"
    SellerSignals = "{"seller_type": "news", "content_category": "sports","mature_ads_accepted" :"false"}"
    PerBuyerSignals = " {"buyer1Name": {"key1" : "value1"},
                         "buyer2Name": {"key1" : "value1", "key2" : "value2" }"
};

// Invoke ad services API to initiate ad selection workflow.
Ad winningAd = selectAds(myAdSelectionConfig);

منطق عروض الأسعار من جهة الشراء

عادةً ما توفّر منصّات جهة الشراء منطق عروض الأسعار. إن الغرض من هو تحديد عروض أسعار الإعلانات المرشحة. قد يفرض رسومًا إضافية ومنطق الأعمال لتحديد النتيجة.

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

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ...};
}

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

تتوقع الدالة المَعلمات التالية:

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

تكلفة الإعلان

بالإضافة إلى عرض السعر، يتوفّر خيار إرجاع التكلفة لمنصّات جهة الشراء لكل نقرة كجزء من generateBid(). على سبيل المثال:

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ..., 'adCost': ...,};
}

إذا كان هذا الإعلان هو الفائز، يتم تقريب adCost بشكل تدريجي إلى 8 بت الخصوصية. يتم بعد ذلك تمرير القيمة المستديرة لـ adCost إلى معلَمة contextual_signals في reportWin أثناء إعداد تقارير مرات الظهور.

منطق التصفية من جهة الشراء

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

يمكن تنفيذ منطق التصفية من جانب الشراء كجزء من منطق عروض الأسعار من خلال عرض قيمة عرض سعر بقيمة 0 لإعلان معيّن.

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

منطق النتائج من جهة البيع

عادةً ما توفّر المنصة التابعة لجهة البيع منطق تحقيق النتائج. الغرض تحديد إعلان فائز استنادًا إلى نتائج منطق عروض الأسعار. قد وتطبيق منطق عمل إضافي لتحديد النتيجة. إذا كان هناك عدة مقدّمي منطق القرار، لا يضمن النظام تسلسل التنفيذ بين المقدّمين. ستستخدم المنصة "عنوان URL لمنطق القرار". مصدر الإدخال معلَمة واجهة برمجة التطبيقات selectAds() لجلب رمز JavaScript الذي من المفترض قم بتضمين توقيع الدالة أدناه:

scoreAd(ad, bid, auction_config, trusted_scoring_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return score_for_this_ad;
}

تتوقع الدالة المَعلمات التالية:

• الإعلان: الإعلان الذي يتم تقييمه ناتج الدالة generateBid().
• عرض السعر: ناتج مبلغ عرض السعر من دالة generateBid().
• تهيئة المزاد: أدخِل مَعلمة في طريقة selectAds().
• إشارات النتائج الموثوق بها: تعتمد منصّات تكنولوجيا الإعلان على البيانات في الوقت الفعلي من أجل لتصفية الإعلانات وتحقيق النتائج المرجوة. على سبيل المثال، يجوز أن يحظر ناشر التطبيق حملة إعلانية من عرض إعلانات في التطبيق تم استرجاع هذه البيانات من المواقع الإلكترونية الموثوق بها مَعلمة عنوان URL لإشارات النتائج في إعدادات المزاد. يجب أن يكون الخادم الذي يعرض هذا الطلب خادمًا موثوقًا به تديره تكنولوجيا الإعلان.
• الإشارة السياقية: قد تشمل طابعًا زمنيًا تقريبيًا أو تقريبيًا. معلومات الموقع الجغرافي:
• إشارة المستخدم: قد تتضمّن معلومات مثل متجر التطبيقات الذي بدأ تثبيت التطبيق.
• إشارة الجمهور المخصّصة: إذا كان الإعلان الذي يتم تسجيل نتيجةه يأتي من جهاز على جهاز الجمهور المخصص، سيحتوي هذا على معلومات مثل القارئ واسم الجمهور المخصص.

وقت تشغيل رمز اختيار الإعلانات

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

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

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

لغة البرمجة

يجب كتابة رمز المزاد الذي توفّره منصّة تكنولوجيا الإعلان بلغة JavaScript. وسيسمح ذلك لمنصات تكنولوجيا الإعلان مثلاً بمشاركة رمز عروض الأسعار في والمنصات التي تتيح "مبادرة حماية الخصوصية"

عرض الإعلان الفائز

ويُعتبر الإعلان الذي يحقق أعلى نتيجة هو الفائز في المزاد. في هذا الاقتراح الأوّلي، يتم تمرير الإعلان الفائز إلى حزمة SDK لعرضه.

وتتمثل الخطة في تطوير الحل لضمان أن المعلومات حول هوية لا يمكن تحديد عضوية الجمهور المخصّص أو سجلّ التفاعل مع التطبيق عن طريق التطبيق أو حزمة SDK من خلال معلومات عن الإعلان الفائز (على غرار Chrome اقتراح الإطارات المحمية).

إعداد تقارير مرّات الظهور والأحداث

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

1. تقارير جهة البيع:
2. التقارير من جهة الشراء

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

هناك خطوتان مطلوبتان لإتاحة إعداد تقارير الأحداث وهما: جهة البيع وجهة الشراء. تحتاج JavaScript إلى تسجيل الحدث الذي يجب أن تتلقّى تقارير الأحداث الخاصة به يكون جهة البيع مسؤولاً عن الإبلاغ عن المعلومات على مستوى الحدث.

توفّر ميزة "الجمهور المحمي" آلية للاشتراك في الأحداث المستقبلية المرتبطة بمزاد فائز من خلال تسجيل إشارات الاستهداف. في reportResult() لدى أحد البائعين جافا سكريبت، فيمكن للأنظمة الأساسية جهة البيع تسجيل أجهزة المرشد باستخدام للدالة registerAdBeacon() في النظام الأساسي. وبالمثل، يمكن للأنظمة الأساسية على جانب الشراء استدعاء طريقة registerAdBeacon() من دالة JavaScript reportWin().

registerAdBeacon(beacons)

الإدخال:

• event_key: سلسلة تشير إلى نوع التفاعل المطلوب التسجيل فيه. ويتم استخدام هذا المفتاح للبحث عن نقطة النهاية التي يرسلها النظام الأساسي الإعلام عن نتائج المزاد.
• reporting_url: عنوان URL الذي تملكه منصة تكنولوجيا الإعلان لمعالجة الحدث

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

تقارير جهة البيع

تستدعي المنصة دالة JavaScript‏ reportResult() في الرمز الذي يوفّره جانب العرض ويتم تنزيله من مَعلمة عنوان URL لمنطق القرار للتحقّق من واجهة برمجة التطبيقات selectAds():

reportResult(render_url, bid, auction_config, contextual_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_url": reporting_url,
                  "signals_for_buyer": signals_for_buyer}};
}

الإخراج: كائن JSON يحتوي على

• الحالة: 0 للنجاح، وأي قيمة أخرى للفشل.
• عنوان URL لإعداد التقارير: يستدعي النظام عنوان URL هذا الذي تم عرضه من الدالة.
• إشارات إلى المشتري: كائن JSON يجب تمريره إلى reportWin لدى المشتري الأخرى.

قد يشفّر جانب العرض الإشارات ذات الصلة في عنوان URL لإعداد التقارير بهدف مساعدتها الحصول على مزيد من الإحصاءات حول المزاد والإعلان الفائز على سبيل المثال، قد يتضمن الإشارات التالية:

• عنوان URL لعرض الإعلان
• مبلغ عرض السعر الفائز
• اسم التطبيق
• معرّفات طلبات البحث
• إشارات المشترين: لإتاحة مشاركة البيانات بين جانب العرض والطلب يمرر النظام الأساسي هذه القيمة المعروضة كمعلمة إدخال إلى رمز إعداد تقارير جانب الطلب.

التقارير من جهة الشراء

يستدعي النظام الأساسي وظيفة JavaScript reportWin() عند الطلب الرمز المقدّم من الجانب الذي تم تنزيله من البيانات الوصفية لعنوان URL لمنطق عروض الأسعار الجمهور المخصّص المرتبط بالمزاد

reportWin(render_url, bid, auction_signals, per_buyer_signals,
        signals_for_buyer, contextual_signals, custom_audience_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_uri": reporting_uri}};
}

الإدخال:

• تم استرجاع auction_signals وper_buyer_signals من. AuctionConfig أي معلومات تحتاج وسيط جهة الشراء إلى نقلها قد يكون عنوان URL لإعداد التقارير واردة من هذا المرجع.
• signals_for_buyer هي نتيجة تقرير جهة البيع. يوفّر ذلك هي منصة جهة البيع التي توفّر فرصة لمشاركة البيانات مع منصة لأغراض إعداد التقارير.
• يحتوي contextual_signals على معلومات، مثل اسم التطبيق يحتوي custom_audience_signals على معلومات الجمهور المخصص. غير ذلك قد تتم إضافة معلومات إليها في المستقبل.

إخراج:

• الحالة: 0 للنجاح، وأي قيمة أخرى للتعذُّر
• عنوان URL لإعداد التقارير: يستدعي النظام عنوان URL هذا الذي تم عرضه من الدالة.

الإبلاغ عن الأحداث

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

ReportEventRequest request = new ReportEventRequest(
  AdSelectionId = ad_selection_id,
  event_key = "view"
  event_data = "{ "viewTimeInSeconds" :1 }",
  reporting_destinations =
    FLAG_REPORTING_DESTINATION_SELLER |
      FLAG_REPORTING_DESTINATION_BUYER,
  input_event = clickInputEvent // or null for view
  )

reportEvent(request)

الإدخال:

• يجب أن يكون ad_selection_id ضمن AdSelectionId من مزاد تم إجراؤه مؤخرًا. استردادها من AdSelectionOutcome.
• event_key هي سلسلة محدَّدة لجهة البيع تصف التفاعل. فعالية.
• event_data هي سلسلة تمثل البيانات المرتبطة event_key
• reporting_destinations هو قناع بت تم ضبطه باستخدام علامات يوفّرها الطور الأساسي. يمكن أن تكون القيمة واحدة من FLAG_REPORTING_DESTINATION_SELLER أو FLAG_REPORTING_DESTINATION_BUYER أو كليهما.
• يتم استخدام input_event (اختياري) للدمج مع "تقارير تحديد المصدر". واجهة برمجة التطبيقات. وهي إما كائن InputEvent (لحدث نقرة) أو فارغة. (لحدث عرض). الاطّلاع على دمج Attribution Reporting API لمزيد من المعلومات تفاصيل حول هذه المعلمة.

بعد أن تستدعي حزمة SDK لجهة البيع reportEvent، استنادًا إلى reporting_destinations: تحاول المنصة مطابقة event_key مع المفاتيح التي سجلها المشترون والبائعون في reportWin reportResult دوال JavaScript إذا كان هناك تطابق، تنشر المنصة event_data إلى reporting_url المرتبط نوع محتوى الطلب هي نص عادي يكون النص الأساسي فيه هو event_data. هذا الطلب بأفضل شكل ويحدث إخفاق بدون تنبيه في حال حدوث خطأ في الشبكة أو حدوث خطأ في الخادم أو في حالة عدم العثور على مفاتيح مطابقة.

دمج Attribution Reporting API

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

من خلال هذا الدمج مع واجهات برمجة التطبيقات، يمكن لتكنولوجيات الإعلان إجراء ما يلي:

• أنشئ خريطة مفاتيح وقيم لمعرّفات الموارد المنتظمة التي سيتم استخدامها في كلّ من: 1) إعداد تقارير التفاعل مع الإعلانات و2) تسجيل المصدر.
• يجب تضمين بيانات المزاد من مزاد "شرائح الجمهور المحمية" في عملية ربط المفاتيح من جهة المصدر لإعداد تقارير الملخّصات المجمّعة (باستخدام واجهة برمجة التطبيقات لإعداد تقارير تحديد المصدر). اطّلِع على اقتراح تصميم ARA للحصول على مزيد من المعلومات.

عندما يشاهد مستخدم إعلانًا أو ينقر عليه:

• سيبدأ عنوان URL المستخدَم في الإبلاغ عن تفاعلات هذه الأحداث باستخدام Protected Audience توفير البيانات اللازمة للمشتري لاستخدامها في تسجيل مشاهدة أو النقر كمصدر مؤهَّل باستخدام Attribution Reporting API.
• قد تختار تقنية الإعلان تمرير CustomAudience (أو محتوى آخر ذي صلة معلومات عن الإعلان، مثل موضع الإعلان أو مدة المشاهدة) باستخدام عنوان URL هذا بحيث يمكن نشر هذه البيانات الوصفية إلى التقارير الموجزة عندما يتم مراجعة الأداء الإجمالي للحملات

تفعيل تسجيل المصدر

سيقبل reportEvent() مَعلمة اختيارية جديدة InputEvent. الفوز يمكن للمشترين الذين يسجّلون إشارات الإعلان اختيار تقارير reportEvent التي تحصل عليها التسجيل في Attribution Reporting API كمصدر مسجَّل الطلب إضافة عنوان "مؤهَّل لإعداد تقارير تحديد المصدر" إلى جميع تقارير الأحداث الطلبات التي تم إرسالها من reportEvent(). أي ردود تتضمّن عناوين ARA مناسبة بنفس الطريقة التي يتم بها تحليل أي عمليات تسجيل لمصدر ARA عادي الرد. الاطّلاع على شرح حول Attribution Reporting API تسجيل عنوان URL للمصدر

بما أنّ ARA على Android تتيح أحداث العرض والنقر، يتم استخدام InputEvents للتمييز بين النوعَين. كما هو الحال في مصدر ARA التسجيل، ستفسّر واجهة برمجة التطبيقات reportEvent() واجهة برمجة التطبيقات التي تم التحقق منها InputEvent كحدث ناتج عن النقر. إذا لم يكن InputEvent متوفّرًا أو كان فارغًا أو غير صالح، سيتم اعتبار تسجيل المصدر مرّة مشاهدة.

يُرجى ملاحظة أنّ eventData بعد المزاد قد يحتوي على معلومات حساسة، ولذلك تزيل eventData في طلبات تسجيل المصدر المُعاد توجيهه.

مثال على إعداد تقارير التفاعل والإحالات الناجحة

في هذا المثال، سنلقي نظرة على منظور المشتري المهتمين في ربط البيانات بالمزاد والإعلان المعروض وتطبيق الإحالات الناجحة

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

سير العمل: قبل بدء المزاد، يرسل المشتري معرّفًا فريدًا إلى البائع كجزء من استجابة عروض أسعار عرض الأسعار في الوقت الفعلي (RTB) الآلية. يمكن أن يكون المعرّف كمتغير مثل auctionId. يتم تمرير رقم التعريف كـ perBuyerSignals في auctionConfig ويصبح متاحًا في منطق عروض الأسعار للمشتري.

1. أثناء تنفيذ reportWin، يمكن للمشتري تسجيل إشارة إعلان سيتم عرضها أثناء فترة عرض الإعلان ولأحداث تفاعل محدَّدة (registerAdBeacon()). لربط إشارات المزاد لحدث إعلان، اضبط إعدادات auctionId كمعلمة طلب بحث لعنوان URL للإشارة.
2. وخلال وقت عرض الإعلان، يمكن تسجيل أجهزة مرشد تم تسجيلها خلال وقت المزاد أو تحسينها باستخدام البيانات على مستوى الحدث. على البائع بدء الإجراء reportEvent() وإدخال البيانات على مستوى الحدث. سترسل المنصة إشعارًا عنوان URL لإشارة الإعلان المسجّلة للمشتري والمرتبطة reportEvent() الذي تم تشغيله.
3. سيُسجِّل المشتري الإعلان باستخدام Attribution Reporting API عن طريق الاستجابة لطلبات إشارة الإعلان باستخدام عنوان Attribution-Reporting-Register-Source لربط إشارات المزاد لحدث إحالة ناجحة معيّن، اضبط auctionId في عنوان URL الخاص بتسجيل المصدر.

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

ينطبق سير العمل المشابه على البائع إذا كان بحاجة إلى الوصول إلى بيانات الإحالة، يمكن للبائع أيضًا استخدام معرّف فريد لإرساله باستخدام "registerAdBeacon()". تشير رسالة الأشكال البيانية تحتوي مكالمة reportEvent() على خاصية وجهة يمكن استخدامها للإرسال. التقرير إلى كل من المشتري والبائع.

خادم موثوق به مُدار من خلال منصّة تكنولوجيا الإعلان

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

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

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

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

https://www.kv-server.example/getvalues?keys=key1,key2

يجب أن تكون استجابة الخادم كائن JSON الذي تكون مفاتيحه key1 وkey2 وغيرها، والتي سيتم توفير قيمها لوظائف عروض أسعار المشتري.

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

في ما يلي نموذج عنوان URL لجلب معلومات عن تصميمات الإعلانات التي تم أخذها في الاعتبار في المزاد، استنادًا إلى عناوين URL لعرض تصاميم الإعلانات:

https://www.kv-server.example/getvalues?renderUrls=render_url1,render_url2

يجب أن تكون الاستجابة من الخادم كائن JSON تؤدي مفاتيحه إلى عرض عناوين URL. المرسلة في الطلب.

وتعمل هذه الخوادم بطريقة موثوق بها لتوفير العديد من معايير الأمان مزايا الخصوصية:

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

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

يمكن للمشترين والبائعين استخدام خادم شائع موثوق به من نوع المفتاح/القيمة والمنصات المتوافقة مع "مبادرة حماية الخصوصية" على Android وعلى الويب.