Настройка событий аналитики мобильной игры (уровни, покупки, retention)
Аналитика мобильной игры без правильно спроектированной таксономии событий превращается в набор бесполезных цифр. Типичная картина: в Firebase или Amplitude есть 300 событий, но ответить на вопрос «почему retention на 7-й день просел с 18% до 11%» невозможно — нужные данные не собирались, либо собирались с ошибками в параметрах.
Архитектура игровых событий
Таксономия строится по трём уровням: сессионные события, прогрессионные события, монетизационные события. Это не просто категоризация — от неё зависит, какие воронки и когортные срезы можно построить.
Сессионные события — 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: сколько попыток игрок делает перед уходом.
Монетизационные события — обязательно через 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-события: что реально нужно
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 недостаточно — нужно убедиться, что события доходят с правильными параметрами:
| Инструмент | Для чего |
|---|---|
| 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 и все события появляются в реалтайме с параметрами.
Типичные ошибки, которые стоят дорого
level_number как строка вместо числа. Кажется мелочью, пока не попытаешься построить воронку «среднее количество попыток по уровням» — агрегация сломана.
Запись событий в фоновом потоке без проверки. Firebase.analytics.logEvent на iOS можно вызывать из любого потока, но на Android некоторые SDK требуют main thread — проверяй документацию конкретной версии.
Избыточные события. 300 событий в проекте — это почти всегда проблема. Google Analytics 4 ограничивает 500 уникальными именами событий на Firebase-проект. Игры с агрессивным трекингом упираются в этот лимит.
Что входит в работу
- Проектирование таксономии событий под конкретный жанр и механику игры
- Реализация трекинга на Unity / нативных iOS (Swift) / нативных Android (Kotlin)
- Настройка user properties и user identification после авторизации
- QA каждого события через DebugView / Event Inspector
- Передача документации с описанием всех событий и параметров
Сроки
Проектирование таксономии и реализация для игры с 20–40 событиями: 3–6 дней в зависимости от количества игровых механик. Стоимость рассчитывается индивидуально.