Реклама в приложениях

Привет, Хабр! Работа со встроенной рекламой в приложениях на платформе Huawei Mobile Services ведётся с помощью сервиса Ads Kit. Сервис предоставляет пользователям персонализированную рекламу, позволяет разработчикам анализировать результаты промокампаний и работать с основными рекламными форматами. В статье я расскажу, что включает в себя этот сервис, какие рекламные форматы поддерживает и какие даёт возможности для аналитики. Кому интересно прошу под кат.

Что такое Ads Kit

Ads Kit включает в себя две службы: Ads Publisher Service и Identifier Service. Ads Publisher Service предоставляет инструменты для интеграции рекламных объявлений и получения отчётов (количества запрошенных и просмотренных объявлений, кликов). Identifier Service обеспечивает работу с рекламным идентификатором пользователя Open Advertising ID (OAID) и персонализацией объявлений.

Пока рекламная платформа доступна только для корпоративных аккаунтов, поэтому стоит помнить, что при работе с платёжными сервисами экосистема Huawei требует обязательную регистрацию юридического лица. Но скоро Ads Kit смогут внедрить в свои приложения все разработчики. Также необходимо учитывать, что Ads Kit работает с HMS Core (APK) 4.0.0, так как на предыдущих версиях возможны ошибки.

Форматы рекламы

Сейчас в Ads Kit доступно 5 разных типов рекламы:

• Баннерная реклама. По размерам баннеры делятся на фиксированные и адаптивные. У фиксированных 5 размеров: 320 x 50 dp, 320 x 100 dp, 300 x 250 dp, 360 x 57 dp для изображений 1 080 x 170 пикселей и 360 x 144 dp для изображений 1 080 x 432 пикселя. Адаптивные рекламные баннеры автоматически регулируют ширину в зависимости от соотношения сторон устройств. Также есть возможность использовать смарт-баннеры при загрузке рекламы Huawei Ads SDK создаёт рекламный экран той же ширины, что и экран, в зависимости от его ориентации на устройстве.

• Нативная реклама. Этот тип рекламы вписывается в окружающий контент, чтобы соответствовать дизайну приложения. Такие объявления можно настраивать по мере необходимости. В нативную рекламу можно встроить не только картинки или текст, но и видео.Huawei предоставляет набор шаблонов нативной рекламы, которые доступны в двух размерах малом и среднем, и их макеты и стили можно настроить под себя. Также есть возможность дизлайкнуть нативную рекламу со стороны пользователя, при этом разработчики могут кастомизировать дальнейшее отображение рекламы после Dislike. Например, спросить, почему эта реклама нерелевантна.

• Rewarded Ads. Реклама с вознаграждением это полноэкранные видеообъявления, которые награждают пользователей за просмотр. При просмотре рекламы сервер отправляет уникальный URL со специфичными параметрами в Ads Kit, чтобы уведомить медиасервер о том, что пользователь должен быть вознаграждён за взаимодействие с видеообъявлением. При принятии решения о том, когда вознаграждать пользователя, необходимо сбалансировать проверку пользователя и скорость подтверждения вознаграждения, чтобы, с одной стороны, защититься от спуфинга, а с другой не заставлять пользователя ждать своей награды.Разработчики Huawei рекомендуют сразу вознаграждать пользователя, обрабатывая запрос на стороне клиента, а потом проверять все вознаграждения при получении обратных вызовов на стороне сервера. Такой подход гарантирует действительность предоставленных вознаграждений, обеспечивая при этом хорошее взаимодействие с пользователем.

• Interstitial Ads. Межстраничные объявления это полноэкранные объявления, которые покрывают интерфейс приложения в точках перехода при работе с приложением. Такая реклама отображается, когда пользователь запускает, приостанавливает или закрывает приложение, не мешая его работе. В межстраничную рекламу можно добавлять видео, текст и картинки.

• Splash Ads. Рекламные заставки отображаются сразу после запуска приложения, даже до того, как отобразится главный экран приложения. Для таких заставок может быть установлен таймер показа и реагирование на конкретные события, например когда пользователь перешёл по рекламной ссылке.

Важно отметить, что компания Huawei строго соблюдает политику конфиденциальности и местное законодательство. Поэтому с помощью расширенных настроек разработчики могут запрашивать у пользователя разрешение на конфиденциальный сбор его информации, либо добавить дополнительные нормативные требования, которые должны быть учтены перед использованием приложения. Например, можно установить тег для контента, предназначенного для детей, в соответствии с законом о защите конфиденциальности детей в интернете (COPPA).

