الإعلانات المدمجة مع المحتوى على Android

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

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

يتم توفير إمكانية عرض إعلانات البانر في وقت تشغيل حزمة SDK من خلال واجهة برمجة التطبيقات SurfaceControlViewHost. يسمح هذا الإجراء لحزمة تطوير البرامج (SDK) بعرض واجهة المستخدم. من عملية "وقت تشغيل SDK" بدون التلاعب بها من خلال تطبيق العميل. استخدِم وضعَي SurfaceView Z فوق أو Z تحت لتحديد ما إذا كانت المساحة التي يتم فيها عرض واجهة مستخدم حزمة SDK أعلى أو أسفل نافذة العميل التطبيق. عند عرض إعلان باستخدام الوضع "ي" أعلاه، فإن حزمة تطوير البرامج (SDK) يتلقّى MotionEvents من تفاعل المستخدم، ولكن تطبيق العميل لا تظهر المشاهدات فوق الإعلان. عند عرض إعلان في الوضع "Z أسفل الشاشة"، يعرض التطبيق مشاهداته الخاصة فوق الإعلان، ولكن MotionEvents عند تفاعل المستخدِم مع الإعلان، يتم توجيهه إلى التطبيق وليس إلى حزمة SDK.

يمكن لحزمة SDK والناشر استخدام مكتبات privacysandbox.ui في Jetpack لإنشاء جلسة واجهة مستخدم والحفاظ عليها.

حاوية الإعلانات التي يملكها التطبيق

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

مخطّط بياني يوضّح كيفية تدفق البيانات بين الناشر وحزمة SDK
مسار التحكّم المقترَح في الإعلانات المدمجة مع المحتوى

إشعارات بشأن حالة الإعلان

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

بالإضافة إلى ذلك، سيتمكن الناشر من إضافة علامات محددة للعرض (سلاسل) إلى تمت إضافة كل عنصر ثانوي إلى NativeAdContainer، ويمكن استخدام هذه البيانات لإعلام حزمة SDK بذلك. مادة عرض الإعلان التي يتوافق معها كل عنصر ثانوي

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

الإقرارات

ستتوفّر الإقرارات التالية لحزمة تطوير البرامج (SDK) للحصول على إصدار أكثر فعالية ضمانات حول عرض الإعلان:

  1. إثبات سلامة الجهاز: استخدِم واجهات برمجة تطبيقات النظام الأساسي، مثل إثبات صحة المفتاح لتحديد سلامة الجهاز.
  2. APK Identity: استخدِم واجهات SdkSandbox API، مثل واجهات برمجة تطبيقات SdkSandboxController.getClientPackageName وPackageManager مثل requestChecksum للتحقق من هوية APK.
  3. VerifiedMotionEvents: في الإصدارات المستقبلية من Android، نستكشف إتاحة تطبيق العميل لنقل التركيز باللمس لجميع إيماءات المستخدم على الأجزاء التي تملكها حزمة SDK من هذا الإعلان المدمج كي تتعامل معها حزمة SDK. يمكن تحويل MotionEvents إلى VerifiedMotionEvents باستخدام واجهات برمجة تطبيقات النظام. يمكن أن يعرض حِزم تطوير البرامج (SDK) واجهة المستخدم الخاصة بها استجابةً لتفاعل المستخدم إذا اختَر ذلك.

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

ندعوك إلى الاطّلاع على الملاحظات بشأن النقاط التالية:

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