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

bookmark_border تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

مساحة التخزين المتوفّرة وإخلاء المساحة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تجزئة النموذج

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

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

يتيح ذلك التصميم التالي:

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

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

دالة UDF الخاصة بـ prepareDataForAdRetrieval()

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

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

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

تؤدي prepareDataForAdRetrieval() عملتَين:

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

prepareDataForAdRetrieval() المرتجعات:

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

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

دالة UDF الخاصة بـ getCandidateAds()

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

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

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

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

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

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

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

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

getCandidateAds() المرتجعات:

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

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

دالة UDF الخاصة بـ generateBid()

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

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

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

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

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

generateBid() المرتجعات:

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

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

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

ميزة

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

الاستنتاج

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

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

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

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

تنفيذ تجزئة النموذج

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تحديد مخطّط حِزم البيانات الخارجة

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

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

على سبيل المثال، ستبدو حمولة الخروج التي تتألف من سمة منطقية واحدة followed by a bucket feature of size two بالشكل التالي:

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

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

إنشاء حِزم بيانات الخروج في generateBid()

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

هناك بديل لهذا التصميم وهو أن يتم احتساب متجه الخروج في 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.

الأذونات

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

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

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

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

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

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

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

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