Для разных типов рекламы также можно проставить теги с возрастом и регионом. Например, согласно соглашению GDPR, действующему в рамках Европейской экономической зоны, нельзя показывать персонализированную рекламу и запрашивать право на её показ для пользователей, не достигших 16 лет,при этом некоторые страны устанавливают порог в 13 лет.

Рекламная аналитика

Анализ трафика и персонализация объявлений осуществляется с помощью службы Identifier Service. Она создаёт и работает с рекламным идентификатором пользователя (OAID). Пользователь может отключить функцию персонализированной рекламы или сбросить свой OAID. При сбросе OAID, если персонализированная реклама не отключена, будет создан новый номер. Если пользователь согласился на обработку своих данных и получение персонализированной рекламы, то разработчики, в свою очередь, получают возможность использовать его зашифрованный обезличенный OAID.

Это можно использовать для анализа трафика и конверсии, разделения групп пользователей и корректировки рекламных кампаний для этого Ads Kit может интегрироваться со сторонними API рекламных платформ. В этом случае необходимо к Ads Kit добавить Analytics Kit, с помощью которого также можно собирать данные по более чем 500 параметрам, включая разные сценарии поведения пользователей, их реакцию на рекламу и ключевые точки, которые влияют на дальнейшее взаимодействие.

Для анализа источников трафика применяется функция Install Referrer, которая считывает информацию из реферальной ссылки, использованной пользователем для установки приложения. Чтобы использовать Install Referrer, требуется интегрировать API Ads Kit и после этого опубликовать приложение в AppGallery.

Ads Kit только один из инструментов монетизации. Также наша платформа позволяет использовать встроенные покупки, мотивировать пользователей с помощью баллов Huawei и системы подарков. На этом пока всё, если у вас есть ещё вопросы по монетизации своих приложений, задавайте их в комментариях.

Тестировать рекламные механики не так просто, как может показаться. Главные действующие лица здесь сторонние SDK, которые не особо подконтрольны команде разработки. А так как рекламные интеграции важная часть наших мобильных приложений, то ниже вместе с @maiscourt и @santypa расскажем, как мы это делаем.

Далее список инструментов с описаниями, задачи тестирования и некоторые внутренние гайдлайны.

---

Для тестирования в основном используется тестовая реклама, которую партнёры готовят заранее. Это делается, потому что разные характеристики рекламы на продакшене не позволяют быть уверенным, что новый функционал или фикс бага не задели основные параметры и работу рекламного креатива.

Но получение тестовой рекламы требует изменения определённых параметров в наших экспериментах, обращения к тестовой админке медиатора, добавления тест-мода (специальные параметры, чтобы партнёр понимал, что запрашивается именно тестовый креатив), использования своей дебаг-панели, а также VPN по странам, а в отдельных кейсах по городам.

И тут нам понадобятся некоторые инструменты.

Инструменты

Ниже список инструментов, которые мы используем при тестировании рекламы, а потом перейдём к задачам.

1. Сниффер для анализа трафика (у нас Charles).

2. Админка у медиатора, где можно настроить получение рекламы от конкретного партнёра на свой тестовый юнит (специальный id, используя который, паблишер запрашивает рекламу у медиатора).

3. Своя админка с фича-тогглами, где можно включить/отключить, или изменить наши эксперименты.

4. Наша дебаг-панель.

5. VPN.

6. Внешние гайдлайны.

7. Внутренняя база знаний и Confluence для её хранения.

8. Чек-листы.

9. Zephyr для хранения тест-кейсов.

Пройдёмся по каждому.

Инструмент 1. Charles. Активно используется не только тестировщиками, но и разработчиками. Практически все задачи требуют замены продакшн параметров на тестовые. Например, часто возникает необходимость добавить в конфиг эксперимент или обращаться к тестовым юнитам медиатора.

К тому же для тестирования при запросе рекламы необходимо добавлять дополнительные параметры тест-мода. Также довольно часто требуется имитировать проблемы с загрузкой креативов и проверять их с нужными параметрами, например, во время регрессионного тестирования.

Инструмент 2. Тестовая админка медиатора. Медиатор это специальная платформа, которая позволяет подключать приложение сразу к нескольким рекламным сетям, а также управлять показом рекламы (например, Google AdMob, Fyber и другие). Ещё во время онбординга мы проводим обучающие курсы по рекламе, где сотрудники в тестовой админке медиатора создают свой тестовый юнит для настройки параметров рекламы под себя.

