BigQuery for Marketers: The GA4 Export, Explained

The export in one picture: the same events, unsampled and kept, queried into the tools you already use.

Every GA4 property has a "BigQuery links" screen in Admin, and most Indian marketing teams have never opened it. That's reasonable. It sounds like an engineering tool, and mostly it is.

But it's also the only way to get your own analytics data out of Google's interface and into a form you fully own. That matters more every year, as covered in our marketing analytics guide, which places BigQuery at the top "decide" layer of the stack.

This page is BigQuery for people who run marketing, not data teams. What GA4 itself is and how its reports work lives in our GA4 guide; building the dashboard on top lives in our Looker Studio post. Here we cover the warehouse in the middle.

What is BigQuery, in marketer's terms?

BigQuery is a database you rent from Google Cloud. You load tables into it — millions of rows if you like — and ask questions in SQL, the standard language for querying tables. It returns answers in seconds even on very large tables, and you pay mainly for how much data each question reads.

Think of it as Google Sheets with no row limit, no "loading…" spinner, and formulas written as sentences instead of cell references.

Two things make it relevant to marketing rather than to IT:

• GA4 exports into it natively. Google built a one-click link from any GA4 property to BigQuery. No connector, no third-party tool, no cost for the export itself.
• Everything else can go in too. Your Google Ads spend, Meta spend, CRM leads, Shopify orders, a Google Sheet of offline sales — once they sit next to your GA4 events, you can join them on a common key and answer questions no single tool can.

Why would a marketer ever touch BigQuery?

Four reasons, in the order they usually bite.

