GA4 + BigQuery: the raw data your e-shop is already leaving on the table

1. Data thresholding. To stop you from identifying individual users, GA4 can hide rows when the numbers are small, especially when Google signals are on. On a smaller market or a niche product, that means real orders can simply vanish from a report.
2. Sampling. Explore reports and big date ranges can be based on a sample of your data, not all of it. The headline number is an estimate. For a marketing overview, fine. For reconciling revenue, not fine.
3. The (other) row and cardinality limits. GA4 caps how many unique values a dimension can show per day. Everything above the cap gets dumped into a single bucket called (other). If you sell thousands of products or have long URLs, your item-level detail can disappear into that bucket.

What BigQuery actually gives you

BigQuery is Google's data warehouse. Think of it as a giant, fast SQL database that lives next to GA4. The GA4 to BigQuery link ships your raw event data there, one row per event, with every parameter attached.

No thresholding. No sampling. No (other) row. Just the events, as they happened.

That single fact changes what you can answer. Instead of the metrics Google chose to pre-build, you have the underlying events and you write the question yourself in SQL.

There's also an ownership angle I care about. GA4's standard data retention tops out at 14 months for user and event level data. After that, the detail is gone from the interface. In BigQuery, the data is yours to keep as long as you want to pay for storage, which is cheap. Two years of clean, queryable history is a genuine asset for an e-shop.

Why an e-shop specifically wants this

A content site can shrug at most of the above. An e-shop can't, because money is attached to the detail.

Here's where the raw export earns its keep.

• Revenue you can reconcile. You can match GA4 purchase events against your backend orders, transaction by transaction, and find exactly where tracking drops or double-counts. Try doing that from a sampled report.
• Real product-level analysis. Because there's no cardinality cap in the export, every SKU, every variant and every long URL stays intact. Your best and worst sellers stop hiding in (other).
• Joining GA4 with the rest of your business. This is the big one. In BigQuery you can join behavioural data with your CRM, your margin data, your returns and your true customer lifetime value. GA4 sees a purchase of 49.90 EUR. Your business knows the margin on it and whether the customer sent it back. Together they tell a different story.
• Custom attribution and cohorts. Once the events are raw, you can build attribution and repeat-purchase cohorts on your own rules instead of GA4's built-in models.

The cost question, answered plainly

People hear "data warehouse" and assume enterprise pricing. For most e-shops that starts out wrong.

Turning on the daily export is free. BigQuery then has a free tier that covers a meaningful amount of storage and query volume every month, and plenty of small shops never leave it.

The honest caveats: the streaming (near real-time) export does have a cost, so start with the daily export unless you truly need live data. And a badly written query that scans your whole table repeatedly can run up a bill. BigQuery charges mainly by how much data your queries read, so query only the days and columns you need.

So it's not free forever at scale. But the barrier to *starting* is basically zero, which is why I tell clients to at least switch it on now and collect history.

How to actually start

You don't need to be a backend engineer for this. If you can find your way around GA4 admin, you can turn it on. This pairs well with the same technical literacy I wrote about for reading REST APIs and GA4's Data API.

A sensible order of operations:

1. Create a Google Cloud project and enable the BigQuery API. The BigQuery sandbox is a fine place to begin at no cost.
2. In GA4 admin, open Product Links, choose BigQuery Links, and link your project.
3. Pick the daily export first. Add streaming only if you have a concrete real-time need.
4. Wait. The export starts from the day you link it, not backwards, so the earlier you switch it on, the more history you'll have when you need it.
5. Once data lands, write a small query to count purchase events per day and compare it to GA4's interface. Seeing the two numbers side by side is the moment it clicks.

When you honestly don't need it yet

I try not to sell people things they don't need. So here's the flip side.

If your shop is small, your product catalogue is short, and the standard GA4 reports match your backend orders closely enough, you can wait. The export will still be there.

But even then, my advice is to link it early and let the data pile up quietly. History is the one thing you cannot backfill later. The day you finally need two years of clean event data, you'll be glad it was already collecting.

Get your tracking right first, though. BigQuery gives you raw data, and raw data from a broken setup is just broken data with more decimal places. Fix the GA4 and GTM implementation, then export it.

Takeaways

If you remember nothing else, remember this.

• GA4's interface can threshold, sample and cap your data. That's fine for a glance, risky for revenue decisions.
• BigQuery gives you the raw, unedited events, with no 14-month cutoff and no (other) bucket.
• For an e-shop, the real prize is joining behaviour with your own business data: margin, returns, real lifetime value.
• Starting is free or close to it. Turn on the daily export now so you're collecting history before you need it.
• Clean the tracking first. Raw data only helps if the collection underneath is trustworthy.

A short sign-off

I'm a bit of a purist about this. My whole positioning is web analytics that actually works, and to me that means trusting the number you report. Raw data in BigQuery is how you earn that trust instead of assuming it.

If you're running an e-shop and you're not sure whether your GA4 numbers reconcile with your orders, that's exactly the kind of thing I audit and fix. Reach out through bmateas.com/contact and let's look at it together.

Thanks for reading. I'll come back to the BigQuery side of this with some concrete SQL soon.