Инструмент 3. Админка с фича-тогглами. Практически все рекламные (и не только) механики в приложении iFunny закрыты под фича-тогглы (механизм реализации, при котором часть кода прячется за флаг, контролирующий его включение или выключение). Это нужно, чтобы сделать более надёжным и безопасным выпуск той или иной функциональности.

Чтобы получить нужный для тестирования конфиг, мы используем нашу админку с фича-тогглами или подменяем параметры, используя Charles. А эксперименты помогают понять, какая из запущенных гипотез является наиболее оптимальной. Всё это есть в нашей админке, которая хранит данные и управляет ими по всем фичам и экспериментам.

Документацию обновляем и дополняем по мере необходимости: если после обновления SDK изменилась описанная логика работы, или если вышли нормативы/регламенты, требующие внесения обязательных правок.

Инструмент 4. Дебаг-панель. Для удобства разработали свою рекламную дебаг-панель, которая представляет собой отдельный интерфейс и в большинстве случаев позволяет локально на клиенте настроить необходимые параметры, заменяя собой практически все инструменты, описанные выше.

Инструмент 5. VPN. В основном используется для проверки задач, связанных с GDPR и CCPA. Для тестирования GDPR подходит VPN с возможностью получения IP европейской страны. Для тестирования CCPA необходим VPN с возможностью получения калифорнийского IP.

Инструмент 6. Внешние гайдлайны. В работе с рекламными SDK часто используем их официальную документацию, где можно получить:

• рекламные креативы и их идентификаторы, которые используются для настройки и получения тестовой рекламы;

• форматы запросов и ответов рекламной SDK, а также параметры, из описания которых понимаем, за что они отвечают, и какие возможные значения для них допустимы;

• changelog изменений рекламных SDK чтобы понять, на какие изменения при обновлении SDK нужно обратить внимание во время тестирования.

Инструмент 7. Внутренняя документация. Внешние гайды не всегда являются достаточно подробными. Кроме того, проверка одной и той же функциональности от разных SDK требует переключения между разными источниками для поиска необходимой информации. Поэтому оказалось удобным агрегировать информацию из разных гайдлайнов SDK и делать сборную внутреннюю документацию в нашем Confluence, дополняя её своими комментариями.

Инструмент 8. Чек-листы. Наравне с внешней и внутренней документацией для проверок различных задач используем чек-листы (пример можно посмотреть ниже в разделе про обновление SDK). Для такого типа задач, как проверка обновлений SDK, обновлений медиатора или адаптеров, мы используем уже составленный чек-лист, который изменяется по мере необходимости.

Для остальных задач составляем чек-листы либо в процессе разработки задачи, либо непосредственно перед тестированием, в зависимости от сложности задач.

Инструмент 9. Тест-кейсы. Тест-кейсы неотъемлемая часть тестирования любого проекта/функциональности, в том числе рекламы. Тест-кейсы разделены по приоритетам, что позволяет использовать risk-based testing, о котором будет рассказано подробнее ниже. В тест-кейсах фигурируют такие проверки, как загрузка и показ рекламы, запросы на рекламу, работа разных механик (например: водопад, аукцион), а также запрос и отображение рекламы от партнёрских рекламных сетей. Данные проверки в полной мере позволяют убедиться, что рекламный функционал работает без сбоев/корректно.

Задачи

Тестирование рекламных интеграций, чтобы все механики работали как часы довольно трудоёмкий процесс. Среди всех задач есть много рутинных, но они компенсируются интересными и технически сложными исследованиями по ходу проработки других задач.

Разберём, с чем приходится сталкиваться на постоянной основе:

1. Обновление SDK.

2. Тестирование форматов.

3. Безопасность.

4. Регрессионное тестирование.

5. Смоук тестирование.

6. Другие задачи (юридические вопросы, локализации, эксперименты, аналитика, рефакторинг и так далее).

Задача 1. Обновление SDK. Можно сказать, что обновление SDK наиболее популярная задача в рамках тестирования рекламы. Из-за частого проведения тестирования обновлений SDK (а также медиатора или адаптеров) составили чек-лист проверок:

• Вёрстка. Проверяем всё: центрирование, размер, отображение на устройствах с разными разрешениями экранов.

