Монетизація та аналітика
Гра вийшла, DAU зростає, але грошей не приходять — або приходять, але неясно звідки. Це класична ситуація, коли монетизація та аналітика були додані «як попалось» замість планування. Переробка системи покупок та аналітичних подій після релізу — дорого та болісно. Розберімо, що потрібно заложити з самого початку.
IAP: архітектура внутрішньоігрових покупок
Технічно інтеграція Unity IAP виглядає просто: підключити SDK, створити каталог продуктів, обробити колбек покупки. На практиці саме тут приховуються більшість проблем — дублювання транзакцій, втрата покупок, відсутність серверної валідації.
Клієнтська vs. серверна валідація
Базова інтеграція Unity IAP працює так: клієнт ініціює покупку, App Store або Google Play повертають квитанцію, клієнт передає її в ігрову логіку і видає предмет. Проблема — клієнта можна зламати. Квитанцію можна підробити або відтворити.
Правильна схема для будь-якої значущої покупки:
- Клієнт ініціює покупку через Unity IAP
- Магазин повертає квитанцію клієнту
- Клієнт відправляє квитанцію на ваш бекенд
- Бекенд валідує квитанцію через Apple App Store API або Google Play Developer API
- Тільки після успішної валідації бекенд видає предмет / зараховує валюту
- Бекенд зберігає ID транзакції — для захисту від replay-атак на одну й ту ж квитанцію
Без серверної валідації ваш магазин вразливий до replay-атак. Це особливо критично для м'якої валюти та бойових пропусків.
Типи продуктів та їхні особливості
| Тип | Приклад | Особливості |
|---|---|---|
| Consumable | Пачка монет, енергія | Можна купувати багатократно, видається кожного разу |
| Non-Consumable | Вимкнення реклами, розблокування контенту | Купується один раз, потребує Restore Purchases (iOS) |
| Subscription | Battle Pass, VIP-статус | Автоматичне продовження, потребує обробки скасування та grace period |
Підписки — найбільш складний тип. Apple та Google по-різному обробляють поновлення, пробні періоди та скасування. Вам потрібна серверна логіка обробки 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 — альтернативний медіатор, часто показує кращий результат у певних географіях.
Практичне правило: якщо гра серйозна — не інтегруйте один рекламний SDK, інтегруйте медіатор (IronSource або MAX) з AdMob, Meta Audience Network та парою регіональних мереж. Різниця в доході може бути 30-60% при одному й тому ж трафіку.
UX-міркування: інтеграція реклами впливає на ретеншн. Rewarded video працює добре — гравці самі вибирають дивитися рекламу за награду. Interstitial між рівнями працює гірше при агресивній частоті показу. Ніколи не показуйте рекламу новим гравцям у перші 24 години — це вбиває ретеншн День 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 — для проектів зі складною структурою даних, real-time синхронізація
Важливо: синхронізувати не весь ігровий стан, а тільки критичні дані — рівень прогресу, куплені предмети, параметри. Важкі дані (replay, скриншоти) зберігати окремо.
Що потрібно вирішити до початку розробки монетизації
- Модель монетизації — premium, freemium, підписка, тільки реклама, гібрид. Визначає архітектуру IAP та рекламної інтеграції
- Бекенд для валідації — потрібен сервер, який буде верифікувати receipts. Якщо його нема, добавте його в обсяг робіт
- Схема аналітичних подій — робиться до кодування. Список подій узгоджується з геймдизайнером та UA-командою
- GDPR/COPPA — якщо аудиторія молодше 13 років або гра для ЄС, потрібна особливої обробки згоди на рекламу та аналітику. Apple ATT-запит впливає на атрибуцію