What the GA4 export gives you, and what it leaves to you.

GA4 can send its raw event data to BigQuery, Google's data warehouse, once a day, and optionally through a more frequent intraday export. Each row is one event, such as a page view or a purchase, with its details attached as nested fields.

It is the closest thing to the data GA4 itself holds. It is not the same thing as GA4's reports, and most of the confusion about it starts there.

GA4's reports are computed from events with rules applied on the way. Sessions are constructed, some user counts are estimated rather than counted exactly, small figures can be withheld to protect privacy, and where consent was declined GA4 can fill gaps with modelled data. The export holds the observed events, before most of that happens.

So a session count written in SQL and the one in the interface will differ, and both can be correct. Decide which one your reports use, write it down, and stop comparing the two expecting them to agree.

The export does not backfill. It carries events from the day the link is made onwards, and nothing from before. History GA4 collected before that day stays in GA4 and can only be retrieved as aggregated reports, not as events.

The practical advice follows directly: link it early, even if nobody will query it for months. A table nobody reads costs little to keep. History you never exported cannot be recovered at any price.

For an agency, that puts the link on the onboarding checklist for every new client whose property does not already have one. Ask first, because the property is the client's, and agree whose cloud project the export lands in before the first day is written.

Before the export answers a reporting question, three things have to happen to it.

• Unnesting

  Event details are stored as lists of keys and values inside each row. Every query has to unpack them, and doing that repeatedly across a large table is slow to write and billed on the data it reads.

• Rebuilding the reports

  Sessions, channel groupings and attribution are not stored as columns. Anything the interface shows ready-made has to be rebuilt in SQL, and rebuilt the same way every time.

• Modelling once

  The sensible end state is a modelled table that does the unnesting and the session logic once, which every report reads instead of the raw events. That table is the real product. The export is its input.

Only GA4. No ad spend, no CRM, no orders as the client's store recorded them. The export answers questions about what people did on the site, and on its own it cannot say what that behaviour cost or what it was worth.

Those answers need the other sources in the same warehouse, reconciled to the same day boundaries, the same currency and the same names, which is a separate job from switching the export on.

SightShark connects GA4 as one of 200+ sources and lands each client's property in your own data warehouse next to that client's ad platforms, CRM and store, modelled so that a session, a conversion and a channel mean one thing in every report.

If a client already has the export running, keep it. It is the event-level record, and there is no reason to switch it off because modelled tables sit beside it.