• Пользовательские сценарии. Тап по контенту/кнопке и по privacy icon, возврат в приложение, воспроизведение и остановка видеорекламы.

• Репорт (отправка жалоб, связанных с рекламой). Пользователь может пожаловаться на рекламный контент или сообщить о технических проблемах.

• Соответствие стандартам GDPR и CCPA.

• Отправка аналитики. Внутренняя и внешняя (партнёру и медиатору).

• Технические проверки. Например, уход в фон во время загрузки рекламы.

Задача 2. Тестирование форматов. Баннерная и нативная рекламы у нас закрепились и работают стабильно, но мы пробуем интегрировать и другие виды, в частности, fullscreen-рекламу. В целом, тестирование Rewarded Video и Interstitial во многом схоже с тестированием других видов: проверяется корректная загрузка и отображение рекламы, а также отправка аналитики.

Ключевым в проверке fullscreen-рекламы является её отображение на разных по диагонали экранах, например, на смартфоне и планшете. Важно, чтобы появившаяся на экране реклама не перекрывалась другими элементами, и по завершению таймера скрывалась автоматически или тапом по крестику, возвращая пользователя в исходную точку приложения:

Отдельно нужно сказать про механику Rewarded Video после окончания просмотра рекламы (или просмотра до определённой временной метки) пользователь должен получить вознаграждение. Поэтому очень важно хорошо протестировать этот функционал.

Подробно про разные форматы мобильной рекламы мы уже писали в отдельной статье.

Задача 3. Безопасность. Чтобы следить за качеством трафика, интегрировали в iFunny внешнее антифрод-решение. В него для дополнительной проверки атрибуции показов и кликов на каждое событие генерируется новое. На стороне системы с помощью технологий машинного обучения и большого объёма накопленных данных происходит дальнейший анализ. Со своей стороны мы проверяем отправку и разметку событий для разных сетей и разных типов рекламы.

Задача 4. Регрессионное тестирование. Раз в две недели iFunny релизится на iOS и Android. Независимо от количества рекламных задач, попавших в релизную ветку, мы проводим регрессионное тестирование рекламного функционала/блока. В регрессионных паках собраны следующего рода проверки:

• Основные проверки, что реклама запрашивается и отображается на нужных экранах приложения.

• Работа нативной и баннерной рекламы, а также рекламных сетей, с которыми сотрудничаем по сути, это упрощённый чек-лист, используемый для тестирования SDK (добавления, обновления).

• Работа разных механик: водопад и биддинг (что это такое, можно ознакомиться здесь).

• Проверка на соответствие юридическим нормам.

• Проверки каких-то наших внутренних разработок (например, эксперименты с дизайном).

Если встречаем проблемы в процессе тестирования (не проходят какие-то кейсы регресса), то чиним в текущей релизной ветке не катимся с рекламой, которая не работает.

Проведение полного ручного прогона регресса занимает порядка 2-3 дней. Поэтому, чтобы сократить время прохождения регресса, используется практика проведения Risk-based testing (вид тестирования, основанный на вероятности риска). Суть такого тестирования исключить некоторое количество тест-кейсов из прогона, проведение которых не может выявить потенциальных ошибок на текущем релизном билде. Иными словами, кейс не имеет смысла включать в регрессионное тестирование, если при разработке не был затронут функционал, проверяющийся в кейсе.

Задача 5. Смоук тестирование. Перед тем, как выкладывать сборку в сторы, а также при тестировании хотфиксов, мы прогоняем смоук тесты. В рамках смоук тестирования реклама проверяется, но не так детально, как при регрессе. Мы тестируем основные моменты, связанные с рекламой, а именно её загрузку и отображение.

Задача 6. Другое. К тестированию других задач можно отнести:

• юридические задачи, например, связанные с GDPR и CCPA;

• задачи локализации (для пользователей iFunny из Бразилии);

• эксперименты, связанные с дизайном рекламы;

• задачи аналитики;

• рефакторинг, оптимизации. Например, оцениваем доступный нам для анализа контент на предмет валидности.

Бонус. Онбординг новых сотрудников

От рекламы напрямую зависит доход приложения, но на рынке не так много людей, досконально разбирающихся в вопросе. Поэтому, помимо чеклистов и гайдлайнов, мы подготовили целый обучающий курс из лекций и семинаров.

Всё обучение делится на два блока. Первый блок состоит из лекций о базовых знаниях, что такое водопад и аукцион; каким образом приложение получает рекламу и какие действия происходят при её обработке; какая бывает аналитика и по каким триггерам собираются события. Краткое содержание этих лекций можно найти здесь.

