پیشنهاد طراحی قابلیت مشاهده SDK Runtime

SDK های تبلیغات در زمان اجرا SDK نمی توانند به سلسله مراتب مشاهده ناشر دسترسی داشته باشند. در عوض، SDK ها در Runtime دیدگاه های خاص خود را دارند. SDK نمی‌تواند از همان View APIهایی که در خارج از زمان اجرا SDK استفاده می‌کند برای تعیین اینکه آیا تبلیغ برای کاربر قابل مشاهده است استفاده کند، زیرا نمای تبلیغ به پنجره برنامه متصل نیست. این شامل APIهای Android View مانند getLocationOnScreen ، getLocationInWindow ، یا getVisibility است که مقادیر مورد انتظار را برمی‌گردانند.

پشتیبانی از اندازه‌گیری قابلیت مشاهده آگهی‌ها یک نیاز اصلی زمان اجرا SDK است. هدف این طرح پیشنهادی دستیابی به پشتیبانی از Open Measurement و خدمات اندازه گیری مشابه است. راه‌حل‌های مورد بحث در اینجا ممکن است برای APIهای Attribution Reporting نیز قابل اجرا باشند. بازخورد شما در مورد این پیشنهاد تشویق می شود.

توانایی ها

هدف این طراحی پشتیبانی از SDKهای تبلیغاتی یا شرکای اندازه‌گیری برای محاسبه داده‌های قابلیت مشاهده زیر است (نام‌ها موقتی هستند و ممکن است تغییر کنند):

تصویری که نشان می‌دهد چگونه اجزای قابلیت نمایش در زمان اجرا SDK با هم کار می‌کنند
نمای کلی از قابلیت مشاهده در زمان اجرا SDK.
  • viewport [Rect] : نمایانگر صفحه دستگاه یا هندسه پنجره برنامه، بسته به قابلیت های پلت فرم است.
  • uiContainerGeometry [Rect] : هندسه SandboxedSdkView در حال ارائه.
  • alpha [float] : کدورت SandboxedSdkView در حال ارائه.
  • onScreenGeometry [Rect] : زیرمجموعه uiContainerGeometry که توسط نماهای والد، تا و از جمله viewport ، بریده نمی شود.
  • occludedGeometry [Rect] : بخش‌هایی از onScreenGeometry که توسط هر گونه نما در سلسله مراتب برنامه مسدود می‌شوند. شامل یک Rect برای هر انسداد، مربوط به صفر، یک یا چند نمای برنامه است که با SandboxedSdkView onScreenGeometry تلاقی می کند.

الزامات

  • مقادیر uiContainerGeometry ، onScreenGeometry و occludedGeometry در فضای مختصات viewport بیان می شوند.
  • گزارش تغییر دید با حداقل تأخیر رخ می دهد.
  • قابلیت مشاهده برای چرخه عمر کامل نمای تبلیغ، از اولین ظاهر تا آخرین آن، قابل اندازه گیری است.

طرح پیشنهادی

این پیشنهاد بر اساس نحوه عملکرد ارائه UI با استفاده از کتابخانه های UI مشتری و ارائه دهنده است. ما کتابخانه‌های رابط کاربری را گسترش می‌دهیم تا به SDK اجازه دهیم یک یا چند ناظر جلسه UI را ثبت کند. هر زمان که رویدادهای مرتبطی که انواع داده‌ها را در بخش قابلیت‌ها تغییر می‌دهند، مشاهده‌گر اطلاعات قابلیت مشاهده را دریافت می‌کند. اندازه‌گیری SDK در زمان اجرا SDK (پیاده‌سازی‌های OMID و MRAID ) می‌توانند این ناظر را به جلسه رابط کاربری متصل کنند تا این اطلاعات مستقیماً برای آنها ارسال شود. شرکای اندازه‌گیری می‌توانند اطلاعات به‌دست‌آمده از کتابخانه‌های رابط کاربری را با داده‌های مربوط به محتوایی که از قبل در دسترس است (مانند هنگام استفاده از اسکریپت‌های اندازه‌گیری تزریق شده در آگهی تبلیغاتی) ترکیب کنند تا رویدادهای قابلیت مشاهده جاوا اسکریپت را ایجاد کنند.

کنترل جریان برای قابلیت مشاهده
کنترل جریان برای قابلیت مشاهده

کتابخانه مشتری از طریق شنوندگان رویداد مانند ViewTreeObserver به تغییرات در رابط کاربری تبلیغات گوش می دهد. هرگاه تشخیص داد که رابط کاربری تبلیغات به گونه‌ای تغییر کرده است که ممکن است بر اندازه‌گیری قابلیت نمایش تأثیر بگذارد، کتابخانه مشتری بررسی می‌کند که آخرین اعلان برای مشاهده‌گر چه زمانی ارسال شده است. اگر آخرین به‌روزرسانی بیشتر از تأخیر مجاز باشد (قابل تنظیم توسط SDK، تا حداقل 200 میلی‌ثانیه در تلفن همراه)، یک شی AdContainerInfo جدید ایجاد می‌شود و یک اعلان به ناظر ارسال می‌شود. این مدل مبتنی بر رویداد برای سلامت سیستم بهتر از نظرسنجی انجام شده توسط اکثر پیاده سازی های OMID در اندروید امروز است.

API

