Інтеграція аналітики даних ігор: подієва модель, 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 } }