Во втором блоке рассказывается о том, какие рекламные механики работают в iFunny. Здесь теоретический материал подкрепляется практикой каждый участник семинара учится получать определённый вид рекламы от наших партнёров и работать с необходимыми инструментами. Практические задания курса образуют своего рода задачник. Прорешав его, можно с уверенностью приступать к реальным задачам из бэклога.

Записанный на видео цикл встреч хранится вместе со всеми сопутствующими материалами в базе знаний компании и обновляется по мере необходимости. В адаптационном чек-листе каждого сотрудника отдела тестирования мобильных приложений есть специальный пункт изучение рекламных тематик. В зависимости от задач сотрудника определяется необходимый минимум знаний, но при желании любой в команде может пройти полный курс на это будет специально выделено время. По окончании онбординга каждый сотрудник отдела тестирования мобильных приложений способен самостоятельно закрыть рекламные тест-кейсы на этапе смоук тестирования.

Вместо заключения

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

Основной способ монетизации наших приложений это реклама, и её рынок растёт с каждым годом. В этой статье рассмотрим четыре основных вида рекламы, каждый из которых делится ещё на несколько типов. И поговорим об особенностях каждого как с технической, так и с пользовательской стороны что такое баннерная слепота, сколько видов нативной рекламы существует, какие размеры выбрать для разных экранов и как работает видео с вознаграждением. А также немного о нашем опыте эффективности разной рекламы.

Но сначала небольшой рекламный глоссарий.

• Плейсмент. Место для размещения рекламы, его нужно выбирать в зависимости от типа рекламы, контента и креатива.

• Инвентарь. Совокупность всех плейсментов паблишера или рекламное пространство, которое предоставляется площадкой (паблишером) рекламодателю для размещения рекламных креативов.

• Паблишер. Рекламная площадка (сайт, мобильное приложение), предоставляющее свой инвентарь под размещение рекламы.

• Рекламная сеть. Система управления и размещения рекламных объявлений на рекламных площадках.

А теперь пройдёмся по общепринятым видам рекламы.

Баннерная реклама

Баннер один из наиболее распространённых видов рекламы в приложениях. Они располагаются в определённой части экрана: блоки фиксируются в верхней или нижней зоне или встраиваются в контент. Также баннеры могут автоматически обновляться через заданное время, то есть ротироваться.

Привлекательность баннерной рекламы в её простоте и дешевизне: несложная интеграция в приложение и легкость в подготовке рекламного креатива делают баннеры наиболее выгодным решением для краткосрочной рекламной кампании.

Механика работы очень проста баннер отображается в определённом блоке, который не перекрывает основной контент. Поэтому пользователь может спокойно пользоваться приложением, находясь на экране с баннером.

Но фиксированное расположение баннера может приводить к тому, что пользователь запоминает позицию рекламы на экране и просто игнорирует. Эффект получил название баннерная слепота, иными словами склонность пользователей игнорировать элементы веб-страницы, которые они воспринимают (часто ошибочно) как рекламу.

В зависимости от размеров и расположения рекламного блока можно выделить следующие типы баннерной рекламы:

1. Standard banner (скрин 1). Это прямоугольный рекламный блок одного из стандартных размеров: 320x50 Banner, 320x250 Medium rectangle, 320x100 Large banner и других. Типы Banner и Large banner располагают снизу или сверху на экране приложения, а тип Medium rectangle встраивают в контент данный формат уже больше относится к нативной рекламе, о которой речь пойдёт далее.

Скрин 1: примеры баннеров стандартных размеров

2. Smart banner. Баннер с фиксированной высотой и адаптивной шириной, которая подстраивается под размер устройства. Это означает, что рекламный креатив заполнит всю ширину на любом экране в любой ориентации. Для того, чтобы на большом экране, например, планшете, смарт-баннер не казался слишком узким, для него реализованы следующие значения высот:

• при высоте экрана устройства менее 400 dp, высота смарт-баннера будет равна 32 dp (актуально и для landscape-ориентации);

• если высота экрана не превышает 720 dp, высота баннера будет 50 dp (обычная portrait-ориентация);

• когда высота экрана составляет более 720 dp, высота рекламного блока равна 90 dp (для планшета данная высота баннера будет распространяться и на landscape, и на portrait). Так баннер будет смотреться органично для любого экрана.

