# Exporting GA4 to BigQuery: when a smaller company really needs it > Three limits of GA4 justify an export to BigQuery, the rest is over-engineering. The real cost, the SQL skills required, and why to switch it on before you need it. - Original page: https://dotsland.com/en/ga4-bigquery-export-when-you-need-it/ - Language: en - Published: 2026-09-08T19:38:21+02:00 - Updated: 2026-09-08T19:38:21+02:00 - Section: Analytics - Publisher: Dotsland, https://dotsland.com/en/ --- ## In short - **Three limits justify an export.** Sampling on complex analyses, thresholding that hides whole rows, and the impossibility of joining your sessions to your real orders or your margins. - **BigQuery gives you the raw data.** One event per row, no thresholding, and the ability to recalculate attribution on your rules rather than Google’s. - **Cost is not the obstacle.** The free tier covers most smaller companies. The obstacle is that someone has to write SQL, otherwise the warehouse stays a cupboard. - **The export is not retroactive.** Switched on today, it recovers nothing from yesterday. That is the reason to wire it up now, even if you will do nothing with it for a year. An e-commerce manager asks us a simple question in a meeting: which acquisition channel brings in the customers who generate the most margin? Not the most revenue, the most margin. GA4 cannot answer that, not today and not ever. The reason is not a missing setting. GA4 does not know your purchase prices, does not see your product returns, and ignores orders cancelled after payment. It measures behaviour on a website, not the health of a profit and loss account. That is the moment a vendor suggests “exporting to a data lake”. Sometimes it is the right instinct. Often it is a project of several weeks for a question a spreadsheet would have settled in two hours. Here is how to tell the difference. ## The three walls of the GA4 interface Three ceilings explain almost every legitimate need to export. If you hit none of them, you do not have a data problem, you have an appetite for a tool. ### Sampling on complex analyses GA4’s standard reports are not sampled. Explorations are: above a certain volume of events over the period requested (in the order of 10 million for a free property), Google computes on an extract and extrapolates. A discreet banner says so at the top of the report. On modest traffic you will never see it. On a high-volume shop crossing six dimensions, it makes fine-grained analysis unreliable. ### Thresholding that makes rows disappear This is the least understood mechanism. When Google Signals is on and a cross-tabulation covers too small a group, GA4 removes the row to avoid identifying anyone. It does not show as zero: it does not appear at all. The direct consequence: your totals no longer add up. You sum the visible rows without reaching the total displayed, and no error is reported. On an analysis by city or by a low-selling product, the missing data is not an anomaly but a privacy rule. ### Joining with your order data This is the most frequent wall in smaller companies. GA4 knows a transaction of 149 EUR took place. It does have a native `refund` event, but nothing sends it automatically from your back office: without explicit wiring, GA4 will not know about the refund that happened three weeks later. As for the 12% margin and the fact that this customer is on their fourth order, no native capability brings them in. That information lives in your back office. As long as the two worlds do not meet in the same table, margin per channel stays unanswered, and no GA4 setting closes that gap. ## What the BigQuery export actually brings GA4’s native export to BigQuery writes one row per event, every day, with every parameter collected. No prior aggregation, no thresholding, no sampling: the table contains what was collected, raw. Two practical consequences. You can join that table to your real orders on a shared identifier, and therefore answer the margin question. You can also recalculate attribution on your own rules: a 7-day window rather than 90, brand traffic excluded, a different weighting of the first touchpoint. A third benefit goes unnoticed: retention. Event data usable in GA4 explorations lasts 14 months at most, two months by default if nobody has touched the setting. In BigQuery it stays as long as you keep it. *Decision grid used in audits, GA4 features as observed in 2026. One row on its own does not justify a project: it is the repetition that decides.* | The stated need | What GA4 can do | When you have to leave the tool | | --- | --- | --- | | Which channels bring the most orders | Acquisition report, enough | Almost never | | Compare two segments across several crossed dimensions | Exploration, sampled on large volumes | When the sampling banner appears | | Analyse a narrow segment (one city, a low-selling product) | Rows removed by thresholding | When rows go missing with no explanation | | Reconcile GA4 revenue with revenue actually collected | Without explicit wiring, returns and cancellations never arrive | When the gap exceeds what you can explain | | Rank channels by margin rather than revenue | Impossible: GA4 does not know your costs | When the question reaches the board | | Recalculate attribution on your rules | Models imposed, not modifiable | When Google’s model contradicts what you see | ## The real cost, presented honestly The daily export from GA4 to BigQuery costs nothing. What is billed is what you do next: storing the tables and the volume of data your queries scan. The orders of magnitude, at Google’s public rates and to be checked before you commit: a monthly free tier of 10 GiB of active storage and 1 TiB scanned, then a few cents per gigabyte stored and a few euros per tebibyte scanned. For a smaller company’s shop, a year of events is counted in gigabytes, not terabytes, and the actual bill often comes out around zero. So it is not the cost of the infrastructure that makes these projects fail. It is uncontrolled usage. > **The mistake not to make** > GA4 export tables are partitioned by day. A query with no date filter, or a `SELECT *` run just to “see what it looks like”, scans the whole history on every execution. Two curious analysts and a dashboard refreshing every hour are enough to take a bill from 0 EUR to three figures. The guard: filter on the date, and set a per-query cost ceiling in the Google Cloud project. ## Without someone who writes SQL, the warehouse stays empty Let us say it plainly, because it is the point vendors avoid: a data warehouse produces no value until someone writes queries against it. BigQuery has no reporting interface. No session chart, no conversion funnel. Tables, where each event stores its parameters in a nested structure you have to know how to unfold before you can even count a row. The first useful query takes half a day for someone who has never seen that format. The question to settle is therefore one of resources, not of technology: who will write the queries? If the answer is “nobody, we will see later”, the export is still worth doing, for the reason that follows. ## The point almost everyone forgets: nothing is retroactive The export starts the day you switch it on and does not reach back in time. Wired up in March 2026, it will never give you 2025 in raw form, whatever you spend on it afterwards. That is what makes the advice asymmetric. Switching the export on costs twenty minutes and, as long as nobody queries it, zero euros a month. Not switching it on costs a year of history on the day the need appears. > **What to take away** > Switch the BigQuery export on now, even with no idea what you will do with it. It is the only decision in this article that needs no trade-off: the cost is nil, the omission cannot be recovered. ## Exporting wrong data does not make it right A warehouse amplifies whatever you feed it. If your purchases are counted twice because they fire from both the browser and the server, BigQuery will faithfully store the double counting, and your analyses will spread it everywhere. So first check that you are exporting something correct: reconciling your real orders with what GA4 records, day by day, is enough to spot most of the gaps, a method we set out in our article on [tracking that lies in silence](https://dotsland.com/en/tracking-server-side-lying-in-silence/). To automate that check, we deploy DataFirefly Server-Side for our clients, published by Datafirefly Limited, our agency’s sister company, whose [free tier of 10,000 requests a month](https://server-side.datafirefly.com/en/) is enough for one shop. The second prerequisite is documentary. Without a [tagging plan kept up to date](https://dotsland.com/en/tagging-plan-web-optimisation/), in six months you will be facing a table holding three versions of the same event, named differently depending on the period, with nobody able to say which one counts. That work of [structuring the measurement](https://dotsland.com/en/expertise/analytics-and-performance/) comes before the warehouse. ## What you can do this week 1. Open the admin of your GA4 property and see whether a BigQuery link already exists. Many do, switched on by a former vendor and never used. 2. If not, create a Google Cloud project and wire up the daily export. Choose the European location for the dataset at creation: it cannot be changed afterwards. 3. On the same screen, raise event data retention to 14 months if it is still on two. 4. Note the activation date. That is the start of your raw history, and it will not start any earlier. 5. Set a per-query cost ceiling before anyone gets access to the project. 6. Write the first query only on the day you have a question GA4 cannot answer. ## Frequently asked questions ### Is the GA4 to BigQuery export free? The daily export itself costs nothing on a standard GA4 property. What is billed is storing the tables and the volume your queries scan, with a monthly free tier that covers most smaller companies’ usage. Streaming export, on the other hand, is billed by volume and is only worth it if you genuinely need minute-level data. ### Will I get my GA4 history back in BigQuery? No. The export starts at the activation date and does not reach into the past. Hence the value of switching it on even with no immediate project: the setup takes a few minutes, the lost history cannot be recovered. ### Do I need a data lake, or is BigQuery enough? For a smaller company whose main source is GA4, BigQuery is almost always enough: it is the native destination of the export, with no development to write. A data lake is justified when you need to bring together many heterogeneous sources, with the volumes and the technical team that go with it. ### Does exporting my GA4 data raise a GDPR issue? The export moves data that has already been collected: it changes neither the legal basis nor the consent obtained. What to watch: the location of the dataset, the retention period you decide on, and the access you grant. Our [reference points on compliant measurement](https://dotsland.com/en/audience-measurement-without-consent/) set out that framework. ## The right question is not a technical one Before opening an export project, write down the question you want answered and see whether [the standard GA4 reports](https://dotsland.com/en/ga4-badly-configured/) already answer it. In most of the files we audit, they do, and the real problem is elsewhere: incomplete collection, a vague tagging plan, or [first-party data never joined](https://dotsland.com/en/first-party-data-from-scratch/) to the rest. When the question genuinely resists the interface, the export becomes not only the right answer but the only one. The order matters: make it reliable, document it, then export. **Unsure whether a GA4 to BigQuery export is worth it for you?** We start by comparing seven days of your real orders against what GA4 records, then we list the business questions your setup cannot answer. [Let’s talk](https://dotsland.com/en/contact-us/).