Разработка внутриигровой монетизации и игровой экономики

Мы разрабатываем системы внутриигровой монетизации с учётом баланса и пользовательского опыта. Более 8 лет мы интегрируем IAP, рекламу и подписки для игр разных жанров — от гипер-казуальных до мидкор RPG. Наша команда реализовала монетизацию в 40+ проектах, используя проверенные стеки: Unity IAP, PlayFab, AppLovin MAX. Когда монетизацию добавляют в конце разработки, она либо нарушает игровой баланс, либо воспринимается игроком как инородное тело — это снижает ARPU и рейтинг. Свяжитесь с нами для аудита или проектирования монетизационной модели.

Как работают IAP в Unity и Unreal?

Основной инструмент для мобильных игр — IAP (In-App Purchases). На Unity реализуется через Unity IAP пакет — единый API для Google Play Billing и Apple StoreKit. Базовая интеграция несложная, но есть нюансы.

Receipt validation. Проверка чека на клиенте бесполезна — любой рутованный Android позволяет сгенерировать фейковый чек. Серверная валидация обязательна: клиент отправляет receipt на бэкенд, бэкенд проверяет через Google Play Developer API или Apple App Store Server API, затем начисляет валюту. Без этого любой читер получает бесплатную валюту за 5 минут. Apple App Store Server API docs рекомендуют именно такой подход.

Consumable vs. Non-consumable vs. Subscription. Consumables (кристаллы, монеты) требуют подтверждения транзакции после начисления: controller.ConfirmPendingPurchase(product). Если не вызвать — Google/Apple вернёт покупку при следующем запуске. Non-consumables (разблокировка контента) должны восстанавливаться через RestorePurchases() — это требование App Store.

Оффлайн-устойчивость. Покупка может начаться при хорошем соединении и завершиться при плохом. Храним состояние транзакции локально (PlayerPrefs или SQLite), обрабатываем pending purchases при следующем запуске. Это в 10 раз снижает количество потерянных транзакций по сравнению с игнорированием PlayFab documentation.

Игровая валюта и экономика

Двойная валюта (мягкая + твёрдая) — стандарт для мидкор игр. Техническая реализация:

• Бэкенд как источник истины. Баланс валют хранится на сервере, клиент — только отображает. Локальный кэш для отзывчивости UI, но всегда синхронизируется с сервером. PlayFab Virtual Currency — готовое решение с транзакционностью и историей операций.
• Защита от race condition. Параллельные запросы на списание (одновременное нажатие кнопки покупки) должны обрабатываться атомарно. PlayFab CloudScript выполняется в одном потоке на пользователя — это решает проблему. Собственный бэкенд требует транзакций в БД.
• Аудит транзакций. Каждое изменение баланса — запись в лог с причиной, суммой, timestamp. Без этого невозможно расследовать жалобы игроков и детектировать аномалии.

Реклама (Ad Monetization)

Для гипер-казуальных и казуальных игр — основной источник дохода. Стек:

• UnityAds — наиболее простая интеграция для Unity-проектов.
• IronSource / AppLovin MAX — mediation платформы, позволяют конкурировать нескольким ad-сетям за показ. Ставки выше на 20-40% по сравнению с одной сетью.
• Rewarded Video требует корректной интеграции с геймплеем: показываем рекламу только в органических точках (Game Over, перед бонусным уровнем), не принудительно.

Interstitial между уровнями — ставим через счётчик, не после каждого уровня. Частота определяется A/B тестированием через Firebase Remote Config или PlayFab Experiments.

LiveOps и события

Временные события, battle pass, сезонный контент — это отдельная инфраструктура. Конфигурация событий живёт на сервере, клиент скачивает при запуске. PlayFab Title Data или собственное CMS. Важно: клиент не должен хардкодить даты событий — это гарантированный баг при изменении расписания.

Battle Pass технически: track прогресса в PlayFab Statistics, milestone rewards через PlayFab CloudScript, отображение прогресса через Addressable-бандлы с иконками наград (чтобы не раздувать base build).

Почему монетизацию нельзя добавлять в конце

Реальный кейс: мобильный match-3, баланс прогрессии спроектирован под fun, без учёта монетизации. На этапе интеграции IAP выяснилось, что игрок проходит весь контент за 4 часа без единой покупки. Пришлось переделывать кривую сложности и добавлять energy system — что потребовало переработки 60% геймплейных систем.

Монетизационная модель должна быть частью GDD с первого дня. Это определяет: кривую прогрессии, структуру валют, точки конверсии, ценность каждого ресурса.

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

• Аудит монетизационной модели — анализ текущей экономики, точек конверсии, конкурентов.
• Проектирование экономики — sink/source баланс, двойная валюта, ценность предметов.
• Интеграция IAP — Unity IAP, серверная валидация, обработка edge cases.
• Настройка рекламы — UnityAds, IronSource/MAX, rewarded video, interstitial.
• Battle Pass и LiveOps — конфигурация событий, трекер прогресса, награды.
• Аналитика монетизации — воронки конверсии, настройка Firebase/Amplitude.
• Документация и обучение — передача инструментов, описание процессов.
• Поддержка после запуска — мониторинг, A/B-тесты, доработки.

Процесс работы

1. Аналитика и проектирование (3-5 дней). Анализ жанра и конкурентов, выбор монетизационной модели, проектирование экономики (sink/source баланс ресурсов).
2. Бэкенд-инфраструктура (1-2 недели). Настройка PlayFab или собственного бэкенда: валюты, каталог предметов, CloudScript для транзакций, серверная валидация чеков.
3. Клиентская интеграция (1-2 недели). Unity IAP, UI магазина, интеграция с геймплеем, обработка edge cases (нет сети, failed purchase, restore).
4. Аналитика (3-5 дней). Настройка воронок конверсии в Firebase/Amplitude: просмотр магазина → инициация покупки → успешная покупка. Отслеживание retention в разрезе монетизационных сегментов.
5. QA и сэнда́кс. Sandbox-тестирование IAP на тестовых аккаунтах Google и Apple. Проверка всех edge cases: отмена покупки, failed payment, восстановление покупок.

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