Getting data into BigQuery is the easy part. Getting it to agree with itself is the work.
Most organizations running BigQuery have data in it. GA4 is exporting. Ad platforms are connected. CRM records are landing. The problem isn't volume — it's that the data from each source was never designed to reconcile with the others. GA4 and BigQuery report different conversion counts for identical date ranges. CRM pipeline doesn't match marketing attribution. Revenue in the warehouse doesn't match Stripe. The warehouse has become the place where data accumulates, not the place where it resolves.
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 with no retention limit. 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: consent mode modeled conversions appear in the GA4 interface but don't export to BigQuery. GA4 applies data sampling on large exploration queries; BigQuery doesn't. 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.
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.
100% of collected events. No sampling. Every row is a real event. Authoritative for volume-based analysis.
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 on qualifying properties. Single attribution column in standard reports.
Four traffic source structures in the schema. session_traffic_source_last_click added July 2024 as the most complete option. Custom attribution models require explicit construction.
Data latency
Near-real-time in standard reports. Processing lag of up to 24–48 hours for some metrics.
Daily export is clean and reconciled. Streaming export gives last-few-hours visibility but should not be used for finance-facing reporting. Late events arrive for 72+ hours after the event date.
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
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.