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

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

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

تتوفّر واجهة برمجة التطبيقات Protected Audience في إصدار تجريبي وهي متاحة للتطوير.

باستخدام ميزة "الجمهور المحمي"، يمكنك إجراء ما يلي:

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

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

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

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

نظرة عامة

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

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

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

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

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

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

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

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

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

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

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

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

جمهور مخصّص

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ScheduleCustomAudienceUpdateRequest

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ستستخدِم المنصة البيانات الوصفية "عنوان URL لمنطق عروض الأسعار" للجمهور المخصّص ل retrieving رمز 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 القابلة للضبط وينفّذه على الجهاز. نظرًا لمحدودية موارد الإعلانات على الأجهزة الجوّالة، يجب أن يلتزم رمز المزاد بالتوجيهات التالية:

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

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

لغة البرمجة

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

عرض الإعلانات بنجاح

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

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

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

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

1. إعداد تقارير جهة البيع
2. إعداد تقارير الجهة المشترية

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

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

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

registerAdBeacon(beacons)

الإدخال:

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

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

إعداد التقارير من جهة البيع

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

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 لعرض الإعلان
• مبلغ عرض السعر الفائز
• اسم التطبيق
• معرّفات طلبات البحث
• الإشارات للمشتري: لتسهيل مشاركة البيانات بين جانب العرض وجانب الطلب، تمرّر المنصة قيمة الإرجاع هذه كمَعلمة إدخال إلى код إعداد تقارير جانب الطلب.

إعداد تقارير الجهة المشترية

تستدعي المنصة دالة reportWin() JavaScript في الرمز المقدَّم من جانب العميل الذي تم تنزيله من البيانات الوصفية لعنوان 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 هو نتيجة reportResult من جهة البيع. يمنح ذلك منصّة عرض المبيعات فرصة لمشاركة البيانات مع منصّة جهة الشراء لأغراض إعداد التقارير.
• يحتوي 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، تحاول المنصة مطابقة event_key مع المفاتيح التي سجّلها المشترون والبائعون في وظائف reportWin و reportResult JavaScript، وذلك استنادًا إلى علامة reporting_destinations. في حال تطابق المحتوى، تُرسِل المنصة event_data إلى reporting_url المرتبط. content type الطلب هو نص عادي يكون النص الأساسي فيه هو event_data. يتم تقديم هذا الطلب كأفضل جهد ممكن، ولا يتم تسجيل أي خطأ في حال حدوث خطأ في الشبكة أو خطأ في الخادم أو عدم العثور على مفاتيح مطابقة.

دمج Attribution Reporting API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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