إشارات تطبيقات محمية لدعم إعلانات تثبيت التطبيقات ذات الصلة

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

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

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

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

تم اقتراح واجهات برمجة التطبيقات التالية لدعم إعلانات تثبيت التطبيقات الفعّالة التي تعمل على تحسين خصوصية المستخدمين عن طريق إلغاء الاعتماد على معرّفات المستخدمين من الجهات الخارجية المختلفة:

1. Protected App Signals API: تتمحور حول تخزين وإنشاء ميزات مصمَّمة بهندسة الإعلانات وتشكّل الاهتمامات المحتملة للمستخدمين. تخزِّن تكنولوجيا الإعلان إشارات محدّدة ذاتيًا عن الأحداث الخاصة بكل تطبيق، مثل عمليات تثبيت التطبيقات أو عمليات فتح التطبيق لأول مرة أو إجراءات المستخدم (المستوى داخل اللعبة أو الإنجازات) وأنشطة الشراء أو الوقت المستغرَق في التطبيق. تتم كتابة الإشارات وتخزينها على الجهاز للحماية من تسرُّب البيانات، ولا تتم إتاحة هذه الإشارات إلا لمنطق تكنولوجيا الإعلان الذي خزّن الإشارة المحدّدة أثناء تشغيل مزاد محمي في بيئة آمنة.
2. Ad Select API: توفّر هذه الواجهة واجهة برمجة تطبيقات لإعداد وتنفيذ مزاد محمي يتم تنفيذه في بيئة تنفيذ موثوقة (TEE) حيث تسترد تكنولوجيا الإعلان الإعلانات المرشحة وتستنتج الاستنتاج وتحتسب عروض الأسعار وتحصل على نتيجة اختيار إعلان "ناجح" باستخدام كلٍّ من إشارات التطبيق المحمية والمعلومات السياقية التي يقدّمها الناشر في الوقت الفعلي.

رسم بياني انسيابي يعرض سير عمل اختيار الإعلانات وإشارات التطبيقات المحمية في "مبادرة حماية الخصوصية" على Android.

في ما يلي نظرة عامة وشاملة عن آلية عمل "إشارات التطبيقات المحمية" لدعم إعلانات تثبيت التطبيقات ذات الصلة. توفر الأقسام التالية من هذا المستند مزيدًا من التفاصيل حول كل خطوة من هذه الخطوات.

• تنظيم الإشارات: أثناء استخدام المستخدمين للتطبيقات المتوافقة مع الأجهزة الجوّالة، تنظّم تكنولوجيا الإعلان الإشارات من خلال تخزين أحداث التطبيقات المحدّدة من خلال تكنولوجيا الإعلان لعرض الإعلانات ذات الصلة باستخدام Protected App Signals API. يتمّ تخزين هذه الأحداث في مساحة تخزين محمية على الجهاز، على غرار شرائح الجمهور المخصّصة، ويتم تشفيرها قبل إرسالها من الجهاز، بحيث لا يمكن إلّا لخدمات عروض الأسعار والمزادات التي تعمل ضمن بيئات التنفيذ الموثوق بها والتي تخضع لضوابط الأمان والخصوصية المناسبة أن تفكّ تشفيرها لعرض الإعلانات وحساب النتائج.
• ترميز الإشارات: يتم إعداد الإشارات وفقًا لوتيرة مجدولة حسب منطق تكنولوجيا الإعلانات المخصّصة. تنفّذ مهمة تعمل في الخلفية لنظام التشغيل Android هذا المنطق لتنفيذ ترميز على الجهاز لإنشاء حمولة بيانات من إشارات التطبيقات المحمية التي يمكن استخدامها لاحقًا في الوقت الفعلي لاختيار الإعلانات خلال مزاد محمي. يتم تخزين الحمولة بشكل آمن على الجهاز إلى أن يتم إرسالها في المزاد.
• اختيار الإعلان: لاختيار الإعلانات ذات الصلة بالمستخدم، تُرسِل حِزم SDK الخاصة بالبائعين حمولةً مشفّرة من "إشارات التطبيقات المحمية" وتضبط مزادًا محميًا. في المزاد، يعمل منطق تخصيص المشتري على إعداد "إشارات التطبيق المحمية" مع البيانات السياقية التي يقدّمها الناشر (البيانات التي تتم عادةً مشاركتها في طلب إعلان مفتوح/عرض الأسعار في الوقت الفعلي) لهندسة الميزات المخصّصة لاختيار الإعلانات (استرجاع الإعلانات والاستنتاج وإنشاء عروض الأسعار). على غرار Protected Audience، يرسل المشترون الإعلانات إلى البائع للحصول على النتيجة النهائية في مزاد محمي.
  • استرجاع الإعلانات: يستخدم المشترون "إشارات التطبيقات المحمية" والبيانات السياقية التي يقدّمها الناشرون للميزات الهندسية ذات الصلة باهتمامات المستخدمين. يتم استخدام هذه الميزات لمطابقة الإعلانات التي تلبي معايير الاستهداف. تتم تصفية الإعلانات التي ليست ضمن الميزانية. بعد ذلك، يتم اختيار أهم ألف إعلان لتقديم عروض الأسعار.
  • عروض الأسعار: يعمل منطق عروض الأسعار المخصّصة لدى "المشترين" على إعداد البيانات السياقية التي يقدّمها الناشر و"إشارات التطبيقات المحمية" لهندسة الميزات التي تُستخدَم كمدخلات لنماذج تعلُّم الآلة الخاصة بالمشتري من أجل الاستنتاج وتقديم عروض أسعار للإعلانات المرشحة ضمن حدود موثوق بها للحفاظ على الخصوصية. وعندئذٍ يُعيد المشتري الإعلان الذي اختاره إلى البائع.
  • نتائج البائع: يسجل منطق النتائج المخصص للبائعين الإعلانات التي يرسلها "المشترون المشاركون" ويختار إعلانًا فائزًا ليتم إرساله مرة أخرى إلى التطبيق لعرضه.
