BigQuery App Analytics: Setup, Queries and Costs

November 13, 2026

BigQuery App Analytics: Setup, Queries and Costs

BigQuery App Analytics: Setup, Queries and Costs

Engineer configuring an app analytics data export

BigQuery app analytics means exporting your raw Firebase or Google Analytics 4 (GA4) events into Google’s data warehouse, so you can query every event with SQL instead of reading fixed dashboards. It is the right layer when you need event-level questions answered. Most app teams also need a daily view of downloads, revenue, subscriptions and ad monetization next to their store listing work, without writing queries. That is the gap Apptenium fills: it brings Firebase, Google Analytics and ad network data into one place, alongside ASO scanning and keyword tracking.

This guide shows what BigQuery adds, how to link it, what lands in the tables, what it costs and where it stops being the quickest route to an answer.

Apptenium
apptenium.com
See App Performance Alongside ASO
Apptenium brings Firebase, Google Analytics and ad network data together with ASO scanning and keyword tracking in one platform.
Visit

TL;DR

  • BigQuery stores raw, event-level app data from Firebase and GA4 and lets you query it with SQL, which the standard reports cannot do.
  • Linking takes a few clicks in Firebase Project Settings or GA4 Admin, but data can take up to 48 hours to start flowing.
  • Exports are free to run into the sandbox; you pay for storage, streaming inserts and queries. Standard GA4 properties export up to 1 million events per day.
  • Raw tables are powerful but need SQL, schema knowledge and upkeep. A unified dashboard answers the everyday questions faster.
  • Apptenium unifies Firebase, Google Analytics and ad data with ASO insights. The Pro plan is $9.99 per month, and there is a free tier.

Table of Contents

What BigQuery adds to app analytics

Firebase and GA4 give you ready-made reports: usage, crashes, notification effectiveness, deep-link performance, in-app purchases and advertising attribution. Firebase’s analytics page says the raw data can also be exported to BigQuery for custom analysis.

The difference is control. According to Firebase’s export documentation, the console tools let you explore historical app data, while BigQuery lets you run your own SQL queries and send the data to your own tools. The same page says export covers Google Analytics, Cloud Messaging, Crashlytics, Performance Monitoring, A/B Testing and Remote Config personalization.

Google Analytics Help adds three points that matter in practice:

  • The export contains raw, unsampled events.
  • You can import external data to join with your events.
  • BigQuery access controls decide who can see the exported tables.

In short, BigQuery is where you go when a question is too specific for a preset report. Examples are “which acquisition cohort bought a subscription within seven days of a particular custom event?” or “how does revenue differ by a custom parameter we pass with each event?”

There are two entry points, and both end in the same kind of dataset.

From Firebase

  1. Open Project Settings in the Firebase console.
  2. Select Integrations.
  3. Click Link on the BigQuery card and follow the on-screen instructions, as described in Firebase Help.

Firebase Help also notes that all apps in the project are linked by default, and apps you add later are linked automatically. You can manage individual apps if you want to keep some out.

From GA4

GA4 needs a bit more preparation. Google Analytics Help lists the requirements: a Cloud project with BigQuery enabled, an Editor-or-higher role on the Analytics property, and Owner access to the BigQuery project.

During linking you can:

  • Choose the BigQuery project and data location.
  • Select which data streams to export.
  • Exclude specific events.
  • Optionally include mobile advertising identifiers.
  • Pick daily or streaming export. Analytics 360 properties can also choose fresh-daily export.

Pick the data location deliberately. It is the kind of setting that is awkward to change later, so decide it with whoever owns your cloud project before you click through.

What to expect after linking

Firebase documents that linking creates a copy of your existing data, that the first propagation may take up to 48 hours, and that daily synchronization follows. Do not treat the timing as a fixed schedule. If you are building a report that a stakeholder reads at 9 a.m., plan for the previous day’s data, not this morning’s.

What the exported tables contain

