Нативная реклама на Android

Формат нативной рекламы позволяет издателю настраивать рекламу, показываемую пользователю. После получения объявления из SDK издатели могут изменить макет и внешний вид объявления, чтобы оно лучше соответствовало пользовательскому интерфейсу приложения: добавить цветовой фильтр, изменить типографику и добавить собственные наложения. Чтобы оптимизировать производительность или удобство использования нативной рекламы, издатели часто устанавливают ограничения на отображение или перекладывают воспроизведение видео на SDK. Наконец, издатели могут настроить прослушиватели кликов по рекламе для отслеживания дополнительных событий, таких как пролистывания вверх.

Формат нативной рекламы требует более высокого уровня доверия к издателю, чем это необходимо для показа других форматов рекламы. SDK обычно хотят обнаружить нарушения политики и убедиться, что рекламный контент, предоставленный издателю, был показан пользователю.

Поддержка баннерной рекламы в среде выполнения SDK обеспечивается через API SurfaceControlViewHost . Это позволяет SDK отображать элементы пользовательского интерфейса из процесса среды выполнения SDK без их вмешательства со стороны клиентского приложения. Используйте режимы SurfaceView Z выше или Z ниже, чтобы определить, находится ли поверхность, на которой отображается пользовательский интерфейс SDK, выше или ниже окна клиентского приложения. Когда объявление отображается в режиме Z выше, SDK получает MotionEvents от взаимодействия с пользователем, но представления клиентского приложения не видны поверх объявления. Когда реклама отображается в режиме Z ниже, приложение отображает собственные представления поверх рекламы, но MotionEvents от взаимодействия пользователя с рекламой передаются в приложение, а не в SDK.

Библиотеки Privacysandbox.ui Jetpack могут использоваться SDK и издателем для установления и поддержания сеанса пользовательского интерфейса.

Рекламный контейнер, принадлежащий приложению

Мы разработали прототип, позволяющий SDK владеть всеми представлениями, содержащими нативную рекламу (включая оверлеи приложения), и обнаружили, что, хотя это и осуществимо, это накладывает некоторые ограничения на пользовательский интерфейс и увеличивает сложность интеграции с SDK. Более прагматичный подход — предоставить приложению право владения большинством просмотров. SDK по-прежнему может отображать некоторые элементы пользовательского интерфейса, например просмотр рекламы, с помощью SandboxedSdkView из Privacysandbox.ui . Такой подход обеспечивает наибольшую гибкость в поддержке существующих и будущих вариантов использования этого формата рекламы: при таком подходе разработчик приложения может перемещать компоненты рекламы и стилизовать их по мере необходимости, в то время как SDK сохраняет право собственности на видеоплеер, если предпочтительным и сохраняет доступ к элементам управления мультимедиа.

Диаграмма, показывающая, как данные передаются между издателем и SDK.
Предлагаемый порядок управления нативной рекламой.

Уведомления о состоянии объявления

Различные SDK анализируют разные свойства просмотров рекламы для обнаружения мошенничества и нарушений политики. Мы хотели бы поддержать это, не предписывая, какие свойства использовать, и не становясь узким местом для SDK, изменяющим набор запрашиваемых свойств. Мы предлагаем создать представление рекламного контейнера и его дочерних представлений с помощью NativeAdContainerInfo . Это будет разделяемый объект с различными геттерами, предоставляющими информацию, ограниченную рекламным контейнером и его содержимым, при этом такая информация сохраняет конфиденциальность и не требует больших затрат на вычисление . SDK сможет выбирать категории сигналов, включенных в NativeAdContainerInfo . SDK будет получать этот объект всякий раз, когда состояние объявления изменяется способами, имеющими отношение к SDK, например, в результате оплачиваемых событий, таких как показ рекламы и клики пользователей.`

Кроме того, издатель сможет добавлять теги представления (строки) к каждому дочернему элементу, добавленному в NativeAdContainer , что можно использовать, чтобы сообщить SDK, какому рекламному ресурсу соответствует каждый дочерний элемент.

Когда пользователь нажимает на представления, принадлежащие SDK, библиотека пользовательского интерфейса пересылает MotionEvent со свойствами, переведенными в координатное пространство SDK, в SDK вместе с исходным MotionEvent. В будущих версиях Android мы изучаем возможность добавления способов, позволяющих клиентскому приложению передавать сенсорный фокус для всех жестов пользователя на части этого нативного объявления, принадлежащие SDK, которые будут обрабатываться SDK.

Аттестации

Для более надежного представления рекламы SDK будут доступны следующие подтверждения:

  1. Аттестация целостности устройства . Используйте API-интерфейсы платформы, такие как Key Attestation, для определения целостности устройства.
  2. Идентификация APK . Используйте API-интерфейсы SdkSandbox, такие как SdkSandboxController.getClientPackageName , и API-интерфейсы PackageManager, такие как requestChecksum для проверки подлинности APK.
  3. VerifiedMotionEvents : в будущих версиях Android мы изучаем возможность разрешить клиентскому приложению переносить сенсорный фокус для всех жестов пользователя на части этого нативного объявления, принадлежащие SDK, которые будут обрабатываться SDK. MotionEvents можно преобразовать в VerifiedMotionEvents с помощью системных API. SDK может отображать собственный пользовательский интерфейс в ответ на взаимодействие с пользователем, если он того пожелает.

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

  1. Предпочтительно, чтобы SDK сам генерировал VerifiedMotionEvents или чтобы библиотека пользовательского интерфейса поставщика делала это для SDK?
  2. Предпочтительно ли, чтобы SDK предоставил издателю право владеть представлениями, содержащими видео, или самому владеть этими представлениями?
  3. Какие свойства вы хотели бы видеть в объекте AppOwnedAdContainerInfo ?
  4. Сколько объявлений или рекламных компонентов, принадлежащих SDK, вы ожидаете одновременно показывать на экране?