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