Each linked GA4 property or Firebase project gets its own dataset named analytics_<property_id>. According to Google’s schema documentation, inside it you will find daily tables named events_YYYYMMDD, plus optional events_intraday_YYYYMMDD tables if you turned on streaming.

Two details trip up new users:

  • Late events. Daily tables can be updated for up to three days after the event date to account for late-arriving events. Events later than that window are not recorded. A report on yesterday’s numbers can therefore shift slightly over the following days.
  • One row per event. Every install, session start, purchase and screen view is a row, with nested parameters. Revenue, product IDs and engagement time sit inside those parameters, so you unpack them in your query rather than reading a column.

That last point is why event-level analysis rewards a data-literate team. The tables are complete, but you are responsible for turning them into metrics your colleagues agree on.

Typical questions teams query

  • Installs: count distinct users on the first-open event.
  • Engagement: count distinct users with engagement events, and sum engagement time per user.
  • Purchases: filter to in-app purchase events and sum the revenue value attached to them.
  • Retention: compare a user’s first-open date with the dates of later events.

Each of these is a short query once you know the schema, and a longer one once you add platform splits, currency handling or de-duplication.

Combining app data with ad and business data

The strongest argument for a warehouse is joining. Firebase says linking AdMob brings ad metrics and AdMob revenue into your Analytics reporting, which supports richer lifetime-value and in-app advertising analysis.

Beyond that, a warehouse can hold CRM, commerce and third-party advertising data next to your app events. Bounteous describes joins that produce things like campaign spend against product performance and return on investment. The practical lesson for a mobile team is that a number such as cost per paying user only exists once spend and purchases are in the same place.

App, advertising, and business data joins

That is also the case for combining marketing and product data more broadly, as shown in this look at how analytics ties to marketing ROI. Teams that tie spend to outcomes can see which channel actually earns its budget.

If you want this joined view without building and maintaining the pipeline, our guides on unifying Firebase and Google Ads for app growth and unifying app analytics into one reliable view walk through the logic step by step.

Visualizing BigQuery data

Raw tables are not something a marketing lead opens on Monday morning. Firebase documents one common route: Looker Studio (formerly Data Studio) can turn exported BigQuery data into customizable, shareable reports. Its Crashlytics dashboard guide shows how to select an exported batch or streaming table as a data source and copy a supplied report template.

The pattern generalizes to any export: choose the table, build or copy a template, and schedule your review. Expect to maintain it. When your event naming changes or you add a platform, the queries behind the charts change too.

What it costs, and the limits to plan for

BigQuery separates running an export from using the data afterward.

  • Exporting is free of charge. Firebase Help says Google Analytics, Cloud Messaging, Crashlytics and Performance Monitoring data can go to the BigQuery sandbox at no cost, within sandbox limits.
  • Using it is billed. BigQuery charges for storage, streaming inserts and queries, as the Firebase blog explains. The same post notes the sandbox needs no payment but has a 60-day default table expiration and restrictions, including no streaming, no transfer service and no DML (data modification statements).
  • Daily versus streaming. Google Analytics Help says daily export is complete for the previous day. Streaming supplies current-day data on a best-effort basis and may have gaps, and it leaves out traffic-source data for new users and new sessions.
  • Volume cap. Standard GA4 properties have a daily export limit of 1 million events. Analytics 360 properties can export up to 20 billion events per day.

For a growing app, the 1 million event cap deserves attention early. An app with many active users and chatty custom events can reach it, so decide which events you really need before you scale. You can exclude events at link time.

Where BigQuery is the right tool, and where a unified view wins

BigQuery shines for custom event-level questions, data-science work, and joins with your own business systems. It asks for SQL skills, schema knowledge, cost monitoring and someone who owns the pipeline.

Most app teams’ weekly questions are simpler, and they cut across more than analytics:

  • Which keywords moved after the last metadata update?
  • Did organic installs rise after the new screenshots?
  • What is revenue by app this week, across subscriptions and ads?
  • What did a competitor change in their listing?

