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

bookmark_border تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

عند اكتمال مزاد "الجمهور المحمي"، تشفّر خدمة 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

إذا كان هناك إعلان فائز في شريحة الجمهور المحمية، يعرض 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) لخدمة عرض الإعلانات للعملاء الوحدات المتسلسلة المشفّرة من adSelectionData في طلبHTTP PUT/POST السياقي الذي يتم إجراؤه على خادم خدمة عرض الإعلانات. لتقليل وقت الاستجابة والتكلفة في مسار الرحلة بالكامل، من الضروري تقليل حجم 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. إنشاء بيانات الجمهور المحمي مسبقًا لكل بائع: بما أنّ إعدادات المزاد الخاصة بالبائع وإعدادات الحمولة البرمجية للمشتري ستكون ثابتة لفترة زمنية كبيرة (يوميًا)، يمكن للمنصة احتساب بيانات الجمهور المحمي المؤهّلة وتخزينها مسبقًا.

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

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

   سيستند إنشاء بيانات الجمهور المحمي مسبقًا إلى

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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