Настройка подій аналітики мобільної гри (рівні, покупки, retention)
Аналітика мобільної гри без правильно спроектованої таксономії подій перетворюється на набір бесполезних цифр. Типічна картина: у Firebase або Amplitude є 300 подій, але відповісти на питання «чому retention на 7-й день просів з 18% до 11%?» неможливо — потрібні дані або не збиралися, або збиралися з помилками в параметрах.
Архітектура ігрових подій
Таксономія будується на трьох рівнях: сесійні eventi, прогресійні eventi, монетизаційні eventi. Це не просто категоризація — від неї залежить, які воронки й когортні зрізи можна побудувати.
Сесійні eventi — session_start, session_end з session_duration_seconds. На session_end потрібно записувати причину завершення: backgrounded, crashed, voluntary_quit. Це дозволяє відрізнити реальний churn від технічних проблем.
Прогресійні eventi критичні для retention-аналізу. Мінімальний набір параметрів для level_start / level_complete / level_fail:
// Android Kotlin + Firebase Analytics
val bundle = Bundle().apply {
putString("level_id", "world2_level07")
putInt("level_number", 23) // глобальний порядковий номер
putInt("attempt_number", attemptCount) // спроби на цей рівень
putString("difficulty", "hard")
putInt("player_score_before", currentScore)
putInt("coins_before", coinBalance)
putLong("time_in_level_ms", elapsed)
}
Firebase.analytics.logEvent("level_complete", bundle)
attempt_number — поле, яке чаще всього забувають. Без нього не можна виміряти frustration point: скільки спроб гравець робить перед уходом.
Монетизаційні eventi — обов'язково через purchase з параметрами, які FB/Google вимагають для ROAS-атрибуції:
// iOS Swift
Analytics.logEvent(AnalyticsEventPurchase, parameters: [
AnalyticsParameterCurrency: "USD",
AnalyticsParameterValue: 1.99,
AnalyticsParameterItemID: "coin_pack_medium",
AnalyticsParameterItemName: "500 Coins",
AnalyticsParameterItemCategory: "currency",
AnalyticsParameterTransactionID: receipt.transactionIdentifier,
"attempt_number_at_purchase": attemptCount, // кастомний
"level_id_at_purchase": currentLevelId
])
level_id_at_purchase та attempt_number_at_purchase показують, на якому «болевому моменту» прогресії відбувається конверсія в покупку. Це прямий інсайт для дизайну монетизації.
Retention-eventi: що реально потрібно
D1/D7/D30 retention рахується автоматично в Firebase, Amplitude, GameAnalytics — якщо правильно ідентифікований користувач. Головна помилка: використання installationId замість userId після авторизації. Після логіну потрібно викликати:
Firebase.analytics.setUserId(userId) // Firebase
amplitude.setUserId(userId) // Amplitude
Без цього один користувач рахується кількома — retention занижується, конверсії дублюються.
Для retention-аналізу також важлива подія daily_login з параметром days_since_install. Не покладайтесь тільки на системний Session Start — додаток у фоні не генерує сесію, але користувач міг «повернутися», просто не відкривши гру в сесії з активністю.
Інструменти верифікації
Просто додати logEvent недостатньо — потрібно переконатися, що eventi доходять з правильними параметрами:
| Інструмент | Для чого |
|---|---|
| Firebase DebugView | Реалтайм перегляд подій на конкретному пристрої |
| Amplitude Event Inspector | Валідація схеми, перевірка user properties |
| GameAnalytics Validator | Специфічна валідація для ігрових подій |
| Charles Proxy / mitmproxy | Перехоп та інспекція raw payload |
DebugView у Firebase — обов'язковий інструмент QA. Пристрій реєструється через adb shell setprop debug.firebase.analytics.app YOUR_PACKAGE_NAME й всі eventi з'являються в реалтайме з параметрами.
Типичні помилки, які стоять дорого
level_number як рядок замість числа. Здається мелочю, поки не спробуєш побудувати воронку «середня кількість спроб по рівнях» — агрегація зломана.
Запис подій у фоновому потоці без перевірки. Firebase.analytics.logEvent на iOS можна викликати з будь-якого потоку, але на Android деякі SDK вимагають main thread — перевіряйте документацію конкретної версії.
Надмірні eventi. 300 подій в проекті — це майже завжди проблема. Google Analytics 4 обмежує 500 унікальними іменами подій на Firebase-проект. Ігри з агресивним трекінгом упираються в цей ліміт.
Що входить у роботу
- Проектування таксономії подій під конкретний жанр і механіку гри
- Реалізація трекінгу на Unity / нативних iOS (Swift) / нативних Android (Kotlin)
- Настройка user properties та user identification після авторизації
- QA кожної eventi через DebugView / Event Inspector
- Передача документації з описом всіх подій та параметрів
Терміни
Проектування таксономії й реалізація для гри з 20–40 подіями: 3–6 днів залежно від кількості ігрових механік. Вартість розраховується індивідуально.