Why this exists

Most write-ups about measurement problems stay abstract - "clean up your tags," "audit your triggers," "reduce duplicate events." None of that tells you what a real diagnosis looks like or how the decisions actually get made under a deadline.

This is a walkthrough of one real audit, details anonymized. The client, timeline, and exact numbers are changed. The problems, the reasoning, and the fixes are not.

The starting point

The request was simple: "our numbers don't match what we're seeing in the storefront." Revenue in the reporting dashboard was running roughly 18% higher than actual processed orders. Nobody knew why, and nobody had looked inside the container in over two years.

Two years of unaudited tags is enough time for a setup to accumulate a lot of quiet damage - old campaigns nobody remembers, triggers built for a page that no longer exists, and fixes layered on top of other fixes.

What the container actually looked like

Opening it up, the picture was less "one bug" and more "several years of small, reasonable-at-the-time decisions that never got revisited."

  • A purchase event firing twice on the confirmation page - once from a template built years earlier, once from a newer implementation nobody had removed the old one for.
  • A checkout trigger still watching for a URL pattern from a storefront redesign that had shipped over a year prior.
  • Eleven tags with no owner, no notes, and no clear trigger logic - built for campaigns that had long since ended.
  • A cross-domain setup that worked for the main site but silently broke on a subdomain added after the original configuration.

None of these were dramatic on their own. Together, they explained the entire gap.

The decision log

This is the part most write-ups skip - not just what was wrong, but the actual reasoning behind each call. Every fix has a trade-off, and the trade-off is usually more informative than the fix itself.

Decision 1: Kill the duplicate, not both

The instinct is to rip out anything that looks redundant. Instead, each of the two firing tags got traced back to what else depended on it. One fed a downstream reporting pipeline nobody had documented. Removing the wrong one would have quietly broken that pipeline instead of fixing the duplication. The newer tag stayed; the older one was retired only after confirming nothing still pointed to it.

Decision 2: Fix the trigger condition, not the symptom

It would have been faster to just disable the stale checkout trigger. Instead, the underlying URL logic got rebuilt to match current page structure, because the alternative - leaving a silent gap in checkout tracking - creates the exact same kind of problem this audit was trying to solve.

Decision 3: Document before deleting the orphaned tags

Eleven unowned tags is tempting to mass-delete. Each one got a short note on what it likely was and why it was being removed, stored outside the container itself. Six months later, if a question comes up about historical data, there's a record of what changed and why - instead of a mystery.

Decision 4: Treat the subdomain gap as a structural issue

The cross-domain break wasn't a one-line fix so much as a sign the whole domain list needed to be centrally managed instead of hardcoded in multiple places. That took longer than a patch would have, but it's the difference between fixing today's break and preventing the next one.

Before and after

Before

  • Revenue overreported by roughly 18%
  • Duplicate purchase event firing on every order
  • Checkout tracking silently broken for over a year
  • Eleven undocumented, unowned tags
  • Cross-domain tracking failing on one subdomain

After

  • Revenue reconciled to within rounding error
  • Single purchase event, verified against order data
  • Checkout trigger rebuilt around current page structure
  • Documented ownership for every active tag
  • Domain list centralized instead of hardcoded

What this actually took

Not a checklist run top to bottom. Every one of these decisions required tracing a tag back to whatever it fed - a report, a dashboard, someone's Monday morning routine - before touching it. The technical fix in each case was usually the easy part. Figuring out what would break if it changed was the real work.

That's the difference between a template and an audit. A template tells you what to look for. An audit is the judgment call made each time something looks wrong but isn't obviously safe to remove. This is the same kind of audit work covered under Analytics & Data - tracing what's actually firing before touching anything.

Frequently asked questions

How long does something like this usually take?

It depends entirely on how much undocumented history is sitting inside the setup. A container that's been touched by one careful owner for years looks very different from one that's changed hands repeatedly with no notes. The tracing work - figuring out what depends on what - is almost always the longer half.

Is a revenue mismatch always a tagging problem?

Not always, but it's one of the first places worth checking. Duplicate events, stale triggers, and unreconciled currency or refund logic account for a large share of the reporting gaps seen in practice.

Can this be done without disrupting current tracking?

Yes. Diagnosis happens in a working copy before anything touches the live setup, and changes get verified against real order data before they replace what's currently running.

Not sure what your own site is telling you?

A short conversation is usually enough to tell whether there's a quick fix or a bigger gap worth addressing.