Firebase Analytics is fine for glancing at dashboards and nearly useless for real analysis. The moment you want to ask your own questions of app data, you need the raw events in BigQuery. Here's the setup, step by step.

Why bother exporting

The Firebase console shows you pre-baked reports and aggregated numbers. It won't let you write arbitrary SQL, join app data to your other sources, or build custom funnels the way you want.

BigQuery gives you the event-level export, one row per event with all parameters, which is the same raw shape the GA4 web export uses. That's the difference between reading someone else's pre-written summary and holding the underlying data you can slice any way you like.

Step one: get on the Blaze plan

BigQuery export requires your Firebase project to be on the pay-as-you-go Blaze plan. This trips people up, so it's worth being clear: the analytics export itself is free, and you only pay standard BigQuery costs for storage and the queries you run.

BigQuery also includes a free monthly query tier, so light use often costs very little in practice. The Blaze requirement is about billing being enabled, not about a fee for the export.

Step two: link Firebase to BigQuery

In the Firebase console the linking itself is a few clicks:

  1. Open Project settings, then the Integrations tab, and find BigQuery.
  2. Enable the link and choose the Analytics data to export.
  3. Pick daily export, and add streaming only if you truly need intraday data.

Daily export is free; streaming export writes continuously and does incur cost, so turn it on only when real-time genuinely matters.

Step three: understand the tables

Once linked, Firebase creates an analytics dataset and writes a daily table, events_YYYYMMDD, plus an events_intraday table if you enabled streaming. It's the same nested, event-per-row structure as the GA4 export.

Data starts flowing from the day you link it; there's no backfill of history, so the sooner you connect it, the more data you'll have later.

One nuance worth knowing: the app export and the GA4 web export share the same schema, so if you run both a website and an app, you can eventually model them side by side in the same warehouse using nearly identical SQL. That consistency is a big part of why teams standardize on the BigQuery export instead of stitching together each platform's own reports.

Step four: run your first query

The structure is nested, so counting events means unnesting parameters. A first query to prove it works:

SELECT
  event_name,
  COUNT(*) AS events,
  COUNT(DISTINCT user_pseudo_id) AS users
FROM `your-project.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260901' AND '20260915'
GROUP BY event_name
ORDER BY events DESC

Note the wildcard table and _TABLE_SUFFIX filter, which keep you from scanning your whole history every time you query.

From here the analysis you couldn't do in the console opens up: build a retention cohort by joining first-open dates to later activity, define your own funnel by sequencing event names, or attach revenue parameters to specific users. All of it is just SQL over the same events table, which is the payoff for setting the export up.

Watch the cost from day one

  • Always filter on _TABLE_SUFFIX so you scan days, not years.
  • Select only the columns you need, since BigQuery bills by bytes read.
  • Skip streaming export unless intraday data changes a real decision.

Exporting Firebase Analytics to BigQuery turns a read-only console into raw event data you can actually interrogate. Enable Blaze, link the project, learn the nested tables, and query with a suffix filter, and your app analytics graduates from glancing at dashboards to asking your own real questions.

Want a stronger data analyst role or a raise? Grab the FREE Product Analyst Playbook and get the exact roadmap to your next offer.