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

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

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

قابلیت‌ها

هدف این طراحی پشتیبانی از 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های اندازه‌گیری در زمان اجرای SDK (پیاده‌سازی‌های OMID و MRAID ) می‌توانند این ناظر را به جلسه‌ی رابط کاربری متصل کنند، به طوری که این اطلاعات مستقیماً برای آنها ارسال شود. شرکای اندازه‌گیری می‌توانند اطلاعات به دست آمده از کتابخانه‌های رابط کاربری را با داده‌های مربوط به محتوای موجود (مانند استفاده از اسکریپت‌های اندازه‌گیری تزریق شده در تبلیغ خلاقانه) ترکیب کنند تا رویدادهای قابلیت مشاهده‌ی جاوا اسکریپت را تولید کنند.

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

رابط برنامه‌نویسی کاربردی

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

• SessionObserver : معمولاً توسط SDK اندازه‌گیری پیاده‌سازی می‌شود و به جلسه‌ای که توسط SDK از طریق privacysandbox.ui برگردانده می‌شود، متصل می‌شود. این رابط همچنین SDK اندازه‌گیری را قادر می‌سازد تا دسته‌های خاصی از سیگنال‌های قابلیت مشاهده را انتخاب کند. این به نوبه خود، کتابخانه کلاینت UI را قادر می‌سازد تا فقط سیگنال‌هایی را که ناظر به آنها علاقه‌مند است جمع‌آوری کند، که برای سلامت کلی سیستم بهتر است.
• registerObserver() : این متد که به کلاس Session اضافه شده است، به هر کسی که به Session دسترسی دارد اجازه می‌دهد تا یک ناظر (Observer) ثبت کند. اگر ناظر پس از باز شدن UI Session ثبت شود، AdContainerInfo ذخیره شده بلافاصله برای او ارسال می‌شود. اگر قبل از باز شدن Session ثبت شود، AdContainerInfo هنگام باز شدن Session برای او ارسال می‌شود.
• AdContainerInfo : کلاسی با getterهایی که به ناظر امکان می‌دهد اطلاعات مربوط به کانتینر تبلیغاتی فقط خواندنی را برای انواع داده‌های ذکر شده در بخش capabilites در بالا دریافت کند. مقادیر برگشتی از این getterها، در صورت امکان، با مقادیر برگشتی parcelable از getterهای موجود در 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 در سطح سطح کار می‌کند و می‌تواند با مشخص کردن حداقل آستانه‌ها برای نمایش، مانند درصد پیکسل‌های قابل مشاهده، زمان روی صفحه یا مقیاس، به ایجاد ادعاهایی در مورد سطح حاوی رابط کاربری تبلیغ کمک کند. این داده‌ها را می‌توان با داده‌های قابلیت مشاهده ارائه شده توسط کتابخانه کلاینت UI، که در بالا توضیح داده شد، بررسی کرد. از آنجایی که داده‌های ارائه شده توسط چارچوب قابل اعتمادتر هستند، هر رویدادی از کتابخانه UI که داده‌های آن با داده‌های چارچوب مطابقت ندارد، می‌تواند نادیده گرفته شود. به عنوان مثال، اگر شنونده ارائه شده به setTrustedPresentationCallback با اعلانی مبنی بر اینکه هیچ پیکسلی از رابط کاربری تبلیغ روی صفحه نمایش داده نمی‌شود، فراخوانی شود و کتابخانه UI کلاینت تعداد پیکسل‌های غیر صفر را روی صفحه نشان دهد، داده‌های دومی می‌توانند نادیده گرفته شوند.

سوالات باز

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