• إعداد التقارير: يتلقى المشاركون في المزاد تقارير الفوز وتقارير الخسائر السارية. ونحن نستكشف آليات الحفاظ على الخصوصية لتضمين بيانات لتدريب النموذج في تقرير الفوز.

المخطط الزمني

	معاينة المطور			إصدار تجريبي
الميزة	الربع الرابع من 2023	الربع الأول من عام 2024	الربع الثاني من 2024	الربع الثالث من 2024
واجهات برمجة التطبيقات لتنظيم الإشارات	واجهات برمجة التطبيقات للتخزين على الجهاز فقط	منطق حصة مساحة التخزين على الجهاز تحديثات يومية للمنطق المخصّص على الجهاز	لا ينطبق	متاحة لنسبة% 1 من أجهزة T+
خادم استرجاع الإعلان في بيئة التنفيذ الموثوقة (TEE)	منتج الحد الأدنى (MVP)	متوفّرة على Google Cloud Platform الدعم لإنتاج أبرز K UDF	متوفّرة على AWS تصحيح الأخطاء والمقاييس بالموافقة، والرصد
خدمة الاستنتاج في بيئة التنفيذ الموثوقة (TEE) تقديم الدعم لتشغيل نماذج تعلُّم الآلة واستخدامها في تقديم عروض الأسعار في بيئة التنفيذ الموثوقة (TEE)	قيد التطوير	متوفّرة على Google Cloud Platform القدرة على نشر نماذج تعلُّم الآلة الثابتة وإنشاء نماذج أولية لها باستخدام Tensorflow وPyTorch	متاحة على AWS نشر نموذج تم إنشاؤه لنماذج Tensorflow وPyTorch القياس عن بُعد وتصحيح الأخطاء والموافقة عليه والمراقبة
دعم عروض الأسعار والمزادات في بيئة تنفيذ موثوقة	متاح على Google Cloud Platform	دمج استرجاع الإعلانات PAS-B&A وTEE (مع تشفير gRPC وTEE<>) إتاحة استرجاع الإعلانات من خلال المسار السياقي (يتضمّن B&A<>دعم K/V على بيئة التنفيذ الموثوقة (TEE))	متوفّرة على AWS إعداد تقارير تصحيح الأخطاء تصحيح الأخطاء والمقاييس والمراقبة بالموافقة

تنظيم إشارات التطبيقات المحمية

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

واجهة برمجة التطبيقات في إشارات التطبيقات المحمية

تتيح واجهة برمجة التطبيقات Protected App Signals API إدارة الإشارات باستخدام آلية تفويض مشابهة للآلية المستخدَمة لشرائح الجمهور المخصَّصة. تتيح Protected App Signals API إمكانية تخزين الإشارات في شكل قيمة عددية واحدة أو كسلسلة زمنية. يمكن استخدام إشارات السلسلة الزمنية لتخزين أشياء مثل مدة جلسة المستخدم. تقدم إشارات السلسلة الزمنية أداة لفرض طول معين باستخدام قاعدة الإخلاء أولًا، أولًا. نوع بيانات الإشارة العددية أو كل عنصر من عناصر إشارة السلسلة الزمنية هو صفيف بايت. ويتم تزويد كل قيمة باسم حزمة التطبيق الذي خزّن الإشارة، والطابع الزمني لإنشاء طلب بيانات من واجهة برمجة التطبيقات لإشارة المتجر. وتتوفّر هذه المعلومات الإضافية في JavaScript لترميز الإشارة. يوضّح هذا المثال بنية الإشارات التي تملكها تقنية إعلانات معيّنة:

