I lost a week of analytics data last month, and the bug was a single string. Not a broken deploy, not a JavaScript error, not a server outage. I had pasted the wrong Google Analytics measurement ID into every page of my site, and nothing in the pipeline noticed.

How it happened

I run a small free tool site, ramrom.io, built in plain PHP on shared hosting. When I set up Google Analytics, I created the property, copied the measurement ID from the dashboard, and dropped it into the tracking snippet on each page. The ID I copied belonged to a different property — one I had created earlier while testing and never deleted. The tag worked perfectly. It fired on every page view and reported it all faithfully to a property I never opened.

That is the nasty part. A wrong measurement ID does not throw an error. There is no failed request, no console warning, no broken layout. The gtag.js script loads, the config call runs, and the browser sends beacons to google-analytics.com exactly as designed. The only symptom is silence: the property you actually look at shows zero visitors, day after day, while you assume traffic is just slow.

How I found it

After a week of flat zeros I stopped blaming traffic and started checking the plumbing. I opened the site, opened the Network tab, and looked at the requests going out to google-analytics.com. Each one carried a tid parameter — the measurement ID the tag was actually sending. I compared it against the ID shown in the Analytics dashboard. They were different.

That comparison is the whole diagnosis. If your Analytics shows nothing, do not guess at filters first. Check the tid in the network request against the ID in your dashboard. It takes thirty seconds.

The fix

The fix itself was one deploy. My site has 14 pages, each carrying the same snippet, so I edited the ID in the shared snippet and uploaded it everywhere. But a string pasted by hand into 14 files is exactly how this happened in the first place, so I made two changes while I was in there.

First, I moved the measurement ID into a single place: one line in the shared header include that every page already pulls in. There is now exactly one copy of the ID on the server. If it ever changes again, there is one file to edit, not fourteen.

Second, I added a verification step to my deploy checklist. After every upload that touches the header, I load the live homepage, open the Network tab, and confirm the tid in the request matches the dashboard. It is a thirty-second check, and it would have caught the original mistake on day one instead of day seven.

What I actually lost

A week of data, and that week is gone for good. Analytics does not backfill. You cannot re-send the beacons from a property you never looked at, and Google will not merge one property's data into another. The traffic happened; the record of it did not. For a small site that is not a catastrophe, but it happened during a week when I was watching for the effect of new pages going live — exactly the week I most wanted the data.

The lesson I kept

The lesson is not "be more careful pasting IDs". That is a wish, not a system. The lesson is that silent failures need a check that is louder than the failure. A wrong ID produces no error, so the check has to live outside the tag: one source of truth for the value, and a manual verification against the live site after every deploy.

If you have just set up Analytics and your reports are empty, do not wait a week like I did. Check the tid in the network request today. If it matches and the reports are still empty after 24 to 48 hours, then start looking at filters, consent banners, and ad blockers. But start with the ID. It is the simplest thing to get wrong and the quietest when you do.