دمج خدمات عروض الأسعار والمزادات وتحسينها

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

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

1. جمع البيانات وتشفيرها لمزاد الخادم
2. إرسال طلب إلى خدمة "بائعين غير موثوق بهم"
3. تلقّي رد من خدمة "بائعين غير موثوق بهم"
4. فك تشفير استجابة مزاد Protected Audience API والحصول على نتيجة المزاد

تقدِّم Protected Audience واجهتَي برمجة تطبيقات جديدتَين لإتاحة مزادات الخوادم قيد التشغيل:

1. تجمع واجهة برمجة التطبيقات getAdSelectionData البيانات الخاصة بمزاد الخادم وتنشئ حمولة بيانات مشفّرة تحتوي على بيانات المزاد. ويستخدم خادم "عروض الأسعار" و"المزاد" هذه الحمولة لإجراء مزاد وإنشاء نتيجة المزاد وعرض نتيجة المزاد.
2. يمكن لعملاء تكنولوجيا الإعلان على الجهاز فقط استدعاء واجهة برمجة التطبيقات persistAdSelectionResult لفك تشفير النتيجة التي تم إنشاؤها من خلال مزاد الخادم والحصول على عنوان URL الرابح لعرض الإعلان.

يجب دمج تكنولوجيا إعلانات البائع على الجهاز وإنشاء ما يلي لإجراء مزاد:

1. جمع البيانات وتشفيرها من خلال مزاد الخادم "البائع": يجب أن تطلب تقنية الإعلان واجهة برمجة تطبيقات getAdSelectionData للحصول على الحمولة المشفرة.
2. إرسال طلب إلى إرسال خدمة البائع غير الموثوق به: طلب HTTP POST أو PUT يحتوي على الحمولة المشفرة التي تم إنشاؤها بواسطة واجهة برمجة التطبيقات getAdSelectionData إلى خدمة البائع غير الموثوق بها والبيانات التي تطلبها خدمة البائع غير الموثوق بها لإنشاء نتائج سياقية.
3. تلقّي ردّ من خدمة "بائعين غير موثوق بهم": قد يتضمّن الردّ من خدمة البائع غير الموثوق بها نتيجة مزاد الجمهور المحمي المشفّر ونتيجة المزاد المستندة إلى السياق.
4. فك تشفير الردود على مزادات شرائح الجمهور المحمية والحصول على نتيجة المزاد: لفك تشفير نتيجة مزاد الجمهور المحمي، يجب أن تطلب تكنولوجيا إعلانات البائعين واجهة برمجة تطبيقات persistAdSelectionResult. ستساعد النتيجة التي يتم تحقيقها من خلال "persistAdSelectionResult" تقنيات الإعلان على تحديد ما إذا كان الإعلان المستند إلى السياق أو "الإعلان المحمي بموجب الجمهور" قد فاز في المزاد ومعرّف الموارد المنتظم (URI) الخاص بإعلان الجمهور المحمي الفائز إن أمكن.

الميزات المتاحة لمزاد الخادم

نهدف إلى إتاحة جميع الميزات المتاحة حاليًا للمزاد على الجهاز فقط. يكون الجدول الزمني لإتاحة هذه الميزات في مزاد الخادم كما يلي:

	مزاد على الجهاز فقط		مزاد الخادم
	معاينة المطور	إصدار تجريبي	معاينة المطور	إصدار تجريبي
