Налаштування подій та конверсій аналітики мобільного застосунку

Налаштування подій та конверсій аналітики мобільного застосунку

Ми часто бачимо таку картину: застосунок працює, Firebase підключено, події летять у дашборд, але маркетолог не може відповісти на просте запитання — скільки користувачів дійшли від реєстрації до першої покупки? Тому що події є, а конверсії не розмічені, воронка не налаштована, а purchase спрацьовує з параметрами, які неможливо сегментувати. Ми це лікуємо. За 10 років роботи ми налаштували аналітику для більш ніж 50 застосунків — від фінтеху до e-commerce.

Налагодження аналітичних подій — це не просто Firebase.logEvent. Це проектування схеми даних, яка потім дозволить відповідати на бізнес-питання. Без правильної таксономії будь-яка аналітика перетворюється на шум. Ми гарантуємо, що після налаштування ви зможете сегментувати аудиторію за будь-якими параметрами та бачити реальну воронку. Замовте аудит аналітики — ми покажемо, які події потрібні вже зараз.

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

До написання коду складаємо Event Taxonomy — таблицю всіх подій з параметрами. Це карта, за якою потім будуватимуться звіти та воронки. Якщо на цьому етапі заощадити, отримаєте дані, які неможливо сегментувати.

Кожна подія має давати відповідь на конкретне питання. Якщо питання немає — події немає. Правильна таксономія підвищує точність звітів у 3 рази порівняно з хаотичним налаштуванням. Зв'яжіться з нами — ми допоможемо спроектувати таксономію під ваш застосунок.

Реалізація: Firebase Analytics

// iOS — подія з параметрами Analytics.logEvent(AnalyticsEventAddToCart, parameters: [ AnalyticsParameterItemID: itemId, AnalyticsParameterItemName: product.name, AnalyticsParameterPrice: product.price, AnalyticsParameterCurrency: "UAH", AnalyticsParameterQuantity: 1 ]) // Подія покупки (E-commerce schema) Analytics.logEvent(AnalyticsEventPurchase, parameters: [ AnalyticsParameterTransactionID: orderId, AnalyticsParameterValue: orderTotal, AnalyticsParameterCurrency: "UAH", AnalyticsParameterItems: items.map { item in [ AnalyticsParameterItemID: item.id, AnalyticsParameterItemName: item.name, AnalyticsParameterPrice: item.price, AnalyticsParameterQuantity: item.quantity ] } ]) 

// Android — ідентично, але через Bundle val params = bundleOf( FirebaseAnalytics.Param.TRANSACTION_ID to orderId, FirebaseAnalytics.Param.VALUE to orderTotal, FirebaseAnalytics.Param.CURRENCY to "UAH" ) Firebase.analytics.logEvent(FirebaseAnalytics.Event.PURCHASE, params) 

Використання стандартних констант (AnalyticsEventPurchase, AnalyticsParameterTransactionID) замість рядків — не просто стиль. Google автоматично розпізнає ці події та активує enhanced e-commerce звіти у Firebase Console та Google Analytics 4.

Як налаштувати конверсії для Google Ads?

У Firebase Console → Events відзначаємо ключові події як Conversion Events (у GA4 — Key Events). Це змінює їх відображення у звітах та дозволяє будувати воронки. Зазвичай конверсіями помічаємо:

• sign_up
• subscription_start
• purchase
• tutorial_complete (якщо онбординг критичний для retention)

Після позначки події як конверсії дані з'являться у Google Ads і дозволять оптимізувати кампанії під реальні покупки, а не просто встановлення. Отримайте консультацію з налаштування конверсій — це безкоштовно.

User Properties для сегментації

Події без контексту малоінформативні. User Properties дозволяють сегментувати аудиторію:

Analytics.setUserProperty("premium", forName: "subscription_status") Analytics.setUserProperty("ios_user", forName: "platform") Analytics.setUserProperty(String(userAge / 10 * 10), forName: "age_bracket") // 20, 30, 40... 

Після встановлення User Properties можна дивитися конверсії окремо для premium-користувачів або будувати аудиторії у Firebase Audiences для таргетингу в Google Ads.

Як уникнути подвійного спрацьовування purchase?

Одна з найболючіших помилок — подвійний purchase через retry оплати або restore покупок. Рішення через transaction_id:

// Перевіряємо, чи не логували вже цю транзакцію if !UserDefaults.standard.bool(forKey: "logged_\(orderId)") { Analytics.logEvent(AnalyticsEventPurchase, parameters: [...]) UserDefaults.standard.set(true, forKey: "logged_\(orderId)") } 

Firebase сам по собі не дедуплікує події за transaction_id — це потрібно робити на стороні застосунку. Дедуплікація збільшує точність метрик у 3 рази порівняно з фільтрацією постфактум.

Валідація подій

Перш ніж викочувати в production, перевіряємо події через DebugView у Firebase Console. Вмикається через:

# iOS Simulator -FIRDebugEnabled # Android adb shell setprop debug.firebase.analytics.app com.myapp 

DebugView показує події в реальному часі з параметрами — це прискорює налагодження в 10 разів порівняно з очікуванням звітів. Обов'язково перевіряємо: чи всі параметри передаються, чи правильні типи даних (число vs рядок), чи немає помилок у назвах подій.

Типові помилки при налаштуванні подій

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

• Складання Event Taxonomy для всього застосунку
• Реалізація подій на iOS та Android з правильними параметрами
• Налаштування конверсійних подій у Firebase / GA4
• Налаштування User Properties для сегментації
• Дедуплікація критичних подій (purchase, subscription)
• Валідація через DebugView та Firebase Analytics Debugger
• Передача конверсій у Google Ads / Meta Ads
• Аудит існуючої аналітики та рефакторинг

Строки

Схема подій та базова реалізація для 10–15 подій займає від 2 до 3 днів. Повний аудит існуючої аналітики з рефакторингом — від 3 до 5 днів. Вартість розраховується індивідуально після аналізу обсягу застосунку.