Back to notes

October 12, 2026 · 6 min read

The E-commerce Tracking Bug That Cost a Client Three Weeks of Data

A single mismatched currency parameter sat in production for three weeks before anyone noticed revenue reporting was quietly wrong. Here's the full postmortem.

PostmortemGA4

A client's revenue numbers in GA4 had been quietly wrong for three weeks before anyone flagged it, and the thing that finally caught it wasn't a dashboard alert — it was a finance team member noticing the GA4 revenue total didn't reconcile with the actual order totals from their payment processor, off by an amount too consistent to be noise.

What broke

The client ran two storefronts, one priced in USD and one in GBP, sharing the same GTM container. A checkout redesign had moved the purchase event's data layer push earlier in the page lifecycle, before a currency-detection script had finished setting the region-specific currency variable. The result: on the GBP storefront, purchase events fired with the currency hardcoded to USD, because that was the data layer's default value before the detection script overwrote it — except now the event fired before the overwrite happened.

GA4 didn't error on this. It happily recorded every GBP transaction's value as if it were USD, silently inflating reported revenue from that storefront by roughly 25% given the exchange rate at the time. No red flags, no broken events, no DebugView warning — the event was perfectly well-formed, just wrong.

The scariest bugs in tracking aren't the ones that break something visibly. They're the ones that produce a number that's plausible enough nobody questions it.

How we found it, and what actually fixed it

  • Found via manual reconciliation against payment processor data, not via any GA4-native alert — there's no built-in check for this failure mode.
  • Root cause traced by replaying the checkout flow in DebugView and watching the currency parameter resolve a beat too early.
  • Fix was a one-line change: gate the purchase event push on the currency variable actually being set, not just present in the data layer.
  • Backfilled the three weeks of distorted GBP revenue reporting manually using the raw BigQuery export, since the GA4 UI numbers couldn't be corrected retroactively.

The lasting change wasn't the code fix, it was adding a monthly reconciliation check between GA4 revenue and the payment processor's ledger, on every storefront, as a standing process. Tracking bugs that produce a plausible wrong number will always slip past DebugView spot checks eventually. A reconciliation habit is the only thing that catches them reliably after the fact.