How BigQuery works
BigQuery is a warehouse: a place to keep large tables of data and ask questions of them in SQL. You do not run a server or size a machine. Data arrives — most often through the built-in GA4 export, a connector from an ad platform, or a file upload — and lands in tables inside a project. You then write a query, and the service works out how to answer it across whatever volume is there.
Charges follow the same shape as the work: you pay for storing the data and for the volume each query has to read. That is why a badly written query over a large table is expensive while a narrow one over the same table is not, and why marketers who write their first queries against everything quickly learn to select only the columns and dates they need.
For marketing, the pull is usually the GA4 export. It sends event-level rows rather than the summarised reports the GA4 interface shows, which means every event with its parameters, ready to be joined against CRM data, cost data or anything else you can load.
Why BigQuery matters
It removes the ceilings that platform reporting imposes. Sampling, row caps, retention windows and the limited set of breakdowns an interface offers are properties of that interface, not of the data. Once the rows are in a warehouse, the questions you can ask are limited only by what was collected.
It is also the honest way to join sources. Ad platforms report on their own conversions and none of them can see the others, so a genuine view of what a customer cost has to be assembled somewhere neutral. A warehouse is that neutral ground, and it is where lead-level and revenue data can meet ad spend.
Where BigQuery goes wrong
The commonest failure is starting from the tool rather than the question. Data gets exported for months, the queries are never written, and a warehouse quietly accrues storage charges without changing a single decision.
The second is treating the export as a backup of a report. The GA4 export is raw event data — sessions, channel groupings and conversions have to be rebuilt in the query — so figures assembled in the warehouse will not automatically agree with the GA4 interface. That is a definition difference, not an error, but it surprises people.
The third is scale mismatch. A small business site with modest traffic gets little from a warehouse that it could not get from the reporting it already has.
How to act on it
Turn the GA4 export on early even if you have no immediate plans for it, because it only fills from the day it is enabled and no one can backfill history. Beyond that, wait until you have a question the existing reporting genuinely cannot answer, then write the query that answers it and point a dashboard at the result rather than at the raw tables. Query narrow columns and short date ranges by habit, and keep an eye on what the project is spending before it becomes a line item nobody can explain. If the goal is reporting a client can read rather than analysis, decide first whether the warehouse or a simpler reporting setup is really what the job needs.