إعداد تقارير الفوز على مستوى الحدث	الربع الأول من عام 2023	الربع الثالث من عام 2023	لا ينطبق	الربع الرابع من عام 2023
التوسّط في العرض الإعلاني بدون انقطاع	الربع الأول من عام 2023	الربع الرابع من عام 2023	لا ينطبق	الربع الأول من العام 24
فلترة تحديد عدد مرات الظهور	الربع الثاني من عام 2023	الربع الثالث من عام 2023	لا ينطبق	الربع الرابع من عام 2023
ضبط الإعلانات السياقية على سير عمل اختيار الإعلانات لتتم فلترتها	الربع الثاني من عام 2023	الربع الأول من عام 2024	لا ينطبق	لا ينطبق
إعداد تقارير التفاعل	الربع الثاني من عام 2023	الربع الثالث من عام 2023	لا ينطبق	الربع الرابع من عام 2023
الانضمام إلى تفويض الجمهور المخصّص	الربع الثالث من عام 2023	الربع الرابع من عام 2023	لا ينطبق	الربع الرابع من عام 2023
فوترة غير مستندة إلى التكلفة لكل ألف ظهور	الربع الثالث من عام 2023	الربع الرابع من عام 2023
تقارير تصحيح الأخطاء	الربع الثالث من عام 2023	الربع الرابع من عام 2023	الربع الثالث من عام 2023	الربع الرابع من عام 2023
توسّط عرض الأسعار المفتوح	لا ينطبق	(لا ينطبق)	لا ينطبق	الربع الأول من عام 2024
فلترة إعلانات تثبيت التطبيقات	الربع الثاني من عام 2023	الربع الأول من عام 2024	لا ينطبق	الربع الأول من عام 2024
إدارة العملة	لا ينطبق	(لا ينطبق)	لا ينطبق	الربع الأول من عام 2024
تكامل K-anon	لا ينطبق	الربع الأول من عام 2024	لا ينطبق	الربع الأول من عام 2024
دمج التجميع الخاص	لا ينطبق	(لا ينطبق)	لا ينطبق	الربع الثالث من عام 2024

إجراء مزادات على الخادم باستخدام واجهات Protected Audience API

في مسار "معاينة المطوِّر"، يعرض AdSelectionManager واجهتَي برمجة تطبيقات جديدتين: getAdSelectionData وpersistAdSelectionResult. وتسمح واجهات برمجة التطبيقات هذه بدمج حِزم تطوير البرامج (SDK) لتكنولوجيا الإعلان مع خوادم عروض الأسعار والمزادات.

جمع البيانات وتشفيرها في مزاد على الخادم

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

للوصول إلى واجهة برمجة التطبيقات، يجب تفعيل الوصول إلى Protected Audience API، ويجب تحديد إذن ACCESS_ADSERVICES_CUSTOM_AUDIENCE في بيان المتّصل.

public class AdSelectionManager {
    public void getAdSelectionData(
            GetAdSelectionDataRequest getAdSelectionDataRequest,
            Executor executor,
            OutcomeReceiver<GetAdSelectionDataOutcome, Exception> receiver) {}
}

GetAdSelectionDataRequest

1. على المتصل ضبط الحقل seller في الطلب حيث يتم استخدامه لإجراء عمليات التحقّق من التسجيل قبل تقديم الطلب.
2. الحقل coordinatorOriginUri اختياري.
   1. وفي حال ضبطها، يجب أن يساوي ذلك المخطط واسم المضيف ومنفذ عنوان URL الخاص بالمنسّق الذي تم ضبطه أثناء نشر خادم B&A التابع للبائع.
   2. يجب أن ينتمي المنسّق إلى قائمة المنسقين المعتمدين:

      موفِّر الخدمة	معرّف الموارد المنتظم (URI)	أصل معرّف الموارد المنتظم (URI)	تلقائي
      Google Cloud	https://publickeyservice.pa.gcp.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.gcp.privacysandboxservices.com	نعم
      Amazon Web Services	https://publickeyservice.pa.aws.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.aws.privacysandboxservices.com	لا

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

public class GetAdSelectionDataRequest {
  public setSeller(AdTechIdentifier seller);
  public setCoordinatorOriginUri(Uri coordinatorOriginUri)
}

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

GetAdSelectionDataOutcome

يتم إنشاء GetAdSelectionDataOutcome كنتيجة لـ getAdSelectionData API. ويشتمل على ما يلي:

1. adSelectionId: عدد صحيح غير شفاف لتحديد استدعاء getAdSelectionData. من المفترض أن يحتفظ برنامج تكنولوجيا الإعلان بقيمة adSelectionId هذه لأنّها تعمل كمؤشر لاستدعاء getAdSelectionData. تتطلّب واجهة برمجة التطبيقات persistAdSelectionResult هذا المعرّف لفك تشفير نتيجة المزاد من خادم "عروض الأسعار والمزاد"، كما يجب توفيره أيضًا في واجهتَي برمجة التطبيقات reportImpression وreportEvent.
2. adSelectionData: هذه هي بيانات المزادات المشفَّرة التي قد يطلبها خادم "عروض الأسعار والمزادات" لتنفيذ المزادات. تحتوي هذه الطريقة على ما يلي:
   1. بيانات "شرائح الجمهور المخصّصة التي تمت تصفيتها" استنادًا إلى تحديد عدد مرات الظهور وفلاتر تثبيت التطبيقات ومتطلبات مزاد الخادم لشرائح الجمهور المخصّصة
   2. وفي إصدار مستقبلي، ستحتوي على بيانات تثبيت التطبيقات.

