Предложение по дизайну видимости во время выполнения SDK

Рекламные SDK в среде выполнения SDK не имеют доступа к иерархии представлений издателя. Вместо этого SDK в среде выполнения имеют свои собственные представления. SDK не может использовать те же API просмотра, которые используются вне среды выполнения SDK, чтобы определить, видно ли объявление пользователю, поскольку представление объявления не прикреплено к окну приложения. Сюда входят API-интерфейсы Android View, такие как getLocationOnScreen , getLocationInWindow или getVisibility , которые не возвращают ожидаемые значения.

Поддержка измерения видимости рекламы является основным требованием среды выполнения SDK . Это проектное предложение направлено на обеспечение поддержки Open Measurement и аналогичных сервисов измерения. Решения, обсуждаемые здесь, также могут быть применимы к API отчетов по атрибуции . Ваши отзывы по этому предложению приветствуются.

Возможности

Целью этого проекта является поддержка рекламных 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 .
  • Отчеты об изменении видимости происходят с минимальной задержкой.
  • Видимость можно измерить на протяжении всего жизненного цикла просмотра объявления, от его первого появления до последнего.

Проектное предложение

Это предложение основано на том, как работает представление пользовательского интерфейса с использованием библиотек пользовательского интерфейса клиента и поставщика. Мы расширим библиотеки пользовательского интерфейса, чтобы SDK мог регистрировать одного или нескольких наблюдателей сеанса пользовательского интерфейса. Наблюдатель будет получать информацию о видимости всякий раз, когда будут обнаружены соответствующие события, которые изменяют типы данных в разделе возможностей . SDK измерений в среде выполнения SDK (реализации OMID и MRAID ) могут прикрепить этого наблюдателя к сеансу пользовательского интерфейса, чтобы эту информацию можно было отправлять им напрямую. Партнеры по измерению могут объединять информацию, полученную из библиотек пользовательского интерфейса, с данными об уже доступном контенте (например, при использовании сценариев измерения, внедренных в рекламное объявление), чтобы генерировать события видимости JavaScript.

Последовательность действий для обеспечения видимости.
Последовательность действий для обеспечения видимости.

Клиентская библиотека прослушивает изменения в пользовательском интерфейсе рекламы через прослушиватели событий, такие как ViewTreeObserver . Всякий раз, когда клиентская библиотека определяет, что пользовательский интерфейс объявления изменился таким образом, что это может повлиять на измерение видимости, она проверяет, когда наблюдателю было отправлено последнее уведомление. Если последнее обновление превышает допустимую задержку (настраиваемую с помощью SDK, минимум до 200 мс на мобильных устройствах), создается новый объект AdContainerInfo и наблюдателю отправляется уведомление. Эта модель, основанная на событиях, лучше влияет на работоспособность системы, чем опрос, выполняемый большинством современных реализаций OMID на Android.

API

В библиотеку Privacysandbox.ui.core будет добавлено следующее:

  • SessionObserver : обычно реализуется SDK для измерения, прикрепляется к сеансу, возвращаемому SDK через файл Privacysandbox.ui. Этот интерфейс также позволит SDK для измерения включать определенные категории сигналов видимости. Это, в свою очередь, позволяет клиентской библиотеке пользовательского интерфейса собирать только те сигналы, которые интересуют наблюдателя, что лучше для общего состояния системы.
  • registerObserver() : добавленный в класс Session , этот метод позволяет любому, у кого есть доступ к сеансу, зарегистрировать наблюдателя. Если наблюдатель зарегистрирован после открытия сеанса пользовательского интерфейса, ему сразу же будет отправлена ​​кэшированная AdContainerInfo . Если они зарегистрированы до открытия сеанса, им будет отправлена AdContainerInfo при открытии сеанса.
  • AdContainerInfo : класс с методами получения, который позволяет наблюдателю получать доступную только для чтения информацию о рекламном контейнере для типов данных, перечисленных в разделе возможностей выше. Возвращаемые значения этих геттеров будут соответствовать, где это возможно, возвращаемым значениям существующих геттеров View и его подклассов. Если рекламный контейнер был создан с помощью Jetpack Compose, это раскрывает семантические свойства контейнера. Этот класс можно использовать для вычисления событий MRAID и OMID, связанных с видимостью.
  • SessionObserverotifyAdContainerChanged() : используется для уведомления наблюдателя при изменении видимости. Он передает объект AdContainerInfo . Это вызывается всякий раз, когда обнаруживаются события, влияющие на типы данных, перечисленные в разделе «Возможности». Примечание. Этот метод можно вызывать в дополнение к методам сеанса. Например, Session.notifyResized() вызывается, чтобы запросить SDK изменить размер объявления, а SessionObserver.notifyAdContainerChanged() также вызывается, когда это происходит.
  • SessionObserverotifySessionClosed() : уведомляет наблюдателя о закрытии сеанса.

Будущие улучшения

Любой код, выполняющийся в процессе приложения, включая код из библиотеки Privacysandbox.ui.client, может быть изменен, если приложение скомпрометировано. Таким образом, любая логика сбора сигналов, выполняющаяся в процессе приложения, подвержена вмешательству со стороны кода приложения. Это также относится к коду SDK, развернутому до доступности Privacy Sandbox, который запускается в процессе приложения. Следовательно, сбор сигналов библиотекой пользовательского интерфейса не ухудшает ситуацию с безопасностью.

Кроме того, код в среде выполнения SDK может использовать API платформы под названием setTrustedPresentationCallback , который может дать ему более надежные гарантии представления пользовательского интерфейса рекламы со стороны платформы. setTrustedPresentationCallback работает на уровне Surface и может помочь сделать утверждения о Surface, содержащем пользовательский интерфейс рекламы, указав минимальные пороговые значения для представления, такие как процент видимых пикселей, время на экране или масштаб. Эти данные можно сравнить с данными о видимости, предоставленными клиентской библиотекой пользовательского интерфейса, как описано выше. Поскольку данные, предоставленные платформой, более надежны, любые события из библиотеки пользовательского интерфейса, данные которых не согласуются с данными из платформы, могут быть отброшены. Например, если прослушиватель, предоставленный setTrustedPresentationCallback , вызывается с уведомлением о том, что на экране не отображаются пиксели рекламного пользовательского интерфейса, а клиентская библиотека пользовательского интерфейса показывает ненулевое количество пикселей на экране, данные из последней могут быть отброшено.

Открытые вопросы

Мы приветствуем обратную связь по следующим вопросам:

  1. Какие сигналы видимости вас интересуют, но не упомянуты в этом пояснении?
  2. В настоящее время предлагается обновлять видимость не реже, чем каждые 200 миллисекунд, при условии внесения соответствующих изменений в пользовательский интерфейс. Эта частота приемлема для вас? Если нет, то какую частоту вы бы предпочли?
  3. Вы предпочитаете анализировать информацию из setTrustedPresentationCallback самостоятельно или чтобы библиотека пользовательского интерфейса поставщика удаляла данные из клиентской библиотеки пользовательского интерфейса, если они не соответствуют данным setTrustedPresentationCallback ?
  4. Как вы используете сигналы видимости? Помогите нам понять ваши варианты использования, оставив отзыв с ответами на эти вопросы .