The tag that measured nothing
19 October 2026
The analytics on this site worked perfectly from the day they were added. The script loaded, the tag fired on every route, Google accepted every hit, and Google’s own tag checker confirmed the site was tagged.
The property named after this site recorded nothing. Not a little — nothing. No data received, demographics empty, the reports snapshot never even configured.
Two properties, one login
The measurement id written into the code belonged to a different property on the same account. The property for this site had its own id, its own data stream, and the right domain on it, and no page ever sent it anything.
Nothing about that is detectable from the browser. A wrong measurement id behaves exactly like a right one: the tag is well-formed, the request succeeds, the response is a 204, and the analytics vendor has no way to tell you that the property you meant is not the property you named. Every signal available at the point of failure said success.
The only test that would have caught it is the one nobody runs on something that is working: open the far end and look.
The comment that explained it away
Three lines below the wrong id sat a note justifying why local page views are excluded from analytics. It described the property as having “a handful of visits”, and used that to argue the exclusion mattered — a few developer page loads would not be noise in a dataset that small, they would be a majority.
The real figure was zero, for the reason written three lines above it. The comment had taken the symptom, found it unremarkable, and supplied a rationale. Anybody reading that file — and several people did, repeatedly — met an explanation for the silence before they met the silence, and had no reason to go and check.
That is the part worth carrying away. A note that rationalises an absence is worse than no note, because it converts a question into a settled matter.
The fourth costume
This project keeps meeting the same failure in different clothes: a setup gap that presents as something else entirely.
A placeholder value left in a config file read as a dead provider, and two support emails went out about an account that was working fine. A missing per-chain address read as an outage, so a provider that had simply never been configured for one chain was reported as failing. A rate limit — a 4xx, like a rejected credential — read as a refused key. And now a correct tag pointing at the wrong property, read as a quiet site.
In each case the system was behaving exactly as built. In each case the diagnosis was drawn from inside the thing that was misconfigured, which is the one vantage point that cannot see the misconfiguration.
What it cost
Not much directly: nobody was tracked more or less than they should have been, and nothing about what is collected changed. What it cost was a decision.
This site is planned in several languages, and the rule for choosing which one to translate first was to read the analytics rather than guess. That rule was followed. The analytics were opened, found empty, and the language work waited — on a dataset that was never going to arrive, because the tag had been filing it elsewhere the entire time.
A measurement you believe in is load-bearing even when it is empty. An empty report does not look like a broken pipeline; it looks like an answer.
Every figure above can be checked against the providers yourself — no account, no sign-up, and nothing is held for you at any point.