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

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

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

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

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

تتوفّر ميزة 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
دمج خوارزمية Kanon	لا ينطبق	الربع الثاني من عام 2024
دمج التقارير المجمّعة	الربع الثالث من عام 2024	الربع الرابع من عام 2024

نظرة عامة

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

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

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

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

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

تجدر الإشارة إلى أنّ عملية الدمج تعمل على النحو التالي:

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

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

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

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

جمهور مخصّص

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

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

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

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

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

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

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

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

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

الردّ على إعلانات المرشّحين والبيانات الوصفية

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

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

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

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

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

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

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

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

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

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

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

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

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

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