Why this exists

A conversion count that goes up is rarely questioned. It's the metric everyone already wants to believe, which is exactly why it's the one most likely to hide a measurement problem instead of a real result. This is what it looked like when a single <script> tag, added months earlier and never removed, turned out to be the entire story.

What it actually looked like

A site redesign months prior had included a full analytics re-platform - new property, new measurement ID, new event naming. The rollout went fine. The old property was supposed to be retired once the new one was confirmed working.

It wasn't. The old tag was still sitting in the page template, untouched, quietly sending the exact same purchase events to a property nobody was looking at anymore - while the new property, the one everyone reported from, was healthy and accurate on its own. Nothing about the new property's numbers was wrong. The problem was a separate report, built later, that pulled from both properties without realizing it.

What was actually happening

A quarterly summary had been built by an outside consultant using an export tool that pulled every measurement ID associated with the account - both the active property and the one that was supposed to be retired. Each purchase event existed in both properties, since both tags were still firing on every checkout. The export tool didn't know the two properties described the same website. It just added their totals together.

The result read as legitimate growth because every individual number involved was, in isolation, completely real. Real purchases. Real timestamps. Real customer IDs. They were just being counted from two places that happened to be watching the same checkout.

  • Live property - accurate, actively monitored, correctly configured
  • Retired property - still tagged, still firing, technically also accurate
  • Quarterly export - summed both, unaware they overlapped

The decision log

Decision 1: Verify the growth in the live property alone before touching anything else

Before assuming the export was wrong, the live property's own dashboard was checked in isolation. It showed real growth - just roughly half of what the export reported. That gap was the first hard evidence something downstream was doubling up, rather than the growth itself being fabricated.

Decision 2: Search the page source for every measurement ID, not just the current one

Rather than assuming the current implementation was the only one, the full rendered page source was searched for every tag matching the platform's script pattern. Two measurement IDs turned up. Only one was supposed to still exist.

Decision 3: Confirm the old property was actually receiving live data

Finding a leftover tag in the source doesn't prove it's still active - it might be disabled server-side or blocked by a since-added rule. Checking the old property's own real-time report directly, and watching a test purchase land in it live, removed any doubt.

Decision 4: Remove the tag, not just exclude the property from future reports

Filtering the retired property out of future exports would have stopped the double-count without stopping the underlying cause - the old tag would still be firing, still be collectible by the next person who builds a report without knowing to exclude it. The actual fix was deleting the script from the template entirely, so there was nothing left to accidentally include again.

Before and after

Before

  • Two live properties tagged on every checkout page
  • Quarterly export summing both without knowing it
  • Conversions reported roughly double the real figure
  • A campaign getting credit for growth that wasn't there

After

  • Retired property's script removed from the template entirely
  • One measurement ID live on the site, verifiable in source
  • Quarterly numbers matched the live dashboard exactly
  • Real, smaller growth figure - trusted, not inflated

What this actually took

One line removed from a page template, and about an hour confirming which of two properties was the ghost. The harder part was psychological, not technical - a number that's going up in the direction everyone wants rarely gets the same scrutiny as one going the wrong way. Auditing what's actually still wired up, not just what the dashboard shows, is part of the Analytics & Data practice on every re-platform, not just the ones that look suspicious.

Frequently asked questions

How common is a leftover tag like this?

More common than a single missed cleanup step suggests - any re-platform, agency handoff, or migration that doesn't include an explicit "remove the old tag" step in its checklist is a candidate, and the symptom rarely announces itself the way a broken tag does.

Why didn't the live property's own report catch this?

It had no way to know a second property existed - each property only sees its own data. The overlap was only visible from outside either one, in a tool pulling from both at once.

Is inflated data actually worse than missing data?

In some ways, yes - missing data usually looks broken and gets investigated quickly. Inflated data that trends the direction everyone hopes for can survive multiple reporting cycles before anyone questions it.

How do you check for this on an existing site?

View the rendered page source and search for every tag matching the analytics platform's script pattern, then confirm each measurement ID found actually corresponds to a property still meant to be active - not just the one shown in the current dashboard.

Wondering if last quarter's growth was actually growth?

It usually takes checking the source, not the dashboard, to find out for sure.