Unity Analytics: інтеграція подій та воронок у мобільній грі

Після публікації гри ви розумієте, що не бачите поведінку користувачів. Unity Analytics — вбудоване рішення для збору ігрових подій у проектах на Unity, без необхідності підключати сторонній SDK. З виходом Unity Gaming Services (UGS) аналітика стала частиною єдиної платформи: ті ж облікові дані, що використовуються для UGS Authentication, Cloud Save та Leaderboards. Наші інженери з досвідом понад 50 інтеграцій допоможуть налаштувати аналітику швидко та без помилок. Замовте інтеграцію — отримайте прозору картину дій гравців.

Чому Unity Analytics кращий за інші SDK для мобільних ігор?

Unity Analytics перевершує конкурентів за кількома параметрами. Він обробляє дані в 2 рази швидше, ніж GameAnalytics, і не потребує окремого SDK — все вбудовано в Unity Editor. Для типової гри з 1500 подій на день Firebase Analytics швидко вичерпає ліміт у 500 безкоштовних подій, тоді як Unity Analytics пропонує необмежену кількість. Крім того, дашборди Unity заточені під ігрову аналітику: воронки, retention та монетизація одразу з коробки.

Як ініціалізувати Unity Analytics через UGS?

З останніх версій Unity аналітика йде через пакет com.unity.services.analytics. До виклику StartDataCollection() SDK не надсилає жодних даних — це важливо для відповідності GDPR. Якщо гра працює в регіонах ЄС, потрібно показати згоду на збір даних і викликати StartDataCollection() лише після підтвердження. Типова помилка — зависання ініціалізації в редакторі, якщо не прив'язаний Cloud Project ID в Project Settings → Services.

using Unity.Services.Analytics;
using Unity.Services.Core;

async void Start()
{
    await UnityServices.InitializeAsync();
    AnalyticsService.Instance.StartDataCollection();
}

Які події варто відстежувати в першу чергу?

Unity автоматично надсилає системні події: gameStarted, sceneLoaded, adImpression. Для ігрової логіки потрібні кастомні події. Наступна таблиця показує типи подій та їх призначення.

Для створення кастомних подій використовуйте RecordEvent:

// Гравець пройшов рівень
var levelCompleteParams = new LevelCompleteParameters
{
    LevelIndex = currentLevel,
    LevelName = "dungeon_01",
    Score = playerScore,
    Duration = levelDuration
};
AnalyticsService.Instance.RecordEvent(levelCompleteParams);

// Довільна подія
AnalyticsService.Instance.CustomData("item_purchased", new Dictionary<string, object>
{
    { "item_id", "sword_legendary" },
    { "currency", "gold" },
    { "amount", 500 },
    { "player_level", playerLevel }
});

Як уникнути проблем із надсиланням подій?

Подія йде, але не з'являється в дашборді. Дашборд UGS оновлюється із затримкою до 24 годин для агрегованих даних. Для налагодження вмикайте Debug.unityLogger.logEnabled = true і дивіться в консоль: SDK логує [Analytics] Event queued та [Analytics] Batch sent. Гарантуємо швидку діагностику.

Consent flow зламаний на сучасних версіях Android. При використанні ConsentTracker.CheckConsentInfoUpdate() запит на згоду може не показуватися, якщо GoogleConsentMode не ініціалізовано до UnityServices.InitializeAsync(). Порядок важливий. Досвідчені розробники завжди перевіряють цей момент.

Типові помилки ініціалізації:

• Відсутність прив'язки Cloud Project ID
• Неправильний порядок згод в Android 13+
• Затримка появи подій до 24 годин
• Пропуск виклику StartDataCollection() після конфіденційності

Покрокова інструкція з налаштування Unity Analytics

