Інтеграція Firebase Analytics у мобільний додаток
Firebase Analytics — це не просто «додати SDK і дивитися DAU». Якщо события називаються button_click без параметрів, або одна і та ж дія логується під різними іменами на iOS та Android — панель управління стає мотлохом, який ніхто не читає. Правильна інтеграція починається з плану подій, а не з pod install.
Архітектура подій
Firebase автоматично збирає стандартні события: first_open, session_start, screen_view (при ввімкненому автоматичному відстеженні екранів), in_app_purchase. Для користувацької поведінки потрібні названі события з параметрами.
Хороша практика — завести перерахування подій замість рядкових констант у коді:
// iOS, Swift
enum AnalyticsEvent {
case productViewed(productId: String, category: String)
case checkoutStarted(cartValue: Double, itemCount: Int)
case purchaseCompleted(orderId: String, revenue: Double, currency: String)
var name: String {
switch self {
case .productViewed: return "product_viewed"
case .checkoutStarted: return "checkout_started"
case .purchaseCompleted: return "purchase_completed"
}
}
var parameters: [String: Any] {
switch self {
case .productViewed(let id, let cat):
return ["product_id": id, "category": cat]
case .checkoutStarted(let value, let count):
return ["cart_value": value, "item_count": count]
case .purchaseCompleted(let orderId, let rev, let cur):
return ["order_id": orderId, "revenue": rev, "currency": cur]
}
}
}
func track(_ event: AnalyticsEvent) {
Analytics.logEvent(event.name, parameters: event.parameters)
}
На Android подібний підхід через sealed class або object з константами.
User Properties та аудиторії
User Properties — атрибути користувача, які залишаються між сесіями та використовуються для сегментації в аудиторіях, Remote Config та A/B тестах:
Analytics.setUserProperty("premium", forName: "subscription_status")
Analytics.setUserProperty("ru", forName: "preferred_language")
Firebase.analytics.setUserProperty("subscription_status", "premium")
Важливо: Firebase обмежує 25 користувацькими properties на проект. Використовуйте їх для стабільних атрибутів (план підписки, тип акаунту), а не для даних сесії.
Автоматичний screen_view та ручний контроль
За замовчуванням Firebase на iOS логує screen_view при кожному появленні UIViewController через swizzling. Це погано працює в TabBar-додатках: при переключенні вкладок события дублюються. Рекомендую вимкнути автоматику та логувати вручну у viewDidAppear:
// Info.plist: FirebaseAutomaticScreenReportingEnabled = NO
override func viewDidAppear(_ animated: Bool) {
super.viewDidAppear(animated)
Analytics.logEvent(AnalyticsEventScreenView, parameters: [
AnalyticsParameterScreenName: "ProductDetail",
AnalyticsParameterScreenClass: "ProductDetailViewController"
])
}
Debug-режим та DebugView
Для перевірки подій у реальному часі — Firebase DebugView в консолі. Активується через launch argument:
-FIRDebugEnabled
У DebugView видно кожну подію з параметрами з затримкою ~1 секунда. В production события попадають у консоль з затримкою до 24 годин — це нормально, але для налагодження DebugView незамінний.
Обмеження, про які забувають
- Максимум 500 унікальних імен подій на проект (не на сесію)
- Ім'я під час до 40 символів, значення рядкового параметра до 100 символів
- До 25 користувацьких числових параметрів на подію
- Дані в BigQuery доступні з платним тарифом Blaze
Що входить до роботи
- Додавання SDK та ініціалізація
- Розробка плану подій разом з командою продукту
- Реалізація типізованого шару трекера
- Конфігурація User Properties
- Конфігурація screen_view (автоматична або ручна)
- Перевірка через DebugView до релізу
Сроки
Базова інтеграція з 10–15 подіями: 1–2 дні. Повний трекінг з аудиторіями та BigQuery: 3 дні. Вартість розраховується індивідуально після аналізу вимог.