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

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

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

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

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

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

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

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

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

الإشارة هي تمثيل لمختلف تفاعلات المستخدمين في أحد التطبيقات، والتي تحدّدها تكنولوجيا الإعلان على أنّها مفيدة لعرض إعلانات ذات صلة. قد يخزّن تطبيق أو حزمة 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 إلى دعم تكنولوجيا الإعلان هذه من خلال توفير حلول مرنة لإدارة إشارات Protected App Signal، وذلك من خلال السماح لبرامج الاتصال على الجهاز بإنشاء إشارات Protected App Signal نيابةً عن المشترين. تُعرف هذه العملية باسم التفويض، وهي تستخدم واجهة برمجة التطبيقات 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) "site"/"origin" مع بيانات تكنولوجيا الإعلان المسجّلة. وفي حال عدم تسجيل تكنولوجيا الإعلان التي يتم إرسال الطلب منها، سيتم رفض الطلب.

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

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

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

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

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

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

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

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

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

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

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

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 إعلان وحساب عروض أسعارها.

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

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

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

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

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

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

تتضمّن عملية تنفيذ generateBid() من جانب المشتري ثلاث خطوات:

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

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

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

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

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

Featurization

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

الاستنتاج

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

يمكن للعملاء تقديم عدد من نماذج تعلُّم الآلة مع تنفيذها generateBid(). سنوفّر أيضًا JavaScript API ضمن 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()، الذي يطلب من المنصة إرسال تقارير البائع والمشتري).

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

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

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

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

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. ارسم النتائج على رسم بياني يكون فيه المحور الأفقي هو حجم حمولة التدريب بالبتات، والمحور العمودي هو النسبة المئوية للأرباح التي حقّقها هذا النموذج مقارنةً بالأساس.

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

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

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

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

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

الأذونات

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

• يهدف الاقتراح إلى إتاحة قائمة التطبيقات المثبَّتة التي خزّنت إشارة واحدة على الأقل من إشارات 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 لتتطلّب إقرارًا من تكنولوجيا الإعلان.