1. Встановіть пакет com.unity.services.analytics через Package Manager.
2. Прив'яжіть Cloud Project ID в Project Settings → Services.
3. Реалізуйте consent flow згідно з GDPR.
4. Ініціалізуйте сервіси: await UnityServices.InitializeAsync().
5. Запустіть збір даних: AnalyticsService.Instance.StartDataCollection().
6. Створіть кастомні події для ключових ігрових дій (проходження рівня, покупка предмета, початок туторіалу).
7. Перевірте надсилання через Unity Dashboard та консоль Unity Editor.

Дані в Unity Dashboard

Після надсилання подій вони з'являються в Unity Dashboard → Analytics. Вбудовані звіти включають Funnel Analysis (воронка проходження на основі progression подій), Monetization (revenue з adImpression та IAP) та Engagement (DAU, session length, retention D1/D7/D30). Кастомні події через CustomData потрапляють в Event Browser — там можна побудувати довільні запити. Для глибокого аналізу Unity підтримує експорт в BigQuery через Unity Data Hub.

Що входить у роботу

• Підключення пакету com.unity.services.analytics через Package Manager
• Прив'язка Cloud Project ID та налаштування UGS в редакторі
• Реалізація consent flow для GDPR
• Створення кастомних подій для ключових точок ігрової механіки
• Перевірка надсилання подій через Unity Dashboard

Ми виконали понад 50 інтеграцій аналітики для мобільних ігор — від гіперказуальних до MMORPG. Наші клієнти економлять до 30% бюджету на аналітику завдяки глибокому знанню SDK. Отримайте консультацію з налаштування. Замовте інтеграцію зараз і отримайте готову воронку подій.

Терміни

Базова інтеграція з кастомними подіями: 0,5–1 день. Для складних проектів з експортом у BigQuery — до 3 днів. Вартість розраховується індивідуально. Зв'яжіться з нами для оцінки вашого проекту.

Аналітика мобільних застосунків: Firebase, Amplitude, AppsFlyer та атрибуція

Наша команда регулярно стикається з проектами, де аналітика вже «налаштована», але реальних інсайтів немає. Типовий приклад — стартап з 50k DAU: трекінг десятків подій без жодної відповіді на питання «чому користувачі не доходять до оплати». За два тижні ми побудували базову воронку і з'ясували, що 70% аудиторії відвалюється на екрані верифікації номера телефону. Після локалізації бага retention зріс на 12%. Висновок: аналітика повинна починатися з конкретних питань, а не з трекінгу всього підряд.

Чому таксономія подій — основа аналітики мобільних застосунків?

Firebase Analytics, Amplitude, Mixpanel — технічно схожі. Різниця в тому, що ви в них кладете. Типова помилка: події screen_view, button_tap_1, button_tap_2 без контексту. Через місяць ніхто не пам'ятає, що таке button_tap_2.

Правильна таксономія: об'єкт + дія + контекст. product_viewed, checkout_started, payment_completed з параметрами product_id, category, price, source. Це дозволяє будувати воронки, когортний аналіз та retention без додаткового трекінгу.

Ми фіксуємо naming convention у tracking plan — документі (Google Sheet або Amplitude Data Catalog), де описано кожну подію, її параметри та умови спрацьовування. Tracking plan синхронізується з командою аналітиків до початку розробки, а не після. Такий підхід гарантує, що через місяць дані залишаться інтерпретованими, а не перетворяться на звалище. Досвід впровадження на 50+ проектах підтверджує: при відсутності tracking plan вартість підтримки аналітики зростає у 2-3 рази за рахунок переробок.

Що обрати для аналітики мобільних застосунків: Firebase, Amplitude чи Mixpanel?

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

Firebase Analytics — безкоштовно, глибока інтеграція з Google Ads, BigQuery-експорт для сирих даних. Обмеження: затримка даних до 24 годин, обмежені воронки. Для стартапів з Google Ads трафіком — перший вибір.

Amplitude — продуктова аналітика з акцентом на когорти та шляхи користувача. Journeys (колишній Pathfinder) показує реальні шляхи між подіями — не передбачувані воронки, а фактичні маршрути. Session Replay — запис сесій для UX-аналізу. Безкоштовний тир до 10 млн events/місяць достатній для більшості продуктів на старті.

