LIMIT 10 doesn't make it cheaper: BigQuery bills the bytes it reads, not the rows it returns
A SELECT * with LIMIT 10 returns ten rows and can still bill the whole table. How BigQuery stores and reads data, and how to make every query read less.
Find it. Understand it. Fix it.
What's wrong with my data? Let's find out.
Most broken dashboards are not broken by the tool. They are broken by small setup mistakes that nobody notices. We find them, explain why they happen and show how to fix them.
The symptom: what you see in the reports, and how to spot it in your own account.
The cause: where the mistake is born (the site, the tag manager, the property settings) and why.
The fix, and how to check that it worked before you trust the data again.
Every short video we publish on Instagram, TikTok and YouTube has a post here. The post replays the same animation in landscape, step by step and without sound, and explains it calmly in writing: the context, the edge cases and how to verify the fix.
The whole data stack, one mistake at a time. We started with Google Analytics 4, the Meta Conversions API and BigQuery.
A SELECT * with LIMIT 10 returns ten rows and can still bill the whole table. How BigQuery stores and reads data, and how to make every query read less.
Without a _TABLE_SUFFIX filter, events_* reads every day you've exported, plus intraday tables with streaming on. Higher bills and totals that don't match.
Unnesting event_params with a CROSS JOIN turns each event into one row per parameter, so COUNT and SUM multiply. How to read parameters without duplicating events.
ga_session_id only identifies a session within one user, so COUNT(DISTINCT ga_session_id) merges sessions of different users. How Google counts them instead.
Tell us what you see in your reports. Email us at hello@wrongwithdata.com