GA4 BigQuery Export: Limits, Costs, Setup and Schema

The GA4 BigQuery export sends your raw, event-level Google Analytics 4 data into a Google BigQuery project that you own, where you can query it with SQL. It is free to switch on for standard GA4 properties, but daily exports are capped at 1 million events per day, and you pay BigQuery for storage, queries and (if you use it) streaming once you go past the free allowances.

The GA4 interface shows you aggregated reports. The export gives you every event row with its parameters, which means you can rebuild sessions, join GA4 with CRM or ad cost data, and keep history on your own terms. This guide covers what the export includes, what it costs, how to link a property, how the tables are laid out, and the queries most marketers write first.

What the GA4 BigQuery export includes

When you link a property, Google creates a dataset in your BigQuery project and writes tables into it. Each row is one event: a page_view, a purchase, a form_submit, or any custom event you send. Google's help documentation describes the data as raw and unsampled, so there are no sampling thresholds of the kind you sometimes hit in GA4 explorations.

You choose how often data arrives. There are three frequency options, and you can enable daily and streaming together.

Daily export

The daily export writes one table per day, named events_YYYYMMDD, containing the previous day's events. Google says it usually lands by mid-afternoon in the property's reporting time zone, and it can be delayed. Events that reach Google late can still be written into a recent daily table, so a table you queried on Tuesday may hold slightly more rows on Thursday. If your dashboards read yesterday's table first thing in the morning, they will often find nothing there yet.

Streaming export

Streaming writes events into an intraday table, events_intraday_YYYYMMDD, within minutes of collection. The intraday table is deleted once that day's daily table is complete. Google labels streaming a best-effort service with no completeness target, and warns that it may contain gaps. One detail catches people out: the traffic_source fields that describe how a new user was first acquired are not populated in intraday tables. Use streaming for near-real-time checks, such as confirming a campaign launch is tracking, and use the daily tables for anything you report on.

Fresh Daily (Analytics 360 only)

Analytics 360 properties get a third option, Fresh Daily, which updates through the day in batches, typically within 60 minutes. Standard properties do not have it.

User data tables

Alongside the event tables, the link can also export user-level tables (pseudonymous_users_ and users_) that describe users rather than individual events. Most marketing analysis starts with the event tables, so treat these as a second step.

Free tier limits and costs

There is no GA4 fee for the export itself on a standard property. The costs and limits sit in two places: the GA4 export limit and BigQuery's own pricing.

• The 1 million events per day cap. Standard properties have a daily (batch) export limit of 1 million events. Google says properties that repeatedly exceed it may have the daily export paused, and missed days are not reprocessed. Streaming export has no event-count limit. Analytics 360 properties can export up to 20 billion events per day.
• Streaming charges. Streaming is billed at $0.05 per gigabyte. Google's rule of thumb is that 1 GB equals about 600,000 GA4 events, so a site sending 3 million events a month would stream roughly 5 GB, about $0.25 a month, before storage and query costs. That figure is an illustration from Google's published rate, not a quote.
• Storage and queries. BigQuery charges for two things: storing data and processing queries. Every export adds to storage, and every query you run scans data. The free compute allowance is 1 TiB of processed query data per month.

If your property sends more than 1 million events on busy days, the first fix Google suggests is event filtering in the link settings. Excluding noisy events you never analyse, such as scroll or user_engagement events if you have no use for them, keeps the daily export under the cap. Check this before a sale period, when event volume can jump well above an ordinary day.

Sandbox vs billing account

You can export GA4 data to the BigQuery sandbox, which needs no payment method. It is a sensible way to test, but its limits matter for a production setup.

According to Google Cloud's sandbox documentation, the sandbox gives you a lifetime limit of 10 GiB of storage (deleting data does not restore the quota) and 1 TiB of processed query data per month. Tables, views and partitions expire automatically after 60 days. The sandbox does not support streaming, and it does not support DML statements such as UPDATE or DELETE.

The 60-day expiry is the limit that matters most for marketers. If you link a property to a sandbox project and forget about it, you will only ever have the last two months of raw data, which defeats one of the main reasons to export. For anything beyond a trial, attach a billing account to the Google Cloud project. Once billing is on, the free monthly query allowance still applies, and you pay only for what you use above it.

The table below summarises the options. Every row comes from Google's GA4 and BigQuery help documentation.

How to link GA4 to BigQuery

Check permissions before you start, because the link cannot be created without them.

1. In Google Cloud, create or select a project and enable the BigQuery API.
2. Check access. You need the Editor role or above on the GA4 property, and the Google account you use must have OWNER access on the Google Cloud project.
3. In GA4, open Admin, find BigQuery links under Product links, and click Link.
4. Choose your BigQuery project from the list.
5. Select a data location. Choose carefully: Google's documented way to change it later is to delete the link, back up and recreate the dataset in the new location, and relink, which pauses the export and can leave a gap. Cross-region dataset replication is the alternative Google lists for moving the dataset without that gap.
6. Pick which data streams to include, and exclude any events you do not need.
7. For app streams, decide whether to include advertising identifiers.
8. Select daily, streaming or both, then review and submit.

Google says data should begin arriving within 24 hours. The export builds history from the day you link, so a property linked today will have one day of raw data tomorrow and a year of it next year. That is the strongest argument for linking early, even if nobody plans to query it for months.

If you are still cleaning up a GA4 setup, fix the tracking before you rely on the export. Duplicate events, missing purchase values and inconsistent event names all land in BigQuery exactly as collected. A GA4 migration and setup review is the place to sort those out.