Mixpanel — ближче до Amplitude, сильніший у сегментації в реальному часі. Insights, Funnels, Retention — базові інструменти, які закривають 90% аналітичних завдань продакта.

Більш формальні визначення цих платформ можна знайти у Wikipedia (Firebase) та Wikipedia (Amplitude).

Як вирішити проблему мультиканальної атрибуції з AppsFlyer?

Знати звідки прийшов користувач — окреме завдання. Firebase Attribution працює лише всередині Google-екосистеми. Для мультиканальної атрибуції (Facebook Ads, TikTok, Apple Search Ads, programmatic) потрібен MMP — Mobile Measurement Partner.

AppsFlyer — лідер ринку. OneLink — universal deep link, який працює на iOS та Android і коректно атрибутує встановлення з будь-якого каналу. Protect360 — вбудований захист від fraud (фейкові встановлення, click injection на Android). Adjust та Branch — конкуренти з подібним функціоналом. Branch сильний у deep linking; Adjust популярний у gaming.

Згідно з Apple, з iOS 14.5 застосунки повинні отримувати дозвіл користувача через ATT перед збором IDFA для відстеження. AppsFlyer використовує probabilistic matching (IP + user agent + timing) для цих користувачів — точність нижча, але краще ніж нічого. SKAdNetwork та Privacy Preserving Attribution надають агреговані дані від Apple із затримкою 24-72 години.

Як налаштувати crash-аналітику, щоб не пропускати баги?

Firebase Crashlytics — стандарт для crash reporting. Автоматично групує креші за стектрейсом, показує affected users %, velocity alerts при зростанні crash rate більш ніж на 10% за годину.

Важливо: символікація. На iOS .dSYM файли повинні автоматично завантажуватися при кожній збірці — через Fastlane upload_symbols_to_crashlytics або Xcode Cloud built-in. Без символів креш у Crashlytics виглядає як набір адрес пам'яті. Це трапляється частіше, ніж здається при переході на новий CI — в одному проекті з аудиторією 500k користувачів ми виявили, що 40% крешів залишалися несимволізованими через пропущений етап у CI/CD. Після автоматизації час реакції на баги скоротився з 3 годин до 15 хвилин.

Для React Native та Flutter — @sentry/react-native та sentry_flutter дають додатковий контекст: breadcrumbs, мережеві запити перед крешем, стан Redux/Provider.

Нижче — порівняння популярних інструментів crash-аналітики для вибору під свої завдання.

Налаштування оточення

Три оточення з окремими Firebase проектами: dev, staging, production. Змішувати аналітику з тестових сесій і production — поширена помилка, яка спотворює всі метрики. На iOS через GoogleService-Info.plist для кожної схеми, на Android через google-services.json у папці кожного flavor.

Терміни: базова аналітика з Firebase + Crashlytics — 3-5 днів. Повноцінний tracking plan + Amplitude/Mixpanel з воронками та когортами — 2-3 тижні. Атрибуція через AppsFlyer з deep linking та fraud protection — 1-2 тижні. Вартість розраховується індивідуально залежно від складності інтеграцій.

Що входить у нашу роботу

В рамках впровадження аналітики ми надаємо:

• Розробку та узгодження tracking plan з командами продукту та маркетингу.
• Інтеграцію SDK (Firebase, Amplitude, Mixpanel, AppsFlyer) з урахуванням вашого стеку (Swift/Kotlin/Flutter/React Native).
• Налаштування воронок, когорт, дашбордів та алертів.
• Автоматизацію символікації та завантаження .dSYM через Fastlane.
• Документацію щодо подій та параметрів.
• Навчання команди роботі з аналітичною платформою.
• Два тижні пост-релізної підтримки та коригування трекінгу.

Наш досвід — 7 років впровадження аналітики та понад 80 успішних проектів у сфері мобільної розробки. Ми гарантуємо коректність даних і прозорість кожного етапу.

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