موارد زیر به کتابخانه privacysandbox.ui.core اضافه خواهد شد:

  • SessionObserver : معمولاً توسط اندازه‌گیری SDK که به جلسه بازگردانده شده توسط SDK از طریق privacysandbox.ui پیوست می‌شود، پیاده‌سازی می‌شود. این رابط همچنین SDK اندازه‌گیری را قادر می‌سازد تا دسته‌های خاصی از سیگنال‌های قابلیت مشاهده را انتخاب کند. این به نوبه خود، کتابخانه مشتری UI را قادر می‌سازد تا سیگنال‌هایی را که مشاهده‌گر به آنها علاقه دارد جمع‌آوری کند، که برای سلامت کلی سیستم بهتر است.
  • registerObserver() : این متد که به کلاس Session اضافه شده است، به هر کسی که به Session دسترسی دارد اجازه می دهد تا یک مشاهده گر را ثبت کند. اگر ناظر پس از باز شدن جلسه رابط کاربری ثبت شود، بلافاصله AdContainerInfo ذخیره شده برای او ارسال می شود. اگر قبل از باز شدن جلسه ثبت نام کرده باشید، پس از باز شدن جلسه AdContainerInfo برای آنها ارسال می شود.
  • AdContainerInfo : کلاسی با دریافت‌کننده‌ها که به مشاهده‌گر امکان می‌دهد اطلاعات محفظه آگهی فقط خواندنی را برای انواع داده‌های فهرست‌شده در بخش قابلیت‌های بالا به‌دست آورد. مقادیر بازگشتی از این دریافت‌کننده‌ها، تا جایی که ممکن باشد، با مقادیر بازگشتی قابل تقسیم از دریافت‌کننده‌های موجود در View و زیر کلاس‌های آن مطابقت دارد. اگر ظرف تبلیغات با استفاده از Jetpack Compose ایجاد شده باشد، این ویژگی های معنایی ظرف را آشکار می کند. از این کلاس می توان برای محاسبه رویدادهای MRAID و OMID مربوط به قابلیت مشاهده استفاده کرد.
  • SessionObserverotifyAdContainerChanged() : برای اطلاع دادن به ناظر در زمان تغییر قابلیت مشاهده استفاده می شود. یک شی AdContainerInfo ارسال می کند. هنگامی که رویدادهایی شناسایی می شوند که بر انواع داده های فهرست شده در بخش قابلیت ها تأثیر می گذارند، این نام خوانده می شود. توجه: این متد ممکن است علاوه بر متدهای روی Session فراخوانی شود. به عنوان مثال، Session.notifyResized() فراخوانی می شود تا از SDK درخواست تغییر اندازه تبلیغ کند، و SessionObserver.notifyAdContainerChanged() نیز زمانی که این اتفاق می افتد فراخوانی می شود.
  • SessionObserverotifySessionClosed() : به ناظر اطلاع می دهد که جلسه بسته شده است.

پیشرفت های آینده

هر کدی که در فرآیند برنامه اجرا می شود، از جمله کدهای کتابخانه privacysandbox.ui.client، در صورت در معرض خطر قرار گرفتن برنامه قابل تغییر است. بنابراین، هر منطق جمع آوری سیگنال که در فرآیند برنامه اجرا می شود، مستعد دستکاری کد برنامه است. این همچنین برای کد SDK که قبل از در دسترس بودن Privacy Sandbox که در فرآیند برنامه اجرا می‌شود، اعمال می‌شود. در نتیجه، جمع آوری سیگنال توسط کتابخانه UI وضعیت امنیتی را بدتر نمی کند.

علاوه بر این، کد در زمان اجرا SDK می‌تواند از یک API پلتفرم به نام setTrustedPresentationCallback استفاده کند که می‌تواند تضمین‌های قوی‌تری از چارچوب در مورد ارائه رابط کاربری تبلیغات به آن بدهد. setTrustedPresentationCallback در سطح Surface کار می‌کند و می‌تواند با تعیین حداقل آستانه برای ارائه، مانند درصد پیکسل‌های قابل مشاهده، زمان روی صفحه یا مقیاس، به اظهارنظر درباره Surface حاوی رابط کاربری تبلیغات کمک کند. این داده‌ها را می‌توان با داده‌های قابلیت مشاهده ارائه شده توسط کتابخانه مشتری UI، که در بالا توضیح داده شد، بررسی کرد. از آنجایی که داده‌های ارائه‌شده توسط چارچوب قابل اعتمادتر هستند، هر رویدادی از کتابخانه UI که داده‌های آن با داده‌های چارچوب مطابقت ندارد، می‌تواند نادیده گرفته شود. به عنوان مثال، اگر شنونده ارائه شده به setTrustedPresentationCallback با اعلانی فراخوانی شود که هیچ پیکسلی از رابط کاربری تبلیغات روی صفحه نمایش داده نمی شود، و کتابخانه UI مشتری تعداد پیکسل های غیر صفر را روی صفحه نمایش دهد، داده های دومی می تواند نشان داده شود. دور انداخته شد.

سوالات باز

ما از نظرات خود در مورد نکات زیر دعوت می کنیم:

  1. به چه سیگنال های قابلیت مشاهده علاقه مند هستید که در این توضیح دهنده ذکر نشده اند؟
  2. پیشنهاد فعلی به‌روزرسانی قابلیت مشاهده کمتر از هر 200 میلی‌ثانیه است، مشروط بر اینکه تغییری مرتبط در رابط کاربری ایجاد شود. آیا این فرکانس برای شما قابل قبول است؟ اگر نه، چه فرکانسی را ترجیح می دهید؟
  3. آیا ترجیح می‌دهید اطلاعات مربوط به setTrustedPresentationCallback را خودتان تجزیه و تحلیل کنید یا کتابخانه UI ارائه‌دهنده داده‌ها را از کتابخانه UI مشتری حذف کند، در صورتی که با داده‌های setTrustedPresentationCallback مطابقت ندارد؟
  4. چگونه سیگنال های قابلیت مشاهده را مصرف می کنید؟ با ارسال بازخوردی که به این سوالات پاسخ می دهد، به ما کمک کنید موارد استفاده خود را درک کنیم.