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

Як аналітика допомагає заробляти?

Remote Config у зв'язці з A/B Testing дозволяє не просто збирати дані, але й тестувати гіпотези. Типовий сценарій: змінити складність третього рівня для 10% аудиторії, заміряти різницю в retention D1 та конверсії в покупку. Реалізація вимагає коректного групування користувачів по FirebaseRemoteConfig.FetchAndActivateAsync() та гарантії, що конфіг застосовується до першого відображення контрольованого екрану. Ми налаштовуємо цей ланцюжок так, щоб результати A/B-тестів були статистично значущими вже при вибірці 2000 користувачів. В одному проєкті це призвело до зростання ARPU на $0.75.

Чому BigQuery важливий для аналітики?

BigQuery дозволяє зберігати сирі події без вибірки (sampling). Ви можете виконувати точні SQL-запити до мільярдів записів. Ми бачили проєкти, де після впровадження BigQuery витрати на аналітичну інфраструктуру знизилися на $2,500 на місяць — за рахунок відмови від сторонніх expensive BI-інструментів.

Порівняння провайдерів аналітики

Строки

Вартість розраховується після аналізу вимог до метрик та поточного стану аналітичної інфраструктури. Ми даємо фіксовану ціну на етапі узгодження обсягу робіт.

Замовте аудит вашої аналітики — ми знайдемо втрати даних і запропонуємо план виправлень. Зв'яжіться з нами, щоб обговорити подієву модель вашої гри.

Монетизація ігор: чому доходи не зростають?

Гра вийшла, DAU зростає, доходи стоять на місці. Часто монетизацію вшивають постфактум — купівлі, події, рекламу додають без системи. Переписувати після релізу дорого й довго, а спроба виправити «на льоту» ламає прогрес і б'є ретеншн. Ми проектуємо ці шари з першого дня, щоб вони приносили гроші, а не перетворювалися на технічний борг.

Чому доходи стоять на місці? (H2)

Більшість проблем монетизації — технічні: втрачені транзакції, зламані підписки, невалідні події. Наприклад, клієнт із казуальною грою на Unity втрачав 30% IAP-доходу через відсутність серверної валідації — гравці отримували товари за перехоплені receipt. Ми замінили схему — дохід виріс на 40% за перший місяць.

IAP: архітектура внутрішньоігрових покупок

Unity IAP SDK виглядає тривіально: каталог продуктів, колбек. На практиці ламається більшість проєктів — дублювання транзакцій, втрата покупок, вразливість до злому.

Клієнтська vs. серверна валідація

Базова схема з клієнтським receipt працює, поки її не розкривають. Зломщик підміняє відповідь магазину — отримує предмет безкоштовно. Правильне рішення — відправляти receipt на бекенд для верифікації через Apple App Store API або Google Play Developer API. Тільки після цього видавати товар і зберігати transaction_id. Без серверної валідації м’яка валюта або battle pass стають мішенню для replay-атак.

Типи продуктів

Підписки — найскладніший тип. Apple і Google по-різному рахують renewal, trial та скасування. Потрібен бекенд, який обробляє Server-to-Server сповіщення (App Store Server Notifications, Google Pub/Sub). Без цього до половини підписок втрачаються.

Відновлення покупок

На iOS без IStoreController.RestoreTransactions() магазин не пропустять. На Android відновлення необов’язкове, але підвищує довіру. Unity IAP робить це одним методом — тестувати обов’язково на реальному пристрої з TestFlight.

Рекламна монетизація

У гіперкежуалі та казуалі реклама — основне джерело доходу. Ключові SDK:

• AdMob — базовий, стабільний, але eCPM нижче середнього.
• IronSource (Unity LevelPlay) — медіатор, проводить аукціон між мережами в реальному часі.
• AppLovin MAX — альтернатива, часто виграє по eCPM у США та Європі.

Практичне правило: використовуйте медіатор (IronSource або MAX) з AdMob, Meta Audience Network та парою регіональних мереж. Пряма інтеграція одного SDK дає доходу на 30-60% менше при тому ж трафіку — перевірено на 20+ проєктах. Медіатор підвищує eCPM в середньому в 1.4 раза порівняно з одиночним SDK.

Як реклама впливає на ретеншн? (H3)

Rewarded video — найщадніший формат: гравець сам вирішує дивитися ролик за винагороду. Interstitial між рівнями ріже ретеншн, якщо показувати частіше ніж раз на 3-4 переходи. Новим гравцям у перші 24 години рекламу не показуємо — це знижує Day 1 retention на 15-25%. Для одного з клієнтів ми налаштували таймінги — Day 7 виріс на 18%.

Аналітика: архітектура подій