These questions need app analytics, store visibility and competitor data side by side. That is the fragmented-analytics problem Apptenium was built around. It integrates data from Firebase, Google Analytics and ad networks, and reports downloads, revenue, subscriptions and ad monetization in the same place as ASO scanning, keyword tracking and competitor intelligence. You get real-time insights without stitching several tools together.

A realistic split of work

Question Where it is answered fastest
Downloads, revenue and subscriptions by app and store Apptenium app analytics
Ad monetization next to listing changes Apptenium
Keyword rank and visibility trends Apptenium keyword tracking
Rival listing and creative changes Apptenium competitor intelligence
Custom event funnels and cohort modeling BigQuery SQL on your exported events

For agencies running several apps, the first four rows are the daily work, and a single view across the portfolio saves the effort of writing and maintaining one query set per client. Our guide on cross-app performance reporting shows how to prove what your ASO work contributed.

From the console to the warehouse: a sensible order

You do not need the warehouse on day one. A practical sequence:

  1. Start with the console and a unified dashboard. Learn what your app does in Firebase first. This overview of Firebase Analytics against Mixpanel for retention helps you see what each console view can and cannot tell you.
  2. Define the metrics your team agrees on. Installs, paying users, revenue and retention windows need one definition each before anyone writes SQL.
  3. Link BigQuery when a question outgrows the dashboards. Link early enough to collect history, since the export starts copying from the moment you link.
  4. Keep storage tidy. Exclude events you do not need, and set expirations deliberately.
  5. Keep the everyday view unified. Use one place for downloads, revenue, ad income and keyword visibility so reporting does not wait on a query.

Tracking installs well matters in both worlds. Our guide to tracking organic installs on iOS and Android and the one on organic uplift measurement explain how to separate what your listing earns from what your campaigns buy. If subscriptions are central to your revenue, check Firebase subscription tracking before trusting any revenue query.

Our view

Raw data is only useful when it ends in a decision. We see app teams collect events in a warehouse and still ask the same simple questions every week: did our listing change move rankings, and did that move installs and revenue?

Our position is that the listing, the keywords, the competitors and the monetization numbers belong in one view. When they live in separate tools, nobody connects a metadata change to a revenue change, and the work of exporting and reconciling takes the time you meant to spend improving the app page.

That is why Apptenium combines ASO scanning, keyword tracking and competitor intelligence with Firebase, Google Analytics and ad network data, and adds AI recommendations that give copy-ready fixes after each scan. A warehouse answers the deep custom questions. The everyday decisions should not need a query.

Mike

See your app data in one place

Apptenium has a free tier with a limited number of scans per month, and a Pro plan at $9.99 per month with unlimited scans and premium features. Connect your Firebase and Google Analytics data, check your listing with the scanner, and follow downloads, revenue and keyword rankings together. Compare the plans on the pricing page.

Apptenium

FAQ

Is BigQuery export for app analytics free?

Exporting Firebase and Google Analytics data to the BigQuery sandbox has no charge, within sandbox limits. BigQuery itself bills for storage, streaming inserts and queries. Check the Firebase Help page for the current details.

How long until data appears in BigQuery after linking?

Firebase says the initial propagation can take up to 48 hours, followed by daily synchronization. Treat the timing as approximate. Daily tables can also be updated for up to three days after an event date, so recent numbers can shift.

Do I need SQL to use BigQuery for app analytics?

Yes, to work with the raw tables directly, since each event is a row with nested parameters. Dashboards in Looker Studio can sit on top once someone has prepared the data. For downloads, revenue and ad income reporting without queries, a unified platform such as Apptenium covers it.

Can BigQuery combine ad spend with app revenue?

Yes. You can store advertising and business data next to your app events and join them, and Firebase says linking AdMob brings ad revenue into Analytics reporting. The result depends on consistent campaign and event naming, so agree on those before you build the joins.

Sources

← Back to Guides · Home