AdTech
Медиация мобильной рекламы для ваших приложений или рекламной сети: использовать платформу медиации, лицензировать готовую или построить свою
Как паблишеру приложений или рекламной сети для приложений выбрать между готовой платформой медиации, white-label продуктом и собственным слоем медиации. Статья также сравнивает, кому на каждом пути принадлежат данные о выручке, договоры с источниками рекламы и SDK и во что обходится смена решения.
Автор: amBrain11 мин чтения
В этой статье
Медиация рекламы — это код внутри приложения, который каждый раз, когда в приложении нужно заполнить рекламное место, запрашивает объявление у нескольких источников рекламы. Затем он старается показать то, за которое заплатят больше всего. Источник рекламы — это любая сеть или биржа, которая может поставлять рекламу. Паблишер приложений или рекламная сеть для приложений может использовать готовую платформу, например Google AdMob, AppLovin MAX или Unity LevelPlay. Можно также лицензировать продукт вендора и запустить его под собственным брендом (white-label) или построить собственный слой медиации. Выбор зависит в основном от того, чем вам нужно владеть. А ещё — от того, сможет ли ваша команда поддерживать в актуальном состоянии SDK, то есть пакет кода, который показывает рекламу, в каждом приложении.
Короткий ответ: если вы выпускаете собственные приложения и у вас нет AdTech-команды, используйте готовую платформу. Каждый день копируйте её данные о выручке по каждому показанному объявлению в собственное хранилище. White-label продукт подходит рекламной сети, которая хочет, чтобы паблишеры устанавливали SDK под её брендом, но не хочет писать его сама. Стройте собственный слой, когда медиация — это то, что вы продаёте, или когда условия платформы отрезают вас от нужных данных или источников рекламы. На любом пути новый SDK доходит до людей только с обновлением приложения.
Что делает медиация внутри приложения?
Приложение показывает рекламу через SDK (software development kit) — пакет кода, который разработчики добавляют в приложение. При медиации главным становится один SDK. Он обращается к нескольким источникам рекламы через адаптеры — небольшие фрагменты кода, которые связывают его с собственным SDK каждой сети.
В справочном центре Google AdMob это сформулировано так: «Медиация позволяет в одном месте управлять источниками рекламы, через которые показываются объявления в ваших приложениях». Unity описывает LevelPlay как «решение для монетизации, которое позволяет разработчикам приложений управлять несколькими рекламными сетями и оптимизировать их с помощью всего одного SDK». Все источники в этой статье открывались 6 ноября 2026 года.
Чем waterfall отличается от in-app биддинга?
Waterfall («водопад») — более старый метод. Паблишер ранжирует источники рекламы по eCPM, выручке на тысячу показов, и SDK опрашивает их по очереди, пока какой-то из них не вернёт объявление. В руководстве AdMob сказано: «Медиация по схеме waterfall вызывает источники рекламы по одному на основе заданного вами среднего eCPM, а не той суммы, которую источник рекламы готов заплатить».
In-app биддинг опрашивает все источники с биддингом одновременно, и каждый называет цену именно за это объявление. В том же руководстве сказано: «Источники с биддингом делают ставки в реальном времени и конкурируют в едином аукционе, а источники в waterfall вызываются по отдельности в порядке их eCPM, который задаёте вы».
Многие схемы совмещают оба метода. В гибридной схеме AdMob выигравшая ставка занимает место в waterfall «в соответствии со значением eCPM», а источники waterfall, стоящие выше неё, вызываются первыми.
AppLovin называет аукцион в MAX аукционом «первой цены» (first-price): победитель платит столько, сколько поставил. Ставки поступают «по протоколу OpenRTB 2.5». OpenRTB — стандарт запросов на ставку от IAB Tech Lab, некоммерческой организации, которая разрабатывает технические стандарты цифровой рекламы. Ставки должны прийти в пределах лимита времени, который называется tmax, а «сервер аукциона MAX объединяет их с источниками спроса без биддинга в waterfall паблишера».
Какими тремя способами можно организовать медиацию?
- Использовать готовую платформу медиации. Вы добавляете в свои приложения её SDK и адаптер для каждого источника рекламы, а waterfall и биддинг настраиваете в её дашборде. Аукцион проводит платформа.
- Лицензировать white-label продукт. Вендор лицензирует вам свой SDK медиации и сервер, который за ним стоит, под вашим брендом. Паблишеры устанавливают SDK под вашим именем, а код поддерживает вендор.
- Построить собственный слой. Ваша команда или нанятая вами компания пишет SDK, адаптеры и сервер аукциона, обычно на открытых стандартах вроде OpenRTB. Код принадлежит вам, и эксплуатируете его вы.
Пути можно совмещать. Prebid Mobile, который Prebid.org называет «библиотекой с открытым исходным кодом для iOS и Android», указывает AdMob и MAX среди поддерживаемых платформ медиации. Ставки он получает от Prebid Server, о котором рассказывает статья о создании собственной supply-side платформы (SSP). SSP — это система, которая предлагает покупателям рекламные места паблишера.
Когда достаточно готовой платформы медиации?
Готовая платформа подходит, когда выполняется большинство из этих условий:
- Вы выпускаете собственные приложения, и рекламная выручка для вас важнее, чем владение рекламной технологией
- В вашей команде некому поддерживать SDK при выходе новых версий iOS и Android
- У нужных вам рекламных сетей уже есть адаптеры для этой платформы
Взамен вы принимаете правила платформы. Она решает, как устроен аукцион и какие биддеры могут в нём участвовать, а её SDK меняется по её собственному графику. Компания, которая проводит аукцион, может и сама продавать в нём рекламу. 6 ноября 2026 года на странице MAX от AppLovin было написано: «Каждая сеть, включая AppLovin, конкурирует в едином аукционе на равных условиях». Проверьте это заявление вендора по своим данным о выручке в разбивке по источникам рекламы.
Рекламная сеть может работать и с паблишерами, которые пользуются готовой платформой: AdMob предлагает custom events (пользовательские события), с помощью которых паблишер может добавить «источник рекламы, который не поддерживает AdMob Mediation».
Когда имеет смысл лицензируемый или white-label продукт?
White-label SDK медиации предлагают компаниям, у которых есть своя рекламная платформа, например рекламной сети для приложений или SSP, которая хочет, чтобы паблишеры отправляли рекламные запросы прямо ей. Берите такой SDK, когда:
- Паблишеры должны устанавливать SDK под вашим именем, чтобы их рекламные запросы сначала попадали на вашу платформу
- У вас есть люди, чтобы подключать паблишеров и поддерживать их, но нет инженеров, чтобы написать и поддерживать SDK
Как описывают такие продукты, видно на примере Teqblaze, вендора AdTech-решений. Его страница SDK называет предложение «брендированным набором для разработки ПО» и говорит, что он «создан для компаний, которые хотят контролировать монетизацию мобильной рекламы, не разрабатывая SDK с нуля». В посте в его блоге за июнь 2024 года сказано, что паблишеры могут «отправлять запросы напрямую на платформу white-label решения». Цен на странице SDK нет. Это собственные заявления вендора.
Бренд ваш, а код остаётся у вендора. Xcode — инструмент Apple для сборки приложений. Когда приложение переходит на новую версию стороннего SDK, Xcode проверяет, «что он подписан тем же разработчиком», поэтому спросите, чья подпись стоит на вашем SDK. Если вендор перестанет обновлять SDK, каждому паблишеру придётся выпустить обновление приложения, чтобы с него уйти.
Когда стоит строить собственный слой медиации?
Стройте, когда выполняется хотя бы одно из условий:
- Медиация — это то, что вы продаёте, например если вы рекламная сеть, которая проводит аукционы в приложениях многих паблишеров
- Вам нужны правила, которые проверенные вами платформы применить не могут, например собственные минимальные цены для каждой группы пользователей. Минимальная цена — это самая низкая ставка, которую вы принимаете.
- Комиссии и доли выручки уже обходятся дороже, чем обошлась бы команда, которая эксплуатирует вашу собственную систему
- Сырые данные о каждом показе (одно объявление, показанное один раз) должны оставаться в ваших собственных системах
После запуска работа продолжается. Каждая сеть продолжает обновлять свой SDK, и адаптер должен успевать за ним. AdMob выпускает новый адаптер для каждой новой версии SDK сети «после тестирования с этим новым SDK». В собственном слое это тестирование проводит ваша команда, а каждая сеть должна согласиться работать с вами по своему договору.
Что принадлежит нам на каждом пути?
Прежде чем подписывать договор или начинать разработку, проверьте четыре вещи.
- Данные о показах и выручке. Все три платформы сообщают выручку по каждому показу, а две из них хранят эти данные ограниченное время. SDK AdMob передаёт её «в момент показа», а комментарий в примере кода Google советует отправлять её «на предпочитаемый вами сервер аналитики прямо в этом колбэке». User-Level Ad Revenue API от AppLovin, интерфейс для выгрузки этих данных, «имеет окно запросов в 45 дней». Unity держит данные LevelPlay на уровне показов за каждую дату «доступными только 14 дней». Копируйте их в собственное хранилище каждый день. С white-label вендором зафиксируйте письменно, что сырые логи принадлежат вам и вы можете выгрузить их в любой момент.
- Отношения с источниками рекламы. На странице настройки Unity сказано: «Чтобы показывать рекламный инвентарь этой сети в своём приложении, у вас должен быть активный аккаунт в ней». В MAX биддеры отправляют ставки на сервер аукциона AppLovin. Спросите каждую платформу, какие подключения останутся вашими, если вы уйдёте. С white-label продуктом проверьте, на чьё имя заключены договоры с покупателями. При собственной разработке каждый такой договор подписываете вы.
- SDK в ваших приложениях. Платформе принадлежат её SDK и его обновления, а white-label вендору — его код. При собственной разработке код может быть вашим — вместе с каждым обновлением и каждым файлом о конфиденциальности.
- Стоимость смены. В App Review Guidelines Apple сказано, что приложения не могут «загружать, устанавливать или выполнять код, который добавляет или изменяет функции или возможности приложения». Политика Google Play гласит, что приложение «не может изменять, заменять или обновлять себя каким-либо способом, кроме механизма обновлений Google Play». Новый SDK медиации доходит до людей только с новой версией приложения, а у тех, кто не обновляется, остаётся старый.
Некоторые изменения не требуют обновления приложения. Порядок waterfall и настройки биддинга хранятся в дашборде платформы. Файл app-ads.txt, в котором перечислены все компании, имеющие право продавать рекламные места паблишера, лежит на сайте разработчика. AdMob напоминает паблишерам: «Если вы используете другую рекламную сеть, не забудьте добавить её в свой файл app-ads.txt».
Какие обязанности перед магазинами приложений и в части приватности приходят с любым рекламным SDK?
Эти обязанности действуют на любом пути. Apple пишет: «Разработчики несут ответственность за весь код, включённый в их приложения». На собственных страницах Apple и Google сказано:
- App Tracking Transparency (ATT). Для iOS Apple пишет: «Чтобы отслеживать пользователей или получать доступ к рекламному идентификатору их устройства, нужно получить их разрешение через фреймворк App Tracking Transparency (ATT)». Отслеживанием Apple называет связывание данных из вашего приложения с данными из приложений, сайтов или офлайн-ресурсов других компаний «в целях таргетированной рекламы или измерения эффективности рекламы». Передача данных пользователя или устройства брокерам данных тоже считается отслеживанием.
- AdAttributionKit и SKAdNetwork. Эти фреймворки Apple сообщают, какая реклама привела к установкам. На странице SKAdNetwork Apple теперь написано: «Используйте AdAttributionKit для рекламных кампаний приложений в App Store и альтернативных магазинах приложений». Рекламные сети «регистрируются в Apple, чтобы получить идентификатор рекламной сети». Apple также пишет: «Право на подтверждение установки имеет только реклама от тех рекламных сетей, для которых есть запись в Information Property List приложения». Этот список поставляется внутри приложения, поэтому новая сеть означает новую версию приложения.
- Манифесты конфиденциальности и подписи. Манифест конфиденциальности — файл, в котором приложение или SDK указывает, какие данные собирает и зачем. Apple поимённо перечисляет определённые SDK. Если вы отправляете на проверку приложение, в котором есть один из них, нужно приложить его манифест конфиденциальности. Если SDK добавлен как бинарный файл (уже собранный код, а не исходники), нужна ещё и его подпись. Разработчикам остальных SDK Apple велит включать манифест, если, среди прочего, SDK «собирает данные о человеке, который пользуется приложениями с этим сторонним SDK» или «обращается к доменам отслеживания».
- Формы о конфиденциальности в магазинах приложений. Apple просит описать ваши практики работы с данными, «включая практики сторонних партнёров, чей код вы интегрируете в своё приложение», и называет среди таких партнёров рекламные сети. Google пишет: «Все разработчики, у которых есть приложение, опубликованное в Google Play, должны заполнить форму Data safety». Форма охватывает данные, «собираемые и обрабатываемые через любые сторонние библиотеки или SDK, используемые в их приложениях».
- Приложения для детей. Google Play пишет: «Если вы показываете рекламу в приложении, а его целевая аудитория включает только детей, вы обязаны использовать только версии рекламных SDK, прошедшие самосертификацию по программе Families». Приложения и для детей, и для пользователей постарше обязаны проверять возраст, например нейтральным запросом возраста, который не подсказывает, какой ответ ожидается. Детям такие приложения могут показывать рекламу только из самосертифицированных версий рекламных SDK. Google требует, чтобы «рекламные SDK и платформы медиации прошли самосертификацию, подтверждающую, что они подходят для детей». AdMob пишет, что его источники с биддингом «не поддерживают показ рекламы для приложений и рекламных запросов, ориентированных на детей». Apple пишет, что приложения категории Kids «не должны включать стороннюю аналитику или стороннюю рекламу». И добавляет, что сторонняя контекстная реклама, то есть объявления, подобранные по тому, что показывает приложение, а не по данным о пользователе, «в ограниченных случаях тоже может быть разрешена».
Правила магазинов приложений меняются, а законы о приватности различаются по странам. Прежде чем добавлять или менять рекламный SDK, проверьте эти пункты у юриста, особенно в приложениях, которыми пользуются дети.
Как проверять viewability и недействительный трафик?
Viewability (видимость) показывает, появилось ли объявление на экране там, где человек мог его увидеть. Open Measurement SDK (OM SDK) от IAB Tech Lab позволяет сторонним измерительным компаниям проверять рекламу в приложениях. IAB Tech Lab пишет, что он «подтверждает, когда объявления появляются на экране, какая их доля видна и как долго», и «упрощает стороннюю проверку недействительного трафика и требований брендов».
На платформе спросите, какие из ваших источников рекламы поддерживают OM SDK. В собственный SDK вы интегрируете его сами, а IAB Tech Lab предлагает сертификацию, которая «подтверждает, что ваша реализация OM SDK работает с провайдерами измерений».
Недействительный трафик — это просмотры рекламы и клики, за которыми не стоит настоящий интерес пользователя. В справочном центре AdMob сказано, что он «охватывает как умышленно мошеннический трафик, так и случайные клики». Две предыдущие статьи объясняют, как рекламная платформа его фильтрует и почему расходятся два набора отчётов.
Сколько стоит каждый путь?
Цены зависят от вендора и вашего объёма, поэтому сравнивайте, как устроена оплата на каждом пути:
- Готовая платформа: выясните, как платформа зарабатывает. 6 ноября 2026 года на странице MAX от AppLovin было написано: «Медиация MAX бесплатна для паблишеров. Сети с биддингом платят AppLovin комиссию с полученной рекламной выручки». Размер этой комиссии там не указан, а на страницах AdMob и LevelPlay, прочитанных для этой статьи, плата за медиацию не упоминалась. Спросите, что и кто удерживает между ставкой рекламодателя и вашей выплатой.
- White-label продукт: плата за подключение или лицензию, ежемесячная плата, доля выручки или их сочетание. Спросите, от чего считается доля.
- Собственная разработка: инженеры для SDK, адаптеров и сервера аукциона. После запуска добавляются серверы и трафик, которые растут вместе с числом рекламных запросов, дежурные сотрудники, сертификация OM SDK и обновления адаптеров.
- Любой путь: время разработчиков на тестирование каждого обновления SDK перед выпуском приложения и юридическая проверка ваших заявлений о конфиденциальности.
Собственная разработка обходится дороже всего до того, как показано первое объявление, а доли выручки растут с каждым объявлением, которое вы продаёте.
Что спросить у компании, которая будет строить или интегрировать для нас медиацию?
- Как сырые данные о выручке по каждому показу будут попадать в наше собственное хранилище и как вы будете сверять их с отчётами каждой сети?
- Для каких рекламных сетей адаптеры будут готовы к запуску и кто обновляет каждый адаптер, когда сеть выпускает новый SDK?
- Как SDK будет вести себя на iOS, если человек откажется от отслеживания, и что будет указано в его манифесте конфиденциальности?
- Кто подписывает SDK и под чьим именем его увидят паблишеры и магазины приложений?
- Будет ли SDK поддерживать OM SDK и кто проведёт его через сертификацию IAB Tech Lab?
- Как реклама для детей и пользователей, чей возраст неизвестен, будет соответствовать политике Families в Google Play?
- Можете ли вы показать, как это работает в приложении, которое сегодня опубликовано в магазинах приложений?
Где здесь место amBrain?
amBrain ведёт этот блог. Три его собственных утверждения касаются серверной стороны описанных здесь путей. Одно звучит так: «amBrain строит supply-side платформы (SSP) для паблишеров». Другое: «amBrain строит ad-серверы: таргетинг, ограничение частоты показов и отчётность». Третье: «amBrain строит пайплайны событийной аналитики для AdTech: сбор и обработка событий показов и кликов и отчётность по ним».
amBrain делает софт с 2019 года. О том, как компания работает с клиентами, она говорит: «Три формата: полная разработка, выделенная команда или инженеры внутри вашей команды». О владении у неё такая строка: «Клиент сохраняет полное владение продуктом и кодом, кроме наших переиспользуемых компонентов». До подписания попросите поимённый список этих компонентов.
Эта статья — не кейс, и работа для клиентов в ней не описывается. В приведённых выше строках amBrain не упоминаются ни платформа медиации, ни мобильный рекламный SDK, ни адаптер для какой-либо рекламной сети. Цен и сроков amBrain статья тоже не приводит. Google, AppLovin, Unity, Teqblaze, Prebid.org, Apple и IAB Tech Lab цитируются по их собственным страницам. Статья никого из них не рекомендует и не утверждает, что с кем-либо из них есть какие-либо отношения.
Это и не юридическая консультация. Прежде чем подписывать договор или выпускать обновление, дайте юристу прочитать договоры с платформой и вендором, а также ваши заявления о конфиденциальности. Если amBrain в вашем шорт-листе, задайте ему те же вопросы, что и любой другой компании.
Темы
- Медиация рекламы
- Мобильные приложения
- In-app биддинг
- Строить или покупать