Тут найглибше. Більшість команд підключають Firebase Analytics, розкидають logEvent() і вважають, що аналітика готова. Через місяць даних немає або вони марні — схема подій не продумана.

Як спроектувати схему подій? (H3)

1. Визначте ключові питання (наприклад, де гравці застрягають у навчанні, який LTV за джерелами трафіку).
2. Для кожного питання складіть набір подій з параметрами.
3. Узгодьте назви з командою (єдиний неймінг).
4. Встановіть ліміти: не більше 500 унікальних типів подій (Firebase), 25 параметрів на подію.
5. Протестуйте pipeline на тестовому акаунті до релізу.

Приклад поганої події:

logEvent("level_complete");

Приклад хорошої події:

logEvent("level_complete", {
  level_id: "world_2_level_5",
  attempts: 3,
  time_spent_sec: 142,
  boosters_used: ["shield", "bomb"],
  session_id: "abc123",
  user_segment: "payer"
});

Перша говорить тільки «рівень пройдено». Друга дозволяє будувати воронки, сегментувати гравців, корелювати поведінку з доходом.

Стандартні категорії подій

Прогрес: tutorial_step_complete (окремо на кожен крок онбордингу), level_start, level_complete, level_fail, chapter_unlock.

Монетизація: iap_initiated (відкрив магазин або тапнув офер), iap_complete (з revenue), iap_fail, ad_show_request, ad_show_complete, ad_reward_claimed.

Залученість: session_start/session_end (з тривалістю), feature_used, push_notification_open.

Firebase Analytics vs. GameAnalytics vs. AppsFlyer

У нормальному проекті стоять усі три. Без AppsFlyer ви витрачаєте бюджет на UA наосліп — він відстежує SKAdNetwork, рахує ROI по кампаніях, інтегрується з Facebook Ads та Google UAC. Для одного клієнта AppsFlyer допоміг знизити вартість встановлення на 25% завдяки точній атрибуції.

Хмарні збереження

Гравець, який втратив прогрес при зміні пристрою, з імовірністю 70% не повернеться. Варіанти:

• Unity Cloud Save (UGS) — швидко, key-value, безкоштовно до ліміту.
• PlayFab Player Data — гнучкіше, сегментація, умовний доступ.
• Firebase Firestore — для складних даних, реалтайм-синхронізація.

Синхронізуйте тільки критичне: рівень, куплені предмети, налаштування. Важкі файли (replay, скріншоти) зберігайте окремо. Наше рішення знижує втрату прогресу до 2% користувачів.

Що входить у вартість? (H2)

Після укладення договору отримуєте:

• Аудит поточної схеми монетизації та аналітики (якщо гра жива) або проектування з нуля.
• Архітектура IAP із серверною валідацією та підтримкою підписок.
• Інтеграція медіатора реклами (IronSource/MAX) та налаштування аукціону.
• Схема аналітичних подій з підключенням Firebase + GameAnalytics + AppsFlyer.
• Хмарні збереження та відновлення покупок.
• Документація по подіях, інструкція для геймдизайнерів.
• 2 тижні безкоштовної підтримки після релізу.

Додатково — доступ до дашбордів, навчання команди роботі з аналітикою.

Чому варто працювати з нами?

7+ років налаштовуємо монетизацію в мобільних іграх. 30+ проєктів — від гіперкежуалу до MMORPG. Стандарт подій, який ми розробили, збільшив конверсію в платіж на 20% у одного клієнта за місяць. Інший отримав зростання LTV на 35% після таргетованих оферів — це принесло додаткові $12 000 щомісяця. Гарантуємо прозорість даних: ви бачите, які події йдуть і скільки приносять. Сертифіковані партнери Unity, 5+ років на ринку.

Терміни орієнтовно

• IAP + серверна валідація: від 5 до 10 робочих днів.
• Рекламна монетизація з медіатором: від 3 до 7 днів.
• Повний цикл (аналітика + IAP + реклама): від 2 до 4 тижнів.

Вартість розраховується індивідуально — замовте безкоштовну оцінку проекту через форму зворотного зв’язку.

Типові помилки (без заголовка, як абзац)

Відсутність серверної валідації робить систему вразливою до злому. Події без параметрів — 50% часу аналітики витрачається на розшифровку. Запуск реклами в перші 24 години вбиває ретеншн: 80% гравців не повертаються. Пряма інтеграція одного рекламного SDK втрачає 30-60% доходу. Усі ці помилки ми виправляємо в межах одного проекту.

Зв’яжіться з нами — розберемо ваш проект і запропонуємо план. Напишіть нам, і ми підготуємо розрахунок за 1-2 дні. Отримайте консультацію вже сьогодні.