GA4 and Firebase Analytics share the same underlying Google infrastructure, which creates constant confusion about which one to use. In practice they solve different needs, and the right answer depends on the type of product you are measuring.

The short version: Firebase Analytics is Google Analytics for Firebase. It is not a competing product. App data collected through the Firebase SDK flows into a GA4 property. The real question is almost never “GA4 or Firebase” — it is which console you should be working in, and which events belong in each place.

Same engine, different purposes

Both use the same data model: events with parameters, rather than the sessions-and-pageviews model of Universal Analytics. Both export to BigQuery with essentially the same schema. What differs is the surface built on top.

Firebase was built for mobile app product teams: technical events, crash reporting via Crashlytics, Remote Config, native feature A/B testing, push messaging. GA4 was built for marketing and combined web/app analytics teams: campaign attribution, conversion funnels, audience export, and integration with Google Ads.

Firebase Analytics GA4
Primary user App product and engineering teams Marketing, growth, analytics
Data sources Native app SDK (iOS, Android, Flutter, Unity) Web (gtag/GTM) and app, via linked Firebase
Strongest at In-product behavior, crashes, feature experiments Attribution, channel ROI, cross-platform journeys
Ads integration No Yes, native with Google Ads
Crash reporting Yes (Crashlytics) No
Remote Config / A/B tests Yes No
Web measurement No Yes
Default identity Device / app instance Configurable: blended, observed or device-based
BigQuery export Yes Yes, free daily export

When to work in Firebase

If the product is a native app and the core questions are about in-product behavior — which feature gets used most, where the app crashes, which variant retains better — Firebase gives you deeper, more native tooling, without going through a marketing analytics layer. Crashlytics and Remote Config alone justify living in that console.

When to work in GA4

If the business needs to know which marketing channel brings converting users, measure campaign ROI, or unify behavior across web and app in a single report, GA4 is the right surface. It is built on the same event model but oriented toward attribution and marketing, and it is the only one of the two that talks to Google Ads.

A Firebase project connects to exactly one GA4 property, and each app in that project becomes an app data stream inside it. Three things people get wrong about this:

The link is not retroactive. Events collected before the link existed do not appear in GA4. This is the same rule as the BigQuery export, and it catches people for the same reason: nothing warns you.

One Firebase project, one GA4 property. You cannot point the same Firebase project at two GA4 properties. If you need app data in more than one place, that is a BigQuery job, not a linking setting.

Unlinking loses the connection, not the history. Data already in GA4 stays there. But relinking does not restore the gap created while it was disconnected.

Why your Firebase and GA4 numbers don’t match

This is the single most common question I get on app measurement, and the answer is almost never “something is broken.” The two consoles are counting deliberately different things.

Different identity. The Firebase console reports on app instances — effectively devices. GA4 lets you choose a reporting identity: blended, observed, or device-based. If GA4 is set to blended and stitching users across devices, its user count will be lower than Firebase’s, because two devices belonging to one signed-in person collapse into one user.

Different definitions of “active.” Firebase counts an active user from the user_engagement event. GA4’s active-user definition is not identical, and differs slightly by platform. Two reasonable definitions, two different numbers.

Different time zones. The Firebase console and the GA4 property each have their own reporting time zone setting. If they disagree, every daily number will be offset — and it will look like a tracking bug rather than a configuration one.

Thresholding in GA4. With Google Signals enabled and low row counts, GA4 withholds data for privacy. The Firebase console does not apply the same thresholding, so it shows rows GA4 hides.

Sampling in explorations. GA4’s standard reports are unsampled; complex explorations over large ranges can be sampled. Firebase reports are not sampled the same way.

Processing latency. Both can lag, and they do not lag identically. Comparing today’s numbers across two consoles is not a comparison at all.

The practical rule: do not try to reconcile the two interfaces. Pick one as the source of truth for each question — Firebase for product, GA4 for marketing — and use BigQuery as the arbiter when a number genuinely matters. BigQuery is the only place with the raw rows both surfaces are summarising.

The limits that break implementations

