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

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

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

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

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

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

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

للبدء، اقرأ دليل المطوِّرين لميزة Protected Audience. ونقدّر ملاحظاتك بينما نواصل تطوير ميزة Protected Audience.

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

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

الميزة	متوفّرة في "معاينة المطوِّر"	متوفّرة في الإصدار التجريبي
إعداد التقارير على مستوى الحدث	الربع الأول من عام 2023	الربع الثالث من عام 2023
التوسّط في العرض الإعلاني بدون انقطاع	الربع الأول من عام 2023	الربع الرابع من عام 2023
فلترة إعلانات تثبيت التطبيقات	الربع الثاني من عام 2023	الربع الثالث من عام 2023
فلترة تحديد عدد مرات الظهور	الربع الثاني من عام 2023	الربع الثالث من عام 2023
ضبط الإعلانات السياقية على سير عمل اختيار الإعلانات لتتم فلترتها	الربع الثاني من عام 2023	الربع الثالث من عام 2023
إعداد تقارير التفاعل	الربع الثاني من عام 2023	الربع الثالث من عام 2023
الانضمام إلى تفويض الجمهور المخصّص	الربع الثالث من عام 2023	الربع الرابع من عام 2023
الفوترة بدون تكلفة لكل ألف ظهور	الربع الثالث من عام 2023	الربع الرابع من عام 2023
دمج خدمات عروض الأسعار والمزادات	الربع الثالث من عام 2023	الربع الرابع من عام 2023
إعداد تقارير تصحيح الأخطاء	الربع الثالث من عام 2023	الربع الرابع من عام 2023
دمج تقارير تحديد المصدر	لا ينطبق	الربع الرابع من عام 2023
توسّط عرض الأسعار المفتوح	الربع الرابع من عام 2023	الربع الرابع من عام 2023
إدارة العملة	الربع الأول من عام 2024	الربع الثاني من عام 2024
تكامل K-anon	لا ينطبق	الربع الثاني من عام 2024
دمج التقارير المجمّعة	الربع الثالث من عام 2024	الربع الرابع من عام 2024

نظرة عامة

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

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

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

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

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

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

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

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

4. تسهِّل المنصّة إعداد تقارير مرّات الظهور ونتائج اختيار الإعلانات. تكمل ميزة إعداد التقارير هذه واجهة برمجة تطبيقات Attribution Reporting API. قد يتم تخصيص منصات تكنولوجيا الإعلان بناءً على احتياجات إعداد التقارير لديها.

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

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

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

جمهور مخصّص

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

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

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

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

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

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

عادةً ما يعتمد التعريف التقليدي المخصّص للجمهور وإعداداته على تقنيات من جهة الخادم وعمليات دمج تستند إلى تقنيات الإعلان بالشراكة مع العملاء والشركاء والوكالات والمعلِنين. تتيح Protected Audience API تفعيل إعدادات تحديد شرائح الجمهور المخصّصة وضبط إعداداتها مع حماية خصوصية المستخدم. للانضمام إلى جمهور مخصّص، يجب على تقنيات إعلانات المشترين التي لا تتوفّر لها حِزم SDK في التطبيقات التعاون مع تقنيات الإعلان التي لها حضور على الجهاز، مثل شركاء قياس أداء الأجهزة الجوّالة (MMP) ومنصّات جهة التوريد (SSP). تهدف 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 وهو اختياري.

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

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

/**
* API To schedule delayed update events for Custom Audience
*
* @param delayedCustomUpdates List of Delayed Update events that trigger a
* call to DSP endpoint provided inside the DelayedCustomUpdate object
*/

public void scheduleCustomAudienceUpdates(
    @NonNull DelayedCustomUpdate delayedCustomAudienceUpdate,
    @NonNull @CallBackExecutor Executor executor,
    @NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)

DelayedCustomAudienceUpdate

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

توفّر Protected Audience آلية للاشتراك في الأحداث المستقبلية ذات الصلة بمزاد ناجح من خلال تسجيل أجهزة المرشد. في وظيفة 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 (اختيارية) للدمج مع Attribution Reporting API. وهي إما كائن InputEvent (لحدث نقرة) أو فارغة (لحدث عرض). يُرجى الاطّلاع على دمج Attribution Reporting API لمزيد من التفاصيل حول هذه المَعلمة.

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

دمج Attribution Reporting API

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

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

• أنشئ خريطة ذات قيمة أساسية لمعرّفات الموارد المنتظمة (URI) لاستخدامها في كلٍّ من 1) إعداد تقارير التفاعل مع الإعلانات و2) تسجيل المصدر.
• يمكنك تضمين بيانات المزاد من مزاد Protected Audience في عملية الربط الرئيسية من جهة المصدر لإعداد التقارير الموجزة المجمَّعة (باستخدام Attribution Reporting API). ويمكنك الاطّلاع على اقتراح تصميم ARA للحصول على مزيد من المعلومات.

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

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

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

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

بما أنّ ميزة ARA على Android تتيح عرض الأحداث والنقر عليها، يتم استخدام InputEvents للتمييز بين النوعَين. كما هي الحال في تسجيل مصدر ARA، فإنّ واجهة برمجة التطبيقات reportEvent() API ستفسّر حدث 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 وما إلى ذلك، وسيتم توفير قيمه لوظائف عروض الأسعار لدى المشتري.

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

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

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

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

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

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

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

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