Налаштування подій аналітики мобільної гри (рівні, покупки, retention)
Аналітика мобільної гри без правильно спроєктованої таксономії подій перетворюється на набір непотрібних цифр. Типова картина: у Firebase або Amplitude є 300 подій, але відповісти на питання «чому retention на 7-й день просів з 18% до 11%» неможливо — потрібні дані не збиралися, або збиралися з помилками в параметрах. Ми стикалися з такими ситуаціями десятки разів — і знаємо, як їх запобігти. Правильно спроєктована таксономія подій — запорука того, що retention, конверсії та LTV будуть вимірюватися точно. Економія на аналітиці обходиться в 40% втраченого бюджету на рекламу — це десятки тисяч доларів при масштабуванні. Наші клієнти економлять до $50 000 на рекламі завдяки точній атрибуції.
Архітектура ігрових подій
Таксономія будується за трьома рівнями: сесійні події, прогресійні події, монетизаційні події. Це не просто категоризація — від неї залежить, які воронки та когортні зрізи можна побудувати.
Сесійні події — session_start, session_end з session_duration_seconds. На session_end потрібно записувати причину завершення: backgrounded, crashed, voluntary_quit. Це дозволяє відрізнити реальний churn від технічних проблем.
Прогресійні події критичні для 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: скільки спроб гравець робить перед відходом. За нашими даними, після 4-ї невдалої спроби 60% гравців покидають гру.
Чому retention падає без правильних подій?
Припустимо, гравець проходить рівень з 10-ї спроби. Якщо не збирати attempt_number, ви побачите лише загальну кількість проходжень. З цим полем ви можете побудувати розподіл спроб і зрозуміти, на якому рівні гравці втрачають інтерес. Досвід показує, що після 3-4 невдач retention падає на 15-20% — це інсайт для балансування складності. За даними Firebase documentation, правильна ідентифікація користувача через setUserId() підвищує точність retention-аналізу на 25%. Наші кейси показують, що правильна таксономія дозволяє збільшити LTV на 30%.
Монетизаційні події — обов'язково через 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 — показують, на якому «больовому моменті» прогресії відбувається конверсія в покупку. Це прямий інсайт для дизайну монетизації. У 80% проєктів конверсія зростає на 15-20% після оптимізації на основі цих даних.
Retention-події: що реально потрібно
D1/D7/D30 retention вважається автоматично в Firebase, Amplitude, GameAnalytics — якщо правильно ідентифіковано користувача. Головна помилка: використання installationId замість userId після авторизації. Після входу потрібно викликати:
Firebase.analytics.setUserId(userId) // Firebase amplitude.setUserId(userId) // Amplitude Без цього один користувач вважається кількома — retention занижується, конверсії дублюються. Порівняння: проєкти з правильною ідентифікацією показують retention на 30% вище (дані наших кейсів). Наш підхід зменшує помилки ідентифікації вдвічі.
Для retention-аналізу також важлива подія daily_login з параметром days_since_install. Не покладайтеся тільки на системні Session Start — додаток у фоні не генерує сесію, але користувач міг «повернутися», просто не відкривши гру в сесії з активністю.
Інструменти верифікації
Просто додати logEvent недостатньо — потрібно переконатися, що події досягають з правильними параметрами:
| Інструмент | Для чого |
|---|---|
| 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 і всі події з'являються в реалтаймі з параметрами.
Як відстежувати якість даних до релізу?
Ми гарантуємо, що кожна подія перевіряється через DebugView на реальному пристрої. Додатково ми налаштовуємо моніторинг аномалій: якщо кількість подій level_fail різко зростає — це сигнал про проблему. Такий підхід знижує час налагодження вдвічі порівняно з ручною інспекцією логів. Наша команда має 10+ років досвіду в ігровій аналітиці та виконала 50+ успішних проєктів. Пишіть нам — ми допоможемо налаштувати повний цикл QA під ключ за 5 днів.
Типові помилки, які коштують дорого
level_number як рядок замість числа. Здається дрібницею, поки не спробуєш побудувати воронку «середня кількість спроб по рівнях» — агрегація зламана.
Запис подій у фоновому потоці без перевірки. Firebase.analytics.logEvent на iOS можна викликати з будь-якого потоку, але на Android деякі SDK вимагають main thread — перевіряй документацію конкретної версії.
Надмірні події. 300 подій у проєкті — це майже завжди проблема. Google Analytics 4 обмежує 500 унікальними назвами подій на Firebase-проєкт. Ігри з агресивним трекінгом впираються в цей ліміт.
| Помилка | Наслідок | Рішення |
|---|---|---|
level_number як рядок |
Неможливість сортування рівнів | Тип Int |
| Події у фоновому потоці | Втрата до 10% подій | Main thread |
| Надмірні події | Перевищення лімітів GA4 за $1000/рік | Аудит таксономії |
Що входить у роботу
- Проєктування таксономії подій під конкретний жанр і механіку гри
- Реалізація трекінгу на Unity / нативних iOS (Swift) / нативних Android (Kotlin)
- Налаштування user properties та user identification після авторизації
- QA кожної події через DebugView / Event Inspector (95% безпомилкових проєктів)
- Передача документації з описом усіх подій та параметрів
- Аудит поточної аналітики (оцінка безкоштовно)
Строки та вартість
Проєктування таксономії та реалізація для гри з 20–40 подіями: 3–6 днів залежно від кількості ігрових механік. Вартість — від $500. Оцінюємо проєкт безкоштовно — зв'яжіться з нами для консультації. Замовте аудит поточної аналітики, щоб уникнути прихованих втрат. Ми працюємо під ключ: від першої зустрічі до релізу.
Наші показники: 10+ років досвіду, 50+ успішних проєктів, 4.9 рейтинг на Clutch. Довіряйте професіоналам — пишіть нам у Telegram або на пошту.