اقتراح تصميم إمكانية العرض في وقت تشغيل حزمة تطوير البرامج (SDK)

لا يمكن لحِزم SDK لعرض الإعلانات في "وقت تشغيل SDK" الوصول إلى بنية العرض الهرمي للناشر. بدلاً من ذلك، تحتوي حِزم SDK في وقت التشغيل على طرق العرض الخاصة بها. لا يمكن لحزمة SDK استخدام واجهات برمجة التطبيقات نفسها الخاصة بـ View التي تستخدمها خارج وقت تشغيل حزمة SDK لتحديد ما إذا كان الإعلان مرئيًا للمستخدم، لأنّ طريقة عرض الإعلان غير مرتبطة بنافذة التطبيق. ويشمل ذلك واجهات برمجة التطبيقات الخاصة بعرض Android، مثل getLocationOnScreen أو getLocationInWindow أو getVisibility، التي لا تعرض القيم المتوقّعة.

يُعدّ توفير إمكانية قياس إمكانية عرض الإعلانات من المتطلبات الأساسية لوقت تشغيل حزمة SDK. يهدف اقتراح التصميم هذا إلى توفير إمكانية استخدام Open Measurement وخدمات قياس مشابهة. قد تنطبق الحلول الموضّحة هنا أيضًا على واجهات برمجة التطبيقات Attribution Reporting API.

الإمكانات

يهدف هذا التصميم إلى مساعدة حِزم تطوير البرامج (SDK) للإعلانات أو شركاء القياس في احتساب بيانات إمكانية العرض التالية (الأسماء مؤقتة وقابلة للتغيير):

صورة توضيحية تعرض كيفية عمل مكوّنات إمكانية رؤية SDK Runtime معًا
نظرة عامة على إمكانية رؤية "وقت تشغيل حزمة تطوير البرامج" (SDK).
  • viewport [Rect]: تمثّل هذه السمة هندسة شاشة الجهاز أو نافذة التطبيق، وذلك حسب إمكانات النظام الأساسي.
  • استبدِل uiContainerGeometry [Rect] بهندسة SandboxedSdkView التي يتم عرضها.
  • alpha [float]: مستوى عتامة SandboxedSdkView الذي يتم عرضه
  • onScreenGeometry [Rect]: المجموعة الفرعية من uiContainerGeometry التي لا يتم اقتطاعها بواسطة طرق العرض الرئيسية، حتى viewport ضِمنًا
  • occludedGeometry [Rect]: أجزاء onScreenGeometry التي تحجبها أي طرق عرض في التسلسل الهرمي للتطبيق تتضمّن Rect لكل عملية حجب، بما يتوافق مع صفر أو عرض واحد أو أكثر من عروض التطبيقات التي تتقاطع مع SandboxedSdkView onScreenGeometry

المتطلبات

  • يتم التعبير عن قيم uiContainerGeometry وonScreenGeometry وoccludedGeometry في مساحة الإحداثيات الخاصة بـ viewport.
  • يتم إعداد تقارير عن تغيير مستوى الظهور بأقل وقت استجابة ممكن.
  • يمكن قياس مستوى الظهور لدورة حياة مشاهدة الإعلان بالكامل، بدءًا من ظهوره الأول وحتى ظهوره الأخير.

اقتراح تصميم

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

التحكّم في التدفق لإمكانية العرض
التحكّم في تدفّق البيانات لإمكانية العرض:

تستمع مكتبة البرامج إلى التغييرات في واجهة مستخدم الإعلان من خلال أدوات معالجة الأحداث، مثل ViewTreeObserver. عندما تحدّد أنّ واجهة مستخدم الإعلان قد تغيّرت بطريقة قد تؤثّر في قياس إمكانية العرض، يتحقّق برنامج مكتبة العميل من وقت إرسال آخر إشعار إلى المراقب. إذا كان آخر تعديل أكبر من مدة الاستجابة المسموح بها (يمكن ضبطها من خلال حزمة تطوير البرامج (SDK)، بحد أدنى 200 ملي ثانية على الأجهزة الجوّالة)، يتم إنشاء عنصر AdContainerInfo جديد ويتم إرسال إشعار إلى المراقب. ويُعدّ هذا النموذج المستنِد إلى الأحداث أفضل لصحة النظام من عملية الاقتراع التي تنفّذها معظم عمليات تنفيذ OMID على Android اليوم.

واجهة برمجة التطبيقات

ستتم إضافة ما يلي إلى مكتبة privacysandbox.ui.core:

  • SessionObserver: يتم تنفيذها عادةً من خلال حزمة SDK لقياس الأداء، ويتم إرفاقها بالجلسة التي تعرضها حزمة SDK من خلال privacysandbox.ui. ستتيح هذه الواجهة أيضًا لحزمة SDK الخاصة بالقياس الموافقة على فئات معيّنة من إشارات إمكانية العرض. ويتيح ذلك لمكتبة برامج واجهة المستخدم جمع الإشارات التي يهتم بها المراقب فقط، ما يحسّن حالة النظام بشكل عام.
  • registerObserver(): عند إضافة هذه الطريقة إلى صف Session، يمكن لأي شخص لديه إذن الوصول إلى الجلسة تسجيل مراقب. إذا تم تسجيل المراقب بعد فتح جلسة واجهة المستخدم، سيتم إرسال AdContainerInfo المخزّن مؤقتًا إليه على الفور. إذا تم التسجيل قبل فتح الجلسة، سيتم إرسال AdContainerInfo عند فتح الجلسة.
  • AdContainerInfo: فئة تتضمّن دوال جلب تتيح للمراقب الحصول على معلومات حاوية الإعلان للقراءة فقط لأنواع البيانات المدرَجة في قسم الإمكانات أعلاه. ستتطابق القيم المعروضة من دوال الجلب هذه، حيثما أمكن، مع القيم المعروضة القابلة للتسلسل من دوال الجلب الحالية في View وفئاته الفرعية. إذا تم إنشاء حاوية الإعلان باستخدام Jetpack Compose، سيؤدي ذلك إلى عرض الخصائص الدلالية للحاوية. يمكن استخدام هذه الفئة لاحتساب أحداث MRAID وOMID ذات الصلة بإمكانية العرض.
  • SessionObserverotifyAdContainerChanged(): يُستخدَم لإرسال إشعار إلى المراقب عندما تتغيّر إمكانية العرض. ويتم تمرير عنصر AdContainerInfo. يتم تنفيذ هذا الإجراء عند رصد أحداث تؤثّر في أنواع البيانات المُدرَجة في قسم "الإمكانات". ملاحظة: قد يتم استدعاء هذه الطريقة بالإضافة إلى طرق أخرى في Session. على سبيل المثال، يتم استدعاء Session.notifyResized() لطلب تغيير حجم الإعلان في حزمة SDK، ويتم أيضًا استدعاء SessionObserver.notifyAdContainerChanged() عند حدوث ذلك.
  • SessionObserverotifySessionClosed(): لإعلام المراقب بأنّه تم إغلاق الجلسة.

التحسينات المستقبلية

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

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

الأسئلة المفتوحة

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