3. Adaptive banner. Самый современный из всех типов баннеров, механизм работы которого основывается на вычислении наиболее оптимального размера рекламного блока через заданную разработчиком ширину, то есть для указанной ширины блока определяется подходящая высота.

На скрине 2 видно, чем описанные баннеры отличаются друг от друга. Выбирая тот или иной тип баннера, нужно обращать внимание на возможности рекламного SDK, так как не каждая рекламная сеть позволяет использовать все типы. Поэтому наиболее частый выбор стандартного баннера обусловлен не только простотой его внедрения, но и распространённостью среди рекламных сетей.

Скрин 2: типы баннеров (стандартный, смарт-баннер, адаптивный)

Баннер может состоять из:

1. Рекламного креатива (обязательный элемент) как правило, он приходит в html-файле, в котором содержится ссылка на ресурс, например, картинку, либо js-файл для анимированного контента.

2. Privacy information icon/Ad choices обязательный для некоторых рекламных сетей (например, AdMob) элемент, который содержит информацию о конфиденциальности, а также даёт возможность пользователю отказаться от просмотра той или иной рекламы;

3. URL адрес, на который происходит переход при клике на баннер (в магазин или на сайт);

4. Трекеры событий (показа и нажатия) это urlы, которые вызываются при выполнении определённых действий: отображения баннера на экране и клики по нему.

Скрин 3: элементы баннера

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

Плюсы:

• известный рекламный формат, по работе с которым накоплено много опыта;

• несложные интеграция в приложение и подготовка рекламного контента;

• считается наиболее выгодным решением для краткосрочной рекламной кампании.

Недостатки:

• на небольших баннерах нельзя поместить много информации;

• большое количество информации делает баннер трудновоспринимаемым для пользователей;

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

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

Нативная реклама вид, при котором рекламный контент органично вписывается в приложение, подстраиваясь под его дизайн и контекст. Благодаря формату и контентной составляющей она выглядит как часть приложения, подстраиваясь под его дизайн и контекст, поэтому считается более информативной и удобочитаемой. В социальной сети такая реклама будет похожа на обычный пост, в онлайн-магазине на ещё один товар. Часто пользователи даже не сразу понимают, что перед ними реклама.

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

Среди основных преимуществ нативной рекламы для рекламодателя возможность кастомизации рекламных блоков и гибкость их исполнения. Размер, внешний вид и местоположение полей подбирается максимально близко к дизайну приложения. Нативная реклама конфигурируется из полей составных частей, из которых разработчик собирает рекламный блок в соответствии с дизайном приложения, а также гайдлайнов рекламных сетей (например, AdMob, Facebook). Среди полей есть обязательные и необязательные.

Основные элементы нативной рекламы (скрин 4):

Скрин 4: элементы нативной рекламы

1. Title заголовок рекламы.

2. Icon иконка приложения или логотип компании размером от 80х80 до 512х512 пикселей.

3. Main image/Media content основной рекламный контент, в качестве которого может выступать статичная картинка или видео.

4. Call To Action (CTA) кнопка или текст с призывом к действию: переходу в магазин или на сайт.

5. URL адрес, по которому происходит переход при клике на Call To Action.

6. Ad Label/Sponsored элемент, показывающий пользователю, что перед ним реклама (возможны различные варианты меток, например, Ads, Sponsored, Реклама, Promoted, Recommended).

К дополнительным элементам можно отнести:

7. Description основной текст рекламного блока.

8. Content rating элемент, указывающий допустимый возраст потребителя рекламного контента.

9. Star rating элемент, показывающий рейтинг рекламируемого приложения или товара.

10. Privacy information icon/Ad choices обязательный для некоторых рекламных сетей (MoPub, AdMob) элемент, который содержит информацию о конфиденциальности, а также позволяет пользователю отказаться от просмотра той или иной рекламы.

11. Warning/Disclaimer предупреждения об особенностях рекламирующихся продукта или услуги.

Все поля должны располагаться внутри рекламного блока, а элементы не перекрывать друг друга.

Перечисленные элементы одинаковы для любых типов нативной рекламы (статичная реклама или нативное видео). Но стоит учесть, что нативная видеореклама требует наличия кнопок для воспроизведения и остановки видео Play/Pause, а также возможности включать и выключать звук Mute/Unmute. Для некоторых рекламных SDK также предполагается возможность перейти в фуллскрин-плеер.