1. Unsampled data. GA4 explorations on a standard property run against a quota of 10 million events per query; go past it and GA4 samples, so your funnel or path report becomes an estimate (Google's data-sampling page). The BigQuery export is every event, always.

2. Retention you control. A standard GA4 property keeps event-level data for 2 or 14 months; only 360 properties go longer, and the setting affects explorations and funnels (Google's retention page). BigQuery keeps whatever you export for as long as you keep the table. Want to compare this Diwali's landing pages with the ones from three Diwalis ago, user by user? Only possible here.

3. Joins. GA4 knows a lead came from Meta. Your CRM knows the lead became a ₹1,80,000 customer four months later. Neither tool can see the other. In BigQuery you join the two on the lead ID or the GA4 client ID and finally see which channels produce customers, not form fills. This is the practical payoff of owning your first-party data rather than renting views of it.

4. Dashboards that don't break. Looker Studio reports built on the GA4 connector are subject to the Google Analytics Data API's quotas, and Google's own docs say reports that exceed them "may display an error message" (Looker Studio connector docs). Point the dashboard at a BigQuery table instead and that quota disappears — the dashboard reads a table you pre-computed.

GA4 interface vs the BigQuery export

Same events, two very different places to look at them.

Retention, sampling, free-tier and timing figures are from Google's own pages, linked in the sections above and below.

How does the GA4 → BigQuery export work?

You link a GA4 property to a Google Cloud project once. From then on, GA4 writes its raw events into a dataset in that project, one table per day. Everything below is from Google's BigQuery export overview unless noted.

• It's available to standard (free) properties. You don't need GA4 360. The export is one of the few things the free tier does that used to be paid-only.
• Daily export. One table per day, named events_YYYYMMDD, written after the day's events are collected. Standard properties have "a daily BigQuery Export limit of 1 million events" on this daily export; go past it and Google's setup page says you'll get an email and the export can be paused.
• Streaming export. An intraday table, events_intraday_YYYYMMDD, updated continuously through the day. Also available to standard properties, with no event cap, but Google charges "$0.05 per gigabyte" for it on top of normal BigQuery costs.
• Late data. Google says it will keep updating a day's table for up to two further calendar days with late-arriving events, so yesterday's numbers can shift slightly.
• The sandbox. You can export into a free BigQuery sandbox with no credit card, but "exports that exceed the sandbox limits incur charges" — and the sandbox has its own catches, covered next.

One practical warning from our own setups: the export starts on the day you link it and does not go back and fill in earlier months. Google's setup page says data "should start flowing to your BigQuery project within 24 hours" (set up BigQuery Export). Nothing before that day ever appears. That is the single best argument for switching it on before you think you need it.

What does BigQuery cost?

Honestly: for most Indian SMBs, nothing. For a large ecommerce site, something, and it's predictable.

Google's BigQuery pricing page (fetched September 2026) states two free allowances every month:

• Storage: "The first 10 GiB per month is free."
• Queries: "The first 1 TiB of query data processed per month is free."

Beyond that, the same page lists on-demand querying at $6.25 per TiB processed in the US multi-region, and active storage at a fraction of a cent per GiB per hour — roughly $0.02 per GiB per month. These are Google's US-dollar list prices; your invoice depends on the region you choose and Google Cloud's billing currency for your account, so treat them as the shape of the cost, not a quote.

What that means in practice, as our opinion from running these exports: a clinic chain or coaching institute doing a few lakh GA4 events a month stores well under a gigabyte a month and runs queries that read megabytes, not terabytes. It stays inside the free tier for years. A D2C brand doing tens of millions of events a month will pay — but in hundreds or low thousands of rupees a month equivalent, not lakhs, as long as nobody writes SELECT * across two years of tables every morning.

Two cost rules that save more than any pricing table:

• Always filter by date. The export is partitioned by day. A query that names the dates it needs reads only those tables; one that doesn't reads everything you've ever exported.
• Build one summary table, not fifty live queries. A scheduled query that writes a daily "sessions, channel, landing page, key events" table is what your dashboard should read. It's tiny, and it's free to read.

About the sandbox. Google's sandbox documentation says you get the same 1 TiB monthly query allowance without "providing a credit card or creating a billing account", but tables "automatically expire after 60 days", storage is capped at a lifetime 10 GiB, and streaming isn't supported. For a GA4 export whose whole point is keeping history, 60-day expiry defeats the purpose. Enable billing on the project; the free tier still applies, and you keep your data.

Three questions you can only answer in BigQuery

You don't need to write SQL fluently to use BigQuery. You need to be able to say precisely what you want, then let a colleague or an AI assistant draft the query and check that the answer makes sense. Here are three questions in the form you'd say them, with the query described in plain English.

Which landing page's visitors actually converted within 30 days?

GA4 credits the session where the conversion happened. You want to know which first page earned the customer, even if they converted weeks later.

The query in English: for every user, take the landing page of their first session in the period. Then look ahead 30 days in the same user's events for a generate_lead or purchase. Count users and converters per first landing page, and divide.

What it changes: a coaching institute we'd typically see finds that its "fees" page has a low same-session conversion rate but the highest 30-day rate of any page — because people read the fees, think, and come back. That page deserves budget, and the interface would never tell you.

Which first channel brings repeat purchasers?

A first purchase from Meta ads and a first purchase from organic search look identical in GA4's revenue report. They aren't identical six months later.

The query in English: for each user with at least one purchase, find the source and medium of their first-ever session. Count how many of those users have two or more purchases. Group by first channel and compare the repeat rate — and, if you've joined order values, the revenue per first-time buyer.

What it changes: this is the cohort question that decides how much a D2C brand can pay to acquire a customer. The full method, including how to read the table, is in our cohort analysis post; BigQuery is where the raw numbers come from once the order export outgrows a spreadsheet.

Which sessions clicked WhatsApp but never filled the form?

Very Indian, very common: the site has a WhatsApp button and a lead form, and half the "leads" bypass the form entirely. GA4 can count both clicks; it can't easily show you the overlap.

The query in English: list every session that has a whatsapp_click event and no generate_lead event. Group those sessions by landing page and channel. You now know which pages push people to WhatsApp instead of the form — and which campaigns produce conversations your CRM never sees, so the ad platform is being told they failed.

What it changes: feed those WhatsApp sessions back to Google Ads and Meta as conversions — usually via server-side tracking — and the algorithms stop optimising away from your best pages. This is the kind of fix we build inside our performance marketing engagements, because a campaign optimised on half its conversions is a campaign paying double.

How to turn on the export and run your first query

The linking steps follow Google's setup page; the query steps are ours.

1. Create or pick a Google Cloud project. Sign in at console.cloud.google.com with the Google account that has Editor access to the GA4 property. Create a project named for the business, not the agency, so the data stays with the client. Enable billing on it — the free tier still applies, and it avoids the sandbox's 60-day expiry.
2. Enable the BigQuery API. In the project, go to APIs & Services › Library, find BigQuery API, click Enable. Google's page also asks you to accept the terms of service the first time.
3. Link from GA4. In GA4, go to Admin › Product links › BigQuery links › Link. Choose the project, choose a data location (pick one close to you; Google notes it cannot be changed once the dataset exists), tick the data streams to export, and choose Daily. Add Streaming only if you genuinely need same-day data and accept its per-gigabyte charge. Submit.
4. Wait a day, then look. Within about 24 hours, open BigQuery in the Cloud console. You'll see a dataset named analytics_ followed by your property ID, containing an events_YYYYMMDD table for the first day. Click it and use Preview — every row is one event, with nested columns for page, traffic source, device and event parameters.
5. Run the sanity query. In the query editor, count events by event_name for yesterday's table. The totals for page_view and your key events should sit close to GA4's own reports for the same day (GA4 applies thresholds and modelling, so expect small gaps, not big ones). If generate_lead or whatsapp_click is missing, fix the tag in your GA4 setup before you build anything on it.
6. Save one summary query as a schedule. Write a query that outputs date, channel, landing page, sessions and key events, using a date filter. Save it, then schedule it to run daily into its own table. That table is what Looker Studio should read — not the raw events.
7. Write down who owns it. The project, the billing account and the link should all be documented in the client's own records. The most common BigQuery disaster we see isn't cost — it's an export that lived in an ex-employee's or ex-agency's Google account.

What you actually need

Less than it sounds.

• A Google Cloud project with billing enabled. Free to create. Billing is enabled so you leave the sandbox; you are still charged nothing until you pass the free tier.
• Editor access on the GA4 property and owner access on the Cloud project, per Google's setup page.
• Someone who can write SQL — or draft it with AI and check it. Three years ago this meant hiring an analyst. Today a marketer who can describe the question precisely, paste the GA4 export schema into an AI assistant and read the result critically will get useful answers in an afternoon. The checking part is not optional: a query that silently double-counts sessions looks exactly like one that doesn't.
• A written list of five questions. Not "explore the data". BigQuery rewards a specific question and punishes browsing, both in cost and in time.

When not to bother with BigQuery

Our honest view: if your site does under roughly 10,000 sessions a month, BigQuery is usually overkill. GA4's explorations won't sample at that volume, 14 months of retention covers a year-on-year comparison, and the questions above can be approximated with a good CRM and a spreadsheet.

Two exceptions to that opinion:

• Turn it on anyway if you plan to grow. The export costs nothing at low volume and the history it builds can't be recreated later. A five-minute link today is fourteen months of extra data next year.
• Turn it on if your sales cycle is long. A manufacturer whose enquiry-to-order takes eight months will outlive a 2-month retention setting before the first deal closes. That business needs BigQuery at 2,000 sessions a month more than a blog needs it at 200,000.

And skip it, at any size, if nobody will own it. An export nobody queries is a bill nobody understands.