The GA4 BigQuery export gives you what the API will not
The Data API answers questions you can express in its dimensions. The BigQuery export hands over the events themselves, with the costs and caveats that come with owning them.
The GA4 BigQuery export gives you the raw events themselves, one row per event, with every parameter attached and a pseudonymous identifier for the device that sent it. The Data API gives you aggregates over the dimensions and metrics Google defines. That is the whole difference, and everything else follows from it: with the export you can ask a question nobody anticipated, join analytics events to your own tables, and recompute a metric with your own definition. What you take on in exchange is a warehouse, a bill, and a set of rules about when the tables are complete.
Google documents the daily BigQuery export as exporting all the raw, unsampled event data once per day from the previous day, with the specific time not guaranteed — typically mid-afternoon in the property's time zone, but sometimes later in the day or the next day. Each day lands in a table named for its date. If streaming export is also enabled, an intraday table for the current day is written continuously and then deleted once the full daily table for that day is complete.
The export is not retroactive in the way people expect a warehouse to be, and it is not instantly final either. Google documents that daily tables continue to be updated for up to two calendar days plus today beyond the date of the table, to absorb events that arrive late — an event bundle timestamped the first of the month can still land in that table on the fourth. Occasionally tables are updated later than that, when historical data has to be reprocessed.
| Question | Data API | BigQuery export |
|---|---|---|
| Sessions by channel last week | One request, minutes of work | A query you have to write |
| Every parameter sent with one custom event | Not available as a general capability | Available, in the event parameter array |
| Join analytics events to your own order table | Not possible | The reason people set this up |
| A metric defined differently from Google's | Not possible | Possible, and your responsibility to defend |
| Numbers that match the Analytics interface | Closer, by construction | Will differ; the export excludes the interface's added modelling |
| Cost | Quota, no invoice | Storage and query charges, or a free sandbox |
First click, linear, time decay and position-based were withdrawn in November 2023. What remains in the GA4 attribution reports is data-driven, paid and organic last click, and Google paid channels last click — and one of the three is still the one arguments end on.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
Google states plainly that the BigQuery event export provides access to raw event and user-level data, excluding the value additions Google Analytics makes to the data found in standard reports and explorations, and that for this reason the export data might differ from the interface. Treating a difference as a defect is the most common way a warehouse project loses its credibility in month two. The two sources are computed differently on purpose, and the honest response is to say which one a given report came from.
Data thresholding is part of the same story from the other direction. Aggregated reporting can withhold rows to protect identity, which is a behaviour of the reporting layer rather than of the events; the export hands over the rows themselves. If a report has ever gone blank on you for reasons nobody could explain, that mechanism is worth understanding before you conclude the export is wrong.
Streaming export exists to make the current day's data available within minutes, and Google is explicit that it is a best-effort operation which may not include all data, for reasons such as late events and failed uploads. The guidance is to query the daily table rather than the intraday one so you are working against a stable dataset for that day. A dashboard built on the intraday table will move under its readers, and the movement will be blamed on whoever built it.
The export itself is a link between two Google products; what costs money is storing the data and querying it, and Google notes that you can export to a free BigQuery sandbox if you want to try it without billing attached. The practical cost driver is query habits rather than storage: a dashboard that scans every day of history on every refresh is expensive in a way that the same dashboard reading a summarised table is not. Building daily aggregate tables early is the difference between a warehouse and a bill.
There is also a governance benefit that has nothing to do with queries. Google states that when you export data to BigQuery you own that data, and can manage permissions on projects and datasets with BigQuery access controls. For anybody who has tried to give a contractor access to exactly one report in an analytics interface, that alone is sometimes the reason to do it.
No. The export begins producing tables from the point the link is set up, so the earliest date you can query is the first day it ran. This is the single most common surprise in adopting it, and the practical consequence is to enable the export as early as possible even if nobody is ready to query it. Data that was never exported cannot be recovered into the warehouse later.
Because the export provides raw event and user-level data and excludes the value additions Google Analytics makes to the data in standard reports and explorations. Google documents this difference rather than treating it as a fault. Both figures can be correct at once, computed under different definitions, which is why any report built on the export should say which source it came from.
Use the daily export for anything that will be quoted, and add streaming only when somebody genuinely needs the current day. Google describes streaming export as a best-effort operation that may not include all data, and recommends querying the daily table for a stable dataset. The intraday table is also deleted once the day's full table is complete, so queries that name it directly are inherently temporary.
Yes. Google documents a daily export limit of up to one million events per day for standard properties, with filtering options available to stay under it, and up to twenty billion events per day for 360 properties. A property that regularly exceeds the standard limit has to either reduce what is exported through filtering or move to the higher tier; there is no version of the export that quietly carries more.
Usually yes, because they answer different questions at different costs. A routine figure such as sessions by channel is one API request and a query with a bill attached. Keep the API for the questions it already answers well, and use the export for the ones it cannot express: event parameters, joins to your own tables, and metrics you define yourself.
Realtime covers the last 30 minutes and never settles. Standard reports cover a date range in the property's time zone and keep changing until processing finishes. Neither is the corrected version of the other.
A consent banner changes what GA4 can measure, and the reports carry no marker saying so. What the seven consent types cover, what basic and advanced consent mode each do when someone declines, and how to read numbers collected under either.