Почему медиация рекламных сетей не вытягивает доход
В приложении чаще всего подключена одна сеть — та, чей менеджер первым прислал доступ. Пока трафик небольшой, этого хватает: заполняемость блоков близка к 100%, доход с показов растёт вместе с аудиторией. Но как только часть показов уходит в гео с низким спросом или на старые устройства, единственный источник перестаёт выкупать инвентарь, и просадка дохода с показов начинается на ровном месте. Потери при этом незаметны: отчёты показывают рост, а доход на активного пользователя падает.
Вторая типовая ошибка — ручная ротация рекламы. Приоритеты выставлены один раз и не пересматриваются: сеть с худшими ставками продолжает забирать верхние позиции, а более выгодный партнёр получает остаток. Никто не сравнивает, сколько принёс бы тот же показ в аукционе, поэтому решение о порядке источников принимается по интуиции, а не по данным.
Третья — провалы заполняемости на части аудитории. Медиация рекламных сетей не разложена по сегментам: разные форматы, площадки и типы трафика уходят в общий поток, и там, где один источник не даёт рекламу, второй даже не запрашивается. В логах это видно как пустые ответы, которые никто не разбирает, а доля невыкупленного инвентаря копится месяцами.
Корень один: настройка медиации сведена к вставке ключей, без приоритетов, таймаутов и регулярного пересмотра ставок. Ниже разбираем, как это закрывается.
Что даёт единый аукцион внутри приложения
Аукционная схема заменяет последовательный водопад: приложение отправляет один запрос, сети отвечают ставками одновременно, показ уходит победителю. В водопаде следующий источник подключался только после отказа предыдущего, поэтому часть запросов заканчивалась пустым ответом, а цепочка таймаутов растягивала загрузку экрана. В едином аукционе решение принимает посредник — по фактической ставке, а не по приоритетам, расставленным вручную.
Заполняемость показов растёт: конкурируют все подключённые сети, и запрос закрывается там, где раньше водопад доходил до конца списка. Доход на активного пользователя поднимается не за счёт количества показов, а за счёт цены каждого — она определяется ставкой победителя. Одновременно падает доля пустых показов и время до отрисовки рекламного блока: вместо цепочки последовательных вызовов выполняется один.
Автоматическая ротация перераспределяет трафик по фактическим результатам сегментов: сеть, которая лучше платит за аудиторию конкретной платформы или страны, получает большую долю запросов без ручной перенастройки. Перед переключением мы снимаем базовый срез и сравниваем на сопоставимом трафике заполняемость, доход на активного пользователя и распределение по сетям — иначе рост легко списать на сезонность.
Технически это опирается на аукционный механизм платформы: Google AdMob сводит ставки сетей-претендентов в одном вызове посредника и возвращает готовое объявление. Частотные ограничения и фильтры категорий продолжают работать поверх аукциона — контроль над тем, что видит пользователь, остаётся у приложения.
Сравнение подходов: медиация против прямых договоров
Схема подключения задаёт, кто и насколько быстро решает, какое объявление показать в каждом показе. Водопад обходит сети последовательно: пока верхняя не ответит отказом, остальные ждут, и часть запросов теряется на таймаутах. Аукцион запрашивает ставки параллельно и отдаёт лучшую в отведённое окно — заполнение растёт без ручной перестановки приоритетов.
Прямые договоры с партнёрами дают фиксированные условия и контроль над форматами, но каждая сеть — отдельная интеграция, своя отчётность и ручная правка приоритетов при изменении условий. Гибридная схема подключения разводит трафик: гарантированные показы идут по прямым приоритетам, остаток — в аукцион.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Посредник с аукционом | Много гео и форматов, нужен быстрый отклик на изменение спроса | Часть данных о покупателе недоступна, правила площадки ограничивают инвентарь |
| Прямые договоры с партнёрами | Ключевые размещения, прогнозируемый спрос, требования к креативу | Каждая сеть — своя интеграция и отчётность, приоритеты правятся вручную |
| Гибридная схема подключения | Нужны и гарантированные показы, и заполнение остатка | Два источника данных, конфликты приоритетов при сверке |
| Собственный сервер ротации | Нестандартные сценарии показа, полный контроль над логикой | Отказоустойчивость, замеры и обновления — целиком на стороне приложения |
Сравнение схем подключения делаем по замерам на реальном трафике: доля заполнения, задержка ответа, разброс ставок по часам.
Как проходит настройка: этапы инженерной работы
Медиация решает, какая сеть получит показ при каждом открытии экрана, — ошибка в приоритете или времени ожидания оборачивается упущенными показами. Работы ведём по фиксированному порядку: каждое изменение измеримо и откатывается, а о полном выпуске решаем по цифрам.
- Аудит рекламного инвентаря. Сводим в таблицу точки показа, форматы и сети, сверяем с фактической статистикой: где показ не заполняется, где формат мешает сценарию экрана. Результат — карта инвентаря и список сетей под включение или отключение.
- Схема приоритетов. Прописываем порядок сетей, предельное время ожидания ответа, поведение при отсутствии заполнения и лимиты показов. Схема согласуется до кода — правки здесь не требуют пересборки.
- Настройка и сборка. Подключаем адаптеры сетей и идентификаторы приложений, задаём правила для вознаграждаемых форматов, собираем релиз на актуальных ветках библиотек медиации и прогоняем проверки на регрессии в показах.
- Тестовый трафик. Выпускаем на часть аудитории, разделив её на контрольную и тестовую группы по сопоставимым когортам: тогда разницу в показах объясняет медиация, а не сезонность.
- Замер дохода до и после. Сравниваем доход на активного пользователя, заполняемость и число показов на сессию в обеих группах и проверяем, что рост не куплен падением удержания.
- Передача управления. Отдаём панель с разбивкой по сетям и форматам, регламент изменений и документацию по конфигурации: дальше ваша команда меняет приоритеты и лимиты сама.
Каждый этап оставляет след: видно, что именно дало рост дохода и как вернуть прежние настройки, если метрики пойдут вниз.
Документация, доступы и правила ротации
Настройка медиации не заканчивается в момент, когда приложение перестало терять показы при пустом ответе сети. Всё, что мы выставили в панелях, должно остаться у вашей команды в рабочем и воспроизводимом виде — иначе смена приоритетов или подрядчика по аналитике превратится в археологию по переписке. Ниже — перечень того, что передаём на ваши руки.
- Передаваемые конфигурации — выгрузка медиационных групп: адаптеры сетей, ключи размещений, тестовые и боевые идентификаторы, веса источников. Хранятся в репозитории рядом с кодом приложения, а не только в панелях сетей.
- Схема подключения — порядок инициализации адаптеров, точка первого показа, поведение при отсутствии заполнения и при обрыве сети. Диаграмма плюс описание того, какая ветка кода отвечает за какой сценарий.
- Правила ротации — эшелоны водопада, минимальный порог ставки, ограничение частоты показов на пользователя, отдельные наборы для первого запуска и для возвращающихся. Для аукциона в реальном времени — свой набор правил.
- Роли доступа — кто заходит в панели сетей и агрегатора, отдельные учётные записи для разработки и продакшена, обязательная двухфакторная аутентификация, финансовые разделы закрыты на двух ответственных.
- Отчётность по доходам — сверка начислений агрегатора с панелями сетей, разбивка по гео, формату и источнику, периодичность сверки и ответственный за расхождения.
- Регламент обновления и откат — как обновляются адаптеры сетей с выходом новых версий, порядок проверки на тестовом трафике и хранение предыдущего набора конфигураций, чтобы вернуть ротацию одной правкой.
Кейс: доход с показов вырос после пересборки схемы
Проект — приложение со смешанной аудиторией: часть пользователей оформляет подписку без показов, остальные остаются на условно-бесплатной модели. Первая схема медиации собиралась «по умолчанию»: основная сеть AdMob зафиксирована в приоритете, ставки задавались вручную и не пересматривались, а резервная подключалась только при явной ошибке ответа. Инвентарь простаивал — доход терялся не на объёме показов, а на схеме их распределения.
Что было
Заполняемость держалась около 62%, доля пустых показов в часы низкого спроса доходила до 28%: каждый четвёртый запрос уходил в никуда. Доход на активного пользователя колебался от публикации к публикации — часть запросов обрабатывалась по старым правилам, и разрыв между расчётной и фактической выручкой доходил до 15%. Больше всего терялось на просроченных ответах: основная сеть отвечала дольше отведённого времени, а резервная в этот момент не подключалась.
Что стало
Пересобрали цепочку: каскад с приоритетами по сетям, параллельный запрос к резервным и отдельные правила для подписочной аудитории, чтобы показы не гасились на этапе запроса. Ставки перевели на пересчёт по фактическим данным, а отключение проблемной сети сделали управляемым — без выпуска новой сборки.
Заполняемость выросла до 89%, пустые показы упали до 9%, доход на активного пользователя прибавил около 40% при том же трафике. Разрыв между расчётом и фактом сократился до 3%, а просроченные ответы ушли как класс отказов: запрос уходит к резервной сети раньше, чем истекает время ожидания.
Что делать, если уже подключены несколько источников?
Если источники уже подключены, задача не в том, что добавить, а в том, как перестроить конфигурацию, не уронив доход. Медиация хранит состояние не в коде приложения, а в удалённой конфигурации: приоритеты, доли, время ожидания ответа и порядок опроса сетей приходят с сервера. Поэтому миграцию без остановки монетизации делают раскаткой на часть аудитории, а не выпуском новой версии в магазин приложений.
Два рабочих сценария
| Сценарий | Когда подходит | Ограничения |
|---|---|---|
| Постепенное переключение | Меняются приоритеты или доли внутри уже работающего набора сетей | Дольше: нужно несколько окон замера, чтобы на каждой доле набралась сопоставимая статистика |
| Параллельный запуск с резервом | Подключается новая сеть или обновлённый адаптер, например AdMob | Требует жёсткого разделения трафика: иначе резерв начинает конкурировать с основным источником и размывает ставку |
Проверка на части трафика — обязательный шаг в обоих случаях. Отдаём новой схеме 5–10% аудитории, зафиксированную по идентификатору устройства, и сравниваем с контрольной группой долю заполнений, время ответа, долю отказов и доход на пользователя. Если разрыв в пределах обычных колебаний — долю расширяем, если проседает хоть один показатель — возвращаем предыдущую конфигурацию.
Резервный источник держим подключённым постоянно, а не включаем в аварийный момент: тогда при отказе основной сети показ уходит в неё в пределах одного запроса, без пустого блока в интерфейсе. Откат — это смена конфигурации на сервере, без пересборки и повторной модерации. Так переключение занимает дни, а не релизные циклы, и монетизация не проваливается ни на одном шаге.
Технические вопросы, которые задают перед стартом
Перед стартом инженерная часть сводится к четырём вопросам: как медиационный слой уживается с уже подписанными договорами, что происходит при отказе источника, какие требования к приложению и сколько занимает переход. Ниже — ответы на то, что чаще всего всплывает на созвоне по оценке.
Риски внедрения лежат не в самом медиационном слое, а в порядке раскатки. Поэтому сначала поднимаем копию окружения, прогоняем цепочку источников на тестовом трафике, и только потом включаем её долями — с возможностью вернуться к прежней схеме показа одной настройкой.
У нас есть прямые договоры с рекламными сетями — медиация их ломает?
Нет. Медиация ставится поверх существующих подключений: сети остаются прямыми партнёрами, меняется только точка, из которой запрашивается реклама. Отчётность и ставки сохраняются, а приоритеты и правила чередования задаются в настройках слоя.
Что произойдёт, если источник не отдал рекламу или отвечает медленно?
Запрос уходит следующему в очереди, пока показ не заполнен или список не исчерпан. Для каждого источника задаются свой таймаут и правило повтора, поэтому медленный партнёр не блокирует экран и не оставляет пустое место.
Какие требования к приложению и сколько занимает переход?
Требования минимальные: актуальная ветка приложения, доступ к тестовой сборке и к кабинетам сетей со стороны заказчика. Переход идёт этапами — интеграция слоя, проверка на реальном трафике, постепенное включение на всю аудиторию; откат — обратной настройкой.
Обсудим задачу и вернёмся с оценкой и планом
Чтобы оценка объёма и план работ опирались на факты, а не на предположения, старт начинаем с исходных данных. Ниже — минимальный набор, который присылают на обсуждение задачи; остальное запрашиваем по ходу разбора.
- Текущая схема медиации рекламных сетей: какие сети подключены, как выстроен приоритет, где заданы правила частоты и очередности показа.
- Рабочие доступы к кабинетам рекламных сетей и агрегатора — не демонстрационные, чтобы видеть реальные ставки, заполняемость и отчёты.
- Выгрузка статистики за полный цикл: доход в разрезе сетей, доля незаполненных показов, отставание данных между кабинетом и агрегатором.
- Схема размещения рекламных блоков в приложении: форматы, экраны, как показы пересекаются с ключевыми действиями пользователя.
- Перечень известных сбоев: просадка заполняемости, расхождения в отчётах, жалобы на частоту, ограничения стор-площадок.
- Ограничения сборки: минимальные поддерживаемые версии платформ, состав рекламных библиотек, сроки обновления приложения.
- Ссылка на тестовую сборку и контакт ответственного за рекламный инвентарь — чтобы согласования не растягивались на недели.
Разбираем это за несколько дней и возвращаемся с оценкой: состав работ, порядок этапов, что меняем в приоритетах сетей, что проверяем на тестовом срезе. План фиксируем так, чтобы каждый этап можно было откатить на предыдущую конфигурацию без остановки показов.
