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

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

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

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

إجراء مزادات على الخادم باستخدام واجهات 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" ثم كائن الحمولة النهائي باستخدام التشفير ثنائي الاتجاه بالمفتاح العام المختلط.

الحصول على نتائج GetAdSelectionData

يتم إنشاء 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 إلى وجود unusedArgumentException كسبب.
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 مشفّرة

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

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

لفك تشفير نتيجة 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: نتيجة المزاد المشفَّرة الناتجة عن عروض الأسعار وخادم المزاد الذي يريد المتصل فك تشفيره.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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