Есть несколько типов нативной рекламы, отличающихся по размеру и расположению рекламного блока, а также по способу отображения контента.

• In-Feed Native Ads формат, когда реклама встраивается в ленту приложения, имитируя при этом дизайн основного контента. При просмотре ленты/контента нативная реклама смешивается с общим контентом, обеспечивая непрерывность.

• In-Feed Social (скрин 5) представляет собой социальный контент (статьи, видео, музыка, изображения), встречающийся в таких социальных сетях, как Facebook, Twitter и других.

  Скрин 5: In-Feed Social реклама

• In-Feed Content (скрин 6) рекламные блоки со статьями, видео, подкастами, изображениями, размещаемые в новостных агрегаторах, например, CNN.

  Скрин 6: In-Feed Content реклама

• In-Feed Product (скрин 7) как правило, это реклама о товарах, услугах, приложениях, которые можно встретить в Amazon, App Store, ASOS.

  Скрин 7: In-Feed Product реклама

In-Feed Native является наиболее используемым в мобильных приложениях. Существует ещё несколько форматов, но их основные места расположения веб-сайты, в мобильных приложениях они используются реже:

• In-Content Native Ads реклама, размещаемая на страницах статей между абзацами контента и разработанная таким образом, чтобы соответствовать дизайну редакторского контента.

• Content recommendation ads блоки с рекомендательными виджетами.

В зависимости от формата можно выделить следующие типы нативной рекламы:

1. MREC (medium rectangle) по сути, данный тип нативной рекламы представляет собой баннер размера 320х250. Мы уже знакомились с ним выше. MREC не содержит всех обязательных для нативной рекламы полей: нет Title, CTA, что также роднит этот тип с баннером.

2. Native тип нативной рекламы, загрузка и постобработка которого зависит от рекламной сети. Используя средства и методы интегрируемых SDK, приложение запрашивает и отображает рекламу. В качестве контента может быть загружено как статичное изображение, так и видео. При загрузке видеорекламы также используется видеоплеер от SDK. Для Native характерно отображение всех обязательных для нативной рекламы элементов и возможно добавление дополнительных. В качестве примера можно привести MoPub, AdMob, Facebook.

3. VAST (Video Ad Serving Template) это нативная видеореклама, отображаемая по VAST-спецификации. В полученном VAST-скрипте содержится информация по рекламе: urlы, которые будут вызваны в случае наступления определённых событий (например, показ, пауза), местоположение видео, форматы и его размер и т.д. Иными словами, VAST-скрипт представляет собой xml-файл, в котором хранится нужная информация для загрузки и показа рекламы.

Безусловно, интеграция и поддержание разных типов нативной рекламы требует от паблишеров больше времени и усилий, в отличие, например, от баннеров. Но также пользователи чаще будут обращать внимание на такую рекламу.

Ещё стоит отметить, что, несмотря на внешнюю схожесть нативной рекламы с контентом, через определённое время пользователи начнут её узнавать. Поэтому для рекламного блока необходимо создавать действительно ценный и полезный контент, чтобы объявление не раздражало читателя.

Rewarded Video

Rewarded Video (видео с вознаграждением) это fullscreen-видеореклама, в основе которой лежит механика вознаграждения за просмотр. Наибольшую популярность данный формат рекламы нашёл в мобильной игровой индустрии. Если обычно паблишеры стараются максимально замаскировать рекламу от пользователя, то в играх её можно выносить на видное место, подкрепляя внутриигровой наградой. Rewarded Video нативно встраивается в контент и награждает пользователя за просмотр рекламы какой-либо ценностью, например, дополнительной жизнью, подсказкой и другими бонусами. При этом некоторые пользователи готовы повторно просматривать рекламу, чтобы получить награду.

Это совсем не означает, что использование Rewarded video в неигровых приложениях недопустимо. На самом деле, данный тип рекламы хорошо ложится в стратегию монетизации любого приложения, благодаря высокой вовлечённости пользователя.

Чтобы Rewarded video приносила доход и при этом не раздражала, важно выбрать правильную награду, которая будет интересна пользователям, и за которую они будут готовы посмотреть рекламу. Например, для обучающих приложений такой функцией может быть возможность получить подсказку или открыть следующее задание, для медиа доступ к эксклюзивному контенту.

Также не стоит забывать про положительный пользовательский опыт при взаимодействие с данным форматом рекламы. Всё дело в награде, которая является своего рода мотиватором для просмотра.

