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

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

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

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) للإعلان الفائز الذي يستهدف الجمهور المحمي، إذا كان ذلك منطبقًا.

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

نسعى إلى توفير جميع الميزات المتاحة للمزاد على الجهاز. في ما يلي الجدول الزمني لإتاحة هذه الميزات في مزاد الخادم:

إجراء مزادات على الخادم باستخدام واجهات 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 ويحتوي على ما يلي:

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 إلى أنّ IllegalArgumentException هو السبب.
2. تتلقّى جميع الأخطاء الأخرى AdServicesException مع IllegalStateException كسبب.

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

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

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

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

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

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

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

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

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

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

PersistAdSelectionResult API

لإلغاء تشفير نتيجة Protected Audience، يمكن أن تطلب تكنولوجيا الإعلان التابعة للبائع الوصول إلى واجهة 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: نتيجة المزاد المشفّرة التي أنشأها خادم "عروض الأسعار والمزاد" والتي يريد المتصل فك تشفيرها.

AdSelectionOutcome response

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

• ‫URI: إذا كان هناك إعلان فائز من Protected Audience، سيتم عرض عنوان 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. في الإصدارات الأولية، يتم استخدام جميع CustomAudiences على الجهاز لإنشاء adSelectionData، وسيتم إضافة مساحة فارغة إلى الحمولة المشفّرة لإخفاء الاختلافات في الحجم. سنحدّ أيضًا من تأثير مَعلمات الإدخال GetAdSelectionData على adSelectionData التي يتم إنشاؤها.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

التخفيف من حدة المشكلة

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

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

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

تحديد الجهات الضارة

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

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