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

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

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

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

لغة البرمجة

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

تحسين عرض الإعلانات

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

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

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

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

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

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

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

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

registerAdBeacon(beacons)

الإدخال:

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

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

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

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

دمج Attribution Reporting API

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

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

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

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

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

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

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

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

يُرجى ملاحظة أنّ eventData بعد المزاد قد يحتوي على معلومات حساسة، ولذلك تزيل eventData في طلبات تسجيل المصدر المُعاد توجيهه.

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

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

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

سير العمل: قبل بدء المزاد، يرسل المشتري معرّفًا فريدًا إلى البائع كجزء من استجابة عروض أسعار عرض الأسعار في الوقت الفعلي (RTB) الآلية. يمكن أن يكون المعرّف كمتغير مثل auctionId. يتم تمرير رقم التعريف كـ perBuyerSignals في auctionConfig ويصبح متاحًا في منطق عروض الأسعار للمشتري.

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. المرسلة في الطلب.

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

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

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

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