يوضح هذا المثال إشارة عددية وإشارة سلسلة زمنية مرتبطة بـ adtech1.com:

• إشارة عددية تتضمّن مفتاح قيمة base64 "A1c" والقيمة "c12Z". وقد تم تفعيل مخزن الإشارات بحلول com.google.android.game_app في 1 حزيران (يونيو) 2023.
• قائمة بالإشارات التي تتضمّن المفتاح "dDE" والتي أنشأها تطبيقان مختلفان.

يتم تخصيص مساحة معيّنة لتكنولوجيا الإعلانات لتخزين الإشارات على الجهاز. سيكون للإشارات حد أقصى لمدة البقاء (TTL) الذي سيتم تحديده.

تتم إزالة "إشارات التطبيقات المحمية" من مساحة التخزين إذا تم إلغاء تثبيت التطبيق المُنشأ، أو حظر استخدام Protected App Signals API، أو إذا محو المستخدِم بيانات التطبيق.

تتألّف واجهة برمجة التطبيقات Protected App Signals API من الأجزاء التالية:

• واجهة برمجة تطبيقات Java وJavaScript لإضافة الإشارات أو تحديثها أو إزالتها.
• واجهة برمجة تطبيقات JavaScript لمعالجة الإشارات المستمرة لإعدادها لهندسة ميزات إضافية في الوقت الفعلي أثناء مزاد محمي يتم تنفيذه في بيئة تنفيذ موثوقة (TEE).

إضافة إشارات أو تعديلها أو إزالتها

يمكن لتكنولوجيا الإعلانات إضافة إشارات أو تعديلها أو إزالتها باستخدام fetchSignalUpdates() API. توفّر واجهة برمجة التطبيقات هذه تفويضًا مشابهًا لتفويض الجمهور المخصّص في Protected Audience.

لإضافة إشارة، يجب أن تتعاون تكنولوجيا الإعلان الخاصة بالمشتري والتي لا تتضمّن حِزم تطوير البرامج (SDK) في التطبيقات مع تكنولوجيا الإعلان التي تعمل على الأجهزة، مثل شركاء القياس على الأجهزة الجوّالة (MMP) ومنصات المورّدين (SSP). وتهدف واجهة برمجة التطبيقات Protected App Signals API إلى دعم تكنولوجيا الإعلان هذه من خلال توفير حلول مرنة لإدارة إشارات التطبيقات المحمية، وذلك من خلال السماح لمستخدمي الأجهزة المتصلة باستدعاء ميزة إنشاء إشارات التطبيقات المحمية بالنيابة عن المشترين. تُسمّى هذه العملية التفويض وتستفيد من واجهة برمجة التطبيقات fetchSignalUpdates(). يأخذ fetchSignalUpdates() معرّف الموارد المنتظم (URI) ويسترد قائمة بتحديثات الإشارات. للتوضيح، يصدر fetchSignalUpdates() طلب GET إلى معرّف الموارد المنتظم (URI) المحدّد لاسترداد قائمة التحديثات التي سيتم تطبيقها على مساحة تخزين الإشارة المحلية. تستجيب نقطة نهاية عنوان URL، التي يملكها المشتري، مرة أخرى بقائمة JSON من الأوامر.

أوامر JSON المتوافقة هي:

• set: يدرج أو يتجاوز قيمة عددية للمفتاح المعين.
• put_if_not_present: تُدخل قيمة عددية لمفتاح معين إذا لم تكن هناك قيمة مخزنة بالفعل. قد يكون هذا الخيار مفيدًا على سبيل المثال، من خلال تحديد رقم تعريف تجربة لمستخدم معيّن وتجنُّب إلغاؤه إذا سبق أن تم ضبطه من خلال تطبيق مختلف.
• append: يضيف عنصرًا إلى السلسلة الزمنية المرتبطة بالمفتاح المحدّد. تُحدِّد المَعلمة maxSignals الحدّ الأقصى لعدد الإشارات في السلسلة الزمنية. إذا تم تجاوز الحجم، تتم إزالة العناصر السابقة. إذا كان المفتاح يحتوي على قيمة عددية، فسيتم تحويله تلقائيًا إلى سلسلة زمنية.
• إزالة: يؤدي هذا الخيار إلى إزالة المحتوى المرتبط بالمفتاح المحدّد.

{
   "put": {
    "A1c": "c12Z",
    "dDE": "d23d",
  },
  "put_if_not_present": {
    "aA9": "a1zfC3"
  }
  "append": {
    "bB1": {"values": ["gh12D", "d45g"], "maxSignals": 20}
  },
  "remove": ["c0D"]
}

