تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

توفير ميزة استهداف الجمهور المخصّص باستخدام 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) اتباع واجهات برمجة التطبيقات لمنصات تكنولوجيا الإعلان والمعلنين لدعم الإعلانات حالات استخدام مستندة إلى التفاعل بطرق تحدّ من مشاركة كلا المعرّفَين في جميع التطبيقات ومعلومات تفاعل المستخدم مع التطبيقات مع الجهات الخارجية:

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

رسم بياني انسيابي يعرض سير عمل إدارة الجمهور المخصّص واختيار الإعلانات في "مبادرة حماية الخصوصية" على Android.

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

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

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

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

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

جمهور مخصّص

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

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

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

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

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

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

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

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

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

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

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

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

بالنسبة إلى اختيارات الإعلانات التي تشمل جماهير مخصّصة، سيجلب النظام الأساسي جلب شراء رمز 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 اقتراح الإطارات المحمية).

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

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

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

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

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

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

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

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

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