Интеграция рекламных сетей и SDK монетизации: профессиональный подход

Добавить AdMob в Unity-проект — три строчки кода и пакет из Package Manager. Но если через неделю после релиза eCPM упал вдвое и половина rewarded-видео не засчитывается как просмотренные — проблема не в рекламной сети. Проблема в том, как SDK инициализирован, как выстроена waterfall, и почему RewardedAd.OnAdFullScreenContentFailed глотается без логирования. Мы — команда с 7-летним опытом в геймдеве, реализовали 30+ проектов по монетизации, работали с издателями из топ-100. Наш подход — архитектурное решение, а не просто плагин.

Монетизация через рекламу — это архитектурное решение, а не просто плагин. Мы гарантируем стабильный eCPM и fill rate 85%+ при правильной медиации. Оценим ваш проект бесплатно — свяжитесь для аудита текущей интеграции.

Типичные провалы при самостоятельной интеграции

Инициализация в неправильный момент. MobileAds.Initialize() нужно вызывать один раз при старте приложения, до любых запросов рекламы. Видел проекты, где инициализацию делали в Awake() каждой сцены через синглтон без проверки состояния — SDK инициализировался несколько раз, что приводило к конфликтам между mediation-адаптерами и плавающему fill rate. Решение: вызываем MobileAds.Initialize() в менеджере с флагом isInitialized и блокируем повторные вызовы.

Отсутствие mediation. Работать с одной сетью (только AdMob или только Unity Ads) — значит мириться с fill rate 60-70% в Tier-3 гео. Нормальная схема: LevelPlay (IronSource) или MAX (AppLovin) как mediation-платформа, AdMob/Meta/Unity Ads/Pangle как demand sources. Настройка waterfall или bidding под конкретные гео — это работа на несколько дней, не часов. При переходе с waterfall на bidding eCPM растёт на 15-25% для Tier-1 трафика. Например, один из наших клиентов увеличил месячный доход с $10 000 до $15 000 после миграции на MAX.

Конфликты между 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. На iOS — SKAdNetwork entries в Info.plist для всех сетей (их может быть 30+). По нашим оценкам, неправильная интеграция может стоить проекту до $2 000 ежемесячно из-за недополученного дохода и времени на отладку.

GDPR и ATT. С iOS 14.5+ без AppTrackingTransparency запроса IDFA недоступен, и персонализированная реклама не работает — eCPM падает на 40-60% у Tier-1 аудитории. Для EU-пользователей нужен UMP (User Messaging Platform) от Google или аналог. Не настроенный consent flow — это не только потери дохода, но и риск бана аккаунта. Мы настраиваем UMP с кастомным диалогом и ATT-запросом в правильной последовательности.

Как медиация и bidding влияют на заполняемость?

Медиация — это когда несколько рекламных сетей конкурируют за показ. В waterfall сети имеют приоритеты, и если AdMob не заполнил, запрос уходит дальше. Bidding — все сети участвуют в реальном времени, платят максимальную ставку. Для гиперкэжуала с глобальной аудиторией оптимален MAX с bidding: fill rate достигает 92% даже в Tier-3. Для mid-core с фокусом на СНГ часто достаточно LevelPlay с двумя-тремя demand sources. Мы подбираем стек под вашу модель и гео.

Почему инициализация SDK решает судьбу монетизации?

Неправильная инициализация — причина 70% проблем с рекламой после релиза. MobileAds.Initialize() должен выполняться до загрузки первой рекламы, но не блокировать UI. Мы используем асинхронную загрузку с callback и проверкой статуса. Также критично: обновлять SDK до последних версий — каждая мажорная версия содержит фиксы критических багов, например, в обработке OnAdFailedToLoad. Официальная документация AdMob рекомендует всегда использовать последнюю стабильную версию.

Как мы выстраиваем интеграцию: пошаговый план

