My monitoring found 494 sessions/month Google Analytics was hiding

For months, the analytics dashboard for one of the sites my fleet runs — a senior-fitness site with 179 pages — said roughly 2 visitors. Meanwhile the site was getting email campaigns, search traffic, and social posts. Something was wrong, and it wasn't the traffic. On July 10 a read-only audit found the truth: 494 sessions, 445 users, and 599 pageviews in the last 28 days, sitting in a Google Analytics property nobody was reading.

The failure: two properties with the same name

Inside the same GA account there were two GA4 properties, both named after the same domain. The deployed site — verified by curling the live pages — sent its data to property A. The internal registry file that every reporting script reads pointed at property B. Property A had 494 sessions in 28 days. Property B had zero rows. Nobody ever saw A, because every dashboard, report, and script faithfully read B.

The tracking was never broken. It was misrouted. The site's tag fired correctly on 153 of its 179 pages, all sending to a property with 14+ months of accumulated history that no report ever opened.

Why the monitor missed it — and that's the real lesson

I already had an analytics monitor. It crawled every site and checked that a GA tag existed on the page. It reported 12/12 sites OK, week after week — and it was technically right. A tag existed. It just pointed somewhere nobody looked. A monitor that checks "is there a tag?" can't catch "is it the right tag?" — presence is not correctness. That's the class of bug that silently eats months.

What the audit actually verified before claiming anything

• The deployed code: only one measurement ID exists anywhere in the repo (306 occurrences, no strays), and live curls of the homepage and key pages all serve it.
• The GA Admin API confirmed both properties exist under the same account, same display name — a true duplicate.
• The GA Data API, 28 days back: the "hidden" property showed 494 sessions; the registered one returned zero rows.
• A control: the site's blog subdomain, where the deployed ID matches the registry, reported 228 sessions — exactly matching what the dashboard showed. The reporting pipeline was fine; only the apex mapping was wrong.
• Bonus finding: 26 of the 179 pages carried no tag at all, so ~15% of the site was invisible even to the right property.

The fix — reporting side, not the site

The tempting fix was to change the site's tag to match the registry. That would have been the wrong move: it would orphan 14 months of real data. Instead, the registry was repointed to the property that actually has the history, the 26 untagged pages got the standard snippet and were redeployed, and the dead duplicate property gets renamed so no human ever reads it again. Total effort: about an hour. Data lost: none.

The monitor that now guards it

The important change isn't the fix — it's that the failure mode is now impossible to repeat quietly. The analytics monitor was upgraded: it still crawls every site, but now it extracts the actual measurement ID from each live page and cross-checks it against the registry. A page with the wrong ID gets flagged WRONG-ID, not a green checkmark. The exact blind spot that hid 494 sessions a month is now a named, tested check that runs on schedule — on the same laptop that runs everything else.

This is what I mean when I say the fleet checks its own work. Not "AI magic" — a crawler, a registry file, and a diff, wired so that the lie my dashboard told me for months can't be told twice.

Want this running on your hardware?

I'm taking the Founding 3 — a $299 done-for-you setup (then $499): I install the fleet on your machine, run the first-run interview, and get your first verified content live before I log off, delivered within 14 days. Two things before you buy: (1) do you have a machine with an NVIDIA GPU — 6 GB VRAM or more — that can stay on 24/7? (2) Is there one person on your team who'll spend 10 minutes a day approving what the agents propose? If both are a yes, join the waitlist and say so in your reply — you're in the Founding 3.