Event table schema basics

The schema looks odd the first time because it uses nested and repeated fields. Once you understand five or six columns, most queries follow the same pattern.

• event_date: the date as a YYYYMMDD string, in the property's time zone.
• event_timestamp: an integer in microseconds, in UTC, for when the event was logged.
• event_name: the event's name, such as page_view or purchase.
• event_params: a repeated record. Each entry has a key and a value, and the value has four possible fields (string_value, int_value, float_value, double_value). Only the field that matches the parameter's type is filled in.
• user_pseudo_id: the pseudonymous ID for a browser or app instance. user_id is filled only if you send your own ID.
• device and geo: records holding device category, operating system, browser, and country, region and city.
• traffic_source: the source that first acquired the user. It does not change on later visits, so it is not the session's source.
• collected_traffic_source and session_traffic_source_last_click: the campaign data collected with the event (UTMs, gclid) and the last-click session source.
• ecommerce and items: transaction-level values and one entry per product in the event.

Because event_params is repeated, you read a parameter with UNNEST. To get the page URL from a page_view, you look inside event_params for the key page_location and take its string_value. The ga_session_id parameter works the same way, using int_value.

The traffic_source column is the most common source of wrong numbers. Analysts who group sessions by traffic_source.source are grouping by first-user source, so returning visitors from a paid campaign get credited to whatever brought them the first time. For session-level channel reporting, use session_traffic_source_last_click or the collected campaign parameters instead.

Common queries marketers run

Sessions

BigQuery has no sessions column. A session is the combination of user_pseudo_id and the ga_session_id event parameter, so you count distinct pairs of the two. Expect the result to come close to the GA4 interface without matching it exactly. GA4 reports and the raw export are calculated in different ways, and the interface can apply processing that the export does not. Agree internally which figure is the reporting standard rather than trying to force a match.

Attribution and channel reporting

With session-level source and medium you can build your own channel groupings, compare first-touch and last-click views side by side, and join GA4 conversions with Google Ads cost data loaded into the same project. This is where the export earns its keep for paid media: you can calculate cost per conversion by campaign using your own conversion definition rather than the one set in the GA4 interface. If paid search is a large share of your budget, pairing this with structured Google Ads management makes the numbers useful rather than merely available.

Funnels

Funnels in SQL are sequences of events per user or session: view_item, then add_to_cart, then begin_checkout, then purchase. You can set your own window and decide whether steps must happen in order. Explorations in GA4 do this too, but in BigQuery you can save the logic, run it on months of data and feed it into other tools.

Landing page and content analysis

Pulling page_location from the first page_view of each session gives you landing pages with their sessions, engagement and conversions. Joined with search data, this shows which organic landing pages bring sessions that convert, which is useful input for an SEO audit.

One habit saves money on every query: select only the columns you need and filter on the table date (with _TABLE_SUFFIX on the wildcard table events_*). BigQuery bills by bytes processed, so SELECT * across a year of tables scans far more data than a query that reads three columns from one month.

When Looker Studio on top of BigQuery makes sense

Looker Studio can connect to GA4 directly, and for many small sites that is enough. BigQuery as the source makes sense when you need things the direct connector cannot do well: joining GA4 with CRM, ad cost or offline sales data, using your own session or channel definitions, keeping more history than your GA4 retention setting allows, or reusing heavy calculations without hitting reporting limits.

The trade-off is cost and upkeep. Every time a dashboard loads or a filter changes, Looker Studio sends queries to BigQuery, and those scan data. The usual pattern is to write a scheduled query that builds a small summary table (sessions, conversions and revenue by day, channel and landing page), then point Looker Studio at that table instead of the raw events. Dashboards load faster and query costs stay small.

What this means for Thai marketers

For Thai businesses the export matters most where GA4 alone falls short: linking website behaviour with LINE OA leads, phone enquiries or sales closed offline. If you load those records into the same BigQuery project, you can join them to GA4 on user_id or a click ID you capture in a form. Two practical points apply. First, choose the data location deliberately when you link, since a later change of region means relinking (with a possible data gap) or setting up cross-region replication. Second, check that Thai page titles and URL-encoded Thai paths read correctly in your queries, because page_location stores the encoded URL as collected.

FAQ

Is the GA4 BigQuery export free?

The export itself is free for standard GA4 properties, but BigQuery charges for storage, query processing and streaming. The free query allowance is 1 TiB of processed data per month, and streaming costs $0.05 per GB.

What happens if my property sends more than 1 million events a day?

Standard properties that repeatedly exceed the 1 million events per day daily export limit may have the daily export paused, and missed days are not reprocessed. You can exclude events in the link settings to stay under the cap, or use streaming, which has no event limit.

Can I use the BigQuery sandbox long term?

The sandbox works for testing but is a poor long-term home because tables expire after 60 days and storage is capped at 10 GiB. It also does not support streaming. Add a billing account to keep history.

Why don't my BigQuery session counts match GA4 reports?

BigQuery numbers are calculated from raw events, while GA4 reports are processed differently, so small gaps are normal. Check that you are counting distinct user_pseudo_id and ga_session_id pairs and using session-level source fields rather than traffic_source.

Getting started

Link the property now, even if the queries come later, because the raw history only starts from the day you connect it. Use a billing-enabled project, pick the data location once, filter out events you will never analyse, and build summary tables before you put a dashboard on top. If your GA4 tracking needs work before the export is worth trusting, our team can help with a GA4 setup and migration review.