Integrating Firebase Analytics into a mobile application
Firebase Analytics is not just "add SDK and watch DAU". If events are named button_click without parameters, or the same action is logged under different names on iOS and Android — the dashboard becomes garbage that no one reads. Proper integration starts with an event plan, not with pod install.
Event architecture
Firebase automatically collects standard events: first_open, session_start, screen_view (when automatic screen tracking is enabled), in_app_purchase. For custom behavior, named events with parameters are needed.
A good practice — create an event enumeration instead of string constants scattered through the code:
// 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)
}
On Android, use a similar approach with sealed class or object with constants.
User Properties and audiences
User Properties — user attributes that persist between sessions and are used for segmentation in audiences, Remote Config, and A/B tests:
Analytics.setUserProperty("premium", forName: "subscription_status")
Analytics.setUserProperty("ru", forName: "preferred_language")
Firebase.analytics.setUserProperty("subscription_status", "premium")
Important: Firebase limits 25 custom user properties per project. Use them for stable attributes (subscription plan, account type), not session data.
Automatic screen_view and manual control
By default, Firebase on iOS logs screen_view when each UIViewController appears through swizzling. This works poorly in TabBar applications: switching tabs duplicates events. I recommend disabling automation and logging manually in viewDidAppear:
// Info.plist: FirebaseAutomaticScreenReportingEnabled = NO
override func viewDidAppear(_ animated: Bool) {
super.viewDidAppear(animated)
Analytics.logEvent(AnalyticsEventScreenView, parameters: [
AnalyticsParameterScreenName: "ProductDetail",
AnalyticsParameterScreenClass: "ProductDetailViewController"
])
}
Debug mode and DebugView
To check events in real time — use Firebase DebugView in the console. Activated through launch argument:
-FIRDebugEnabled
DebugView shows each event with parameters with ~1 second delay. In production, events reach the console with up to 24-hour delay — this is normal, but for debugging DebugView is indispensable.
Limitations people forget about
- Maximum 500 unique event names per project (not per session)
- Event name up to 40 characters, string parameter value up to 100 characters
- Up to 25 custom numeric parameters per event
- BigQuery data available with paid Blaze plan
What's included in the work
- Adding SDK and initialization
- Developing an event plan with the product team
- Implementing a typed tracker layer
- Configuring User Properties
- Configuring screen_view (automatic or manual)
- Verification through DebugView before release
Timeline
Basic integration with 10–15 events: 1–2 days. Full tracking with audiences and BigQuery: 3 days. Cost calculated individually after requirements analysis.