Получение вознаграждения основное отличие данного типа рекламы от остальных, поэтому при реализации Rewarded Video важно учесть обработку события получения этого вознаграждения. Ниже приводится примитивная механика работы Rewarded Video (скрин 8):

1. Реклама открыта пользователем и отображается на экране в fullscreen-режиме.

2. Если пользователь закрыл рекламу, не дождавшись конца воспроизведения, то отправится событие onClose, означающее, что пользователь закрыл объявление. В таком случае вознаграждения он не получит.

3. Если пользователь просмотрел рекламу целиком (или до определённого рекламодателем временного маркера), то отправится событие onRewarded, означающее, что пользователь получит награду.

   Скрин 8: пример работы Rewarded Video

Что нужно учесть при интеграции Rewarded Video:

1. Не стоит злоупотреблять и внедрять этот тип рекламы сразу во много функций/мест в приложении, чтобы не раздражать пользователей.

2. Вознаграждение за просмотр устанавливается паблишером, однако в качестве награды не могут использоваться материальные средства.

3. При выполнении пользователем условий (а именно просмотра рекламы) паблишер обязан выдать ему вознаграждение.

4. Необходимо подробно описывать условия получения награды. При этом для описания необходимого действия могут использоваться значки, внешний вид которых чётко указывает на рекламный характер объявления. Рекомендуется использовать слово Реклама рядом со значком.

5. Не нужно забывать про максимально возможное время воспроизведения видео. Посмотрев рекламу на протяжении 30 секунд, пользователь вряд ли будет рад увидеть ещё один рекламный ролик.

6. Необходимо учитывать, что видеореклама может запускаться со звуком, поэтому в этот момент само приложение не должно издавать никаких звуков.

7. Нет смысла внедрять рекламу в самом начале приложения это может отпугнуть новых пользователей.

8. Rewarded Video это реклама продолжительностью до 30 секунд, поэтому креатив (само видео) может загружаться долго. Из-за этого также не рекомендуется вставлять видео в начале сессии (сессия сеанс взаимодействия пользователя с приложением). Либо реализовывать предзагрузку видео.

9. Расположение рекламы не в начале сессии является наилучшим вариантом для поиска и показа рекламы с более высоким CPM (Cost Per Mille цена за тысячу показов).

Interstitial

Еще один формат fullscreen-рекламы. Как правило, запуск такой рекламы инициируется триггерами, и сама реклама появляется между действиями или экранами приложения.

Например, после того, как пользователь прошёл первый уровень игры, а второй ещё не загрузился, может отобразиться Interstitial-реклама. В зависимости от реализации данной рекламы, пользователь может сразу же её закрыть, нажав на крестик, или ему придётся досмотреть рекламу до конца, либо до определённого маркера (обычно это 5 секунд). После чего пользователь снова возвращается к основному контенту приложения (скрин 9).

Скрин 9: пример работы Interstitial

Interstitial-реклама, по сути, является баннером большего размера, перекрывающим экран приложения (так называемый, Interstitial Banner Ads). Такой формат удобен для рекламодателей тем, что позволяет разместить больше информационного контента различного типа. Это может быть:

• статичное изображение;

• видеоконтент (в таком случае реклама ещё называется Videostitial Ads);

• анимированный контент.

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

Одновременно такой формат рекламы является и наиболее навязчивым для пользователей. Ведь они не только не знают момента, когда Interstitial может появиться вновь, но и не могут игнорировать её, как, например, баннерную или нативную рекламы. Поэтому, внедряя в приложение Interstitial-рекламу, нужно понимать, какой должна быть частота её показа. На практике эту проблему решает запуск Interstitial через A/B-эксперимент. Таким образом, можно проверить несколько гипотез о частоте показа, проанализировать их и выбрать наиболее оптимальную.

Вывод

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

В наших приложениях в качестве основных видов выбраны нативная и баннерная реклама, они дают следующее распределение по доходам:

1. Баннер 41%

2. Нативная реклама:

• VAST 24%

• MREC 18%

• Native 17%

Также проводились эксперименты с внедрением Rewarded Video и Interstitial-рекламы. В результате проведённых тестов данные оказались следующими:

1. Интеграция Rewarded Video показала в 20 раз больший CPM, чем у баннерной рекламы, но при этом почти в два раза меньший филлрейт (процент запросов на показ рекламы).

2. CPM Interstitial-рекламы, по сравнению с баннерами, тоже в среднем больше в 20 раз.

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