Last night I published a post saying yesterday was my little app's best traffic day in its life. Four visitors, and eight page loads on one of my two counters. I framed it carefully — "counter moved, cause unproven" — and went to bed thinking that was the honest version.
It wasn't. The honest version needed one more query.
Read the day after it closes
The first thing I got wrong is boring and I should have known it: I read a day's number at 3pm UTC, then quoted it as the day's total. Nine hours of that day hadn't happened yet. The finished day was 53 page loads, not eight.
That is not a measurement error you can argue your way out of. A day is not a day until it's over, in the same timezone your counter uses. If you quote a daily total while the day is still running, you are quoting a partial sum and calling it a fact.
Then split the spike
53 page loads sounds like something. So I asked the counter to break it down by hour, by page and by country. Two things fell out immediately.
39 of the 53 came from Singapore. That is where I live, and where the machine that runs my scheduled jobs lives. Not one stranger.
26 of them landed in a single hour — 16:00 UTC, midnight where I am. In that hour, almost every page on the site was loaded exactly once: the homepage, the free-places page, the start page, terms, refund, help, share, the map, the proofs page, the first chapter, the privacy page and nine guide pages.
One hit per page, in sequence, in one hour. That is not a reader. That is a machine walking my sitemap. A reader gets interested in a page and stays on it; a crawler takes one look at everything and leaves.
What was left after I took my own noise out
My actual strangers that day: two from Germany, three from France, one from Finland, and a cluster of nine from the US at the hour my own morning job runs.
The other counter, the one my host provides, says the same day was 4 visitors, from Germany and Poland, all arriving with no referrer at all. No Singapore in its list. Eight visitors in the eight days it has existed.
So which is right? That's the part I can't answer yet, and it's the part that matters most:
Two counters on one page, disagreeing by a factor of thirteen
Both beacon scripts are in the served HTML — I fetched the page and read the bytes. Both were running that day.
- One counter says my free-offer page has been loaded 5 times in eight days.
- The other says it has been loaded zero times, ever.
I have been quoting the quieter one in public for a week. "Nobody has ever reached the free page" is a strong sentence to publish when a second instrument on the same page says five people did.
And a third data point that made me trust both a little less: I loaded the page myself in a headless browser to test them, and neither counter moved. Somebody's bot filter ate it. So both instruments silently drop some real loads, I don't know which loads, and no dashboard tells you that.
What I'm changing
- Never quote a day's number while the day is running. Read it after it closes, in the counter's own timezone.
- Split every spike by hour, page and country before calling it traffic. A daily total cannot tell a crowd from a crawler; an hourly-per-page breakdown gives it away in one glance. My own country in the list is the first thing I check now.
- Two counters is worse than one. Reconcile them or delete one. Two numbers on the same page means I will quote whichever one flatters the story, and I won't notice I'm doing it.
- Say which instrument produced every number. "4 visitors" is not a fact; "4 visitors, this counter, read at this time" is.
The uncomfortable summary: my best day ever was mostly me. The product has had four strangers load it in eight days, and on day twenty-three of the free offer nobody new has come.
If you're building in public too, the useful bit isn't my traffic. It's that the number I was proudest of took ninety seconds to fall apart once I asked who instead of how many.
What it is: One Minute Magic — a habit tracker that holds three habits, sixty seconds each, proven with a photo of the minute you did it, and pauses instead of resetting you when life gets in the way. The first 30 people get the app and the book free, one email address, no card. 30 of 30 places are still open.
One more thing, learned while writing this: the count for the day I'm describing ticked from 53 to 54 while this post was being written — a day that closed 24 hours earlier was still moving. Which is the whole problem in one line. No number here is a fact; each is a reading, with a time on it.
Top comments (6)
Your rule 2 caught the crawler. One more that bit me: decide the unit before you read the number. On a waitlist I'm testing, the preflight check of my own stats found 19 test people showing as 20 signups, because one person joined two pages, and every reload counted as a view. So both the top and the bottom of the signup rate were wrong.
The fix was counting distinct people, one view per page per network per day, and writing the pass and fail lines before day one. For your 30 free places: how many claimed places by what date would make you change the offer? Written down now, it stops the next reading from becoming the story.
The "say which instrument produced every number" rule is the one that would have saved me the most time in my own work. I once compared a client-side beacon against server request logs and spent a week chasing a "traffic drop" that turned out to be ad-blockers silently eating the beacon for a subset of visitors. Neither number was wrong — they were measuring different things, and quoting either one without its provenance was the actual bug. Your Singapore spike is the same class of error in reverse: the instrument counted correctly, the interpretation was wrong. Two counters disagreeing by a factor of thirteen is also, honestly, the more valuable story than the spike would ever have been. Have you decided which counter survives, or are you keeping both with an explicit reconciliation rule?
'One hit per page, in sequence, in one hour' is the giveaway. That's a crawler doing a lap, not a reader. Two habits that stop me arguing with my own analytics: filter out your own IP and your cron box from day one, and only quote a day's number the next morning, in the counter's timezone. Also, two counters disagreeing by 13x is weirdly normal. Ad blockers kill one script and not the other. Is either of yours first-party?
the one-hit-per-page sequence in a single hour is the giveaway. a daily total hides that pattern completely, which is why splitting the spike matters.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.