GA4 and Firebase: web vs app measurement differences

Key Takeaway

GA4 and Firebase share the same data model but different admin surfaces. When both are linked, events from app and web merge into one property, which can inflate user counts and break attribution if cross-platform identity is not configured.
Intermediate

GA4 can combine web and app streams inside one property, but that does not make the two data sources directly interchangeable. Web and Firebase app tracking use different runtime signals, attribution mechanisms, and identifiers. Understanding those differences prevents bad comparisons and bad reporting decisions.

Web Stream
App (Firebase) Stream
Session definition
Starts on the first event and times out after inactivity. Tracked via first-party browser identifiers.
Starts when app is brought to foreground. Ends after 30 min of inactivity in the background. Not broken at midnight.
User identifier
Browser cookie (client_id). Persistent per browser/device. Lost on cookie clear or new browser.
Firebase Installation ID (app instance). Persistent per app install. Lost on app uninstall.
Traffic source attribution
UTM parameters in URL and HTTP referrer headers. Works for any source that can append URL parameters.
App attribution depends more heavily on SDK integrations, deep-link handling, app-store signals, and often an MMP.
Event parameters
Up to 25 custom parameters per event. Standard web events: page_view, scroll, click, form_submit.
Up to 25 custom parameters per event. App-specific auto-events: first_open, app_update, app_remove, screen_view.
BigQuery export
Events exported to BigQuery include page_location, page_referrer, and standard web fields.
Events include firebase_screen, app_version, and device-level fields not present in web exports.

Session definition differences

On the web, sessions are defined by the tag running in the browser. A session starts with the first page_view or other GA4 event and times out after inactivity. GA4 does not restart web sessions at midnight the way Universal Analytics did.

In mobile apps via Firebase SDK, sessions start when the app is brought to the foreground and end after inactivity with the app in the background. The practical implication is that web and app sessions are created from different signals, so their counts are not directly comparable even inside one property. Begin by confirming each stream is set up correctly usingGA4 property configuration checks.

Traffic source attribution in apps

Web traffic source attribution comes from UTM parameters in URLs and HTTP referrer headers. Apps have neither of these mechanisms for standard app-to-app attribution. Mobile app traffic source attribution uses different systems:

  • Google Ads: Google Ads to app conversion tracking uses Google Play referral parameters or the iOS SKAdNetwork framework. These integrate with GA4 via the Firebase SDK.
  • Apple Search Ads: Attribution from Apple Search Ads requires specific Firebase SDK configuration and uses AdServices framework on iOS.
  • Third-party networks: Attribution from Facebook, TikTok, and other paid channels for app installs typically uses a Mobile Measurement Partner (MMP) like AppsFlyer or Adjust. These tools export attribution data to GA4 via their own integrations, and may also flow data through theGA4 Measurement Protocolfor server-side use cases.

This means app traffic in GA4 typically shows much higher organic and direct attribution than web traffic, because the attribution mechanisms for paid app install campaigns often sit outside GA4.

1

Create or open your GA4 property

In GA4 Admin, confirm your property already has a web data stream. If you are adding app tracking to an existing web property, the same property will house both streams.

2

Add an ios or android app stream

In Admin > Data Streams, click Add stream and select iOS app or Android app. Enter your app bundle ID and app name. GA4 generates a Firebase App ID and a google-services.json (Android) or GoogleService-Info.plist (iOS) config file.

3

Integrate the Firebase SDK

Add the Firebase SDK to your mobile app and include the downloaded config file. Initialise FirebaseApp in your app entry point. The SDK automatically collects first_open, session_start, and app lifecycle events.

4

Implement a consistent user ID

Send the same user_id from both your web tag and the Firebase SDK whenever a user is authenticated. This is usually the clearest deliberate identifier for cross-platform analysis. Without it, GA4 relies much more heavily on device- or platform-specific identifiers.

5

Align event names across streams

Define a shared event taxonomy so the same user action uses the same event name on web and in the app. If your web implementation sends add_to_cart, the app must send add_to_cart, not add_item or add_to_basket.

Cross-platform attribution via user ID

To analyse users who interact with both your website and your app, User ID is usually the clearest linking mechanism available to your team. A user who logs into your website and your app should send the same user_id from both the web tag and the Firebase SDK if you want reporting to line up around that known user.

Without User ID, a user who visits the website three times and then purchases in the app appears as four separate users: three anonymous web users and one app user. With User ID, all four sessions are attributed to the same user, giving you a complete cross-platform view. UseGA4 conversion tracking setupto make sure the conversion event itself is configured to count properly across both streams.

Event naming alignment

For cross-platform reporting to work, the same user behaviour must use the same event names across web and app. If your website sends add_to_cart and your app sends add_item_to_cart for the same action, they appear as separate events in reports. Define a shared event taxonomy that both web and app implementations follow, and audit both implementations against this taxonomy periodically — including the parameters defined in yourcustom dimensions audit.

Automatic events that differ by platform

Firebase automatically collects a set of app-specific events that have no web equivalent: first_open (first launch after install), app_update, app_remove, os_update, and screen_view. These appear in your GA4 property's events report alongside web events. Understanding which events are app-only prevents confusion when event volumes do not match expectations.

Web and app attribution checklist

  • User ID is implemented consistently across both web and Firebase app using the same identifier
  • Event names for shared user actions (add_to_cart, purchase, sign_up) are identical across web and app streams
  • App-specific automatic events (first_open, app_update) are understood and not confused with web events
  • Mobile app attribution for paid channels uses an MMP or Firebase-native mechanism, not UTM parameters
  • Cross-platform attribution is validated in GA4 User Explorer by identifying users with both web and app sessions

Findings should be reviewed by a qualified analyst before they are used for major reporting, media, or implementation decisions.

GA4 Audits Team

GA4 Audits Team

Analytics Engineering

Specialising in GA4 architecture, consent mode implementation, and multi-layer audit frameworks.

Share