Field guide

Six reasons your Shopify tracking tool is lying to you

Most differences between Shopify and GA4 are not tracking faults. Six of them are normal behaviour in Google's own systems, and every one produces a gap that looks exactly like a broken purchase event. A tool that treats them as breakage will raise alarms all week — and the cost is not the wasted mornings, it is that you stop believing the next alert.

Each section below states what the cause looks like, why it is not a fault, and the specific check that tells you which one you are looking at.

1. GA4 has not finished processing yet

Looks like: an order exists in Shopify with no matching GA4 purchase. Identical in every way to an event that never fired.

GA4 does not process events instantly, and Google does not publish a guaranteed completion time. Standard properties commonly take hours; the Data API can return an incomplete picture the whole time. An order placed twenty minutes ago being absent from GA4 is the expected state, not a symptom.

How to tell: check the order's age before drawing any conclusion. A gap under a few hours old proves nothing at all. CommerceTrace applies a 6 hour freshness window by default and reports anything inside it as inconclusive with the reason named, rather than as a missing purchase.

2. Google grouped your transaction IDs into an “(other)” row

Looks like: specific orders missing from GA4, often in clusters, on higher-volume stores.

GA4 has cardinality limits. When a report requests more unique dimension values than it can return, Google aggregates the overflow into a single row literally labelled (other). Your transaction IDs are still in there — they are just no longer individually addressable. Query for one and it is absent.

How to tell: the Data API response carries a data-loss flag when this happens. A tool that ignores it will report real orders as missing on exactly the stores that have the most orders. CommerceTrace reads that flag and returns GA4_OTHER_ROW_DATA_LOSS — inconclusive, because the order may well be present and simply unaddressable.

3. Thresholding suppressed the data

Looks like: data missing from a report for no visible reason, typically on lower-traffic stores or narrow date ranges.

When Google Signals is active, GA4 withholds rows that could identify individual users. The suppression is applied silently at query time — the report simply returns less than the property holds.

How to tell: the response metadata declares it. An absence under thresholding is not evidence of anything, so the honest verdict is inconclusive. CommerceTrace reports GA4_SUBJECT_TO_THRESHOLDING and stops there rather than converting a suppressed row into an accusation.

4. The report was sampled

Looks like: revenue totals that are close but never quite right, and individual orders that come and go between runs.

For large or complex queries GA4 estimates from a subset of your data. The totals are approximations, and any single transaction may or may not be represented in the sample. Comparing a sampled report against exact Shopify order values will always produce differences that are not faults.

How to tell: the API declares sampling in the response. Any comparison built on a sampled report is unsafe at the order level, which is why GA4_SAMPLED yields inconclusive rather than a value mismatch.

5. You are comparing against GA4's reporting currency

Looks like: every value slightly wrong, by a consistent-looking ratio. This one convinces people their tracking is broken more often than any other on this list.

A GA4 property has a reporting currency. If a customer is charged in CAD and the property reports in USD, GA4 converts using its own daily rate. The purchase event was perfectly correct; the report simply is not in the currency you are comparing against.

We hit this on our own test store: an order looked like a clear value mismatch until the ratio turned out to match that day's real exchange rate. The tracking was fine.

How to tell: compare against the presentment currency the customer was actually charged, not your store's home currency, and read the property's reporting currency from the API metadata. CommerceTrace separates GA4_REPORTING_CURRENCY_MISMATCH — an artifact — from WRONG_CURRENCY, which is a real fault.

6. A transport retry looked like a duplicate

Looks like: two purchase hits for one order, which is the signature of genuine double-counting.

Not every repeated hit is a second fire. The browser transport re-sends a hit when delivery is uncertain — the same event, sent twice, deliberately. Counting that as a duplicate sends you looking for a second tag that does not exist.

Separately, GA4's aggregated reporting can show eventCount above one without that proving two independent fires: aggregation cannot distinguish separate tags from reprocessing.

How to tell: a genuine duplicate requires two distinct wire-level hits that are not retries of each other. CommerceTrace collapses identified retries, and treats an aggregate count above one as GA4_AGGREGATED_DUPLICATE_UNVERIFIED — inconclusive, never a confirmed duplicate.

What this costs you

Each of these produces a gap indistinguishable, on its face, from a purchase event that never fired. A tool that reports them as breakage is not being cautious — it is being wrong in the direction that feels responsible, which is the harder kind to notice.

The failure mode is not the individual false alarm. It is what a run of them does to you: after the third investigation that turns up nothing, the alerts become noise, and the real break arrives to an audience that has already stopped reading.

The rule we build to

It would rather say “I don't know yet” than say “this is broken” and be wrong.

Every finding is graded confirmed, suspected, or inconclusive, and an inconclusive result always names the reason — so you know what would settle it rather than being left with a shrug. That grading is the product, not a disclaimer attached to it.

See how the grading works · See how the chain is traced