Інтеграція Yandex Mobile Ads: де застосунок втрачає дохід
Інтеграція реклами в застосунок найчастіше будується просто: запит надсилається в момент відкриття екрана. На нестабільній мережі відповідь не встигає повернутися до переходу користувача далі — запит надіслано, показ не відбувся, і у звітах він проходить як порожній. Аудиторія та сама, а дохід на користувача просідає.
Друга точка втрат — як запит доходить до аукціону. Якщо формати не підібрані під розмір і контекст екрана, частина запитів потрапляє туди без конкуренції, частина не доходить узагалі: слот залишається порожнім або заповнюється найдешевшим варіантом.
Окремий випадок — показ, який зараховується, коли екрана вже не видно: мережа його не приймає, а застосунок витрачає трафік.
Третя причина — налаштування, виставлені один раз під час запуску.
Частотні обмеження, порядок перемикання між мережами, поведінка за відсутності заповнення, оновлення ставок у Яндекс Рекламі після зміни аудиторії — усе це впливає на монетизацію мобільного застосунку сильніше, ніж прийнято думати.
Розрив між кількістю запитів і кількістю зарахованих показів і є втратою доходу застосунку — його видно у звітах ще до правок. Далі розбираємо, як закривається кожне з цих місць і які метрики вважаємо підтвердженням результату.
Що дає коректно налаштована реклама в застосунку
Покази в застосунку — керований ресурс, а не «увімкнули й працює». Частота показів на користувача, набір форматів (міжсторінковий, з винагородою, банер) і точки виклику задають, скільки рекламних подій отримає кожен активний користувач за сесію.
Формат із винагородою змінює логіку: увага обмінюється на внутрішньоігрову цінність, і такий показ не сприймається як перешкода.
Заповнюваність тримається на медіації: запит надсилається в кілька джерел із пріоритетами й таймаутами, у разі порожньої відповіді спрацьовує підстраховка.
Yandex Mobile Ads працює як одне з джерел попиту — його частка в потоці задається вагами, тому просідання одного каналу не обнуляє покази в застосунку.
Дохід із трафіку зростає без залучення нової аудиторії: той самий сеанс дає більше показів за високими ставками, а ліміт частоти не виснажує користувача.
Міжсторінкові та покази з винагородою розставляються за подіями — завершення рівня, повернення в меню, — а не посеред введення даних чи оплати.
Для утримання важливіша передбачуваність, ніж кількість. Обмеження показів на годину, виключення першого сеансу й пауза після невдалої дії знижують роздратування, при цьому показів на активного користувача залишається стільки ж.
Підсумок видно у звітах: заповнюваність тримається на цільовому рівні, дохід із трафіку й дохід на активного користувача зростають, а видалення застосунку після рекламних сесій не частішають. Ми звіряємо ці показники за когортами до й після переробки схеми.
Формати показів і режими медіації рекламних мереж
Формат показу й спосіб підключення мереж — два незалежні рішення, і плутати їх дорого.
Реклама з винагородою тримається на добровільному перегляді й дає найвищий відгук, міжсторінкові вставки монетизують паузи між діями, а нативні блоки вбудовуються в стрічку й не ламають верстку.
Формат вибирається під сценарій, але якщо мережа одна, застосунок швидко впирається в стелю: для частини аудиторії показ просто не знаходиться.
Готові формати Yandex Mobile Ads закривають базовий сценарій однією інтеграцією, а далі потрібна медіація рекламних мереж — запит надсилається кільком джерелам, і показ забирає той, хто запропонував кращі умови.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Одна мережа | Швидкий запуск, один формат, передбачувана аудиторія | Заповнюваність просідає на вузькому гео та в години низького попиту, підстраховки в разі відмови джерела немає |
| Медіація рекламних мереж | Кілька форматів одразу, потрібна висока заповнюваність | Потрібні правила пріоритету й контроль затримки завантаження блоку |
| Пріоритетний аукціон | Зрілий трафік, є чим керувати ставками | Дохід гірше прогнозується, потрібна аналітика по кожному джерелу |
Каскад пріоритетів простіше налагоджувати, і він передбачуваний за часом відгуку; єдиний аукціон точніше перерозподіляє потік, але потребує власної аналітики. Схему фіксуємо в конфігурації медіації — формати вмикаються по одному й змінюються без перезбирання застосунку.
Етапи впровадження: від аудиту розміщень до передачі налаштувань
Впровадження реклами в застосунок починається не з підключення бібліотеки, а з аудиту монетизації. Дивимося, які екрани користувач проходить, де затримується, де закриває застосунок, і зіставляємо це з уже підключеними джерелами, включно з Yandex Mobile Ads.
Результат етапу — схема розміщень: скільки блоків, на яких екранах, із якою частотою і як вони поступаються одне одному.
- Аудит сценаріїв і поточної монетизації: карта екранів, тривалість сесії, місця обриву, перелік працюючих джерел.
- Схема розміщень: формат під кожен екран — банер, міжсторінковий на природних паузах, з винагородою за дією користувача, нативний усередині контенту.
- Налаштування рекламних блоків: окремий ідентифікатор на формат, порядок джерел у ланцюжку, інтервали між показами, поведінка за відсутності заповнення.
- Перевірка показів на реальних збірках: тестові пристрої, прогін на слабкому інтернеті та в офлайні, заповнюваність за регіонами, коректність закриття й повернення в застосунок.
- Калібрування за метриками: частка показів до запитів, вплив на утримання й глибину сесії, правка частоти там, де зростає відтік.
- Передача команді: конфігурації, список блоків, документація й правила зміни частот без випуску нової версії застосунку.
Налаштовані блоки, схеми розміщень і документація
Робота з рекламою в застосунку не закінчується на підключенні Yandex Mobile Ads — цінність залишається в артефактах, які переживають реліз.
Без них кожна наступна зміна починається з археології: де стояв блок, чому в нього саме такий інтервал, з якої причини вимикали джерело при просіданні заповнюваності. Тому передаємо замовнику повний комплект, а не усні домовленості.
- Карта розміщень — екран, позиція в розмітці, формат блоку, поведінка при прокручуванні та логіка відкладеного підвантаження.
- Конфігурації блоків — ідентифікатори, прив’язка до місць показу, пріоритет джерел у медіації, умови включення резервного джерела.
- Правила частоти — інтервали між показами, обмеження на старті сесії, поведінка за слабкої мережі й ліміт на один екран.
- Регламент показів — що робити за порожньої відповіді, таймауту й помилки ініціалізації, коли блок ховається зовсім.
- Інструкції для розробників — як додати новий блок, які перевірки пройти, як перемкнути джерело без випуску нової збірки.
- Документація з монетизації — які метрики знімаємо (покази, заповнюваність, утримання) і як за ними ухвалюються рішення про перестановку блоків.
- Схеми та чек-ліст приймання — порядок ініціалізації, обробка збоїв, порядок відкату конфігурації до попередньої робочої версії.
Комплект живе поряд із кодом, а не в листуванні: карта розміщень оновлюється разом з екранами, правила частоти винесені в конфігурацію, інструкції описують дії, що не потребують участі автора інтеграції. Новий інженер вводить блок за документом, не відновлюючи історію рішень.
Кейс: як зросла заповнюваність показів після доопрацювання
Клієнт — сервіс із щоденним сценарієм використання: користувач відкриває застосунок кілька разів на день, але сесії короткі.
Монетизація трималася на одному рекламному модулі Yandex Mobile Ads й одному форматі, який викликався лише при вході в стрічку, — тому показів запитувалося менше, ніж відбувалося переходів між екранами.
Що було
Заповнюваність показів трималася близько 46%: частина запитів не встигала отримати оголошення за відведений час очікування, частина приходила, коли екран уже закривався.
На активного користувача припадало 2,8 показу на добу, а відтік на екранах із рекламою сягав 21% — понад половина йшли в перші секунди після вставки.
Що змінили
Розвели покази за екранами й сценаріями: один формат — на переходах між розділами, другий — усередині стрічки, третій — за бажанням, за бонусний контент.
Налаштували попереднє завантаження оголошення, порядок запитів за недоступності основного джерела, обмеження частоти на користувача й м’яке очікування відповіді, щоб порожня відповідь не блокувала інтерфейс.
Показ більше не стартує, поки екран не відрисовано: реклама перестала перекривати кнопки й провокувати закриття.
Що стало
Заповнюваність зросла з 46% до 88%, покази на активного користувача — з 2,8 до 7,4 на добу, відтік на екранах із рекламою впав до 7%, а скарг на нав’язливість стало майже втричі менше.
Порівнювали з контрольною групою, де порядок показів залишився попереднім: там метрики не змінилися, тому зростання показів не списали на сезонність.
Чим відрізняється пряма інтеграція Yandex від медіації мереж
Пряме підключення реклами — це коли застосунок звертається до однієї мережі й віддає їй весь слот. Шлях від запиту до креативу коротший, посередників немає, і на трафіку, де мережа конкурує за аудиторію, дохід із показу вищий.
Зворотний бік — заповнюваність дорівнює інвентарю однієї мережі: у рідкісному гео, вночі або при збої на її боці блок залишається порожнім, і цей показ втрачено безповоротно.
Медіація мереж ставить між застосунком і рекламодавцями шар-арбітр. Працюють два механізми: пріоритет мереж — черга, де мережа викликається за заздалегідь відомим доходом із показу, і аукціон показів — мережі конкурують за кожен конкретний показ у реальному часі.
Черга простіша в налаштуванні й передбачуваніша, аукціон вичавлює більше з якісного трафіку, але потребує чесної статистики: на кривих даних він починає віддавати покази найдешевшим мережам.
Порівняння підходів упирається в задачу. Там, де потрібні стабільний дохід і заповнюваність під 95% на будь-якому пристрої, виграє медіація: не віддала креатив одна мережа — слот підхоплює наступна за пріоритетом.
Там, де важливі контроль над форматами, передбачуваність і максимальна ставка на своєму трафіку, — пряме підключення.
На практиці частіше збираємо гібрид: основну частину трафіку закриває пряме підключення Яндекс Мобайл Реклама як джерело першого пріоритету, а медіація страхує провали заповнюваності.
Щоб вибрати конфігурацію, вмикаємо обидва варіанти на зіставних сегментах аудиторії й дивимося заповнюваність, дохід на тисячу показів і частку блоків, що залишилися без реклами.
Пріоритети перезбираємо за фактичними даними, а не за обіцянками мереж: черга, виставлена приблизно, тихо втрачає відсотки виторгу на рівному місці.
Часті технічні питання про рекламу в застосунку
Перше питання зазвичай про терміни. Тестовий показ запускається того самого дня на тестовому ідентифікаторі блоку.
Бойові вмикаються після модерації акаунта й заповнення платіжних даних — це кілька робочих днів, і від коду вони не залежать: якщо застосунок уже зібрано, затримка майже завжди сидить у налаштуваннях акаунта.
Друге — «мережу підключено, а показів немає». Діагностика йде ланцюжком: модуль реклами ініціалізується до першого екрана, запит надсилається з валідним ідентифікатором, відповідь мережі доходить і логується, оголошення відрисовується у виділеній області.
Обрив на будь-якому кроці дає порожній блок без помилки — тому кожен етап логуємо окремо, а не шукаємо причину навмання.
Мережу вже підключено, але показів майже немає — що перевіряємо?
Спочатку виключаємо помилки інтеграції: момент ініціалізації, валідність ідентифікатора, наявність місця під банер, поведінку при зміні орієнтації та згортанні застосунку. Якщо код чистий, дивимося налаштування самої мережі — географію, категорію контенту, частотні обмеження. Далі це питання заповнення, а не розробки.
Хто відповідає за обмеження на боці мережі?
Частка заповнення, географія, антифрод і правила модерації задаються рекламною мережею Яндекс, і ми на них не впливаємо.
Наша зона — коректний запит, готовність екрана й прозора статистика: ви бачите, скільки запитів пішло і на якому кроці вони відсіялися, і з цим уже можна йти в підтримку мережі.
Реклама псує користувацький досвід — це якось обмежують?
Формати й частоту задаємо ми: міжсторінкова реклама лише між екранами, не поверх дій, ліміт показів одному користувачу за сесію, вимкнення на платних тарифах. Це налаштовувані параметри, а не разовий компроміс — значення змінюються після запуску без перезбирання застосунку.
Обговоримо задачу й повернемося з оцінкою та планом робіт
Обговорити задачу можна на будь-якому етапі — коли застосунок лише проєктується або вже живе в сторах і потребує рекламного блоку. Щоб оцінка проєкту була точною, а не «на око», інженерам достатньо опису продукту й доступу до поточного коду. Далі терміни рахуємо за етапами, а не однією цифрою на весь обсяг.
Що надіслати для старту:
- короткий опис застосунку: платформа, аудиторія, на якому етапі продукт — розробка, реліз чи підтримка;
- екрани й сценарії показу: між рівнями, після дії, у стрічці, на паузі;
- потрібні формати — банер, міжсторінковий, з винагородою за перегляд, нативний;
- доступ до репозиторію або збірки, якщо інтеграція йде в готовий продукт;
- доступи до акаунта рекламної мережі й тестові ідентифікатори місць показу, якщо вони вже заведені;
- метрики, за якими будете приймати роботу: заповнюваність, утримання, вплив на конверсію.
Старт робіт — після погодження плану й обсягу першої ітерації.
План збираємо в порядку реальної інтеграції: розмітка місць показу, підключення рекламної мережі в тестовому режимі, перевірка на живих пристроях і слабкій мережі, потім реліз і передача проєкту з документацією щодо заведення нових блоків.
Це дає змогу змінювати частотність і сценарії без звернення до нас. Опишіть задачу — повернемося з оцінкою проєкту, планом робіт і пропозицією щодо термінів.