public class GetAdSelectionDataOutcome {
  Public getAdSelectionId(long adSelectionId);
  public byte[] getAdSelectionData();
}

الأخطاء والاستثناءات ومعالجة الأخطاء

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

1. في حال بدء getAdSelectionData باستخدام وسيطات غير صالحة، تشير AdServicesException` إلى السبب UnknownArgumentException.
2. ويتم تصنيف جميع الأخطاء الأخرى على أنّها AdServicesException مع السبب IllegalStateException.

إرسال طلب إلى خدمة بائع غير موثوق بها

باستخدام AdSelectionData، يمكن لحزمة تطوير البرامج (SDK) على الجهاز فقط إرسال طلب إلى الخدمة الإعلانية للبائع من خلال تضمين البيانات في طلب POST أو PUT:

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
...
})

وتكون حزمة تطوير البرامج (SDK) على الجهاز فقط مسؤولة عن ترميز هذه البيانات. ننصح باستخدام حل فعّال من حيث المساحة، مثل إرسال الطلب إلى الخدمة الإعلانية لدى البائع على شكل بيانات متعددة الأجزاء/form-data.

تلقّي ردّ من خدمة بائع غير موثوق بها

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

تعمل خدمة البائع غير الموثوق بها على إعادة توجيه adSelectionData وAuctionConfig المشفّرة إلى خدمة SellerFrontEnd لخادم عروض الأسعار والمزاد التي تعمل في بيئة TEE.

عند اكتمال مزاد Protected Audience API، تعمل خدمة SellerFrontEnd على تشفير نتيجة المزاد وعرضها كاستجابة لخدمة البائع غير الموثوق بها.

ترسل خدمة البائع غير الموثوق بها ردًا إلى الجهاز يحتوي على إعلان سياقي و / أو نتيجة مزاد Protected Audience API مشفّرة.

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

واجهة برمجة التطبيقات PersistAdSelectionResult

لفك تشفير نتيجة Protected Audience API، يمكن لتقنية إعلانات البائع طلب واجهة Protected Audience API الثانية persistAdSelectionResult. فواجهة برمجة التطبيقات تفك تشفير النتيجة وتعرض AdSelectionOutcome، وهو الكائن نفسه الذي يتم عرضه اليوم من مزاد على الجهاز.

للوصول إلى واجهة برمجة التطبيقات، على المتصل تفعيل الوصول إلى Protected Audience API وتحديد إذن ACCESS_ADSERVICES_CUSTOM_AUDIENCE في ملف البيان.

    public void persistAdSelectionResult(
            PersistAdSelectionResultRequest persistAdSelectionResultRequest,
            Executor executor,
            OutcomeReceiver<AdSelectionOutcome, Exception> receiver) {}

PersistAdSelectionResultRequest

يجب أن يحدّد المتصل ما يلي في الطلب:

public final class PersistAdSelectionResultRequest {
  Public setAdSelectionId(long adSelectionId);
  public setSeller(AdTechIdentifier seller);
  public setAdSelectionResult(byte[] adSelectionResult);
}

1. adSelectionId: المعرّف المبهم الذي يتم إنشاؤه بواسطة الطلب getAdSelectionData الذي يريد المتصل فك تشفير نتيجته.
2. seller: يجب ضبط معرّف تكنولوجيا الإعلان الخاص بالبائع في طلب إجراء عمليات التحقّق من التسجيل قبل تقديم الطلب.
3. adSelectionResult: نتيجة المزاد المشفَّرة التي ينشئها خادم "عروض الأسعار والمزاد" التي يريد المتصل فك تشفيرها

استجابة AdSelectionResult

إذا كان هناك فائز Protected Audience، ستعرض AdSelectionOutcome معرّف الموارد المنتظم (URI) الفائز لعرض الإعلان.وبعد فك تشفير adSelectionResult، يتم الاحتفاظ ببيانات إعداد التقارير داخليًا. وتعرض معاودة الاتصال OutcomeReceiver.onResult() رمز AdSelectionOutcome يحتوي على:

• URI: إذا كان أحد إعلانات Protected Audience API فائزًا، سيتم عرض عنوان URL الخاص بعرض الإعلان الفائز. وإذا لم يكن هناك فائز Protected Audience، فسيتم عرض Uri.EMPTY.
• adSelectionId: adSelectionId المرتبطة بمزاد الخادم هذا

الأخطاء والاستثناءات ومعالجة الأخطاء

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

1. إذا تم بدء getAdSelectionData باستخدام وسيطات غير صالحة، تشير العلامة AdServicesException إلى أنّ السبب هو IllegalArgumentException.
2. ويتم تصنيف جميع الأخطاء الأخرى على أنّها AdServicesException مع السبب IllegalStateException.

اعتبارات الخصوصية

يتم تشفير adSelectionData لضمان عدم إمكانية الوصول إلى البيانات التي يتم نقلها سوى عبر PPAPI والخوادم الموثوق بها.

على الرغم من التشفير، يمكن أن يحدث تسرُّب البيانات بسبب الحجم adSelectionData. يمكن أن يختلف حجم adSelectionData للأسباب التالية:

1. التغييرات في بيانات CustomAudience المتوفّرة على الجهاز
2. تغييرات على منطق فلترة CustomAudience
3. التغييرات على الإدخال في مكالمة getAdSelectionData.

ويمكن استخدام التغيير في حجم adSelectionData لإنشاء معرّف على مستوى التطبيقات كما هو مذكور في مناقشة تسريب المعلومات التي تبلغ وحدة بت. وتنطبق هنا أيضًا العديد من إجراءات التخفيف المطبَّقة على تسرُّب وحدات بت واحدة.

لإدارة هذه المعلومات، نخطّط لإنشاء adSelectionData نفسه لجميع طلبات البيانات من getAdSelectionData API. في الإصدارات الأولية، يتم استخدام كل "CustomAudiences" على الجهاز لإنشاء adSelectionData وستتم إضافة الحمولة المشفَّرة حسب أوجه الاختلاف في حجم القناع. سنحدّ أيضًا من تأثير معلَمات إدخال GetAdSelectionData في البيانات adSelectionData التي يتم إنشاؤها.

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

تحسينات الحجم

من المتوقّع أن تجمع حزمة تطوير البرامج (SDK) الخاصة ببرنامج تكنولوجيا الإعلان وحدات البايت المشفَّرة من adSelectionData ضمن طلب HTTP PUT/POST السياقي الذي يتم إجراؤه على خادم تكنولوجيا الإعلان. لتقليل وقت الاستجابة للإرسال وخفض التكلفة، من الضروري تقليل حجم adSelectionData قدر الإمكان بدون التأثير في الأداة.

نخطط لاستكشاف التحسينات التالية ويُحتمَل أن نقدِّمها في الإصدارات القادمة لتقليل حجم adSelectionData:

1. الحمولة التي يتم إنشاؤها في مجموعة ثابتة من أحجام الحِزم مع مساحة متروكة: للحدّ من تسرُّب البيانات من اختلافات الأحجام مع السماح بانخفاض الأحمال، نقترح استخدام تجميع البيانات ذات الحجم الثابت للحمولة التي تم إنشاؤها. على سبيل المثال، عند إبقاء عدد المجموعات صغيرًا، سينتج عن 7 أقل من 3 بتات من القصور المُسرّب لكل استدعاء لـ getAdSelectionData.

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

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

   سيتم بعد ذلك استخدام هذه الإعدادات لتقييم مساهمة المشتري في adSelectionData التي يتم إنشاؤها لكل طلب getAdSelectionData.

   ستسمح إعدادات حمولة المشترين بتحديد ما يلي:

   1. قائمة البائعين المسموح بهم: لن تتم إضافة شرائح الجمهور المخصّصة للمشترين إلى البيانات الأساسية إلا إذا بدأ بائع محدّد في القائمة المسموح بها مكالمة getAdSelectionData. سنقوم بجلب تهيئة الحمولة بشكل منتظم لإبقاء القائمة المسموح بها محدَّثة.
   2. حد الحجم لكل بائع: يمكن للمشتري تحديد حجم لكل بائع لتحديد حجم البيانات التي سيتم إرسالها في الحمولة عند بدء المزاد من قِبل بائع معين. سيكون هذا مفيدًا إذا أراد المشتري تخصيص المزيد من الموارد لمعالجة بيانات المزاد من بائعين معينين. تعيد خدمة SellerFrontendService توجيه البيانات المتعلقة بالمشتري فقط إلى كل خدمة SellerFrontendService. لذلك، من خلال وضع حدّ أقصى للحجم لكل بائع، يمكن للمشتري التحكّم صراحةً في كمية البيانات التي يتم نقلها ومعالجتها من خلال خدمة BuyFrontendService في خادم عروض الأسعار والمزادات في المزادات التي يعرضها البائع.

3. إعدادات البائعين: نقيّم إمكانية ضبط إعدادات المزاد لكل بائع، ما يتيح للبائعين تحديد معلَمات المزاد للتحكم في حجم الحمولة والمشاركين في المزاد. وأثناء التسجيل، ستتمكّن تكنولوجيا إعلانات البائع، إن أمكن، من تحديد نقطة النهاية التي يمكن أن تجلب Protected Audience من خلالها إعدادات المزاد لكل بائع بوتيرة منتظمة. سيتم بعد ذلك استخدام هذه الإعدادات لتحديد تركيبة adSelectionData وحدودها التي يتم إنشاؤها لكل طلب getAdSelectionData.

   على غرار إعدادات المشتري، سيسمح الإعداد لكل بائع للبائعين بتحديد مجموعة المشترين الذين يتوقعون رؤيتهم في المزاد وتحديد الحدود على مساهمة كل مشترٍ في حجم الحمولة.

   تسمح إعدادات مزاد البائع للبائعين بتحديد:

   1. قائمة المشترين المسموح بها: بالنسبة إلى المزادات التي بدأها البائع المعنيّ، سيتمكّن المشترون المدرَجون في القائمة المسموح بها فقط من المساهمة بشرائح الجمهور المخصَّصة في المزاد. يجب تعديل إعدادات المزاد يوميًا لإبقاء القائمة المسموح بها محدّثة من خلال القائمة المسموح بها للمشترين من جهة الخادم.
   2. حد الحجم لكل مشترٍ: يمكن للبائعين وضع حدّ أقصى لكل مشترٍ من أجل تنظيم حجم البيانات التي يحمّلها كل مشترٍ في الحمولة التي يتم إرسالها إلى SellerFrontendService. إذا تجاوز المشتري الحدّ الأقصى للحجم المسموح به لكل مشترٍ، سيتم استخدام أولوية الجمهور المخصّص التي تم ضبطها في إعدادات حمولة المشتري للحصول على البيانات ضمن الحدود المتوقّعة.
   3. الأولوية لكل مشترٍ: اسمح للبائعين بتحديد الأولوية لكل مشترٍ. سيتم استخدام أولوية المشتري لتحديد بيانات المشترين التي يجب الاحتفاظ بها في الحمولة إذا تجاوز حجم الحمولة حد حجم الحمولة.
   4. الحد الأقصى لحجم الحمولة: قد يخصّص بائعون مختلفون موارد مختلفة لتخصيص الموارد، وقد يرغبون في وضع حدّ أقصى لحجم حمولة المزاد لكل طلب. سيراعي الحدّ الأقصى للحجم مجموعات بيانات الحجم الثابتة التي حدّدتها Protected Audience API.

4. التغييرات في الجمهور المخصّص

   1. تحديد أولوية الجمهور المخصّص: السماح للمشترين بتحديد قيمة الأولوية في شريحة جمهور مخصّصة. سيتم استخدام الحقل priority لتحديد الجماهير المخصّصة التي يجب تضمينها في مزاد إذا تجاوزت مجموعة الجماهير المخصّصة للمشترين حدود الحجم لكل بائع أو مشترٍ. قيمة الأولوية غير المحدّدة في "الجمهور المخصّص" سيتم ضبطها تلقائيًا على 0.0.

5. التغييرات في بيانات الحمولة

   1. تقليل البيانات المُرسَلة في الحمولة: كما هو موضّح بالتفصيل في تحسين حمولة خدمات عروض الأسعار والمزادات، تعتمد الحمولة العالية على بيانات ads المخصّصة للجمهور وإشارات عروض أسعار المستخدمين وإشارات Android. ويمكن خفض الحمولات الأعلى من خلال ما يلي:
      1. توجيه العميل إلى إرسال أرقام تعريف عرض الإعلانات (بدلاً من عناصر الإعلانات) في الحمولة
      2. جعل العميل لا يرسل أي بيانات إعلان في الحمولة
      3. لا يتم إرسال إشارات عروض أسعار المستخدِمين في حمولة العميل.

تسمح الاستراتيجيات المذكورة أعلاه لتقنيات الإعلانات بتحديد الإعدادات من أجل إدارة تركيبة حمولة adSelectionData وحدودها، إلا أنّها يمكن أن تصبح أيضًا عاملاً في تعديل حجم adSelectionData من خلال تغيير مَعلمات الإعدادات. ولتجنُّب ذلك، سيتم استرجاع الإعدادات يوميًا بواسطة Protected Audience من نقطة النهاية التي تم ضبطها.

تحسين وقت الاستجابة

للحصول على مستوى فائدة من فائدة مزادات الخوادم، نحتاج إلى التأكّد من أنّ وقت استجابة كل طلب وواجهة برمجة تطبيقات getAdSelectionData وpersistAdSelectionResult يتيحان ذلك. على الرغم من سعينا إلى إتاحة ميزات واجهات برمجة التطبيقات في عام 2023، سيركّز الإصدار اللاحق على مقاييس أداء وقت الاستجابة والتحسينات المتعلّقة بواجهات برمجة التطبيقات.

نستكشف الاستراتيجيات التالية لجعل وقت الاستجابة ضمن الحدود المقبولة:

1. إنشاء مُسبَق لبيانات الجمهور المحمي حسب كل بائع: بما أنّ إعدادات مزاد البائع وإعدادات حمولة المشترين ستكون ثابتة لمدة كبيرة (يوميًا)، يمكن أن تحتسب المنصة بيانات "الجمهور المحمي" المؤهَّلة وتخزّنها مسبقًا.

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

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

   وسيعتمد إنشاء بيانات Protected Audience مسبقًا على

   1. موافقة البائع على إنشاء بيانات Protected Audience مسبقًا.
   2. المشترون المؤهلون للمشاركة في مزاد يبدأه بائع معين.
   3. تحديد شرائح الجمهور المخصّصة لكل مشترٍ ستكون جزءًا من الحمولة استنادًا إلى:
      1. وحدود الحجم لكل مشترٍ وأولوية كل مشترٍ وحدود الحجم القصوى المحددة في تهيئة البائع،
      2. الحدّ الأقصى المسموح به للحجم لكل بائع، وأولوية الجمهور المخصّصة المحدّدة في إعدادات المشتري.

2. التطبيق السريع للفلترة السلبية: إذا كان البائع يفضّل ذلك، يمكن للمنصة احتساب adSelectionData مسبقًا من خلال الإنشاء المسبق بيانات Protected Audience وتطبيق الفلترة السلبية بدلاً من طلب getAdSelectionData المهم. وسيسمح هذا للبائعين بالموازنة بين تقليل وقت الاستجابة وقبول قِدم البيانات في التصفية السلبية.

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

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

   بالنسبة إلى الطلبات اللاحقة التي يتم إجراؤها على getAdSelectionData، يمكن للمتصل توفير مرجع للحمولة المحسوبة مسبقًا لاستخدامها في الجيل adSelectionData.

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

الحد من إساءة الاستخدام وتحديدها

كما هو موضّح في اعتبارات الخصوصية، يتم إنشاء adSelectionData باستخدام جميع بيانات المشترين على الجهاز.

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

الحد من آثار الخطأ

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

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

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

تحديد الكيانات الضارّة

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

لضمان استقرار النظام الأساسي وسلامته، نحتاج إلى إيجاد آلية لتحديد الكيانات الضارة، وتحديد موجّهات إساءة الاستخدام، وتحديد الحوافز لهجمات محدّدة. في الإصدارات اللاحقة، سنقدِّم تفسيرات توضّح متّجهات إساءة الاستخدام المحتملة وإجراءات الحماية للتصدّي لها.