Интеграция систем аналитики данных игр
Firebase Analytics в Unity подключается за полчаса. Но когда через месяц продакшена Product Manager спрашивает «почему конверсия в покупку на Android вдвое ниже, чем на iOS» — оказывается, что все события логируются с правильными именами, но параметры частично теряются из-за превышения лимита в 25 кастомных параметров на событие. А воронка retention вообще не настроена, потому что session_start и first_open считаются автоматически, но уровни прохождения никто не отправлял.
Аналитика — это не «подключить SDK». Это спроектированная событийная модель, согласованная с геймдизайном и бизнес-метриками.
Где теряются данные
Неверная событийная таксономия. Firebase ограничивает: 500 уникальных event names на приложение, имена до 40 символов, параметры до 25 на событие, строковые значения до 100 символов. Проекты, которые логируют level_complete_world_1_level_5_stars_3 как имя события — быстро упираются в потолок и теряют историческую гибкость данных.
Правильная схема: level_complete как event, world_id, level_id, stars, time_sec, attempts — как параметры. Это позволяет строить срезы в BigQuery без необходимости менять клиентский код.
Sampling в GA4. Firebase Analytics (GA4) применяет sampling при больших объёмах данных в стандартном интерфейсе. Для точных данных нужна интеграция с BigQuery Export — это бесплатно в Firebase, но требует настройки. Без BigQuery воронки на миллионных аудиториях показывают приблизительные цифры.
Дублирование событий. В Unity при использовании DontDestroyOnLoad для аналитического менеджера легко получить ситуацию, когда после загрузки новой сцены старый инстанс не уничтожен — события отправляются дважды. FirebaseAnalytics.LogEvent() не идемпотентен, дублей в сыром потоке не видно без group by на стороне BigQuery.
Что входит в интеграцию
Проектирование событийной модели — совместно с геймдизайнером и аналитиком заказчика. Определяем: какие события нужны для retention-анализа (D1/D7/D30), для воронки монетизации, для балансировки сложности уровней, для A/B-тестов. Фиксируем в event taxonomy document до написания кода.
Подключение SDK: Firebase Analytics как основа, плюс при необходимости — Amplitude (удобнее для поведенческого анализа), GameAnalytics (бесплатный, хорошо для мобильного гиперкэжуала), или AppsFlyer/Adjust для attribution. Каждый SDK требует отдельной инициализации с учётом GDPR/ATT.
Реализация: пишем абстракцию IAnalyticsService поверх конкретных SDK — это позволяет менять провайдеров без правки игрового кода. AnalyticsManager — синглтон через ServiceLocator, не MonoBehaviour — убирает зависимость от жизненного цикла сцен.
Настройка BigQuery Export из Firebase Console, создание базовых аналитических запросов для отчётности (retention, funnel, revenue по сегментам), опционально — дашборд в Looker Studio.
Remote Config как часть аналитического цикла
Firebase Remote Config в связке с A/B Testing позволяет не просто собирать данные, но и тестировать гипотезы. Типичный сценарий: изменить сложность третьего уровня для 10% аудитории, замерить разницу в retention D1 и конверсии в покупку. Реализация требует корректной группировки пользователей по FirebaseRemoteConfig.FetchAndActivateAsync() и гарантии, что конфиг применяется до первого отображения контролируемого экрана.
Сроки
| Масштаб | Срок |
|---|---|
| Firebase Analytics, базовая событийная модель, одна платформа | 3–7 дней |
| Firebase + BigQuery + attribution SDK | 2–3 недели |
| Полный стек с Remote Config, A/B, дашборды | 4–6 недель |
Стоимость рассчитывается после анализа требований к метрикам и текущего состояния аналитической инфраструктуры.