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

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

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

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

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

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

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

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

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

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

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

الإشارة هي تمثيل لتفاعلات المستخدمين المختلفة في أحد التطبيقات، والتي تحدّدها تكنولوجيات الإعلان على أنّها مفيدة لعرض إعلانات ذات صلة. قد يخزِّن تطبيق أو حزمة 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" والتي تم إنشاؤها بواسطة تطبيقَين مختلفَين

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

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

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

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

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

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

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

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

• ‫put: لإدراج قيمة عددية أو إلغاء قيمة عددية للمفتاح المحدّد
• ‫put_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) "الموقع الإلكتروني"/"المصدر" مع بيانات تكنولوجيا الإعلان المسجّلة. وفي حال لم تكن تكنولوجيا الإعلان التي تقدّم الطلب مسجّلة، سيتم رفض الطلب.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • ‫auction_config.seller_signals (بالنسبة إلى إشارات البائع

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

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

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

بشكل عام، تستخدم منطق المشتري المخصّص بيانات سياقية يقدّمها الناشر وProtected App Signals لاختيار عرض سعر وتطبيقه على الإعلانات ذات الصلة بطلب الإعلان. تتيح المنصة للمشترين تضييق نطاق مجموعة كبيرة من الإعلانات المتاحة لتشمل الإعلانات الأكثر صلة (أفضل k)، والتي يتم احتساب عروض الأسعار لها قبل إرجاع الإعلانات إلى البائع لاختيارها نهائيًا.

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

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

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

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

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

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

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

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

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

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

وهذا يتيح إمكانية التصميم التالي:

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

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

دالة prepareDataForAdRetrieval() المعرَّفة من قِبل المستخدم

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

تتلقّى prepareDataForAdRetrieval() المعلومات التالية:

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

prepareDataForAdRetrieval() يؤدي وظيفتَين:

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

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

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

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

دالة getCandidateAds() المعرَّفة من قِبل المستخدم

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

تتلقّى getCandidateAds() المعلومات التالية:

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

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

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

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

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

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

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

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

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

دالة generateBid() المعرَّفة من قِبل المستخدم

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

تتلقّى generateBid() المعلومات التالية:

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

تنفّذ generateBid() للمشتري ثلاثة إجراءات:

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

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

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

يُرجى العِلم أنّ generateBid() المستخدَم في "إعلانات تثبيت التطبيقات" يختلف عن generateBid() المستخدَم في "إعلانات تجديد النشاط التسويقي".

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

Featurization

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

الاستنتاج

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ولكي تفرض المنصة متطلبات الخصوصية المتطورة، يجب أن تكون حمولات الخروج منظَّمة بطريقة يمكن للمنصة فهمها. ستحدّد تكنولوجيات الإعلان بنية حمولات الخروج من خلال توفير ملف 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() "البيانات المحدّدة من المستخدم" الخاصة به. بعد تحويل هذه البيانات إلى ميزات، تنشئ تكنولوجيات الإعلان حمولتها بتنسيق JSON. سيتم تضمين حمولة الخروج هذه في تقرير الفوز الخاص بالمشتري ليتم إرسالها إلى خوادم تكنولوجيا الإعلان.

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

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

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

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

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

validate(payload, schema)

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

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

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

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

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

إجراءات حماية البيانات

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

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

الأذونات

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

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

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

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

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

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

يقدّم هذا الاقتراح طرقًا تتيح لتقنيات الإعلان التحكّم في إشارات Protected App Signals:

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