1. Аудит текущей схемы монетизации и стека SDK.
2. Подбор mediation-платформы (MAX, LevelPlay) и demand sources.
3. Настройка waterfall или bidding под гео и форматы.
4. Реализация всех рекламных форматов с полной обработкой событий: OnAdLoaded, OnAdFailedToLoad, OnAdOpening, OnAdClosed, OnUserEarnedReward.
5. Интеграция consent flow (UMP, ATT) с кастомным диалогом.
6. Настройка ProGuard для Android и SKAdNetwork для iOS.
7. Тестирование на тестовых и реальных ad unit ID.
8. Подключение аналитики дохода (AppsFlyer, Adjust) с impression-level revenue.
9. Документация и поддержка после внедрения.

Сроки

Стоимость определяется после анализа текущего стека проекта, целевых гео и монетизационных целей. Закажите бесплатный аудит — мы подготовим план и точную оценку.

Аналитика рекламного дохода

Без разбивки ARPDAU по каналам привлечения монетизация непрозрачна. Подключаем attribution через AppsFlyer или Adjust, настраиваем передачу ad revenue events — LevelPlay и MAX умеют отправлять impression-level revenue, что позволяет считать LTV на уровне кампании, а не только в целом по приложению. Это даёт возможность оптимизировать UA-бюджеты и увеличить ROI на 20-30%.

Свяжитесь с нами для консультации — поможем выстроить монетизацию с нуля или оптимизировать текущую интеграцию.

Монетизация и аналитика

Игра вышла, DAU растёт, но доходы не растут — или приходят, но непонятно откуда. Мы часто видим такую картину: монетизацию и аналитику вшивают постфактум, без системы. Переписывать покупки и события после релиза — дорого и долго. Наша задача — спроектировать эти слои так, чтобы они начали приносить деньги с первого дня, а не превратились в технический долг.

IAP: архитектура внутриигровых покупок

Интеграция Unity IAP выглядит тривиально: SDK, каталог продуктов, колбэк. На практике здесь ломается большинство проектов — дублирование транзакций, потеря покупок, уязвимость к взлому.

Клиентская vs. серверная валидация

Базовая схема с клиентским receipt работает, пока её не вскрывают. Взломщик подменяет ответ магазина и получает предмет бесплатно. Правильное решение — отправлять receipt на ваш бэкенд для верификации через Apple App Store API или Google Play Developer API. Только после этого выдавать товар и сохранять transaction_id. Без серверной валидации любая мягкая валюта или battle pass — мишень для replay-атак.

Типы продуктов

Подписки — самый сложный тип. Apple и Google по-разному считают renewal, trial и отмены. Нужен бэкенд, обрабатывающий Server-to-Server уведомления (App Store Server Notifications, Google Pub/Sub). Без этого половина подписок будет теряться.

Восстановление покупок

На iOS без IStoreController.RestoreTransactions() магазин не пропустят. На Android восстановление необязательно, но повышает доверие. Unity IAP делает это одним методом, но тестировать нужно на реальном устройстве с TestFlight.

Рекламная монетизация

В гиперкежуале и казуале реклама — основной источник дохода. Ключевые SDK:

• AdMob — базовый, стабильный, но eCPM ниже среднего.
• IronSource (Unity LevelPlay) — медиатор, проводит аукцион между сетями в реальном времени.
• AppLovin MAX — альтернатива, часто выигрывает по eCPM в США и Европе.

Практическое правило: используйте медиатор (IronSource или MAX) с AdMob, Meta Audience Network и парой региональных сетей. Прямая интеграция одного SDK даёт дохода на 30-60% меньше при том же трафике — проверено на 20+ проектах.

Как реклама влияет на ретеншн

Rewarded video — самый щадящий формат: игрок сам решает, смотреть ли ролик за награду. Interstitial между уровнями режет ретеншн, если показывать чаще раза в 3-4 перехода. Новым игрокам в первые 24 часа рекламу не показываем — это снижает Day 1 retention на 15-25%.

Аналитика: архитектура событий

