When you actually need BigQuery — and when it's just an extra cost

Someone — an agency, a freelancer, or someone on your own team — said "we should connect GA4 to BigQuery." It sounds serious, it sounds expensive, and it's not obvious what you'd actually get for it. The natural question: is this a real need, or a way to sell you extra work?

The honest answer is "it depends" — but on three specific things, not a vague feeling. If none of the situations below describe you, don't buy it yet; that money does more good somewhere else.

When GA4's own reports already answer the question

If what you check is monthly traffic sources, conversion counts, and top pages, you already have the answer. GA4's standard report panel — not the Explore section, the regular reports — already computes and displays those numbers, and according to Google's own documentation, standard aggregated reports aren't subject to sampling (source). There's no hidden margin of error in those figures; they're already accurate.

A typical monthly review looks like this: "how many buyers came from each channel this month," "which five pages got the most views," "is there a real gap between mobile and desktop visitors" — every one of those questions is already answered by the standard charts in the regular report panel. If that's genuinely all you need, BigQuery doesn't hand you a single new number to act on — you'd just start paying for the same answer through a more expensive door.

When sampling turns into a real problem

The different case: your traffic is high, and you regularly build custom explorations that cross several dimensions at once — say, traffic source × device × landing page. There the numbers can shift slightly from one query to the next, and that's a property of the Explore section's live query engine, not of the standard reports. Who actually runs into this: a local service business with a few hundred monthly visitors almost never reaches that point, because there simply isn't enough event volume to process. An online store handling hundreds of orders a day, testing a new data cut every week, hits it regularly.

The fix is straightforward: data exported to BigQuery is, in Google's own words, "raw, unsampled event data" (source). Query that table directly with SQL and the interface's sampling behaviour disappears entirely. But that benefit only pays off if you're genuinely running regular multi-dimension queries — not if you check one traffic number once a month.

Data retention — the 14-month wall

Try to compare last year's Black Friday against the year before that inside Explore, and you can hit a wall: on a standard, free GA4 property, event-level data is retained for a maximum of 14 months, and that limit applies specifically to Explorations and funnel reports (source). The same page is explicit that the setting does not affect standard aggregated reports. If a year-over-year traffic trend is all you're after and you're pulling it from the standard report panel, that 14-month wall isn't actually blocking you — check that before you pay for anything.

Here's where the difference comes from: an aggregated report already shows a summed number per day ("240 sessions today"), while event-level data keeps each individual visitor's own path — which ad they came from, which pages they viewed, how many days later they came back. The summed number never "disappears," because it's already been calculated; a single visitor's path, though, drops out of Explore after 14 months. If you run a seasonal business and need event-level analysis spanning several years — which campaign brought a user in, how many months later they bought — the wall becomes real. Data exported to BigQuery sits in your own table permanently, with nothing auto-deleted.

Multiple sources in one place — where GA4 stops on its own

GA4 shows what happened on your site, but it doesn't hold the real deal value from your CRM or a sale closed over the phone. Ask yourself how this actually gets done today: most likely, someone pulls a spreadsheet from Google Ads, another from Meta, a third list from the CRM, and reconciles all three by hand in a spreadsheet at month end. That takes time and carries a repeat risk of error every single month, because none of these systems recognises another system's customer ID.

If you want ad spend, on-site behaviour, and actual sales results in one table, every source has to land in the same place and be joined with SQL — which is exactly what a data warehouse does: GA4, ad platforms (Meta, Google Ads) and your CRM in one queryable base. A join built correctly once doesn't need re-doing by hand every month — it refreshes on its own.

Why it's already an extra cost on a small site

The numbers themselves make the case: BigQuery's own free tier covers 10 GiB of storage and 1 TiB of query processing per month (source), and standard GA4 properties get up to 1 million events exported for free per day (source). A small or mid-sized site's daily event volume, and the table it builds up, usually stay well inside those limits for a long time — so the BigQuery bill itself is rarely the actual problem.

There's a separate choice buried in here too: the standard, free export is daily and typically delivers yesterday's data by mid-afternoon the next day; a near-real-time (streaming) export costs extra per GB and excludes new-user attribution data (source). For most small businesses, a one-day lag changes nothing — streaming export only earns its cost when operational decisions genuinely need to be made hour by hour.

The real cost sits elsewhere: someone has to write and maintain the SQL, fix the join every time a platform changes its export structure, and actually open the result and act on it. A warehouse nobody queries is a recurring maintenance cost with zero return, no matter how cheap the raw processing is.

BigQuery doesn't make your data better — it raises the number of questions you can ask; a question you'll never ask isn't worth paying for, even when the bill itself is free.

Ask yourself three questions: do I regularly build multi-dimension queries in Explore? Do I need event-level history longer than 14 months? Do I want ad spend, site behaviour and CRM data in one table? If none of those is "yes," don't buy BigQuery now. If at least two are, our work bringing all your data into one warehouse exists for exactly that — we work out together which sources you actually need, and stop you paying for the rest.