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