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

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

مسار مزاد "الجمهور المحمي".

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

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

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

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

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

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

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

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

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

على المتصل ضبط الحقل seller في الطلب لأنّه يتم استخدامه لإجراء عمليات التحقّق من التسجيل قبل خدمة الطلب.

public class GetAdSelectionDataRequest {
  Public setSeller(AdTechIdentifier seller);
}

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

GetAdSelectionDataOutcome

يتم إنشاء GetAdSelectionDataOutcome كنتيجة لواجهة برمجة التطبيقات getAdSelectionData. ويحتوي على ما يلي:

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` إلى السبب في وجود { َلَArgumentException.
2. تتلقّى جميع الأخطاء الأخرى AdServicesException مع IllegalStateException كسبب.

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

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

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

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

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

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

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

عند اكتمال مزاد "الجمهور المحمي"، تشفّر خدمة SellerFrontEnd نتيجة المزاد وتُرجعها كاستجابة لخدمة البائع غير الموثوق بها.

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

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

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

لفك تشفير نتيجة 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   بعد ذلك، سيستند الإنشاء المُسبَق لبيانات الجمهور المحمي إلى

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

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

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

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

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

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

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

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

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

الحد من تأثير المشكلة

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

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

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

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

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

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