Інтеграція систем аналітики даних ігор
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 як событіе, 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 тижнів |
Вартість розраховується після аналізу вимог до метрик та поточного стану аналітичної інфраструктури.