Проектирование системы монетизации мобильной игры
Монетизация — это не «добавить кнопку купить». Это система, которая должна быть спроектирована одновременно с игровым дизайном, а не прикручена после беты. Игры, где монетизацию добавляли задним числом, легко узнать: IAP-предложения появляются без контекста, rewarded-кнопки висят на главном экране без связи с игровой механикой, а конверсия в платящего пользователя не превышает 0.5%.
Хорошо спроектированная система монетизации — это когда игрок сам ищет, где потратить деньги, потому что это решает его реальную игровую проблему.
Выбор модели монетизации
Перед тем как писать код — нужно ответить на три вопроса: какой жанр, какая целевая аудитория, какой LTV ожидается. От ответов зависит всё.
Free-to-Play с IAP — основная модель для казуальных и мидкор-игр. Игра бесплатна, доход — через покупки внутри. Конверсия в платящего: 2–5% для хорошо оптимизированных игр. ARPPU (средний доход с платящего пользователя) — от $5 до $50+.
Реклама (rewarded + interstitial) — хорошо работает в гиперказуальных и казуальных играх с высоким DAU. Rewarded даёт $10–30 ARPDAU в хайпиковых гиперкажах, interstitial — $2–8. Агрессивная реклама без rewarded быстро убивает retention.
Подписка — растущая модель для игр с регулярным контентом. Конверсия 3–8%, но retention значительно выше, чем у разовых IAP.
Гибридная — комбинация нескольких источников. Правильная гибридная модель распределяет аудиторию: бесплатные игроки монетизируются через рекламу, платящие — через IAP и подписку. Важно не показывать рекламу платящим пользователям — это раздражает и увеличивает churn.
Сравнение моделей по жанру
| Жанр | Основная модель | Дополнительная | Типичный ARPDAU |
|---|---|---|---|
| Гиперказуал | Реклама (interstitial) | Rewarded, IAP no-ads | $0.02–0.08 |
| Казуал (puzzle, match-3) | IAP (extra lives, boosters) | Rewarded | $0.05–0.20 |
| Мидкор (RPG, стратегия) | IAP (валюта, пропуска) | Подписка | $0.15–0.80 |
| Хардкор (MOBA, батлрояль) | Подписка + косметика | Battle Pass | $0.30–2.00 |
Архитектура системы монетизации
IAP: структура продуктов
In-App Purchases делятся на три типа — consumable (расходники), non-consumable (разовые покупки) и subscriptions. Неправильный выбор типа критичен: consumable нельзя «восстановить» через Restore Purchases, non-consumable — можно.
Типичная ошибка при проектировании каталога IAP: слишком много позиций. Исследования App Store показывают, что оптимальное количество IAP-предложений в магазине — 6–8 одновременно. Больше — когнитивная перегрузка, хуже конверсия.
Структура ценовых тиров для мобильных игр обычно выглядит так: starter pack ($0.99–1.99), mid-range bundle ($4.99–9.99), whale offer ($19.99–49.99) и VIP ($99.99). Стартовый пакет с высокой ценностью за низкую цену — главный инструмент конверсии первого платёжа.
Мягкая и твёрдая валюта
Большинство мидкор-игр используют dual-currency систему:
- Мягкая валюта (coins, gold) — зарабатывается в игровом процессе, тратится на базовый прогресс
- Твёрдая валюта (gems, crystals) — покупается за реальные деньги или зарабатывается через rewarded/события, тратится на премиум-контент и ускорение
Конвертация мягкой валюты в твёрдую должна быть ограничена или отсутствовать — иначе теряется смысл покупки твёрдой валюты. Обратная конвертация (твёрдой в мягкую) — допустима, но с невыгодным курсом.
Battle Pass как стержень монетизации
Battle Pass — сезонная механика с двумя треками наград (бесплатный и платный). Экономически работает так: игрок видит привлекательные награды на платном треке и платит авансом за ожидаемые получить их через активный геймплей.
Ключевые параметры при проектировании:
- Длина сезона: 28–42 дня (слишком короткий — не успевают пройти, слишком длинный — теряют интерес)
- Количество уровней: 50–100
- Ежедневный прогресс без платёжей: должен достигать 70–80 уровня за сезон при casual-активности
- Стоимость: $4.99–9.99 базовый, $14.99–19.99 с бонусными уровнями
Rewarded реклама в игровом контексте
Rewarded работает только там, где предложение органично вписывается в потребность. «Посмотри рекламу, получи 10 монет» на главном экране — плохо. «Тебе не хватает 1 жизни, хочешь продолжить бесплатно?» в момент поражения — конверсия 30–50%.
Placement точки, которые работают:
- Продолжение после поражения (continue button)
- Удвоение наград за уровень
- Открытие ежедневного бонусного сундука
- Ускорение таймера строительства/восстановления
Каждый placement — отдельный rewarded placement ID в AdMob/IronSource. Это позволяет видеть в аналитике, какие предложения конвертируются, а какие игнорируют.
Античит и верификация транзакций
Клиентская выдача наград за IAP и rewarded — уязвимость. Минимальный набор защиты:
IAP верификация: Receipt validation через Apple Receipt Validation API или Google Play Developer API. Клиент отправляет receipt на ваш backend, backend верифицирует у Apple/Google, только потом выдаёт товар. Это блокирует replay-атаки с перехваченными receipts.
Rewarded SSV: описано выше — IronSource/AdMob делают callback на ваш endpoint с ECDSA-подписью.
Rate limiting: ограничение количества rewarded в сутки на уровне сервера, не только на клиенте. Клиентский лимит обходится за 5 минут через frida или просто сбросом SharedPreferences.
Аналитика монетизации
Метрики, без которых нельзя оптимизировать монетизацию:
- ARPU (average revenue per user) = общий доход / MAU
- ARPPU (average revenue per paying user) = доход от платящих / количество платящих
- Conversion rate = платящие пользователи / все пользователи
- LTV (lifetime value) — когорта-анализ за 7/14/30/90 дней
- ROAS (return on ad spend) — если есть UA-кампании
Реализуем через Firebase Analytics (logEvent("purchase", ...)) + exportируем в BigQuery для когортного анализа. Impression-level revenue из AdMob/IronSource добавляем в ту же аналитику для полной картины LTV.
Этапы проектирования
- Анализ жанра и конкурентов — изучаем топ-10 похожих игр в сторе, их IAP-каталог, отзывы пользователей о монетизации
- Выбор модели — на основе жанра, аудитории, каналов привлечения
- Проектирование валютной системы — типы валют, источники, стоки, коэффициенты
- Каталог IAP — тиры цен, пакеты, стартовые предложения
- Rewarded placements — точки интеграции, механика предложений
- Технические требования — что реализовывать на клиенте, что на сервере
- План A/B-тестов — какие гипотезы проверяем в первую очередь
Сроки проектирования: 2–3 дня для базовой модели, 5–7 дней для комплексной системы с детальным GDD по монетизации и техническими спецификациями. Стоимость рассчитывается индивидуально.