يتم التعبير عن جميع المفاتيح والقيم باستخدام Base64.

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

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

حصة مساحة التخزين والإخلاء

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

الترميز على الجهاز فقط لنقل البيانات

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

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

إذا لم يسجّل المشتري برنامج ترميز للإشارات، لن يتم إعداد الإشارات، ولن يتم إرسال أيّ من الإشارات المنظَّمة على الجهاز إلى خدمتَي عروض الأسعار والمزاد.

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

سير عمل اختيار الإعلانات

من خلال هذا الاقتراح، يمكن للرمز المخصّص لتكنولوجيا الإعلان الوصول فقط إلى "إشارات التطبيقات المحمية" داخل واجهة برمجة تطبيقات Protected Auction (واجهة برمجة التطبيقات Ad Selection API) التي يتم تنفيذها في بيئة تنفيذ موثوقة (TEE). ولتلبية احتياجات حالة استخدام تثبيت التطبيق بشكل أكبر، يتم جلب إعلانات المرشحين أثناء المزاد المحمي في الوقت الفعلي. وهذا يتناقض مع حالة استخدام تجديد النشاط التسويقي التي تكون فيها الإعلانات المرشحة معروفة قبل المزاد.

يستخدم هذا الاقتراح سير عمل مشابهًا لاختيار الإعلانات مثل اقتراح الجمهور المحمي مع تعديلات لدعم حالة استخدام تثبيت التطبيق. ولتلبية متطلبات الحوسبة الخاصة بهندسة الميزات واختيار الإعلانات في الوقت الفعلي، يجب عرض مزادات إعلانات تثبيت التطبيقات على خدمات عروض الأسعار والمزادات التي يتم عرضها في بيئة التنفيذ الموثوقة (TEE). الوصول إلى "إشارات التطبيقات المحمية" خلال "مزاد محمي" غير متاح في المزادات على الجهاز فقط.

سير عمل اختيار الإعلانات في "مبادرة حماية الخصوصية" على Android

في ما يلي خطوات سير عمل اختيار الإعلانات:

1. تُرسِل حزمة تطوير البرامج (SDK) للبائع الحمولة المشفَّرة على الجهاز فقط من إشارات التطبيقات المحمية.
2. ينشئ خادم البائع إعدادات مزاد ويرسلها إلى خدمة عروض الأسعار الموثوق بها والمزادات التابعة للبائع، جنبًا إلى جنب مع الحمولة المشفَّرة، وذلك من أجل بدء سير عمل اختيار الإعلانات.
3. تعمل خدمة "عروض الأسعار والمزادات" لدى البائع على تمرير الحمولة إلى خوادم الواجهة الأمامية الخاصة بالمشترين الموثوق بهم والمشاركين.
4. تنفِّذ خدمة عروض الأسعار التي يقدّمها المشتري منطق اختيار الإعلانات من جهة الشراء.
   1. تنفيذ منطق استرداد الإعلان من جهة الشراء:
   2. تنفيذ عروض الأسعار من جهة الشراء:
5. يتم تنفيذ منطق تسجيل جهة البيع من جهة البيع.
6. يتم عرض الإعلان وبدء إعداد التقارير.

بدء سير عمل اختيار الإعلانات

عندما يكون التطبيق جاهزًا لعرض إعلان، تبدأ حزمة تطوير البرامج (SDK) لتكنولوجيا الإعلان (عادةً منصات SSP) سير عمل اختيار الإعلانات عن طريق إرسال أي بيانات سياقية ذات صلة من الناشر والحمولات المشفَّرة حسب كل مشترٍ والمضمَّنة في الطلب المُرسَل إلى المزاد المحمي باستخدام طلب getAdSelectionData. وهي واجهة برمجة التطبيقات نفسها المستخدَمة لسير عمل تجديد النشاط التسويقي والموضّحة في اقتراح دمج عروض الأسعار والمزادات لنظام التشغيل Android.

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

يحدّد البائع ما يلي:

• الحمولة التي تم تلقّيها من "getAdSelectionData" والتي تحتوي على إشارات التطبيقات المحمية.

