يوضح اقتراح تصميم عروض الأسعار والمزادات على نظام التشغيل Android بالتفصيل تنفيذ وتدفق البيانات للمزادات التي يتم إجراؤها على Android باستخدام خادمَي "عروض الأسعار الموثوق بها" و"المزاد". لضمان معالجة البيانات أثناء نقلها فقط من خلال واجهات برمجة التطبيقات والخوادم الموثوق بها، يتم تشفير البيانات بين العميل والخادم باستخدام التشفير ثنائي الاتجاه بالمفتاح العام المختلط.
لإجراء المزاد كما هو موضّح سابقًا، يجب أن تتّبع تقنية إعلان البائع على الجهاز الخطوات التالية:
- جمع البيانات وتشفيرها لمزاد الخادم
- إرسال طلب إلى خدمة "بائعين غير موثوق بهم"
- تلقّي رد من خدمة "بائعين غير موثوق بهم"
- فك تشفير استجابة مزاد Protected Audience API والحصول على نتيجة المزاد
تقدِّم Protected Audience واجهتَي برمجة تطبيقات جديدتَين لإتاحة مزادات الخوادم قيد التشغيل:
- تجمع واجهة برمجة التطبيقات
getAdSelectionData
البيانات الخاصة بمزاد الخادم وتنشئ حمولة بيانات مشفّرة تحتوي على بيانات المزاد. ويستخدم خادم "عروض الأسعار" و"المزاد" هذه الحمولة لإجراء مزاد وإنشاء نتيجة المزاد وعرض نتيجة المزاد. - يمكن لعملاء تكنولوجيا الإعلان على الجهاز فقط استدعاء واجهة برمجة التطبيقات
persistAdSelectionResult
لفك تشفير النتيجة التي تم إنشاؤها من خلال مزاد الخادم والحصول على عنوان URL الرابح لعرض الإعلان.
يجب دمج تكنولوجيا إعلانات البائع على الجهاز وإنشاء ما يلي لإجراء مزاد:
- جمع البيانات وتشفيرها من خلال مزاد الخادم "البائع": يجب أن تطلب تقنية الإعلان
واجهة برمجة تطبيقات
getAdSelectionData
للحصول على الحمولة المشفرة. - إرسال طلب إلى إرسال خدمة البائع غير الموثوق به: طلب
HTTP POST
أوPUT
يحتوي على الحمولة المشفرة التي تم إنشاؤها بواسطة واجهة برمجة التطبيقاتgetAdSelectionData
إلى خدمة البائع غير الموثوق بها والبيانات التي تطلبها خدمة البائع غير الموثوق بها لإنشاء نتائج سياقية. - تلقّي ردّ من خدمة "بائعين غير موثوق بهم": قد يتضمّن الردّ من خدمة البائع غير الموثوق بها نتيجة مزاد الجمهور المحمي المشفّر ونتيجة المزاد المستندة إلى السياق.
- فك تشفير الردود على مزادات شرائح الجمهور المحمية والحصول على نتيجة المزاد:
لفك تشفير نتيجة مزاد الجمهور المحمي، يجب أن تطلب تكنولوجيا إعلانات البائعين
واجهة برمجة تطبيقات
persistAdSelectionResult
. ستساعد النتيجة التي يتم تحقيقها من خلال "persistAdSelectionResult
" تقنيات الإعلان على تحديد ما إذا كان الإعلان المستند إلى السياق أو "الإعلان المحمي بموجب الجمهور" قد فاز في المزاد ومعرّف الموارد المنتظم (URI) الخاص بإعلان الجمهور المحمي الفائز إن أمكن.
الميزات المتاحة لمزاد الخادم
نهدف إلى إتاحة جميع الميزات المتاحة حاليًا للمزاد على الجهاز فقط. يكون الجدول الزمني لإتاحة هذه الميزات في مزاد الخادم كما يلي:
مزاد على الجهاز فقط |
مزاد الخادم |
|||
معاينة المطور |
إصدار تجريبي |
معاينة المطور |
إصدار تجريبي |
|
إعداد تقارير الفوز على مستوى الحدث |
الربع الأول من عام 2023 |
الربع الثالث من عام 2023 |
لا ينطبق |
الربع الرابع من عام 2023 |
الربع الأول من عام 2023 |
الربع الرابع من عام 2023 |
لا ينطبق |
الربع الأول من العام 24 |
|
الربع الثاني من عام 2023 |
الربع الثالث من عام 2023 |
لا ينطبق |
الربع الرابع من عام 2023 |
|
ضبط الإعلانات السياقية على سير عمل اختيار الإعلانات لتتم فلترتها |
الربع الثاني من عام 2023 |
الربع الأول من عام 2024 |
لا ينطبق |
لا ينطبق |
الربع الثاني من عام 2023 |
الربع الثالث من عام 2023 |
لا ينطبق |
الربع الرابع من عام 2023 |
|
الربع الثالث من عام 2023 |
الربع الرابع من عام 2023 |
لا ينطبق |
الربع الرابع من عام 2023 |
|
فوترة غير مستندة إلى التكلفة لكل ألف ظهور |
الربع الثالث من عام 2023 |
الربع الرابع من عام 2023 |
||
تقارير |
الربع الثالث من عام 2023 |
الربع الرابع من عام 2023 |
الربع الثالث من عام 2023 |
الربع الرابع من عام 2023 |
توسّط عرض الأسعار المفتوح |
لا ينطبق |
(لا ينطبق) |
لا ينطبق |
الربع الأول من عام 2024 |
الربع الثاني من عام 2023 |
الربع الأول من عام 2024 |
لا ينطبق |
الربع الأول من عام 2024 |
|
إدارة العملة |
لا ينطبق |
(لا ينطبق) |
لا ينطبق |
الربع الأول من عام 2024 |
تكامل K-anon |
لا ينطبق |
الربع الأول من عام 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
في الطلب حيث يتم استخدامه لإجراء عمليات التحقّق من التسجيل قبل تقديم الطلب. - الحقل
coordinatorOriginUri
اختياري.- وفي حال ضبطها، يجب أن يساوي ذلك المخطط واسم المضيف ومنفذ عنوان URL الخاص بالمنسّق الذي تم ضبطه أثناء نشر خادم B&A التابع للبائع.
- يجب أن ينتمي المنسّق إلى قائمة المنسقين المعتمدين:
موفِّر الخدمة معرّف الموارد المنتظم (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 لا - إذا لم يتم توفير مصدر منسّق، يتم استخدام المنسِّق التلقائي.
- على الرغم من أنّه من غير المرجّح أبدًا أن يتغيّر عنوان URL المنسّق، إلا أننا ننصح بشدة بتنفيذ آلية لإدارة عنوان URL هذا بشكل ديناميكي. ويضمن ذلك استيعاب أي تغييرات مستقبلية يتم إجراؤها على عنوان URL بدون الحاجة إلى إصدار جديد من حزمة تطوير البرامج (SDK).
public class GetAdSelectionDataRequest {
public setSeller(AdTechIdentifier seller);
public setCoordinatorOriginUri(Uri coordinatorOriginUri)
}
بعد التحقّق من صحة الطلب، تتألف بيانات المشترين على الجهاز من
BuyerInput
وProtectedAudienceInput
. بعد ذلك، يتم تشفير كائن الحمولة النهائي باستخدام تشفير المفتاح العام المختلط ثنائي الاتجاه.
GetAdSelectionDataOutcome
يتم إنشاء GetAdSelectionDataOutcome
كنتيجة لـ getAdSelectionData
API. ويشتمل على ما يلي:
adSelectionId
: عدد صحيح غير شفاف لتحديد استدعاءgetAdSelectionData
. من المفترض أن يحتفظ برنامج تكنولوجيا الإعلان بقيمةadSelectionId
هذه لأنّها تعمل كمؤشر لاستدعاءgetAdSelectionData
. تتطلّب واجهة برمجة التطبيقاتpersistAdSelectionResult
هذا المعرّف لفك تشفير نتيجة المزاد من خادم "عروض الأسعار والمزاد"، كما يجب توفيره أيضًا في واجهتَي برمجة التطبيقاتreportImpression
وreportEvent
.adSelectionData
: هذه هي بيانات المزادات المشفَّرة التي قد يطلبها خادم "عروض الأسعار والمزادات" لتنفيذ المزادات. تحتوي هذه الطريقة على ما يلي:- بيانات "شرائح الجمهور المخصّصة التي تمت تصفيتها" استنادًا إلى تحديد عدد مرات الظهور وفلاتر تثبيت التطبيقات ومتطلبات مزاد الخادم لشرائح الجمهور المخصّصة
- وفي إصدار مستقبلي، ستحتوي على بيانات تثبيت التطبيقات.
public class GetAdSelectionDataOutcome {
Public getAdSelectionId(long adSelectionId);
public byte[] getAdSelectionData();
}
الأخطاء والاستثناءات ومعالجة الأخطاء
إذا تعذّر إكمال عملية إنشاء بيانات اختيار الإعلانات بنجاح لأسباب مثل
الوسيطات غير الصالحة أو انتهاء المهلة أو الاستهلاك الزائد للموارد،
يوفّر استدعاء OutcomeReceiver.onError()
السمة AdServicesException
مع السلوكيات التالية:
- في حال بدء
getAdSelectionData
باستخدام وسيطات غير صالحة، تشيرAdServicesException
` إلى السبب UnknownArgumentException. - ويتم تصنيف جميع الأخطاء الأخرى على أنّها
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 مشفّرة.
بعد تلقّي الردّ، يمكن لرمز تكنولوجيا إعلان البائع على الجهاز أن يختار
استخدام الإعلان المستند إلى المحتوى فقط في الردّ أو إذا لاحظ أنّ هناك
قيمة متزايدة في الحصول على نتيجة "الجمهور المحمي"، يمكنه اختيار
فك تشفير نتيجة "الجمهور المحمي" من خلال طلب
واجهة برمجة تطبيقات PersistAdSelectionResult
.
واجهة برمجة التطبيقات PersistAdSelectionResult
لفك تشفير نتيجة 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);
}
adSelectionId
: المعرّف المبهم الذي يتم إنشاؤه بواسطة الطلبgetAdSelectionData
الذي يريد المتصل فك تشفير نتيجته.seller
: يجب ضبط معرّف تكنولوجيا الإعلان الخاص بالبائع في طلب إجراء عمليات التحقّق من التسجيل قبل تقديم الطلب.adSelectionResult
: نتيجة المزاد المشفَّرة التي ينشئها خادم "عروض الأسعار والمزاد" التي يريد المتصل فك تشفيرها
استجابة AdSelectionResult
إذا كان هناك فائز Protected Audience، ستعرض AdSelectionOutcome
معرّف الموارد المنتظم (URI) الفائز لعرض الإعلان.وبعد فك تشفير adSelectionResult
، يتم الاحتفاظ ببيانات إعداد التقارير داخليًا. وتعرض معاودة الاتصال OutcomeReceiver.onResult()
رمز AdSelectionOutcome
يحتوي على:
URI
: إذا كان أحد إعلانات Protected Audience API فائزًا، سيتم عرض عنوان URL الخاص بعرض الإعلان الفائز. وإذا لم يكن هناك فائز Protected Audience، فسيتم عرض Uri.EMPTY.adSelectionId
:adSelectionId
المرتبطة بمزاد الخادم هذا
الأخطاء والاستثناءات ومعالجة الأخطاء
إذا تعذّر إكمال عملية إنشاء بيانات اختيار الإعلانات بنجاح لأسباب مثل
الوسيطات غير الصالحة أو انتهاء المهلة أو الاستهلاك الزائد للموارد،
يوفّر استدعاء OutcomeReceiver.onError()
السمة AdServicesException
مع السلوكيات التالية:
- إذا تم بدء
getAdSelectionData
باستخدام وسيطات غير صالحة، تشير العلامةAdServicesException
إلى أنّ السبب هوIllegalArgumentException
. - ويتم تصنيف جميع الأخطاء الأخرى على أنّها
AdServicesException
مع السببIllegalStateException
.
اعتبارات الخصوصية
يتم تشفير adSelectionData
لضمان عدم إمكانية الوصول إلى البيانات التي يتم نقلها سوى عبر PPAPI والخوادم الموثوق بها.
على الرغم من التشفير، يمكن أن يحدث تسرُّب البيانات بسبب الحجم adSelectionData
. يمكن أن يختلف حجم
adSelectionData
للأسباب التالية:
- التغييرات في بيانات
CustomAudience
المتوفّرة على الجهاز - تغييرات على منطق فلترة
CustomAudience
- التغييرات على الإدخال في مكالمة
getAdSelectionData
.
ويمكن استخدام التغيير في حجم adSelectionData
لإنشاء معرّف على مستوى التطبيقات كما هو مذكور في مناقشة تسريب المعلومات التي تبلغ وحدة بت. وتنطبق هنا أيضًا العديد من إجراءات التخفيف المطبَّقة على تسرُّب وحدات بت واحدة.
لإدارة هذه المعلومات، نخطّط لإنشاء adSelectionData
نفسه لجميع طلبات البيانات من getAdSelectionData
API. في الإصدارات الأولية، يتم استخدام كل
"CustomAudiences
" على الجهاز لإنشاء adSelectionData
وستتم إضافة
الحمولة المشفَّرة حسب أوجه الاختلاف في حجم القناع. سنحدّ أيضًا من تأثير معلَمات إدخال GetAdSelectionData
في البيانات adSelectionData
التي يتم إنشاؤها.
مع ذلك، يؤدي إنشاء adSelectionData
نفسها لجميع تقنيات الإعلان باستخدام جميع
بيانات المزاد على الجهاز فقط إلى إنشاء حمولة كبيرة يجب نقلها الآن
في كل مكالمة إلى خادم تكنولوجيا الإعلان. ويؤدي استخدام جميع شرائح الجمهور المخصَّصة على الجهاز فقط لإنشاء حمولة المزادات إلى فتح المنظومة المتكاملة لإساءة الاستخدام من الكيانات الضارّة. لقد تناولنا هذه المخاوف في قسمَي تحسينات الحجم وإجراءات الحدّ من إساءة الاستخدام أدناه.
تحسينات الحجم
من المتوقّع أن تجمع حزمة تطوير البرامج (SDK) الخاصة ببرنامج تكنولوجيا الإعلان وحدات البايت المشفَّرة من adSelectionData
ضمن طلب HTTP PUT/POST
السياقي الذي يتم إجراؤه على خادم تكنولوجيا الإعلان. لتقليل وقت الاستجابة للإرسال وخفض التكلفة، من الضروري تقليل حجم adSelectionData
قدر الإمكان بدون التأثير في الأداة.
نخطط لاستكشاف التحسينات التالية ويُحتمَل أن نقدِّمها في
الإصدارات القادمة لتقليل حجم adSelectionData
:
الحمولة التي يتم إنشاؤها في مجموعة ثابتة من أحجام الحِزم مع مساحة متروكة: للحدّ من تسرُّب البيانات من اختلافات الأحجام مع السماح بانخفاض الأحمال، نقترح استخدام تجميع البيانات ذات الحجم الثابت للحمولة التي تم إنشاؤها. على سبيل المثال، عند إبقاء عدد المجموعات صغيرًا، سينتج عن 7 أقل من 3 بتات من القصور المُسرّب لكل استدعاء لـ
getAdSelectionData
.وإذا تجاوزت البيانات المتاحة على الجهاز فقط الحد الأقصى لحجم الحزمة، سيتم استخدام الاستراتيجيات المذكورة أدناه، مثل قيم الأولوية، لتحديد البيانات التي سيتم استبعادها.
إعدادات المشتري: نقيّم إمكانية السماح للمشترين بإعداد ضبط حمولة البيانات لكل مشترٍ. ستكون هذه التهيئة مفيدة لتحديد المزادات التي يهتم المشتري بالانضمام إليها. وأثناء التسجيل، يمكن لتكنولوجيا الإعلان الخاصة بالمشتري تسجيل نقطة نهاية يمكن من خلالها لـ Protected Audience جلب إعدادات حمولة البيانات بشكلٍ يومي ومنتظم إذا كان ذلك ممكنًا. وبدلاً من ذلك، قد تعرض واجهات برمجة التطبيقات للحفاظ على الخصوصية واجهة برمجة تطبيقات للسماح لتقنيات الإعلانات للمشترين بتسجيل نقطة النهاية هذه.
سيتم بعد ذلك استخدام هذه الإعدادات لتقييم مساهمة المشتري في
adSelectionData
التي يتم إنشاؤها لكل طلبgetAdSelectionData
.ستسمح إعدادات حمولة المشترين بتحديد ما يلي:
- قائمة البائعين المسموح بهم: لن تتم إضافة شرائح الجمهور المخصّصة للمشترين إلى البيانات الأساسية إلا إذا بدأ بائع محدّد في القائمة المسموح بها مكالمة
getAdSelectionData
. سنقوم بجلب تهيئة الحمولة بشكل منتظم لإبقاء القائمة المسموح بها محدَّثة. - حد الحجم لكل بائع: يمكن للمشتري تحديد حجم لكل بائع لتحديد حجم البيانات التي سيتم إرسالها في الحمولة عند بدء المزاد من قِبل بائع معين. سيكون هذا مفيدًا إذا أراد المشتري تخصيص المزيد من الموارد لمعالجة بيانات المزاد من بائعين معينين. تعيد خدمة SellerFrontendService توجيه البيانات المتعلقة بالمشتري فقط إلى كل خدمة SellerFrontendService. لذلك، من خلال وضع حدّ أقصى للحجم لكل بائع، يمكن للمشتري التحكّم صراحةً في كمية البيانات التي يتم نقلها ومعالجتها من خلال خدمة BuyFrontendService في خادم عروض الأسعار والمزادات في المزادات التي يعرضها البائع.
- قائمة البائعين المسموح بهم: لن تتم إضافة شرائح الجمهور المخصّصة للمشترين إلى البيانات الأساسية إلا إذا بدأ بائع محدّد في القائمة المسموح بها مكالمة
إعدادات البائعين: نقيّم إمكانية ضبط إعدادات المزاد لكل بائع، ما يتيح للبائعين تحديد معلَمات المزاد للتحكم في حجم الحمولة والمشاركين في المزاد. وأثناء التسجيل، ستتمكّن تكنولوجيا إعلانات البائع، إن أمكن، من تحديد نقطة النهاية التي يمكن أن تجلب Protected Audience من خلالها إعدادات المزاد لكل بائع بوتيرة منتظمة. سيتم بعد ذلك استخدام هذه الإعدادات لتحديد تركيبة
adSelectionData
وحدودها التي يتم إنشاؤها لكل طلبgetAdSelectionData
.على غرار إعدادات المشتري، سيسمح الإعداد لكل بائع للبائعين بتحديد مجموعة المشترين الذين يتوقعون رؤيتهم في المزاد وتحديد الحدود على مساهمة كل مشترٍ في حجم الحمولة.
تسمح إعدادات مزاد البائع للبائعين بتحديد:
- قائمة المشترين المسموح بها: بالنسبة إلى المزادات التي بدأها البائع المعنيّ، سيتمكّن المشترون المدرَجون في القائمة المسموح بها فقط من المساهمة بشرائح الجمهور المخصَّصة في المزاد. يجب تعديل إعدادات المزاد يوميًا لإبقاء القائمة المسموح بها محدّثة من خلال القائمة المسموح بها للمشترين من جهة الخادم.
- حد الحجم لكل مشترٍ: يمكن للبائعين وضع حدّ أقصى لكل مشترٍ من أجل تنظيم حجم البيانات التي يحمّلها كل مشترٍ في الحمولة التي يتم إرسالها إلى SellerFrontendService. إذا تجاوز المشتري الحدّ الأقصى للحجم المسموح به لكل مشترٍ، سيتم استخدام أولوية الجمهور المخصّص التي تم ضبطها في إعدادات حمولة المشتري للحصول على البيانات ضمن الحدود المتوقّعة.
- الأولوية لكل مشترٍ: اسمح للبائعين بتحديد الأولوية لكل مشترٍ. سيتم استخدام أولوية المشتري لتحديد بيانات المشترين التي يجب الاحتفاظ بها في الحمولة إذا تجاوز حجم الحمولة حد حجم الحمولة.
- الحد الأقصى لحجم الحمولة: قد يخصّص بائعون مختلفون موارد مختلفة لتخصيص الموارد، وقد يرغبون في وضع حدّ أقصى لحجم حمولة المزاد لكل طلب. سيراعي الحدّ الأقصى للحجم مجموعات بيانات الحجم الثابتة التي حدّدتها Protected Audience API.
التغييرات في الجمهور المخصّص
- تحديد أولوية الجمهور المخصّص: السماح للمشترين بتحديد قيمة الأولوية في شريحة جمهور مخصّصة. سيتم استخدام الحقل
priority
لتحديد الجماهير المخصّصة التي يجب تضمينها في مزاد إذا تجاوزت مجموعة الجماهير المخصّصة للمشترين حدود الحجم لكل بائع أو مشترٍ. قيمة الأولوية غير المحدّدة في "الجمهور المخصّص" سيتم ضبطها تلقائيًا على0.0
.
- تحديد أولوية الجمهور المخصّص: السماح للمشترين بتحديد قيمة الأولوية في شريحة جمهور مخصّصة. سيتم استخدام الحقل
التغييرات في بيانات الحمولة
- تقليل البيانات المُرسَلة في الحمولة: كما هو موضّح بالتفصيل في تحسين حمولة خدمات
عروض الأسعار والمزادات، تعتمد الحمولة العالية على بيانات
ads
المخصّصة للجمهور وإشارات عروض أسعار المستخدمين وإشارات Android. ويمكن خفض الحمولات الأعلى من خلال ما يلي:- توجيه العميل إلى إرسال أرقام تعريف عرض الإعلانات (بدلاً من عناصر الإعلانات) في الحمولة
- جعل العميل لا يرسل أي بيانات إعلان في الحمولة
- لا يتم إرسال إشارات عروض أسعار المستخدِمين في حمولة العميل.
- تقليل البيانات المُرسَلة في الحمولة: كما هو موضّح بالتفصيل في تحسين حمولة خدمات
عروض الأسعار والمزادات، تعتمد الحمولة العالية على بيانات
تسمح الاستراتيجيات المذكورة أعلاه لتقنيات الإعلانات بتحديد الإعدادات من أجل إدارة تركيبة حمولة adSelectionData
وحدودها، إلا أنّها يمكن أن تصبح أيضًا عاملاً في تعديل حجم adSelectionData
من خلال تغيير مَعلمات الإعدادات. ولتجنُّب ذلك، سيتم استرجاع الإعدادات يوميًا بواسطة Protected Audience
من نقطة النهاية التي تم ضبطها.
تحسين وقت الاستجابة
للحصول على مستوى فائدة من فائدة مزادات الخوادم، نحتاج إلى التأكّد من أنّ وقت استجابة كل طلب وواجهة برمجة تطبيقات getAdSelectionData
وpersistAdSelectionResult
يتيحان ذلك. على الرغم من سعينا إلى إتاحة ميزات واجهات برمجة التطبيقات في عام 2023، سيركّز الإصدار اللاحق على مقاييس أداء وقت الاستجابة والتحسينات المتعلّقة بواجهات برمجة التطبيقات.
نستكشف الاستراتيجيات التالية لجعل وقت الاستجابة ضمن الحدود المقبولة:
إنشاء مُسبَق لبيانات الجمهور المحمي حسب كل بائع: بما أنّ إعدادات مزاد البائع وإعدادات حمولة المشترين ستكون ثابتة لمدة كبيرة (يوميًا)، يمكن أن تحتسب المنصة بيانات "الجمهور المحمي" المؤهَّلة وتخزّنها مسبقًا.
ويتطلّب ذلك من المنصة إنشاء آلية لمراقبة التعديلات التي يتم إجراؤها على شرائح الجمهور المخصّصة وتعديل بيانات الجمهور المحمي التي يتم إنشاؤها مسبقًا استنادًا إلى التعديلات. ستحتاج المنصة أيضًا إلى توضيح أهداف مستوى الخدمة بشأن التأخير الذي يمكن أن تتوقّعه تكنولوجيا الإعلان بين تعديلات الجمهور المخصّصة وظهور التغيير في
adSelectionData
الذي تم إنشاؤه لمزاد الخادم.بما أنّ الجهاز يوفّر نموذجًا محدودًا للحوسبة للموارد مع أولويات عمليات مختلفة، ندرك أنّ توفير مرفق ما قبل الإنشاء هذا يجب أن يأتي مع ضمانات ذات موثوقية عالية وضمانات هدف مستوى الخدمة.
وسيعتمد إنشاء بيانات Protected Audience مسبقًا على
- موافقة البائع على إنشاء بيانات Protected Audience مسبقًا.
- المشترون المؤهلون للمشاركة في مزاد يبدأه بائع معين.
- تحديد شرائح الجمهور المخصّصة لكل مشترٍ ستكون جزءًا من
الحمولة استنادًا إلى:
- وحدود الحجم لكل مشترٍ وأولوية كل مشترٍ وحدود الحجم القصوى المحددة في تهيئة البائع،
- الحدّ الأقصى المسموح به للحجم لكل بائع، وأولوية الجمهور المخصّصة المحدّدة في إعدادات المشتري.
التطبيق السريع للفلترة السلبية: إذا كان البائع يفضّل ذلك، يمكن للمنصة احتساب
adSelectionData
مسبقًا من خلال الإنشاء المسبق بيانات Protected Audience وتطبيق الفلترة السلبية بدلاً من طلبgetAdSelectionData
المهم. وسيسمح هذا للبائعين بالموازنة بين تقليل وقت الاستجابة وقبول قِدم البيانات في التصفية السلبية.ويمكن أن توفّر المنصة هذا الدعم من خلال توفير خيار تلقائي في إعدادات "البائع" مع تحديد حد لانتهاء الصلاحية وخيار إلغاء في
getAdSelectionData
للسماح بإجراء آخر عمليات حسابية إذا لزم الأمر. بدلاً من ذلك، يمكن أن توفّر المنصة واجهة برمجة تطبيقات إضافية للإعداد من أجل طلبها قبلgetAdSelectionData
من أجل الاستعداد للمزاد.احتساب حمولة البيانات في مزادات متعدّدة: في سيناريوهات معيّنة، قد يكون من الأفضل استخدام واجهة برمجة تطبيقات تعمل بأداء وقت الاستجابة على حساب زيادة قِدم البيانات. ولتوفير ذلك، يمكن للنظام الأساسي تقديم واجهة برمجة تطبيقات للإعداد اللازمة لاحتساب الحمولة بالكامل وتقديم إشارة إلى الحمولة المحسوبة للمتصل.
بالنسبة إلى الطلبات اللاحقة التي يتم إجراؤها على
getAdSelectionData
، يمكن للمتصل توفير مرجع للحمولة المحسوبة مسبقًا لاستخدامها في الجيلadSelectionData
.
جميع الإستراتيجيات الثلاث المذكورة أعلاه موجودة في مرحلة الاستكشاف الأولية وتهدف إلى وصف الاتجاه الذي قد تتخذه المنصة لتحسين وقت الاستجابة. وبينما نستكشف المزيد من الملفات الشخصية التفصيلية لوقت الاستجابة لمتطلّبات واجهة برمجة التطبيقات وتكنولوجيا الإعلان، سنواصل اقتراح استراتيجيات إضافية.
الحد من إساءة الاستخدام وتحديدها
كما هو موضّح في اعتبارات الخصوصية، يتم إنشاء adSelectionData
باستخدام
جميع بيانات المشترين على الجهاز.
في المقابل، إذا تم استخدام جميع بيانات المشترين على الجهاز لإنشاء
ناتج adSelectionData
، قد يتظاهر كيان ضار كمشتري، ما قد ينشئ بيانات احتيالية للمشترين بهدف خفض مستوى أداء Android، وبالتالي زيادة الحمولة في البيانات لزيادة
التكلفة التي تفرضها تقنية الإعلان لإجراء المزادات أو تنفيذ عروض الأسعار، وما إلى ذلك.
الحد من آثار الخطأ
إنّ بعض الإجراءات المذكورة في قسم اعتبارات الحجم مثل ضبط حمولة المشترين التي تتضمّن البائعين المدرَجين في القائمة المسموح بها وإعدادات مزاد البائع التي تحتوي على مشترين مُدرَجين في القائمة المسموح بها ستساعد في استبعاد البيانات غير المتوقّعة في الحمولة.
يمكن أيضًا أن تساعد إجراءات التفكير في الحجم الأخرى، مثل السماح لمنصات عرض المبيعات (SSP) بتحديد أولوية المشتري، ووضع الحصة لكل مشترٍ في الحمولة التي تم إنشاؤها، وتحديد حد أقصى للحجم لكل حمولة في المزاد، يمكن أن يساعد أيضًا في الحد من تأثير انتفاخ الحمولة الضارة. تهدف هذه الإجراءات إلى السماح لتقنيات الإعلان بتحديد تقنية الإعلان التي يتعاون معها، ووضع حدود مقبولة على الحمولة التي تحتاج إلى معالجتها.
كما ذكرنا سابقًا، يجب أن تراعي جميع إجراءات التخفيف التي تم إدخالها لمكافحة إساءة الاستخدام والقيود المفروضة على الحجم اعتبارات الخصوصية.
تحديد الكيانات الضارّة
مع أنّ إجراءات التخفيف المذكورة أعلاه تحمي الجيل adSelectionData
من مزادات الخوادم، إلا أنّها لا تساعد في تحديد الكيانات الضارة أو حماية المنصة من إساءة الاستخدام، مثل إنشاء عدد غير مسبوق من الجماهير المخصّصة من المشترين.
لضمان استقرار النظام الأساسي وسلامته، نحتاج إلى إيجاد آلية لتحديد الكيانات الضارة، وتحديد موجّهات إساءة الاستخدام، وتحديد الحوافز لهجمات محدّدة. في الإصدارات اللاحقة، سنقدِّم تفسيرات توضّح متّجهات إساءة الاستخدام المحتملة وإجراءات الحماية للتصدّي لها.