Why GA4, CRM, and Looker Studio numbers do not match

Teams often ask which number is correct when GA4, the CRM, and Looker Studio disagree. That question is too broad. The useful question is: which number answers this specific business decision under an agreed definition? A source of truth should be assigned per metric, not declared once for every number in the company.

Why a mismatch can be valid

The three surfaces can describe different parts of the same customer journey:

• GA4 records measured website or app behavior. Its event, session, active-user, total-user, and attribution concepts are not interchangeable. Google documents the distinctions between GA4 user metrics and notes that reports and explorations can differ because of fields, filters, retention, thresholds, modeling, and processing.
• A CRM stores operational records and state. A contact may have been imported, created manually, merged, duplicated, updated after the original visit, or associated with several forms, opportunities, and purchases. The exact object model depends on the CRM and its configuration.
• Looker Studio displays the result of connector queries, calculated fields, filters, blends, and chart aggregation. Google's GA4 connector uses the Analytics Data API and is intended to match GA4 reporting rather than GA4 explorations, according to the official connector documentation.

Even two views inside GA4 can differ. Google lists supported fields, filter matching, segments, comparisons, retention, low-user thresholds, behavioral modeling, and processing time among the reasons for report and exploration differences. Treat the name of the metric as a starting point, not proof that two queries are equivalent.

Start with a metric contract

Before opening the dashboard, write one sentence such as: How many completed, non-test orders were paid in the store's timezone during June, excluding cancellations and including refunds as a separate measure? Then document:

1. Business question: the decision this number changes.
2. Metric name and owner: who defines it and who signs off on it.
3. Grain: event, session, person, contact, lead, order, opportunity, line item, or another object.
4. Numerator and denominator: especially for rates such as lead conversion or purchase conversion.
5. Date field and timezone: event time, contact create time, opportunity close time, order paid time, refund time, or another agreed timestamp.
6. Inclusions and exclusions: test records, spam, internal traffic, duplicates, failed payments, cancelled orders, refunds, offline sales, and missing consent.
7. Identity and deduplication rule: which stable key connects or separates records.
8. Freshness and tolerance: when the data is considered closed and what difference requires investigation.

Use a seven-layer discrepancy workflow

1. Metric contract: confirm that the labels describe the same business question, grain, period, and inclusion rules.
2. Collection: confirm the source event or CRM action occurred once, reached the intended property or account, and carried the required fields.
3. Identity and joins: inspect transaction IDs, contact IDs, user IDs, merge rules, deduplication, and the join keys used by any blend.
4. Time and attribution: align timezone, timestamp, reporting window, channel scope, attribution model, and lookback rule.
5. Processing: allow the source and connector to finish processing before declaring a recent-period discrepancy.
6. Transformation: inspect filters, calculated fields, row limits, blending, aggregation, and chart-level settings.
7. Reconcile and decide: trace a known sample, classify the remaining delta, record the accepted definition, and name the owner.

Compare a closed period before comparing today

Google says GA4 processing can take 24 to 48 hours and that report values may change during processing. Daily attribution credit for key events can also change later. See the official GA4 data-freshness guidance. Looker Studio can serve a previous query result from memory while a data source remains inside its freshness threshold; connector refresh settings and blends therefore belong in the evidence log. See Looker Studio data freshness.

For the first reconciliation, use a completed historical period that is old enough for the relevant sources to finish processing. Save the exact date range, timezone, filters, connector, chart, and export time. Once that period reconciles, test recent data separately rather than mixing processing delay with definition problems.

Record evidence before changing the implementation

• The exact GA4 property, stream, report or exploration, dimensions, metrics, filters, comparisons, and date range.
• The CRM account, object, saved view or report, lifecycle or pipeline state, create or close field, deduplication rule, and export timestamp.
• The Looker Studio report, data source, connector owner, data credentials, freshness setting, blend, join keys, calculated fields, chart filters, and aggregation.
• One small privacy-safe sample of known events, contacts, orders, or opportunities that can be traced without publishing customer data.
• The expected total, observed totals, explained difference, unexplained difference, decision owner, and next review date.

How to reconcile one metric without guessing

1. Choose one closed period: avoid the current day while processing and freshness are still moving.
2. Export the smallest useful detail: use transaction IDs, contact IDs, dates, states, and values rather than comparing only two headline totals.
3. Normalize the contract: align timezone, date basis, grain, status, filters, currency, and exclusions.
4. Classify every unmatched record: missing collection, duplicate, late processing, excluded status, identity failure, join failure, attribution difference, or transformation error.
5. Prove the first divergence: find the earliest layer where the same known record stops matching.
6. Repair only that layer: do not rebuild tags, CRM workflows, connectors, and dashboards at the same time.
7. Repeat the closed-period test: confirm that the repair changes the expected records without creating duplicates or a new reporting break.
8. Publish the contract: document the accepted number, owner, refresh rhythm, known limits, and response when the threshold changes.

Expected difference or broken implementation?

A difference can be expected when two views use different grains, reporting surfaces, freshness windows, attribution rules, consent or modeled data, or lifecycle states. Google explicitly documents differences among GA4 reports, explorations, the Data API, and BigQuery in its reporting-surfaces comparison.

Investigate as an implementation problem when a stable closed-period delta cannot be explained, a known record disappears at a specific handoff, the same transaction appears more than once, totals multiply after a blend, a change creates a permanent step shift, or a metric cannot be reproduced from its written contract.

Choose a source owner by metric

• Website and app behavior: use a validated analytics implementation and the GA4 surface defined in the contract.
• Contact state, lead ownership, and opportunity stage: use the CRM object and lifecycle rules approved by the operating team.
• Order and payment state: use the commerce, payment, or finance system that controls completed, cancelled, refunded, and net states.
• Dashboard presentation: use Looker Studio to communicate an agreed metric, not to silently redefine its owner.

There is no universal source of truth for every metric. One business may use the commerce platform for paid orders, the CRM for sales ownership, GA4 for measured acquisition behavior, and Looker Studio for a documented cross-source review.

Watch joins and aggregation in Looker Studio

Google documents that a blended source needs shared join keys and that included records depend on the join configuration and source order. A non-unique key can multiply rows; an unmatched key can drop expected records. Review the official join-key definition. Aggregation also changes the result when a chart groups or summarizes a metric at a different dimension set. Some Google Analytics metrics use automatic aggregation because the connector does not expose raw data for reaggregation; see Looker Studio aggregation.

Do you need BigQuery?

Not for every discrepancy. Start with a metric contract, source exports, known record IDs, and the equivalent GA4 report. BigQuery becomes useful when the business needs event-level analysis, repeatable SQL reconciliation, longer transformation history, or controlled joins beyond the dashboard connector. It also represents a different reporting surface, so it should not be expected to reproduce every modeled or attributed GA4 report value automatically.

Keep the evidence privacy-safe

Use redacted IDs, masked emails, test orders, limited date windows, and approved exports. Do not paste customer names, payment details, access credentials, API keys, full CRM exports, or private screenshots into a public form. A useful first message can name the metric, systems, period, observed totals, likely boundary, and business decision without exposing customer data.

When a reporting audit is worth it

If the mismatch spans collection, CRM state, ecommerce transactions, attribution, connector rules, and dashboard calculations, an isolated chart edit is unlikely to resolve ownership. Arifur Rahman uses the same contract-to-reconciliation method shown here: define the decision, trace a known sample, locate the first divergence, then document the smallest repair and its proof test. Use the related Looker Studio dashboard setup when the source path is already clear, or start with a Systems Audit when several live tools and owners are involved.