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

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

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

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

تُقدّم ميزة Protected Audience واجهتَي برمجة تطبيقات جديدتَين لتمكين تنفيذ مزادات الخادم:

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

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

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

الميزات المتوافقة مع مزاد الخادم

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

تنفيذ مزادات الخادم باستخدام واجهات برمجة التطبيقات Protected Audience API

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

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

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

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

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

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

PersistAdSelectionResult API

لفك تشفير نتيجة Protected Audience، يمكن لتكنولوجيا الإعلان الخاصة بالبائع طلب persistAdSelectionResultProtected Audience API الثانية. تفكِّك واجهة برمجة التطبيقات التشفير عن النتيجة وتعرض 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. تغييرات شريحة الجمهور المخصّصة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

التخفيف من المخاطر

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

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

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

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

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

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