Интеграция рекламных сетей и SDK монетизации
Добавить AdMob в Unity-проект — три строчки кода и пакет из Package Manager. Но если через неделю после релиза eCPM упал вдвое и половина rewarded-видео не засчитывается как просмотренные — проблема не в рекламной сети. Проблема в том, как 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 недель |
Стоимость определяется после анализа текущего стека проекта, целевых гео и монетизационных целей.