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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

إذا لم يسجّل المشتري برنامج ترميز الإشارات، لن تكون الإشارات جاهزة، ولا يتم إرسال أيٍّ من الإشارات المنظّمة على الجهاز فقط إلى "عروض الأسعار والمزاد"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

مؤسسة UDF prepareDataForAdRetrieval()

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

يحصل prepareDataForAdRetrieval() على المعلومات التالية:

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

تنفِّذ ميزة "prepareDataForAdRetrieval()" إجراءَين:

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

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

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

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

مؤسسة UDF getCandidateAds()

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

يحصل getCandidateAds() على المعلومات التالية:

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

تنفِّذ ميزة "getCandidateAds()" ما يلي:

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

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

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

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

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

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

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

مؤسسة UDF generateBid()

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

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

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

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

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

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

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

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

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

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

من الناحية الفنية، الطريقة التي يعمل بها هي:

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

تحديد مخطط الأحمال الصادرة

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

وسنوفّر ملف 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 -- سيتم تضمينها في تحديث لاحق.

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

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

1. تحديد بنية النماذج التي سيتم استخدامها مع "التطبيقات المحمية" الإشارات. على سبيل المثال، سيحتاج إلى تحديد ما إذا كان سيقوم استخدام تحليل النماذج إلى العوامل.
2. تحديد مقياس لقياس جودة النموذج. المقاييس المقترَحة هي انخفاض نسبة AUC وخسارة السجل.
3. حدد مجموعة الميزات التي سيستخدمها خلال تدريب النموذج.
4. وباستخدام بنية النموذج ومقياس الجودة ومجموعة ميزات التدريب، تشغيل دراسات الاستحلاب لتحديد الأداة المساعدة التي ساهمت بها كل بت لكل بت والنموذج الذي يريد استخدامه في PAS. البروتوكول المقترح لدراسة الإزالة :
   1. تدريب النموذج باستخدام جميع الميزات وقياس الفائدة؛ هذا هو المتوقع للمقارنة.
   2. لكل خاصية مستخدمة لإنتاج المتوقع، تدرب على النموذج مع جميع ميزات باستثناء هذه الميزة.
   3. قياس الأداة المساعدة الناتجة. اقسِم الدلتا على حجم العنصر. بالبت؛ هو الأداة المتوقعة لكل بت لهذه الميزة.
5. تحديد أحجام حمولة التدريب المهمة لإجراء التجارب. أر الاقتراح [5, 10, 15, ..., size_of_all_training_features_for_baseline] بت. يمثل كل من هذه القيم حجمًا محتملاً لـ egressPayload والذي تقييم التجربة.
6. لكل حجم ممكن، حدد مجموعة من الميزات أقل من أو تساوي ذلك الحجم الذي يزيد من الفائدة لكل بت، باستخدام نتائج دراسة الاستنساخ.
7. تدريب نموذج لكل حجم ممكن وتقييم فائدته باعتبارها النسبة المئوية لفائدة النموذج الأساسي المُدرَّب على جميع الميزات.
8. ارسم النتائج على رسم بياني حيث المحور س هو حجم التطبيق والحمولة بوحدات البت، والمحور ص هو النسبة المئوية للإيرادات الناتجة عن هذا النموذج مقارنة بخط الأساس.

بعد ذلك، يمكن لتقنيات الإعلان تكرار الخطوات من 5 إلى 8 في تجارب الزيارات المباشرة، وذلك باستخدام البيانات المُرسَلة عبر temporaryUnlimitedEgressPayload. يمكن لتقنيات الإعلان اختيار مشاركة نتائج تجاربهم المتعلقة بالزيارات في الوقت الفعلي وخارجه من خلال "مبادرة حماية الخصوصية" للإبلاغ عن القرار بشأن حجم egressPayload.

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

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

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

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

الأذونات

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

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

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

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

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

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

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

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