Nine Days of Our Analytics Went to Another Website

At the start of September we opened Analytics to see how a campaign had done, and found what we had found the day before, and the day before that: nothing. Not a dip. A flat, absolute zero. No users, no events, nothing in real-time. Nine days of it.

The site was up. People were signing up. The reports were empty.

The cause was one line of code that had been correct for a year and then quietly stopped being correct - without anyone touching it. If you run Google Ads and Google Analytics on the same site, the same thing can happen to you.

First, the wrong suspect

Our first theory was the cookie banner. It is the most satisfying explanation in analytics: consent is genuinely complicated, the law is real, and people are refusing cookies will explain any missing number you like.

It was wrong, and it cost us two days. Consent was denying storage, yes - but a denied consent still sends a cookieless ping. Zero is not what refusal looks like. Zero means the tag never ran, or it ran somewhere we were not looking.

There is a general lesson in that one, and it is worth more than the rest of this article: before you explain a number, check whether the number is yours. Our audience is behaving differently is a far more interesting story than the pipe is disconnected, and when a metric goes to exactly zero it is almost never the right one.

What had actually happened

A Google tag has two kinds of identity, and almost nobody needs to know the difference until the day they very much do.

It has an ID - the name of the container itself. And it has destinations: the accounts that container is allowed to send data to. One tag, several destinations. An Analytics property here, an Ads account there.

Our page did what a thousand tutorials tell you to do: it declared our Google Ads ID. That worked for a year, because our Ads ID also happened to be an ID of our own container. Then, in the space of about two minutes on a Tuesday morning, it stopped being one.

Here is the trap. When you configure an ID, the tag treats it as a tag ID, not as a destination. So it asked Google which container owns this ID, and Google answered honestly. The only container still claiming it belonged to an entirely different website - one that shares nothing with this product except a years-old advertising account. Our page loaded that site's tag, that site's configuration, and that site's Analytics property.

Our visitors were being measured perfectly. In an account we were not reading.

The nine days are not coming back

This is the part worth knowing before it happens to you: Analytics does not move data between properties. Not through support, not through an export, not on a paid tier. Data lands where it lands, and it stays there.

We could read what we had lost, which is its own particular kind of unpleasant: 14 sessions, 9 links created, 3 sign-ups, 2 people who opened the pricing page, 0 purchases.

Small numbers. They were also the only nine days of evidence we had for a campaign we were paying for, and they now live permanently in someone else's property.

The check that takes thirty seconds

You do not need Tag Manager for this. Open your own site, view the page source, and search for gtag('config'. Then read what comes after it.

• An ID starting with G- - that is a measurement ID. It is the one you want declared on the page.
• An ID starting with AW- and nothing else - you are relying on an inheritance. Your Analytics data is arriving because some container, somewhere, still lists your property as a destination. That arrangement can change without anyone touching your website. Ours did.

Now the other half, which takes twenty seconds and is the one people skip: open Analytics, go to Realtime, and load your own site in another tab. If you do not appear within a minute, you are not writing where you think you are writing.

Do that after every change to a tag, an ad account or a consent banner - not once a quarter. Nine days passed for us because nobody had a reason to look.

The rule we follow now is deliberately boring: one project, one Analytics property, one tag, and that tag carries every destination. Declare the measurement ID on the page. Never the bare Ads ID.

The second thing we had wrong: consent for the entire planet

While we were in there we found something else with a real cost attached. Our consent defaults denied analytics and advertising storage for every visitor on earth. It felt responsible.

It was over-compliance, and Google Ads flagged it before we noticed: a warning that 100% of consent signals were coming back denied in various regions, including regions outside the EEA.

Prior consent is the law in the EEA, the UK and Switzerland. It is not the law everywhere. Applying it everywhere does not make you safer - it makes you blind in markets where you were free to measure, and it does nothing extra for the users the rule was written to protect. We regionalised it: denied by default where consent must come first, granted elsewhere, with the banner still shown to everyone and a refusal still respected everywhere.

And the one that was entirely our own doing

The last one is the most common of the three, and the easiest to inflict on yourself while doing something sensible.

To keep the site fast, we loaded the analytics script lazily: on the first interaction, with a timer as a fallback. The timer was set to ten seconds.

Measured on the live site, the tag was appearing about eleven and a half seconds after the page started loading. Which means every visitor who arrived, read something, and left without scrolling or clicking produced nothing. No page view. Not even the cookieless ping, so they could not be modelled or estimated either. As far as the data was concerned, they never came.

We moved the fallback to two and a half seconds - after the page has painted, long before any real reader gives up. Deferring third-party scripts is still the right call for performance. Just go and check what it quietly deleted.

Three things to do this week

1. View source on your own site and read the ID you are declaring.
2. Open Realtime and prove to yourself that your own visit lands in the property you think it does.
3. Find out when your tag actually loads, and ask what happens to a reader who leaves after six seconds.

None of this is advanced. All three failures survived for months inside a setup that looked completely normal from the outside, on a site run by people who do this for a living.

If you run that first check and find something you did not expect, tell us - we would genuinely like to know how common this is. We suspect the answer is much more common than anyone admits.

A smaller surface to get wrong

We build short links with click analytics and dynamic QR codes for a living, so spending nine days unable to measure ourselves was not lost on anyone here.

One upside of measuring a link rather than a page: the count lives in your own dashboard, and it does not depend on a container, an inheritance or a consent default going right. A scan is a scan. If you want the longer version of that, we wrote a beginner's guide to tracking link clicks, or you can just see what is included and start counting something today.