Why do GA4 numbers not match your sales or CRM?

Are the reports counting the same thing?

Write a plain-language definition for each number. A submitted form, an accepted enquiry, a qualified opportunity and a paid invoice are four different milestones. Calling all four “conversions” hides the reason the totals differ.

For purchases, establish whether the report counts orders created, payments authorised, payments captured or orders completed. Decide how cancellations, refunds, test records and duplicate records are treated. Record the currency and whether shipping or tax is included in revenue.

Google documents that GA4 reports and explorations can also differ because of filtering, retention, thresholds, modelling and processing. Check those settings before treating one GA4 view as a definitive reference for another.

How do you create a fair comparison?

Freeze a comparison period that has finished processing in the systems involved. Avoid debugging an incomplete current day unless the incident itself requires it. Use the same time zone and write down whether the report is based on event time, transaction time or an import timestamp.

Export the smallest useful set of records from each source. Where appropriate and permitted, use a non-personal transaction identifier to match the outcome across systems. Do not add customer email addresses to analytics events just to simplify reconciliation.

Create four groups: present in both sources, present only in the business system, present only in analytics, and repeated identifiers. Inspect representative records from each group. This is more informative than changing settings until two headline totals happen to match.

What causes missing or repeated events?

A browser event can be absent because of consent choices, blocked scripts, navigation before delivery or an implementation error. A successful server-side order can therefore exist without a corresponding browser observation. Respect the person’s choices while investigating; do not treat consent as a technical obstacle to work around.

Repeated events can come from multiple tag installations, a confirmation page that emits an event on every reload, retries or a frontend and backend both reporting the same action. Inspect the trigger and identifier for a real test journey before editing the entire tracking setup.

Use a controlled test record, trace it from the interface to the receiving systems, and check whether it is accepted once. Where the collection system supports deduplication, configure it deliberately and verify its actual behaviour rather than assuming that a repeated identifier always solves the problem.

• Record the trigger: click, server acceptance or confirmed completion.
• Check what happens after refresh, back navigation and a retry.
• Test failure paths as well as the successful path.
• Separate a tracking failure from a failed business transaction.

Why can attribution change a seemingly simple count?

A channel report is an allocation of credit, not necessarily an inventory of transactions. A person can visit several times, use more than one device or return directly before completing a purchase. Different attribution rules can assign that outcome differently.

GA4 reporting identity is another setting to document when comparing user-oriented views. Google describes how identity choices affect the way activity is associated with users. Do not casually change a property-wide setting just to make a single report resemble a spreadsheet.

Reconcile overall outcomes before drilling into channel credit. If the total set of transactions agrees but channel totals differ, the investigation belongs in attribution and reporting definitions. If transactions themselves are missing, start with collection and processing instead.

What does a reconciliation example look like?

Imagine a fictional service business that reports 120 form submissions in analytics and 95 new CRM leads for a week. That difference does not establish that 25 leads were lost. Some submissions may be retries, existing contacts or records filtered by the CRM’s qualification rules.

The analyst first aligns the week and status definitions. They then identify repeated submission identifiers, rejected spam and accepted updates to existing contacts. Only the remaining unexplained records become candidates for a delivery investigation.

The numbers here are illustrative, not client evidence. The outcome of the exercise should be a reconciliation note: what each system counts, the known reasons for differences, and the unresolved exceptions with owners. A percentage discrepancy without that explanation is not a useful diagnosis.

How do you make the reports trustworthy again?

Create a measurement specification for each important event: its business meaning, trigger, required fields, allowed values and accountable owner. Connect the specification to a test that covers successful completion, failure and retry. Keep the document small enough that developers and analysts actually use it.

Add basic monitoring for missing identifiers, sudden volume changes and repeated outcomes. Interpret these alongside releases, campaigns and business activity. A drop in traffic and a broken event collector can look similar on a single chart.

When publishing a dashboard, include the definition and freshness of its key metrics. State which system establishes revenue or accepted leads, and explain why channel-attributed analytics is not a replacement for that record. Confidence grows from traceability, not from pretending every total is exact.

What should you do with the remaining uncertainty?

Some differences will remain because the systems observe different populations or apply different processing. Document the limitation and decide whether it changes the decision the report supports. A campaign comparison can still be useful with understood limits; a financial total requires a different level of reconciliation.

Do not manufacture missing transactions or inflate a metric to close a gap. If an estimate is needed, label it and explain the method. Keep measured events separate from modelled or inferred outcomes.

SystemVale’s emphasis is a measurement chain that can be inspected: customer action, application result, stored business record, analytics observation and reporting rule. Once that chain is clear, the team can decide what to fix and what simply needs a better definition.