Інтеграція рекламних мереж та SDK монетизації
Додати AdMob у Unity-проект — три строки коду та пакет з Package Manager. Але якщо через тиждень після релізу Product Manager запитує «чому eCPM упав вдвічі на Android порівняно з iOS» — проблема не в рекламній мережі. Проблема у тому, як SDK ініціалізований, як вибудована waterfall, та чому RewardedAd.OnAdFullScreenContentFailed глотається без логування.
Монетизація через рекламу — це архітектурне рішення, а не плагін.
Типові провали при самостійній інтеграції
Інеціалізація у неправильний момент. MobileAds.Initialize() потрібно викликати один раз при старті додатку, до будь-яких запитів реклами. Бачив проекти, де інеціалізацію робили у Awake() кожної сцени через синглтон без перевірки стану — SDK інеціалізовувався кілька разів, що приводило до конфліктів між mediation-адаптерами та плавучому fill rate.
Відсутність mediation. Працювати з однією мережею (тільки AdMob чи тільки Unity Ads) — значит мирити із fill rate 60-70% у Tier-3 географії. Нормальна схема: LevelPlay (IronSource) або MAX (AppLovin) як mediation-платформа, AdMob/Meta/Unity Ads/Pangle як demand sources. Настройка waterfall чи bidding під конкретні географії — це робота на кілька днів, не годин.
Конфлікти між SDK. AdMob, Meta Audience Network та Unity Ads тягнуть свої версії com.google.android.gms, play-services-ads та нативних бібліотек. При ручному управлінні залежностями у mainTemplate.gradle легко словити DuplicateClass чи NoSuchMethodError у рантаймі на Android. Правильний шлях — External Dependency Manager (EDM4U) з чіткими force-резовліами у Dependencies.xml.
GDPR та ATT. З iOS 14.5+ без AppTrackingTransparency запиту IDFA недоступний, та персоналізована реклама не працює — eCPM падає на 40-60% у Tier-1 аудиторії. Для EU-користувачів потрібен UMP (User Messaging Platform) від Google або аналог. Не настроєний consent flow — це не тільки втрати доходу, але й ризик бану аккаунту.
Як вибудовуємо інтеграцію
Починаємо з вибору mediation-стека під конкретний проект. Для гіперкажуального з глобальною аудиторією — MAX з bidding, для mid-core з СНГ-фокусом — іноді достатньо LevelPlay з двома-трьома demand sources.
Формати реклами під монетизаційну модель гри: interstitial між рівнями, rewarded за продовження чи внутрішньоігрову валюту, banner у меню (обережно — баннери убивають UX, ставимо тільки якщо явно потрібно). Кожен формат реалізуємо з повною обробкою подій: OnAdLoaded, OnAdFailedToLoad, OnAdOpening, OnAdClosed, OnUserEarnedReward.
Для rewarded критично: блокувати повторний запит EarnedReward якщо користувач вийшов з додатку в момент перегляду та повернувся — подвійна видача валюти відбувається саме так.
На Android настроюємо ProGuard-правила для кожного SDK — без них у release-білді половина рекламної логіки стрипається obfuscation'ом. На iOS — SKAdNetwork entries у Info.plist для всіх використовуваних мереж (їх може бути 30+).
Тестування робимо на тестових ad unit ID у девелоперському оточенні, потім — на реальних з обмеженим трафіком через internal testing channel.
Аналітика рекламного доходу
Без розбивки ARPDAU за каналами привлечення монетизація непрозора. Підключаємо attribution через AppsFlyer чи Adjust, настроюємо передачу ad revenue events — LevelPlay та MAX умеют надсилати impression-level revenue, що дозволяє рахувати LTV на рівні кампанії, а не тільки в цілому по додатку.
Строки
| Сценарій | Строк |
|---|---|
| Одна рекламна мережа, базові формати | 3–5 днів |
| Mediation (2-3 мережі) + GDPR/ATT + аналітика | 1,5–3 тижні |
| Повний mediation-стек з bidding + attribution | 3–5 тижнів |
Вартість визначається після аналізу поточного стека проекту, цільових географій та монетизаційних цілей.