Firebase Analytics BigQuery Export: Official Docs and Settings

Lately, I keep hearing the same two questions from app teams: where are the official Firebase Analytics BigQuery export docs, and what should we configure after the link is live? The official Firebase docs cover the click path. This post is the practical companion: what to turn on, what to double-check, and what can hurt you two months later if you miss it.

Quick answer

Use the official Firebase BigQuery export documentation to link Firebase to BigQuery from the Firebase console. After that, check four things before you call the export done:

1. Pick the BigQuery region intentionally.
2. Enable streaming export if you need intraday events.
3. Decide whether advertising identifiers should be exported.
4. Remove the default 60-day table expiry if you need long-term history.

First, Firebase gets your app events into BigQuery. Second, BigQuery gives your data team the raw event tables they need for retention, funnels, activation, LTV, attribution, and experiment analysis.

1. Backed by Google: Firebase Analytics isn't your average analytics tool. It's built on the foundation of Google's internal solutions for app challenges, refined and available for everyone.
2. Seamless Google Analytics Integration: Firebase and Google Analytics are buddies. Whatever you track in Firebase, you can seamlessly analyze in Google Analytics. The best part? It's user-friendly, no need for a tech whiz; your product manager can handle it.
3. Comprehensive Toolbox: Firebase is more than just an analytics tool. It handles errors, secures user data, allows for remote config adjustments, and even offers A/B testing. It's a holistic solution for refining and perfecting your app's operation.
4. Industry Standard with Community Support: Many other apps, similar to yours, use it. That means a supportive community and ample resources to tap into when challenges arise.
5. Cost-Effective: In a landscape where similar tools come with a hefty price tag, Firebase stands out. Oh, and did I mention it's free? Google's offering it without a bill attached, making it an attractive choice for budget-conscious startups.

Here are the settings I care about before I trust the export.

Recommended Settings

I won't copy the official Firebase BigQuery export documentation step by step. Use the Firebase guide for the setup flow, then use the notes below to make the export useful for actual analysis:

• Go to the Integrations page in the Firebase console.
• In the BigQuery card, click Link.
• Follow the on-screen instructions to enable BigQuery.

With those initial steps covered, let's now explore additional settings to optimize your data export process:

1. Region: Consider regulations like GDPR in Europe, CCPA in the US, or KVKK in Turkey when choosing a region to store your data.
2. Export Frequency: Firebase has its quirks with batch processing, like a daily limit of 1 million events. Instead, I recommend the more real-time Streaming option. Yes, it's a bit pricier, but the pros outweigh the cons, especially if you're aiming for almost real-time data.
3. Advertising Identifiers: Device tracking can be tricky, making it smart to have IDFA/IDFV and GPS-Adid for debug purposes. Enabling advertising IDs also empowers you for future data integration, particularly when dealing with various data sources such as marketing (MMPs like Adjust/Appsflyer, ad networks like Facebook/Google/TikTok), or revenue data.

With data in BigQuery, the real work starts. You can join Firebase events with subscriptions, payments, campaigns, support tickets, feature flags, and warehouse models. That is where Firebase stops being a product analytics screen and becomes part of your company data model.

Firebase BigQuery Export FAQ

Where are the official Firebase Analytics BigQuery export docs?

The official setup guide is here: Firebase BigQuery export documentation. Use it for the console steps. Use this post for the settings and retention checks that are easy to miss.

Does Firebase export raw events to BigQuery?

Yes. Firebase creates event tables in BigQuery, usually with daily events_YYYYMMDD tables and, when streaming export is enabled, intraday tables. That raw event-level shape is what makes deeper SQL analysis possible.

Should I enable streaming export?

Enable it when product, marketing, or data teams need same-day reporting. If you only review yesterday's numbers, daily export can be enough. I usually prefer streaming for active apps because debugging delayed data is not fun.

What should I check right after linking Firebase to BigQuery?

Check the BigQuery region, streaming export, advertising identifiers, and table expiration. Those four decisions decide whether the export is compliant, useful for attribution, fresh enough for the business, and safe for long-term analysis.

One Last Thing: Turn Off the 60-Day Expiry

One gotcha that catches a lot of people off guard: by default, the analytics_xxxxxxxxx dataset that Firebase creates in BigQuery comes with a 60-day table expiration set on it. That means any daily events_YYYYMMDD table older than 60 days will be automatically deleted, and you'll lose your historical data before you even realize it.

If you're planning to do any serious long-term analysis (cohort retention, year-over-year comparisons, LTV modeling, etc.), make sure to remove this expiry as soon as you set up the export. You can do it from the BigQuery console (open the dataset → Edit details → uncheck Enable table expiration), or just run this:

-- Replace `analytics_xxxxxxxxx` with your dataset name
ALTER SCHEMA `analytics_xxxxxxxxx`
SET OPTIONS (default_table_expiration_days = NULL);

Do this on day one. Otherwise you'll be kicking yourself two months in when the older tables start disappearing.

One important catch: changing the dataset's default expiry only affects new tables created from that point on. Every existing daily shard (events_YYYYMMDD, events_intraday_YYYYMMDD) keeps the 60-day expiration it was born with. You need to clear it on each of them individually.

Rather than clicking through every table, run this script in the BigQuery console. It loops through all the sharded tables in the dataset and clears the expiration:

-- Replace `analytics_xxxxxxxxx` with your dataset name
FOR record IN (
  SELECT table_name
  FROM `analytics_xxxxxxxxx.INFORMATION_SCHEMA.TABLES`
  WHERE table_name LIKE 'events_%'
     OR table_name LIKE 'events_intraday_%'
) DO
  EXECUTE IMMEDIATE FORMAT(
    "ALTER TABLE `analytics_xxxxxxxxx.%s` SET OPTIONS (expiration_timestamp = NULL)",
    record.table_name
  );
END FOR;

After it finishes, your historical data is safe. No more silent deletions.