Интеграция аналитики данных игр: событийная модель, Firebase, BigQuery

Интеграция аналитики данных игр: событийная модель, Firebase, BigQuery

Мы регулярно сталкиваемся с ситуацией, когда Firebase Analytics в Unity подключается за полчаса. Через месяц продакшена Product Manager обнаруживает: конверсия в покупку на Android вдвое ниже, чем на iOS. События логируются с правильными именами, но параметры частично теряются из-за превышения лимита в 25 кастомных параметров на событие. Воронка retention не настроена: session_start и first_open считаются автоматически, а уровни прохождения никто не отправлял. Аналитика — это не «подключить SDK». Это системная работа: проектирование событийной модели, согласованной с геймдизайном и бизнес-метриками. За 5 лет мы выполнили более 50 интеграций — от гиперказуалок до проектов класса AAA. Наш опыт показывает, что правильная архитектура аналитики экономит до 40% времени на интерпретацию данных.

Почему теряются данные?

Неверная событийная таксономия. 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 воронки на миллионных аудиториях показывают приблизительные цифры. В нашей практике мы сократили погрешность выборки до 1% — для клиента это означало корректировку прогноза выручки на 15%.

Дублирование событий. В Unity при использовании DontDestroyOnLoad для аналитического менеджера легко получить ситуацию, когда после загрузки новой сцены старый инстанс не уничтожен — события отправляются дважды. FirebaseAnalytics.LogEvent() не идемпотентен, дублей в сыром потоке не видно без group by на стороне BigQuery. Мы решаем это через Service Locator и гарантированный singleton — количество дублей падает до нуля.

Как спроектировать событийную модель?

1. Определите ключевые воронки: регистрация, прохождение уровней, покупки.
2. Назначьте ответственного за таксономию — геймдизайнера или аналитика.
3. Зафиксируйте имена событий и параметры в документе до написания кода.
4. Убедитесь, что имена событий не превышают 40 символов, а число параметров — 25.
5. Протестируйте отправку событий на этапе разработки с помощью DebugView.

Что входит в интеграцию

Проектирование событийной модели — совместно с геймдизайнером и аналитиком заказчика. Определяем: какие события нужны для 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.

{ "event": "level_complete", "parameters": { "world_id": 3, "level_id": 15, "stars": 2, "time_sec": 120, "attempts": 4 } }