Монетизация и аналитика
Игра вышла, DAU растёт, но деньги не приходят — или приходят, но непонятно откуда. Это классическая ситуация, когда монетизация и аналитика были добавлены «как придётся», а не спроектированы заранее. Перепиливать систему покупок и события аналитики после релиза — больно и дорого. Разберём, что нужно заложить с самого начала.
IAP: архитектура внутриигровых покупок
Технически интеграция Unity IAP выглядит просто: подключить SDK, создать каталог продуктов, обработать колбэк покупки. На практике именно здесь кроется большинство проблем — дублирование транзакций, потеря покупок, отсутствие серверной валидации.
Клиентская vs. серверная валидация
Базовая интеграция Unity IAP работает так: клиент инициирует покупку, App Store или Google Play возвращают receipt, клиент передаёт его в игровую логику и выдаёт предмет. Проблема — клиент можно взломать. Receipt можно подменить или воспроизвести.
Правильная схема для любых значимых покупок:
- Клиент инициирует покупку через Unity IAP
- Магазин возвращает receipt клиенту
- Клиент отправляет receipt на ваш бэкенд
- Бэкенд валидирует receipt через Apple App Store API или Google Play Developer API
- Только после успешной валидации бэкенд выдаёт предмет / зачисляет валюту
- Бэкенд сохраняет transaction ID — для защиты от повторного использования одного receipt
Без серверной валидации ваш магазин уязвим к replay-атакам. Это особенно критично для мягкой валюты и боевых пропусков.
Типы продуктов и их особенности
| Тип | Пример | Особенности |
|---|---|---|
| Consumable | Пачка монет, энергия | Можно покупать многократно, выдаётся каждый раз |
| Non-Consumable | Отключение рекламы, разблокировка контента | Покупается один раз, нужен Restore Purchases (iOS) |
| Subscription | Battle Pass, VIP-статус | Автоматическое продление, нужна обработка отмены и grace period |
Подписки — наиболее сложный тип. Apple и Google по-разному обрабатывают renewal, trial-периоды и отмены. Необходима серверная логика обработки S2S-уведомлений (Server-to-Server notifications): Apple отправляет их через App Store Server Notifications, Google — через Pub/Sub.
Восстановление покупок
На iOS обязательно реализовать Restore Purchases — иначе App Store отклонит приложение. На Android это не обязательно (Google сам восстанавливает non-consumable), но рекомендуется. Unity IAP предоставляет IStoreController.RestoreTransactions().
Рекламная монетизация
Для free-to-play без IAP или в связке с IAP реклама остаётся основным источником дохода в гиперкежуале и казуальных играх.
Ключевые SDK:
- AdMob (Google) — стандарт для Android, хорошо работает на iOS. Rewarded video, interstitial, banner, app open ads.
- IronSource (Unity LevelPlay) — медиация. Вместо прямой интеграции одного SDK, медиатор в реальном времени проводит аукцион между несколькими рекламными сетями и показывает объявление с максимальным eCPM.
- AppLovin MAX — альтернативный медиатор, часто показывает лучший результат в certain гео.
Практическое правило: если игра серьёзная — не интегрируйте один рекламный SDK, интегрируйте медиатор (IronSource или MAX) с AdMob, Meta Audience Network и парой региональных сетей. Разница в доходе может быть 30-60% при том же трафике.
UX-соображения: интеграция рекламы влияет на ретеншн. Rewarded video работает хорошо — игрок сам выбирает смотреть рекламу за награду. Interstitial между уровнями работает хуже при агрессивной частоте показа. Никогда не показывайте рекламу новым игрокам в первые 24 часа — это убивает ретеншн Day 1.
Аналитика: архитектура событий
Здесь глубже всего. Большинство команд подключают 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
Это разные инструменты, решающие разные задачи, и в нормальном проекте стоят все три.
Firebase Analytics — поведенческая аналитика внутри игры. BigQuery-экспорт, Audiences для сегментации, A/B-тесты через Remote Config. Бесплатно до определённых объёмов. Ограничение: 500 уникальных типов событий на приложение, 25 параметров на событие.
GameAnalytics — специализирована под игры. Из коробки: прогрессия, ресурсы (добавление/трата внутренней валюты), дизайн-события, ошибки. Хорошая бесплатная tier. Слабее Firebase по гибкости кастомных событий, но проще для геймдизайнеров.
AppsFlyer — атрибуция. Отвечает на вопрос «откуда пришёл этот игрок и сколько он принёс». Интегрируется с рекламными кабинетами (Facebook Ads, Google UAC, TikTok Ads), считает ROI по каждой кампании, поддерживает SKAdNetwork для iOS. Без атрибуции вы тратите бюджет на UA вслепую.
Облачные сохранения
Технически не монетизация, но напрямую влияет на ретеншн и конверсию: игрок, потерявший прогресс при переходе на новое устройство, с высокой вероятностью не вернётся.
Варианты:
- Unity Cloud Save (UGS) — простая интеграция, key-value хранилище, бесплатно до определённого объёма
- PlayFab Player Data — гибче, поддерживает сегментацию и условный доступ к данным
- Firebase Firestore — для проектов с сложной структурой данных, реалтайм-синхронизация
Важно: синхронизировать не весь игровой стейт, а только критичные данные — уровень прогресса, купленные предметы, настройки. Тяжёлые данные (replay, скриншоты) хранить отдельно.
Что нужно решить до начала разработки монетизации
- Модель монетизации — premium, freemium, подписка, только реклама, гибрид. От этого зависит архитектура IAP и рекламной интеграции
- Бэкенд для валидации — нужен сервер, который будет верифицировать receipts. Если бэкенда нет, его нужно заложить в объём работ
- Схема аналитических событий — делается до кодирования. Список событий согласовывается с геймдизайнером и UA-командой
- GDPR/COPPA — если аудитория моложе 13 лет или игра для EU, нужна особая обработка согласий на рекламу и аналитику. Apple ATT-запрос влияет на атрибуцию