Here's a claim I'll defend to anyone: if you run a real e-shop and you only ever look at the GA4 interface, you are seeing a polished, rounded, occasionally edited version of your own data.
I don't mean GA4 is lying to hurt you. It just makes trade-offs to keep reports fast and to protect user privacy. Those trade-offs are fine for a quick look. They are not fine when someone asks you *why did revenue drop 6% last week* and you need an answer you can trust.
The fix is not a fancier dashboard. It's getting the raw data out. And the free, built-in way to do that is the BigQuery export.
Let me explain what the interface hides first, because that's the part people underestimate.
When you open a report in GA4, three things can happen between the real events and the number on your screen. None of them are bugs. All of them can bite an e-shop.
Once you know these exist, you start to see why the raw export matters.
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.
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.
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.
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:
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.
If you remember nothing else, remember this.
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.