This is the part that rarely appears in the comparison posts, and it is where most implementations actually go wrong.

  • App streams are capped at 500 distinctly-named events per app. Web streams are not capped the same way. Teams that log button_clicked_checkout, button_clicked_cart and so on as separate event names burn through that ceiling fast. Use one event name with parameters instead.
  • 25 parameters per event, and on a standard GA4 property you get 50 event-scoped custom dimensions. Parameters you never register as custom dimensions are collected but not queryable in the UI — though they do land in BigQuery.
  • Reserved event names differ between the two. Firebase auto-collects events like first_open, session_start and in_app_purchase; overwriting a reserved name silently corrupts the report that depends on it.
  • Double counting. If you fire both the Firebase SDK and gtag.js for the same action on a hybrid or webview app, you get the event twice, with no warning anywhere in the interface.
  • Retention is shorter than people assume. On a standard GA4 property, user- and event-scoped data for explorations is retained for 2 or 14 months depending on your setting — and the default is the short one. Aggregated standard reports keep longer, but the granular data you would want for a year-over-year cohort analysis quietly expires. The BigQuery export is the only way to keep it.

The mistake of running both without one event plan

It is common to see implementations where Firebase and GA4 log events with different names and parameters for the same action, creating two sources of truth that never reconcile. When leadership asks why the app report and the marketing report disagree, this is almost always the reason.

Define a single measurement plan first — one document listing every event, its parameters, and its definition in plain language. Then decide which events go to which tool. The plan comes before the implementation, not after the numbers stop matching.

A setup checklist

For a product with an app and a website, in this order:

  1. Write the event plan before any code. Event names, parameters, definitions, and which surface each one answers a question for.
  2. Create the GA4 property first, then link Firebase to it. Set the reporting time zone on both to the same value, today.
  3. Set data retention to 14 months in GA4 admin. It is a two-click change and the default costs you a year of history.
  4. Turn on the BigQuery export the same day, before anyone asks for it.
  5. Register the parameters you will actually query as custom dimensions, within the 50-slot budget. Ration them deliberately.
  6. Audit for double counting on any hybrid or webview screen, by counting events per session in BigQuery rather than trusting the interface.
  7. Decide the source of truth per question, write it down, and stop reconciling the rest.

The practical recommendation

For most products with both an app and a website, the combination that works is GA4 as the marketing and attribution layer, with Firebase as the deep product analysis layer, both fed by the same event plan, and BigQuery as the arbiter when the two interfaces disagree.

You are rarely choosing one. You are deciding what belongs in each.

Common questions

Is Firebase Analytics the same as GA4? They share the event data model, the BigQuery schema, and the underlying pipeline. Firebase Analytics is the app-focused surface; GA4 is the marketing-focused surface over largely the same data. A Firebase project links to a GA4 property, and app events flow into it.

Do I need both Firebase and GA4? If you have a native app and run paid acquisition, yes — Firebase for product and crash data, GA4 for attribution and Google Ads. If you are web-only, you only need GA4. If you have an app with no marketing spend, Firebase alone may be enough.

Can Firebase track my website? Not meaningfully. Firebase Analytics is built around native app SDKs. Web measurement belongs in GA4 through gtag.js or Google Tag Manager.

Which one should I use for attribution? GA4. Firebase has no native Google Ads integration and no attribution modeling. If the question is “which channel produced this conversion,” that is a GA4 question.

Why are my Firebase and GA4 user counts different? Most often reporting identity: Firebase counts app instances, while GA4 may be stitching users across devices. Time zone mismatches and GA4’s thresholding account for most of the rest. See the section above — the two are not supposed to match exactly.

Does linking Firebase to GA4 import my historical app data? No. The link starts collecting from the moment it is created. There is no backfill, in either direction.

Is Firebase Analytics free? Yes, Google Analytics for Firebase is free with unlimited event reporting for standard events. Costs appear elsewhere in Firebase — Cloud Functions, Firestore, hosting — and in BigQuery once you exceed the sandbox limits.

Whichever you land on, turn the BigQuery export on the same day: here is what it gives you, and here is why there is no backfill if you wait.

If tracking is the thing that is not adding up on your own account, see how I work with brands — measurement is usually the first thing I audit.