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

{
 "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() API التي تتيح مشاركة معلومات مشابهة.

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

دمج Attribution Reporting API

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

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

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

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

• سيوفّر عنوان URL المستخدَم للإبلاغ عن تفاعلات هذه الأحداث باستخدام ميزة "شريحة الجمهور المحمية" البيانات اللازمة للمشتري لاستخدامها في تسجيل مشاهدة أو نقرة كأحد المصادر المؤهَّلة من خلال 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 في طلبات تسجيل المصدر المُعاد توجيهه.

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

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

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

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

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

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

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

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

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

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

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

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