Getting data into BigQuery is the easy part. Getting it to agree with itself is the work.
When warehouse revenue does not match the CRM or Stripe, finance stops trusting marketing's CAC and ROAS, and every revenue conversation starts with which number to believe. The GA4 export is raw event data, while the interface, the CRM, and billing each define a conversion differently (Google Analytics Help, BigQuery Export). We build the governed model that defines each measure once and reconciles it to the system of record; see the work we did for Apimio.
The warehouse has data. The data doesn't agree. The team doesn't trust it.
BigQuery is capable of being the governed source of truth for every marketing, product, and revenue decision in the business. The GA4 export gives you unsampled, event-level behavioral data that lands in your own project, so retention is your decision rather than a GA4 UI setting. dbt gives you version-controlled business logic that makes attribution reproducible and testable. The stack works. What most organizations are missing is the architecture that connects these pieces into a model the business can actually make decisions from.
GA4's BigQuery export is genuinely powerful and genuinely difficult to work with. The schema is nested and repeated — event parameters land as arrays of key-value structs that require UNNEST operations for even basic queries. There is no native session table; sessions have to be constructed from event-level data. Traffic source attribution lives in four different fields depending on how the session was attributed, and they populate under different conditions.
The practical consequence: most teams get the GA4 export running, open the events table, and find that the schema is more complex than expected. Analysts write custom queries to extract the dimensions they need, each with slightly different logic. The same metric gets calculated differently across different analysts and different reports. Data confidence erodes — not because the data is wrong, but because there's no shared data model that defines how it should be calculated.
Building that model requires three things: a well-designed event schema (or a transformation layer that corrects the schema that exists), a dbt model layer that defines business logic as code, and a governed data contract between the teams that produce data and the teams that consume it.
There's an additional reconciliation gap that can't be closed through better SQL: the export is raw event data, so modeling additions shown in the GA4 interface, including consent mode modeled conversions, are not exported (Google Analytics Help, BigQuery Export). The GA4 interface also applies data sampling on large Exploration queries, while the BigQuery export does not. The two systems measure different things by design. Understanding which source answers which question — and building the reporting architecture around that distinction — is the difference between a warehouse that creates confusion and one that creates clarity.
Why do GA4 and BigQuery report different conversion counts?
Because they are not the same dataset. The GA4 BigQuery export is raw, unsampled, event-level data with last click observed and no modeling applied; the GA4 interface adds modeling that the export does not contain (Google Analytics Help, BigQuery Export). The count in the warehouse therefore comes from a different definition than the count in the interface, and neither was designed to reconcile with the CRM or billing. Reconciling them is architecture work: one governed model that defines the conversion once.
These aren't bugs. They're architectural differences — and they need to be understood before you build attribution on top of them.
Every team that connects GA4 to BigQuery eventually discovers that the numbers don't match. Understanding why is the prerequisite for building a warehouse model that resolves the discrepancy rather than hiding it.
Sampling
Applies sampling on large Exploration queries. Results are estimates above the property's event threshold.
All collected events up to the export limit; standard properties are limited to 1 million events per day on the daily export. No sampling within that limit. (Google Analytics Help, BigQuery Export.)
Modeled conversions
Includes consent mode modeled conversions — statistically estimated events from users who declined consent. Inflates conversion counts.
No modeled conversions. Only collected events. Will always show fewer conversions than the GA4 interface in markets with significant consent decline rates.
Timezone
Uses the GA4 property timezone. Day boundaries match what the team expects.
Exports in UTC. Daily comparisons require explicit timezone conversion in SQL — otherwise day-boundary events shift between dates.
Session construction
Sessions calculated natively. Session metrics available directly in standard reports.
No session table in the export. Sessions must be constructed from event-level data using ga_session_id. Session counts will differ slightly depending on construction logic.
Traffic attribution
Uses GA4's attribution model — Last Click by default, with Data-Driven Attribution available. Single attribution column in standard reports.
Four traffic source structures in the schema, including session_traffic_source_last_click as the most complete option. Custom attribution models require explicit construction.
Data latency
Near-real-time in standard reports. Data processing can take 24 to 48 hours for some metrics. (Google Analytics Help, Data freshness.)
Daily export is clean and reconciled. Streaming export gives last-few-hours visibility but should not be used for finance-facing reporting. Google updates the daily export tables for up to three days after the event date. (Google Analytics Help, Compare Analytics reports and data exported to BigQuery.)
Four layers. Each one shapes whether the layer above it produces analysis the business can trust.
A warehouse truth layer on BigQuery isn't a single system — it's four interconnected layers, each with specific architecture decisions that determine whether the whole produces governed, reconciled, trustworthy numbers.
What lands in BigQuery. GA4 daily export for behavioral events. Server-side collected events from sGTM or RudderStack for conversion signal that bypasses browser limitations. CRM and revenue data via source connectors or direct API writes. The quality and schema consistency of what arrives determines what the layers above can build.
The layer that turns raw BigQuery data into governed business models. Staging models clean and standardize source data. Intermediate models build reusable logic — sessionization, attribution, identity resolution. Mart models expose the dimensions and metrics business teams actually use. Tests validate that the logic is correct and that data contracts between layers are honoured.
The logic that connects the same person across GA4 behavioral events, CRM records, and revenue data. Without a governing identity model, the same customer appears as different entities in different source systems, and lifecycle analysis — from acquisition channel through to revenue — is structurally impossible regardless of how well the rest of the warehouse is built.
What downstream systems read from the warehouse. BI tools (Looker, Tableau) pointed at governed dbt mart models rather than raw event tables. Reverse ETL pushing warehouse-computed metrics back into CRM, ad platforms, and activation tools. The final layer — and the one most visible to the business — but entirely dependent on the quality of the three layers beneath it.
The consistent architectural patterns that produce a warehouse the team has data in but doesn't trust.
These aren't data quality problems in the traditional sense. The data is there. The architecture that connects it into a governed, reconciled model hasn't been built.
Three entry points — all converge on the same outcome: a warehouse the business can make decisions from.
The Assessment maps the current state of the BigQuery environment — what's in it, how it's structured, where the reconciliation gaps are — and identifies the specific architecture work required.
GA4 export configuration and schema review, existing transformation layer (if any), dbt model coverage and test quality, identity resolution architecture, revenue and CRM data integration. Output: a specific picture of what's producing the reconciliation gaps and what the architecture would need to look like to resolve them.
- Specific diagnosis of discrepancies
The team behind BigQuery architecture.
Itika builds the data and AI layer at Analytico: Python pipelines, warehouse workflows, and applied AI that turns clean measurement data into something teams can use.
Nishan founded Analytico and leads its measurement architecture, turning fragmented analytics, ad platform, CRM, and backend data into numbers leadership can trust.
Valentina builds the pipelines behind Analytico's measurement work, moving event and business data into the warehouse in a form teams can model, test, and trust.
BigQuery — frequently asked questions
If the numbers in your BigQuery environment don't agree — the architecture is where to look first.
The Measurement Architecture Assessment maps the current state of the BigQuery environment: event schema, transformation layer, identity resolution, and the specific gaps producing the reconciliation problems. It identifies what the architecture would need to look like for the warehouse to become the governed source the business actually uses.