Mobile Application Analytics: Firebase, Amplitude, AppsFlyer and Attribution
Analytics configured in a rush — this is a table with thousands of events without a single answer to "why users don't reach payment". Proper analytics starts with questions, not tracking everything.
Event Taxonomy: Before Writing Code
Firebase Analytics, Amplitude, Mixpanel — technically similar. The difference is what you put in them. Typical mistake: events screen_view, button_tap_1, button_tap_2 without context. In a month, no one remembers what button_tap_2 is.
Proper taxonomy: object + action + context. product_viewed, checkout_started, payment_completed with parameters product_id, category, price, source. This allows building funnels, cohort analysis and retention without additional tracking.
Naming convention is fixed in a tracking plan — document (Google Sheet or Amplitude Data Catalog) describing each event, its parameters and triggering conditions. Tracking plan is synchronized with analytics team before development starts, not after.
Firebase Analytics vs Amplitude vs Mixpanel
Firebase Analytics — free, deep integration with Google Ads, BigQuery export for raw data. Limitations: data delay up to 24 hours in standard interface, limited funnels. For startups with Google Ads traffic — first choice.
Amplitude — product analytics with focus on cohorts and user journeys. Journeys (formerly Pathfinder) shows real paths between events — not assumed funnels, but actual routes. Session Replay with iOS/Android SDK — session recording for UX analysis. Free tier up to 10M events/month sufficient for most products at start.
Mixpanel — closer to Amplitude, stronger in real-time segmentation. Insights, Funnels, Retention — basic tools covering 90% of product analytics tasks.
AppsFlyer and Install Attribution
Knowing where a user came from — separate task. Firebase Attribution works only within Google ecosystem. For multi-channel attribution (Facebook Ads, TikTok, Apple Search Ads, programmatic) you need MMP — Mobile Measurement Partner.
AppsFlyer — market leader. OneLink — universal deep link working on iOS and Android correctly attributing install from any channel. Protect360 — built-in fraud protection (fake installs, click injection on Android).
Adjust and Branch — competitors with similar functionality. Branch strong in deep linking; Adjust popular in gaming.
iOS 14.5+ and ATT broke deterministic attribution for ~40-60% of iOS audience refusing permission. AppsFlyer uses probabilistic matching (IP + user agent + timing) for these users — accuracy lower, but better than nothing. SKAdNetwork and Privacy Preserving Attribution provide aggregated data from Apple with 24-72 hour delay.
Crashlytics and Crash Analytics
Firebase Crashlytics — standard for crash reporting. Automatically groups crashes by stack trace, shows affected users %, velocity alerts on crash rate growth.
Important: symbolication. On iOS .dSYM files must automatically upload with each build — via Fastlane upload_symbols_to_crashlytics or Xcode Cloud built-in. Without symbols crash in Crashlytics looks like set of memory addresses. This happens more often than expected when switching to new CI.
For React Native and Flutter — @sentry/react-native and sentry_flutter provide additional context: breadcrumbs, network requests before crash, Redux/Provider state.
Environment Setup
Three environments with separate Firebase projects: dev, staging, production. Mixing analytics from test sessions and production — common mistake distorting all metrics. On iOS via GoogleService-Info.plist for each scheme, on Android via google-services.json in each flavor folder.
Timeline: basic analytics with Firebase + Crashlytics — 3-5 days. Full tracking plan + Amplitude/Mixpanel with funnels and cohorts — 2-3 weeks. Attribution via AppsFlyer with deep linking and fraud protection — 1-2 weeks.