Your website report says conversions increased. Your CRM says qualified leads fell. Finance wants to know whether the customers you acquired last quarter have bought again.
These are connected questions, but they are difficult to answer with a website dashboard alone. You need to inspect the underlying activity, define what matters to your business and connect it to what happened afterwards.
That is why the raw GA4 event export matters. It gives you material for building a reporting model you control. The value comes from what you do with those events: the definitions you apply, the quality checks you make and the business records you can reliably join.
What you get from the BigQuery export
GA4 can export event-level data to BigQuery. You can query that dataset directly and build reporting around your own definitions. It is an export of collected data, rather than a reproduction of every processing feature in the GA4 interface. Google’s BigQuery export overview.
Google’s reporting surfaces can apply sampling, aggregate high-cardinality values into an “other” row and include modelling. BigQuery’s event export does not apply that reporting-surface sampling or include the same modelled results. Consequently, a BigQuery query and a GA4 report are not guaranteed to match. Google’s reporting surfaces comparison.
The useful question is: which definition answers the business question, and can we explain how it was calculated?
For a lead-generation business, that might mean separating a demo request from a newsletter subscription. For a retailer, it might mean linking a recorded purchase to the order system before treating it as recognised revenue. Both require more thought than choosing a default conversion metric.
Understanding activity when analytics cookies are declined
There is a useful distinction between an event being collected and a person’s journey being observable.
With an appropriate advanced consent-mode implementation, cookieless pings can be collected when analytics storage is denied. Google documents their presence in the BigQuery export. The fields and continuity available need to be assessed against the actual implementation. Google’s explanation of BigQuery and the GA4 interface.
It would be wrong to say that GA4 always hides everyone who declines cookies. Eligible properties can use behavioural modelling to estimate activity in reports. That modelled behavioural data is not included in BigQuery. Without persistent identifiers, observed page views also cannot simply be counted as distinct people: ten views could represent one person or several. Google’s behavioural modelling documentation.
The opportunity is to investigate what was actually collected and what it can support. In practice, we would assess:
- Page and event activity: which pages and actions appear in the available events, without claiming a complete journey between them.
- Recorded purchases and revenue: whether purchase events contain the necessary values and transaction references, and how they reconcile to the order system.
- Device, browser and broad geography: which fields are populated and suitable for aggregate breakdowns, rather than assuming every dimension is available.
- Campaign context: whether landing-page or campaign information survives in the relevant fields. Available campaign context is not the same as complete attribution.
- Consent signals over time: whether the mix of events carrying granted, denied or unset signals changes after a banner or tagging update.
An event-level consent split is not automatically a visitor consent-acceptance rate. If one visitor generates twenty events and another generates two, counting events gives them different weights. A proper acceptance-rate measure needs an appropriate denominator, potentially from the consent platform itself.
This is useful measurement with explicit limits. It does not recover events that were blocked from being collected, recreate absent identifiers or justify connecting activity across consent boundaries.
From website activity to customer-level analytics
Raw event data becomes particularly valuable when it can be connected to the records your business already uses.
Imagine a prospective customer browsing on a phone, returning on a laptop and eventually signing in or submitting a lead form. Linking those actions requires a reliable identifier at the relevant points. It is not something that exporting the events automatically supplies.
GA4 supports User-ID for connecting activity associated with the identifiers you provide. A consistently implemented, appropriate first-party ID can help recognise signed-in activity across devices. It does not make every anonymous visit identifiable. Google also sets requirements for the IDs you send; email addresses and other prohibited personally identifiable information should not be used as User-ID. Google’s User-ID guidance.
With suitable identifiers, access controls and permitted uses established, a reporting model can connect:
- A lead submission to its CRM qualification status and eventual outcome.
- A purchase event to an order, its adjustments and subsequent purchases.
- Identified customer activity to loyalty or account records.
Those joins support questions about lead quality, repeat purchasing, retention and customer value. Lifetime-value reporting also requires sufficient order history and an agreed revenue or margin definition; website events alone do not provide either.
For example, two campaigns might generate the same number of lead forms. Joining the identifiable leads to CRM outcomes could show that one produces more qualified opportunities. The useful output is the comparison alongside its match coverage, including how many leads could not be joined.
That last part matters. If only half of the leads have usable identifiers, reporting on the matched half as though it represented everyone would create false confidence. Make the unmatched records visible and investigate whether coverage differs by campaign, device or period.
Where appropriate, these insights can inform optimisation and audience planning. Any activation of customer data needs its own eligibility and consent checks; having an analytical join does not automatically make every record suitable for targeting.
Build the definitions once, then use them across tools
The next step is a maintained data model. Decide how to classify pages, recognise business events, handle repeated records and calculate metrics. Record the choices so another analyst can understand them.
Our article on why engaged sessions can be a misleading KPI illustrates the point: activity only becomes a useful performance measure when it reflects what your business is trying to achieve.
We recommend keeping three concepts distinct in reporting:
| Reporting concept | What it represents |
|---|---|
| Collected activity | Events and fields present in the export |
| Business calculations | Your rules for metrics, groupings and customer joins |
| Estimates | Modelled figures, clearly labelled with their assumptions |
This helps teams explain a number before reusing it in a dashboard, API response or AI analysis. Connecting an AI assistant to a poorly defined dataset does not resolve ambiguity about what a conversion or customer means.
Start collecting before you need the history
The standard BigQuery link does not backfill raw events from before it was established. Export setup also requires decisions about permissions, configuration and Google Cloud resources. Google’s export setup guidance.
Before relying on the dataset, check that expected events are arriving, required parameters are populated and collection or export limits are not creating gaps. Agree how updates to historical data will be handled and monitor ongoing storage and query costs.
“Raw” is not a quality guarantee. Duplicate purchase events, missing parameters and inconsistent tagging still need attention. Any filtering for internal, suspicious or unwanted activity needs explicit rules; a BigQuery export does not by itself clean the dataset.
How Bright Analytics helps
Our GA4 reporting approach brings event collection, business modelling and reporting together. We assess what the export supports, define the KPIs and customer joins, and make the resulting model usable by your teams.
The Marketing Analytics Platform combines managed data pipelines, a customised data model and reporting, with API and MCP connections for other tools.
Talk to us about your GA4 reporting if you need to move from website activity to questions about customers, revenue and the decisions your team makes every day.