Когда пора мигрировать платформу медиации?
Смена платформы медиации рекламы — одно из самых значимых решений, которые принимает мобильный паблишер. Уровень медиации определяет, какую рекламу видят пользователи, сколько вы зарабатываете за показ и насколько плавно работает рекламный опыт. Миграция несёт реальные риски, однако оставаться на неоптимальной платформе означает нести накапливающиеся потери, которые растут с каждым днём.
Явные сигналы, что пора оценить переход:
- Снижение eCPM без рыночных объяснений: Если ваши eCPM падают, а отраслевые бенчмарки остаются стабильными, на текущей платформе могут быть пробелы в спросе или проблемы оптимизации, которые новые игроки уже решили.
- Лучшая поддержка биддинга в другом месте: Если ваша текущая платформа поддерживает 3 партнёра по биддингу, а конкурент — 8, вы упускаете плотность аукциона (и доходы).
- Закат или устаревание SDK: Когда платформа медиации объявляет о конце жизни своего SDK или прекращает активную разработку функций, миграция неизбежна. Вопрос не в том, произойдёт ли она, а в том, когда.
- Отсутствие форматов рекламы: Если платформа не поддерживает рекламу при открытии приложения, rewarded interstitials или нативный биддинг, тогда как конкуренты поддерживают, каждый недостающий формат — упущенный доход.
- Ограничения отчётности: Если вы не можете получить детальные данные eCPM по сети, гео, рекламному блоку и формату, вы работаете вслепую. Современные платформы предоставляют это как стандарт.
Планирование миграции: подход с параллельным тестированием
Главное правило миграции медиации — никогда не делать жёсткого переключения. Подход с параллельным тестированием защищает нижнюю границу вашего дохода, одновременно проверяя производительность новой платформы на реальном трафике.
Параллельная стратегия работает следующим образом:
- Фаза 1 (Настройка): Интегрируйте новый SDK медиации наряду с существующим. Настройте идентичные рекламные блоки, источники спроса и цены пола на обеих платформах.
- Фаза 2 (Разделение трафика): Направьте 10–20% трафика на новую платформу, оставив 80–90% на существующей. Используйте флаг удалённой конфигурации или фреймворк A/B-тестирования для управления разделением.
- Фаза 3 (Мониторинг): Запускайте обе платформы одновременно не менее 2 недель, сравнивая eCPM, fill rate, задержку и процент сбоев по разделению.
- Фаза 4 (Масштабирование): Если новая платформа соответствует старой или превосходит её, постепенно увеличивайте долю трафика: 20% → 50% → 80% → 100%.
- Фаза 5 (Очистка): Удалите старый SDK медиации и связанные конфигурации, когда 100% трафика проработает на новой платформе не менее одной недели со стабильными показателями.
Данные, необходимые перед переходом
До начала любой миграции экспортируйте и задокументируйте исчерпывающие базовые данные с текущей платформы. Эти данные служат двум целям: они обеспечивают сравнительные бенчмарки для оценки новой платформы и информируют начальную конфигурацию нового водопада или биддинга.
Ключевые точки данных
- Исторический eCPM по сети и географии: Как минимум, последние 90 дней ежедневного eCPM для каждого источника спроса с разбивкой по стране или группе стран. Это позволяет понять, какие сети работают хорошо на каких рынках, и определяет порядок нового водопада.
- Fill rate по сети и формату рекламы: Сеть с высоким eCPM, но 5% fill rate вносит иной вклад, чем сеть с умеренным eCPM и 90% fill rate. Оба показателя необходимы для точной настройки.
- Объём показов по рекламному блоку: Понимайте, какие рекламные размещения генерируют больше всего показов. Это ваши высокоприоритетные блоки, которые следует мигрировать последними, чтобы минимизировать риск.
- Данные о задержке: При наличии задокументируйте среднее время загрузки рекламы и процент таймаутов для каждой сети. Это помогает установить соответствующие значения таймаута на новой платформе.
- Доходы по дням недели и времени суток: У рекламных рынков есть недельные и суточные циклы. Документирование этой закономерности гарантирует, что вы не примете обычные циклические вариации за изменения, вызванные миграцией.
Желательные данные
- ARPDAU на уровне пользователя по когортам
- Данные о частоте показа рекламы на уровне сессии
- Показатели сбоев и ANR, коррелирующие с активностью рекламного SDK
- Детальные логи биддинга, если текущая платформа их предоставляет
Пошаговый процесс миграции
Шаг 1: Установка нового SDK медиации
Добавьте новый SDK медиации и все необходимые адаптерные SDK в проект. Пока не удаляйте старый SDK. Оба будут сосуществовать на этапе параллельного тестирования. Ключевые действия:
- Добавьте зависимость от основного SDK медиации
- Добавьте адаптерные SDK для каждого источника спроса, который планируете использовать
- Инициализируйте новый SDK в классе Application или AppDelegate, под флагом удалённой конфигурации
- Убедитесь, что сборка компилируется без конфликтов между старым и новым SDK
Шаг 2: Настройка рекламных блоков и источников спроса
В панели управления новой платформы воссоздайте конфигурацию рекламных блоков:
- Создайте рекламные блоки, соответствующие существующим размещениям (тот же формат, тот же интервал обновления для баннеров)
- Добавьте все источники спроса с соответствующими ID приложений и ID размещений
- Установите начальные цены пола на основе исторических данных eCPM со старой платформы
- Включите биддинг для всех источников, поддерживающих его; настройте записи водопада для остальных
Шаг 3: Реализация разделения трафика
Используйте систему удалённой конфигурации (Firebase Remote Config, собственную систему флагов функций или простой серверный переключатель) для управления тем, какой SDK медиации обрабатывает каждую сессию:
- При запуске приложения проверьте удалённый флаг, чтобы определить, какой SDK активен для данной сессии
- Запрашивайте рекламу только через активный SDK на протяжении всей сессии. Не смешивайте SDK в рамках одной сессии.
- Записывайте, какой SDK активен, в аналитику, чтобы можно было чисто сегментировать данные о производительности
Шаг 4: Параллельная работа в течение минимум двух недель
Две недели — минимальный период оценки. Эта продолжительность охватывает будние и выходные паттерны, учитывает колебания спроса и даёт алгоритмам биддинга время изучить ваш инвентарь. В этот период:
- Ежедневно мониторьте eCPM, fill rate и общий доход для обеих групп
- Отслеживайте метрики стабильности приложения (процент сбоев, ANR) по обеим группам
- Следите за проблемами пользовательского опыта (медленная загрузка рекламы, пустые рекламные фреймы, неожиданная полноэкранная реклама)
- Не вносите изменений в конфигурацию ни одной из платформ в этот период, если только что-то явно сломано
Шаг 5: Сравнение и принятие решения
После параллельного периода сравните две платформы по этим параметрам:
- Доход на DAU: Основная метрика. Если новая платформа генерирует равный или более высокий доход на ежедневного активного пользователя, она проходит основной тест.
- Fill rate: Более высокий fill rate означает больше монетизированных показов. Новая платформа с на 5% более высоким fill rate и аналогичным eCPM — явный победитель.
- Задержка: Более быстрая загрузка рекламы означает лучшую видимость и пользовательский опыт.
- Стабильность: Если новый SDK увеличивает процент сбоев, доходный прирост может не стоить этого.
Шаг 6: Переключение и очистка
После принятия решения в пользу новой платформы увеличьте трафик до 100%, мониторьте ещё 5–7 дней, затем полностью удалите старый SDK. Обновите список зависимостей, удалите старый код инициализации и очистите любую условную логику, связанную с разделением трафика.
Распространённые ловушки при миграции медиации
Даже тщательно спланированные миграции сталкиваются с проблемами. Осведомлённость о распространённых ловушках помогает избежать их или быстро восстановиться:
- Потеря исторических данных оптимизации: Алгоритмы биддинга на старой платформе имеют многомесячные данные о вашем инвентаре. Новая платформа начинает с нуля. Ожидайте 1–2 недели субоптимальной производительности, пока алгоритмы обучаются.
- Конфликты SDK: Запуск двух SDK медиации одновременно может вызвать конфликты зависимостей, особенно если оба включают одни и те же SDK источников спроса разных версий. Тщательно тестируйте на стейджинг-сборке перед развёртыванием в продакшн.
- Несоответствие цен пола: Слишком высокие полы на новой платформе убивают fill rate. Слишком низкие — оставляют деньги на столе. Используйте исторические данные как отправную точку и корректируйте после первой недели.
- Сравнение неравных временных периодов: Рекламные рынки колеблются. Сравнение первой недели новой платформы с первой неделей старой платформы трёхмесячной давности не является валидным сравнением. Параллельное тестирование устраняет эту проблему.
- Спешка со сроками: Давление с целью показать быстрые результаты ведёт к преждевременным выводам. Две недели параллельных данных — минимум. Четыре недели лучше для паблишеров со значительным трафиком.
Миграция с AdMob Mediation на Google Ad Manager
Один из наиболее распространённых путей миграции — переход с AdMob медиации на полноценную платформу Google Ad Manager. Это обновление обусловлено превосходными возможностями GAM для паблишеров в масштабе:
- Поддержка прямых сделок: GAM позволяет прямым продажам конкурировать наряду с программатик-спросом, что AdMob медиация не поддерживает
- Расширенная отчётность: GAM предоставляет детальную отчётность по позициям, рекламодателям, креативам и пользовательским измерениям
- Open Bidding: Серверный биддинг GAM поддерживает более широкий спектр партнёров-бирж, чем клиентская медиация AdMob
- Унифицированные правила ценообразования: Устанавливайте цены пола с детализацией по гео, устройству и формату по всем источникам спроса из единого интерфейса
Именно такую миграцию RevenueFlex выполняет регулярно. Переход с AdMob медиации на полностью управляемую настройку GAM включает воссоздание всей рекламной конфигурации в GAM, маппинг источников спроса, установку новых цен пола на основе исторических показателей и запуск параллельной оценки для подтверждения нейтральности или улучшения доходов. Паблишеры, осуществляющие этот переход с надлежащим планированием, как правило, видят рост дохода на 10–25% после полной оптимизации водопада GAM.
Миграция медиации — не проект на выходные. Это многонедельный процесс, требующий тщательного планирования, дисциплинированного параллельного тестирования и терпения, пока новые алгоритмы изучают ваш инвентарь. Но для паблишеров на неэффективной платформе долгосрочное влияние на доходы от смены платформы делает краткосрочные усилия оправданными.