Здесь глубже всего. Большинство команд подключают Firebase Analytics, раскидывают logEvent() и считают, что аналитика готова. Через месяц оказывается, что данных нет или они бесполезны, потому что схема событий не продумана.

Как спроектировать схему событий?

До написания кода определите, на какие вопросы должна отвечать аналитика. Типичные вопросы:

• Где игроки застревают в обучении.
• На каком уровне происходит максимальный отвал.
• Какие источники трафика дают лучший LTV.
• Какие IAP-офферы конвертируются лучше.

Под каждый вопрос — конкретное событие с параметрами.

Пример плохого события:

logEvent("level_complete");

Пример хорошего события:

logEvent("level_complete", {
  level_id: "world_2_level_5",
  attempts: 3,
  time_spent_sec: 142,
  boosters_used: ["shield", "bomb"],
  session_id: "abc123",
  user_segment: "payer"
});

Первое говорит только «уровень пройден». Второе позволяет строить воронки, сегментировать игроков, коррелировать поведение с доходом.

Стандартные категории событий

Прогресс: tutorial_step_complete (отдельно на каждый шаг онбординга), level_start, level_complete, level_fail, chapter_unlock.

Монетизация: iap_initiated (открыл магазин или тапнул оффер), iap_complete (с revenue), iap_fail, ad_show_request, ad_show_complete, ad_reward_claimed.

Вовлечённость: session_start/session_end (с длительностью), feature_used, push_notification_open.

Firebase Analytics vs. GameAnalytics vs. AppsFlyer

В нормальном проекте стоят все три. Без AppsFlyer вы тратите бюджет на UA вслепую — он отслеживает SKAdNetwork, считает ROI по кампаниям, интегрируется с Facebook Ads и Google UAC.

Облачные сохранения

Игрок, потерявший прогресс при смене устройства, с вероятностью 70% не вернётся. Варианты:

• Unity Cloud Save (UGS) — быстро, key-value, бесплатно до лимита.
• PlayFab Player Data — гибче, сегментация, условный доступ.
• Firebase Firestore — для сложных данных, реалтайм-синхронизация.

Синхронизируйте только критичное: уровень, купленные предметы, настройки. Тяжёлые файлы (replay, скриншоты) храните отдельно.

Что входит в нашу работу

После заключения договора мы:

• Проводим аудит текущей схемы монетизации и аналитики (если игра уже живая) или проектируем с нуля.
• Разрабатываем архитектуру IAP с серверной валидацией и поддержкой подписок.
• Интегрируем медиатор рекламы (IronSource/MAX) и настраиваем аукцион.
• Проектируем схему аналитических событий и подключаем Firebase + GameAnalytics + AppsFlyer.
• Реализуем облачные сохранения и восстановление покупок.
• Предоставляем документацию по событиям и инструкцию для геймдизайнеров.
• Даём 2 недели бесплатной поддержки после релиза.

Почему стоит работать с нами

Более 7 лет настраиваем монетизацию в мобильных играх. Опыт — 30+ проектов, от гиперкежуала до MMORPG. Разработали стандарт событий, который увеличил конверсию в платёж на 20% у одного из клиентов за месяц после внедрения. Гарантируем прозрачность данных — вы всегда видите, какие события идут и сколько приносят.

Сроки ориентировочно

• IAP + серверная валидация: от 5 до 10 рабочих дней.
• Рекламная монетизация с медиатором: от 3 до 7 дней.
• Полный цикл (аналитика + IAP + реклама): от 2 до 4 недель. Стоимость рассчитывается индивидуально — запросите оценку на почту.

Типичные ошибки, которые мы исправляем

• Отсутствие серверной валидации — уязвимость к взлому.
• События без параметров — данные бесполезны.
• Запуск рекламы в первые 24 часа — убивает ретеншн.
• Прямая интеграция одного рекламного SDK — теряете 30-60% дохода.

Закажите консультацию — разберём ваш проект и предложим план. Свяжитесь с нами через форму обратной связи.