Firebase + GA4 for Mobile Apps: The Setup That Actually Works (2026)

How do GA4 and Firebase work together?

Firebase is the mobile SDK that sends events to GA4 — for iOS and Android apps, Firebase Analytics IS GA4 (same backend, same property if linked, same reports). Setup pattern: create a GA4 property, add data streams for each platform (Web, iOS app, Android app), link Firebase project for the app streams.

Events fire from the app via Firebase SDK and appear in the same GA4 property as your web events. Decision: unified vs separate property. Unified (web + iOS + Android in one property) gives cross-platform user journey reporting; separate properties give cleaner per-platform analysis.

Most properties should start unified and add separation only when cross-platform reporting becomes irrelevant. iOS App Tracking Transparency (ATT) and Android Privacy Sandbox restrict identifier access — use gbraid (iOS app) and wbraid (iOS web) click IDs for privacy-preserving Google Ads attribution.

The architecture

For a property with web + mobile apps:

Each data stream has its own measurement ID (web) or Firebase app ID (iOS/Android). Events flow into the unified GA4 property where they're queryable together.

Setting up the data streams

In GA4 Admin → Data Streams → Add stream:

For iOS app:

• Choose iOS app
• Provide bundle ID, app name
• Download the GoogleService-Info.plist file
• Add to your Xcode project
• Initialise Firebase in your AppDelegate (or SwiftUI App)

For Android app:

• Choose Android app
• Provide package name, app name, SHA-1 fingerprint
• Download google-services.json
• Add to your Android project
• Apply the Google Services Gradle plugin

For web:

• Choose Web
• Provide the website URL
• Add the gtag snippet OR configure GA4 Configuration tag in GTM

Each stream gets its own ID. Events from each stream appear in the same property's reports, distinguishable by stream_id.

Unified vs separate property decision

The trade-off:

Unified property (web + iOS + Android in one)

Pros:

• Cross-platform user journey reports (user starts on web, completes purchase in app — visible as one journey)
• Single audience definitions usable across web and app
• Single configuration to maintain
• BigQuery export is one project to query

Cons:

• Some reports are awkward (web sessions and app sessions counted differently)
• Cross-platform identity resolution requires user_id implementation
• Events have different default parameters per platform
• Filtering reports to "just web" or "just app" requires every report to filter by stream_id

Separate properties (one per platform)

Pros:

• Clean per-platform metrics without filtering
• Different teams can manage different properties
• Different ad-platform linkages per property
• Easier to optimise reports per platform

Cons:

• No cross-platform journey analysis without manual data warehouse work
• Triple the configuration overhead
• Audience definitions can't span platforms
• BigQuery exports go to multiple datasets

The recommendation: start unified. Add separation only if you have specific needs the unified property can't serve, and if cross-platform reporting genuinely doesn't matter for your business.

What changes from web to mobile tracking

Mobile apps have specific tracking dynamics web doesn't:

1. Automatic events differ

Mobile apps automatically capture:

• app_open — every time the app opens
• app_remove — when the app is uninstalled
• app_update — when the user updates to a new version
• screen_view — automatic screen tracking via Firebase
• notification_open — when the user opens a notification (Firebase Cloud Messaging)
• in_app_purchase — automatic IAP tracking on iOS/Android stores

Web doesn't have these. Don't try to recreate them — they're free with the SDK.

2. Identifier landscape

Web: Cookie-based client_id (the _ga cookie value), persistent until cookie cleared.

iOS app:

• IDFA (Identifier for Advertisers) — requires user opt-in via App Tracking Transparency (ATT). Most users decline (~70%+ opt-out rates typical).
• IDFV (Identifier for Vendor) — always available, scoped to your developer account.
• App Instance ID — Firebase-generated, always available.

Android app:

• Advertising ID (AAID) — historically always available, increasingly restricted under Android Privacy Sandbox.
• App Instance ID — Firebase-generated, always available.

The implication: iOS app cross-device matching is significantly weaker than web. Use App Instance ID for in-app behaviour analysis; use IDFA only for the small percentage of consenting users.

3. Attribution mechanics

Web: gclid for Google Ads, fbclid for Meta, etc. Click IDs append to URL on ad click.

iOS app:

• gbraid — Google Ads click ID for iOS apps where ATT is denied. Privacy-preserving aggregated attribution.
• wbraid — Google Ads click ID for iOS web where ATT is denied. Same privacy mechanism.
• For ATT-granted users, standard gclid behaviour.

Android app:

• Similar click-ID mechanism but currently more permissive than iOS.

The pattern: configure your Google Ads → Firebase + GA4 linkage, and let the platforms handle the privacy-preserving attribution automatically. Don't try to capture iOS app gclids manually — the privacy framework doesn't support it.

4. Session counting differs

Web sessions: 30-minute inactivity timeout.

App sessions: also 30-minute timeout but with different mechanics for backgrounding/foregrounding. An app pushed to the background and brought back within 30 minutes is the same session; longer is a new session.

The implication: app sessions per user are typically much higher than web (users open apps frequently for short bursts). Don't compare web and app sessions directly without normalising.

The four mobile-specific gotchas

Gotcha 1 — DebugView for app debugging

Standard DebugView works for web. For mobile, you need to enable debug mode in the app:

iOS: add launch argument -FIRDebugEnabled in Xcode's scheme.

Android: run adb shell setprop debug.firebase.analytics.app PACKAGE_NAME.

Without these, your test events fire to production reports with normal latency, not DebugView.

Gotcha 2 — App version as a key dimension

Apps have versions. Bug fixes and feature changes happen per-version. Always send your app version as a custom dimension on every event so you can segment reports by version.

GA4 captures app_version automatically, but verify it's populated in your reports.

Gotcha 3 — Push notification attribution

When a user opens a push notification, Firebase records notification_open. But linking that to the original campaign that sent the notification requires explicit configuration in your push provider (Firebase Cloud Messaging, OneSignal, etc.).

If you want "campaigns that drove app re-engagement" reporting, configure push providers to pass campaign metadata in the notification payload.

Gotcha 4 — In-app purchase reconciliation

iOS and Android stores have their own purchase tracking that differs from your in-app server tracking. The reconciliation is messy:

• Apple App Store / Google Play Store reports
• Firebase automatic IAP tracking
• Your own server-side purchase tracking
• GA4 purchase events

These four numbers rarely match exactly. Pick one as canonical (usually your own server) and document the variance with the others.