Раньше любое существенное изменение в рекламной монетизации зависело от графика релизов. Хотели предзагружать ещё одно объявление с вознаграждением, изменить оформление нативного плейсмента или ослабить ограничения частоты показов в одной стране? Даже самый быстрый путь требовал правок в коде, ожидания проверки и двух недель поэтапного развёртывания, прежде чем менялись показатели.
В этом релизе мы перенесли три такие задачи в портал Apps Kit SDK. Предзагрузка рекламы, дизайн нативных объявлений и конфигурации по регионам теперь управляются удалённо, а настройки применяются к уже установленным приложениям. Без обновления приложения, отправки на проверку в магазин и ожидания, пока пользователи старых версий наконец обновятся.
1. Предзагрузка рекламы из портала — оптимизация fill rate без кода
Отсутствие рекламы в ответ на запрос — no-fill — редко связано с нехваткой спроса. Чаще всего запрос просто отправляется слишком поздно: пользователь доходит до рекламного плейсмента, SDK запускает аукцион, время ожидания истекает до ответа участников с выгодными ставками — и вы либо показываете дешёвое резервное объявление, либо не показываете ничего. Предзагрузка решает проблему тайминга, а не спроса.
Теперь предзагрузку можно настроить для каждого плейсмента прямо в портале. Укажите, сколько объявлений каждого формата держать готовыми к показу, выберите триггер загрузки и задайте срок хранения объявления в кэше, после которого оно будет удалено и загружено заново. Измените настройки в 9 утра — и увидите эффект на когортах того же дня.
- Глубина предзагрузки по форматам — держите наготове одно межстраничное объявление и два объявления с вознаграждением или задайте отдельные значения для каждого плейсмента
- Триггеры — предзагружайте рекламу при запуске приложения, открытии экрана или после определённого события, например начала уровня
- Срок жизни кэша (TTL) — удаляйте устаревшие креативы до показа, чтобы не показывать объявление, ставка на которое потеряла актуальность двадцать минут назад
- Правила пополнения кэша — загружайте новое объявление сразу после показа или ждите следующего триггера, чтобы сократить число запросов
Защитные ограничения не менее важны, чем сами настройки. Если предзагружать всё и везде, можно быстро занять память на бюджетных Android-устройствах и раздуть число запросов на объявления, которые так и не будут показаны. Это незаметно ухудшает fill rate и ваши позиции у рекламных сетей. Портал показывает соотношение запросов и показов для каждого плейсмента с предзагрузкой: вы сразу увидите, если глубина предзагрузки слишком велика, и сможете уменьшить её в тот же день.
Для начала рекомендуем предзагружать только самые ценные плейсменты — рекламу с вознаграждением и первое межстраничное объявление в сессии. Начните с одного объявления в кэше и небольшого TTL. Оцените результаты и увеличивайте глубину только там, где соотношение запросов и показов остаётся приемлемым.
2. Дизайн нативной рекламы в портале — без обновления приложения
Нативная реклама приносит результат, когда органично вписывается в приложение. Именно поэтому её так сложно дорабатывать. Раньше любое изменение макета — размер заголовка, расположение иконки, цвет кнопки CTA, радиус скругления — требовало правки файла разметки внутри сборки, а каждый эксперимент обходился в отдельный релиз.
Теперь шаблоны нативных объявлений можно создавать и редактировать в портале. Соберите макет из стандартных элементов нативной рекламы: иконки, заголовка, текста, медиа, данных рекламодателя и CTA. Настройте шрифты, цвета, отступы и радиус скругления, затем опубликуйте шаблон для действующих приложений. SDK отрисует его во время работы приложения, поэтому пользователи увидят новый дизайн при следующем получении конфигурации.
- Создание макетов перетаскиванием элементов — для нативных плейсментов в ленте, в формате баннера и на всю ширину экрана
- Настройки типографики, цветов, отступов, скруглений и оформления CTA — включая отдельные варианты для светлой и тёмной тем
- Отдельные шаблоны для каждого плейсмента — нативный блок в ленте не обязан выглядеть так же, как блок на экране результатов
- Тестирование вариантов — сравните два шаблона по CTR и eCPM, прежде чем выбрать победителя
- Соблюдение рекламных правил заложено в шаблон: обязательная маркировка рекламы и информация о рекламодателе есть в каждом шаблоне, и скрыть их настройками оформления нельзя
На практике дизайн нативной рекламы перестаёт быть задачей для разработчиков и становится экспериментом по монетизации. Команды, которые раньше выпускали один нативный макет в квартал, теперь могут тестировать новый каждую неделю. Именно такие последовательные улучшения обычно и обеспечивают накопительный рост eCPM нативной рекламы.
3. Конфигурации по регионам — свои рекламные настройки для каждого рынка
Единая рекламная конфигурация для всего мира всегда где-то работает плохо. Частота межстраничных показов, которую спокойно воспринимает аудитория США, может вызвать отток пользователей на развивающемся рынке, где сессии короче, а соединение медленнее. Минимальная ставка, которая защищает eCPM в Tier 1, может оставить рекламный инвентарь без заполнения в Tier 3.
Теперь почти любую рекламную настройку можно задать для региона, страны или группы стран. При обработке запроса приоритет получает наиболее конкретное правило: настройки страны переопределяют настройки региона, а настройки региона — глобальную конфигурацию по умолчанию.
- Правила плейсментов — включайте, отключайте или меняйте рекламные форматы для отдельных рынков
- Ограничения частоты и интервалы между показами — более строгие лимиты там, где сессии короткие, и более мягкие там, где они длинные
- Минимальные ставки — задавайте пороги по странам, чтобы защищать eCPM в Tier 1, не снижая заполняемость в Tier 3
- Глубина предзагрузки и тайм-ауты — больше объявлений в кэше и больше времени на ответ для медленных сетей, меньшие значения для быстрых
- Шаблоны нативной рекламы — отдельный шаблон для рынка, если этого требуют особенности шрифтов или длина текста на местном языке
Конкретный пример. В США, Великобритании и Германии вы используете рекламу с вознаграждением и межстраничные объявления с интервалом 90 секунд, жёстким порогом минимальной ставки и глубиной предзагрузки два. В Индии, Индонезии и Бразилии оставляете рекламу с вознаграждением, снижаете частоту межстраничных показов до одного в три минуты, убираете жёсткий порог ставки, чтобы аукцион мог выбрать победителя, увеличиваете тайм-аут аукциона для медленных соединений и используете облегчённый нативный шаблон, который быстрее отрисовывается на бюджетных устройствах. Одна сборка — два совершенно разных сценария показа рекламы.
Как три функции работают вместе
Максимальную пользу эти функции приносят в связке. Региональные конфигурации определяют, какую рекламу показывать на каждом рынке; предзагрузка гарантирует, что объявление будет готово в нужный момент; нативные шаблоны из портала помогают органично вписать рекламный блок в интерфейс с учётом местной специфики.
В качестве отправной точки рекомендуем такую конфигурацию: включите предзагрузку одного объявления с вознаграждением для всех стран, создайте две группы рынков — развитые и развивающиеся — со своими ограничениями частоты и минимальными ставками и опубликуйте по одному нативному шаблону для каждой группы. Три изменения в портале и ни одной строки кода — этого достаточно, чтобы понять, влияют ли эти настройки на ARPDAU вашего приложения, прежде чем вкладываться в более тонкую оптимизацию.
Лучшая рекламная конфигурация — та, которую можно изменить во вторник после обеда и оценить уже к четвергу.
Чек-лист внедрения
- Сначала включите предзагрузку рекламы с вознаграждением — это самый ценный формат, и оценить результат на нём проще всего
- Наблюдайте за соотношением запросов и показов в течение недели, прежде чем увеличивать глубину предзагрузки хотя бы в одном плейсменте
- Создайте один нативный шаблон, соответствующий иерархии размеров шрифта в приложении, и проведите A/B-тест с текущим макетом
- Разделите десять основных стран на две-три региональные группы вместо того, чтобы настраивать каждую отдельно
- Меняйте только один параметр за раз в каждой группе: при одновременных изменениях невозможно определить, какое из них повлияло на ARPDAU
- Оценивайте каждое изменение не раньше чем через семь дней — нужна полная неделя, чтобы учесть когортные эффекты и колебания по дням недели
Все три функции уже доступны в портале на всех тарифах, включая 14-дневный пробный период. Если Apps Kit SDK уже интегрирован, новые настройки применятся при следующем получении конфигурации — ничего обновлять или повторно отправлять на проверку не нужно.