• الإشارات السياقية باستخدام:

  • auction_config.auction_signals (للحصول على معلومات حول المزاد)

  • auction_config.seller_signals (لإشارات البائع

  • auction_config.per_buyer_config["buyer"].buyer_signals (لإشارات المشترين)

• قائمة المشترين المُضمَّنة في المزادات باستخدام الحقل buyer_list.

التنفيذ المنطقي لاختيار الإعلانات من جهة الشراء

على مستوى عالٍ، يستخدم المنطق المخصّص للمشتري البيانات السياقية التي يوفّرها الناشر و"إشارات التطبيقات المحمية" لاختيار عرض أسعار وتطبيقه على الإعلانات الملائمة لطلب الإعلان. ويتيح النظام الأساسي للمشترين تضييق نطاق مجموعة كبيرة من الإعلانات المتاحة إلى الإعلانات الأكثر صلة (أعلى ك)، التي يتم حساب عروض أسعارها قبل إرجاع الإعلانات إلى البائع للاختيار النهائي.

منطق اختيار الإعلانات من جهة الشراء في "مبادرة حماية الخصوصية" على Android

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

ملاحظة: هذا المسار هو مزيج من التعليمات البرمجية لإطار العمل والوظائف التي يحدّدها المستخدم (UDFs) والتي تشتمل على منطق النشاط التجاري للمشتري. يتم تنفيذ هذه الدوال المعرَّفة من قِبل المستخدم في JavaScript أو WASM. وعلى المستوى العالي، تكون العملية كما يلي:

1. تتلقى خدمة purchaseFrontEnd طلب إعلان.
2. ترسل خدمة purchaseFrontEnd طلبًا إلى خدمة عروض الأسعار للمشتري. تشغّل خدمة عروض الأسعار لدى المشتري أداة UDF تُسمى prepareDataForAdRetrieval()، وتنشئ طلبًا للحصول على أفضل ألف مرشح من خدمة استرجاع الإعلانات. ترسل خدمة عروض الأسعار هذا الطلب إلى نقطة نهاية خادم الاسترداد الذي تم إعداده.
3. تشغِّل خدمة استرجاع الإعلانات getCandidateAds() UDF، التي تتمّ فلترتها وصولاً إلى مجموعة أفضل K من الإعلانات المرشحة، والتي يتم إرسالها إلى خدمة عروض الأسعار للمشتري.
4. تشغّل خدمة عروض الأسعار لدى المشتري واجهة المستخدم الموحدة (UDF) generateBid()، التي تختار أفضل مرشح، وتحتسب عرض سعرها، ثم تُرجعه إلى خدمة SellFrontEnd.
5. تعمل خدمة purchaseFrontEnd على إرجاع الإعلانات وعروض الأسعار إلى البائع.

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

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

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

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

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

تحليل النموذج إلى عوامل

تحليل النموذج إلى تحليل هو تقنية تجعل من الممكن تقسيم نموذج واحد إلى أجزاء متعددة، ثم دمج هذه القطع في التنبؤ. في حالة استخدام تثبيت التطبيق، غالبًا ما تستخدم النماذج ثلاثة أنواع من البيانات: بيانات المستخدم، والبيانات السياقية، وبيانات الإعلانات.

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

هذا يجعل التصميم التالي ممكنًا:

1. قسِّم النموذج إلى جزء خاص (بيانات المستخدم) وقطعة غير خاصة أو أكثر (البيانات السياقية وبيانات الإعلان).
2. اختياريًا، مرر بعض أو كل القطع غير الخاصة كوسيطات إلى UDF تحتاج إلى إجراء تنبؤات. على سبيل المثال، يتم تمرير التضمينات السياقية إلى الدوال المعرَّفة من قِبل المستخدم في per_buyer_signals.
3. اختياريًا، يمكن لتكنولوجيا الإعلان إنشاء نماذج للقطع غير الخاصة، ثم تحقيق عمليات التضمين من هذه النماذج في متجر القيمة الرئيسية لخدمة استرجاع الإعلانات. يمكن للدوال المعرَّفة من قِبل المستخدم في خدمة استرجاع الإعلانات جلب هذه التضمينات في وقت التشغيل.
4. لإجراء توقع أثناء استخدام الدالة UDF، يمكنك دمج التضمينات الخاصة من خدمة الاستنتاج مع عمليات التضمين غير الخاصة من وسيطات دالة UDF أو مخزن القيم الأساسية مع عملية مثل منتج نقطة. هذا هو التوقع النهائي.

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

مؤسسة prepareDataForAdRetrieval() UDF

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

تأخذ prepareDataForAdRetrieval() المعلومات التالية:

• الحمولة لكل مشترٍ التي تم استلامها من "getAdSelectionData" تحتوي هذه الحمولة على "إشارات التطبيقات المحمية".
• إشارات السياق auction_signals (للاطّلاع على معلومات عن المزاد) وbuyer_signals (لحقلَي إشارات المشترين).

يتم تنفيذ إجراءين من قِبل prepareDataForAdRetrieval() وهما:

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

يمكن إرجاع المشتريات مقابل prepareDataForAdRetrieval():

• إشارات التطبيقات المحمية: حمولة الإشارات المنظّمة بواسطة تكنولوجيا الإعلانات.
• الإشارات الخاصة بالمزاد: تشمل إشارات جهة البيع الخاصة بالمنصة ومعلومات سياقية مثل auction_signals وper_buyer_signals (بما في ذلك التضمينات السياقية) من SelectAdRequest. يشبه ذلك شرائح الجمهور المحمية.
• إشارات إضافية: معلومات إضافية مثل عمليات التضمين الخاصة التي تم استردادها من خدمة الاستنتاج.

يتم إرسال هذا الطلب إلى خدمة استرجاع الإعلانات، التي تُجري مطابقة المرشحات وتشغِّل بعد ذلك getCandidateAds() UDF.

مؤسسة getCandidateAds() UDF

تعمل "getCandidateAds()" على خدمة "استرجاع الإعلانات". تتلقّى هذه الأداة الطلب الذي أنشأه prepareDataForAdRetrieval() بشأن خدمة عروض الأسعار للمشتري. تنفّذ الخدمة getCandidateAds() التي تجلب أفضل مرشحي عروض الأسعار من خلال تحويل الطلب إلى سلسلة من طلبات البحث، وعمليات جلب البيانات، وتنفيذ منطق مخصص للنشاط التجاري ومنطق مخصص آخر لاسترداد البيانات.

تأخذ getCandidateAds() المعلومات التالية:

• إشارات التطبيقات المحمية: حمولة الإشارات المنظّمة بواسطة تكنولوجيا الإعلانات.
• الإشارات الخاصة بالمزاد: تشمل إشارات جهة البيع الخاصة بالمنصة ومعلومات سياقية مثل auction_signals وper_buyer_signals (بما في ذلك التضمينات السياقية) من SelectAdRequest. يشبه ذلك شرائح الجمهور المحمية.
• إشارات إضافية: معلومات إضافية مثل عمليات التضمين الخاصة التي تم استردادها من خدمة الاستنتاج.

في ما يلي الإجراءات التي يمكن من خلالها getCandidateAds():

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

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

• تمّ تمرير التضمينات السياقية باستخدام الإدخال الإشارات الخاصة بالمزادات.
• تم تمرير التضمينات الخاصة باستخدام إدخال الإشارات الإضافية.
• تم تعزيز أي تكنولوجيا إعلانات للتضمينات غير الخاصة من خوادمها في خدمة القيمة الأساسية لـ "خدمة استرداد الإعلانات".

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

يمكن إرجاع المشتريات مقابل getCandidateAds():

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

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

مؤسسة generateBid() UDF

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

تأخذ generateBid() المعلومات التالية:

• الإعلانات المقترحة: أعلى آلاف من الإعلانات المعروضة من خلال خدمة استرداد الإعلانات.
• الإشارات الخاصة بالمزاد: تشمل إشارات جهة البيع الخاصة بالمنصة ومعلومات سياقية مثل auction_signals وper_buyer_signals (بما في ذلك التضمينات السياقية) من SelectAdRequest.
• إشارات إضافية: معلومات إضافية سيتم استخدامها في وقت عرض الأسعار.

يتم تنفيذ generateBid() لدى المشتري ثلاثة أشياء:

• التخصيص: يحوّل الإشارات إلى ميزات لاستخدامها أثناء الاستنتاج.
• الاستنتاج: يتم إنشاء توقّعات باستخدام نماذج تعلُّم الآلة لاحتساب قيم مثل نسبة النقر إلى الظهور ومعدّلات الإحالات الناجحة المتوقّعة.
• عروض الأسعار: الجمع بين القيم المستنتَجة مع مدخلات أخرى من أجل احتساب عرض سعر إعلان مرشّح.

يمكن إرجاع المشتريات مقابل generateBid():

• الإعلان المرشح.
• مبلغ عرض السعر المحسوب له.

لاحظ أن generateBid() المستخدم في إعلانات تثبيت التطبيقات يختلف عن الآخر المستخدم لإعلانات تجديد النشاط التسويقي.

توضّح الأقسام التالية الميزات والاستنتاج وعروض الأسعار بمزيد من التفاصيل.

التمتع

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

الاستنتاج

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

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

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

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

تنفيذ تحليل النموذج إلى عوامل

لقد شرحنا سابقًا تحليل النماذج. في وقت عرض السعر، يكون النهج المحدد هو:

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

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

منطق النتائج من جهة البيع

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

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

وقت تشغيل رمز اختيار الإعلان

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

إعداد التقارير

يستخدم هذا الاقتراح واجهات برمجة التطبيقات لإعداد التقارير نفسها المستخدَمة في اقتراح إعداد تقارير محميّة عن الجمهور (على سبيل المثال، reportImpression() الذي يتيح للمنصة إرسال تقارير البائعين والمشترين).

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

نتحقّق على المدى الطويل من حلول الحفاظ على الخصوصية لمعالجة التدريب على النموذج باستخدام البيانات المستخدَمة في المزادات المحمية بدون إرسال بيانات المستخدمين على مستوى الحدث خارج الخدمات التي تعمل في بيئة التنفيذ الموثوقة (TEE). سنقدّم تفاصيل إضافية في تحديث لاحق.

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

من الناحية الفنية، تكون آلية عمل هذه الميزة:

1. تحدّد تكنولوجيا الإعلان مخططًا للبيانات التي يريدون نقلها.
2. في generateBid()، تبني حمولة البيانات عند الخروج منها.
3. تتحقق المنصة من حمولة الخروج مقابل المخطط وتفرض حدود الحجم.
4. تضيف المنصة تشويشًا إلى حمولة الخروج.
5. يتم إدراج حمولة البيانات في تقرير الفوز بتنسيق سلكي، ويتمّ استلامها على خوادم تكنولوجيا الإعلانات وفكّ ترميزها واستخدامها لتدريب النماذج.

تحديد مخطط حمولات الخروج

لكي تفرض المنصة متطلبات الخصوصية المتغيّرة، يجب تنظيم حمولات الخروج بطريقة يمكن للنظام الأساسي فهمها. ستحدّد تكنولوجيا الإعلان هيكل حمولات الخروج من خلال توفير ملف JSON للمخطط ستتم معالجة هذا المخطط من خلال المنصة، مع الحفاظ على سرّيته من خلال خدمتَي "عروض الأسعار" و"المزاد" باستخدام الآليات نفسها التي تستخدمها موارد تكنولوجيا الإعلان الأخرى مثل النماذج والمستنِدة إلى الذكاء الاصطناعي (UDF).

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

على سبيل المثال، ستبدو حمولة البيانات المخرَجة التي تتكوّن من ميزة منطقية واحدة متبوعة بميزة حزمة من الحجم الثاني كما يلي:

egressPayload = {
  features : [
    {
      type: "boolean_feature",
      value: false
    },
    {
      type: "bucket_feature",
      size: 2,
      value: [
        {
          value: false
        },
        {
          value: true
        }
      ]
    }
  ]
}

التفاصيل حول مجموعة أنواع الميزات المتوافقة متاحة على GitHub.

إنشاء حمولات عند الخروج في generateBid()

تتوفّر جميع إشارات التطبيق المحمية لمشترٍ معيّن في generateBid() UDF. وبعد تفعيل هذه الميزة، تنشئ تكنولوجيا الإعلان حمولتها بتنسيق JSON. سيتم تضمين حمولة البيانات هذه في تقرير الفوز للمشتري من أجل نقلها إلى خوادم تكنولوجيا الإعلان.

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

التحقُّق من صحة حمولة الخروج

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

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

سنوفّر لتقنيات الإعلان واجهة برمجة تطبيقات JavaScript لضمان أن تجتاز حمولة البيانات الصادرة التي تنشئها في generateBid() عملية التحقق من النظام الأساسي:

validate(payload, schema)

إن واجهة برمجة تطبيقات JavaScript هذه مخصصة تمامًا للمتصلين لتحديد ما إذا كانت حمولة بيانات معينة ستجتاز عملية التحقق من النظام الأساسي. يجب إجراء عملية التحقق الفعلية في النظام الأساسي للحماية من الدوال الضارة والعاملة في generateBid().

كتم صوت حمولة الخروج

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

طريقة التشويش هي:

1. تحمِّل المنصة تعريف المخطط لحمولة المخرجات.
2. وسيتم اختيار% 1 من حمولات الخروج لأغراض التشويش.
3. إذا لم يتم اختيار حمولة بيانات مخرج، يتم الاحتفاظ بالقيمة الأصلية بالكامل.
4. إذا تم اختيار حمولة البيانات الصادرة، سيتم استبدال قيمة كل ميزة بقيمة عشوائية صالحة لنوع الميزة هذا (على سبيل المثال، إما 0 أو 1 لإحدى الميزات المنطقية).

إرسال حمولة البيانات المخارجة واستلامها وفك ترميزها لتدريب النموذج

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

تتوفّر التفاصيل حول تنسيق الأسلاك لجميع أنواع الميزات وحمولة الخروج نفسها على GitHub.

تحديد حجم حمولة البيانات الصادرة

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

طريقة تحديد الحجم هي:

1. في البداية، سندعم حمولتي خروج في generateBid():
   1. egressPayload: حمولة الخروج المحدود ذات الحجم التي وصفناها حتى الآن في هذا المستند. في البداية، سيكون حجم حمولة الخروج 0 بت (ما يعني أنه ستتم إزالتها دائمًا أثناء التحقق من الصحة).
   2. temporaryUnlimitedEgressPayload: حمولة مؤقت ذات حجم غير محدود لتجارب الحجم. تستخدم عملية تنسيق حمولة الخروج هذه وإنشائها ومعالجتها الآليات نفسها المستخدمة في egressPayload.
2. سيكون لكل من حمولات المَخرَج هذه ملف JSON للمخطط الخاص بها: egress_payload_schema.json وtemporary_egress_payload_schema.json.
3. نوفّر بروتوكول تجربة ومجموعة من المقاييس لتحديد فائدة النموذج في مختلف أحجام حمولة الخروج (على سبيل المثال، 5، 10، ... بت).
4. بناءً على نتائج التجربة، نحدد حجم حمولة الخروج من خلال المُفاضلات الصحيحة المتعلّقة بالخصوصية والفائدة.
5. نُعيِّن حجم egressPayload من 0 بت إلى الحجم الجديد.
6. بعد مرور فترة نقل محدّدة، سنزيل temporaryUnlimitedEgressPayload، ونترك egressPayload بحجمه الجديد فقط.

نبحث عن قيود تقنية إضافية لإدارة هذا التغيير (على سبيل المثال، تشفير egressPayload عند زيادة حجمه من 0 بت). وسيتم تضمين هذه التفاصيل، إلى جانب معلومات إضافية مثل بروتوكول التجربة وتوقيت التجربة وتوقيت إزالة temporaryUnlimitedEgressPayload، في تحديث لاحق.

تدابير حماية البيانات

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

1. سيتم تشويش كل من egressPayload وtemporaryUnlimitedEgressPayload.
2. لتضييق نطاق جمع البيانات وحمايتها، لن يتوفّر temporaryUnlimitedEgressPayload إلا خلال مدة تجارب الحجم، حيث سنحدِّد المقاس الصحيح للسمة egressPayload.

الأذونات

تحكُّم المستخدم

• يهدف الاقتراح إلى منح المستخدمين إذن الوصول إلى قائمة التطبيقات المثبّتة التي خزّنت "إشارة تطبيق محمية" واحدة على الأقل أو شريحة جمهور مخصَّصة.
• يمكن للمستخدمين حظر التطبيقات وإزالتها من هذه القائمة. يؤدي الحظر والإزالة إلى ما يلي:
  • يؤدي ذلك إلى محو جميع إشارات التطبيقات المحمية وشرائح الجمهور المخصّصة المرتبطة بالتطبيق.
  • تمنع التطبيقات من تخزين إشارات التطبيقات المحمية والجماهير المخصّصة الجديدة.
• يمكن للمستخدمين إعادة ضبط Protected App Signals وProtected Audience API بالكامل. وعند حدوث ذلك، سيتم محو أي إشارات تطبيقات محمية وجماهير مخصّصة حالية على الجهاز.
• يمكن للمستخدمين إيقاف "مبادرة حماية الخصوصية" بالكامل على Android، بما في ذلك Protected App Signals API وProtected Audience API. وفي هذه الحالة، تعرِض واجهات برمجة التطبيقات Protected Audience و"إشارات التطبيقات المحمية" رسالة استثناء عادية: SECURITY_EXCEPTION.

أذونات التطبيقات وعناصر التحكّم فيها

يهدف الاقتراح إلى منح التطبيقات إمكانية التحكّم في إشارات التطبيقات المحمية:

• يمكن للتطبيق إدارة عمليات الربط باستخدام "إشارات التطبيقات المحمية".
• يمكن أن يمنح التطبيق أذونات لمنصّات تكنولوجيا الإعلان التابعة لجهة خارجية من أجل إدارة إشارات التطبيقات المحمية نيابةً عنه.

التحكّم في منصّات تكنولوجيا الإعلان

يوضّح هذا الاقتراح طُرق تكنولوجيا الإعلان للتحكّم في إشارات التطبيقات المحمية:

• يجب أن تسجّل جميع تقنيات الإعلان في "مبادرة حماية الخصوصية" وأن توفّر نطاق "موقع إلكتروني" أو "مصدر" يتطابق مع جميع عناوين URL لـ "إشارات التطبيقات المحمية".
• يمكن لتكنولوجيا الإعلان عقد شراكة مع تطبيقات أو حِزم تطوير برامج (SDK) لتوفير رموز مميّزة لإثبات الملكية تُستخدَم للتحقّق من إنشاء "إشارات تطبيقات محمية". وعند تفويض هذه العملية إلى أحد الشركاء، يمكن ضبط ميزة إنشاء "إشارات تطبيقات محمية" بهدف الحصول على إقرار من خلال تكنولوجيا الإعلان.