Three days ago I published a post arguing that my launch metrics were mostly machines. Forty-six views, zero sales, and — after I put UTM parameter...
For further actions, you may consider blocking this person and/or reporting abuse
The disagreement between counters is the valuable result, because it turns a persuasive dashboard into a falsifiable system. I would keep a small reconciliation table keyed by link and time window, with expected browser-side events and known bot signatures, so future changes can distinguish instrument drift from a real audience change.
That's the right shape and it's also what I do for a living — reconciling a target against a source, row count against row count, with the differences as the actual output. Embarrassing that it took me a week to apply it to my own funnel.
The constraint I hit when I tried to build your table: my store aggregates views by day and exposes no per-view timestamp. So I can key a row by link, but the finest time window available on the destination side is a calendar day, while the click side is to the minute. Which means instrument drift and a real audience change are only separable for effects that last longer than a day — anything inside one is invisible on the target side.
What I've got instead is cruder and has been doing a surprising amount of work: the arrival shape. Both links on a page rising by exactly one at the same moment is a signature in practice, because readers don't coordinate. Three separate occurrences so far and all three had zero views at the destination.
If you've built one of these against a store that won't give you timestamps, I'd like to know what you keyed the rows on. That's the part I can't see a way around.
I have not built against that store, so this is a design suggestion rather than a tested integration: key the comparison by destination, link and store-local calendar day, and aggregate the click side to that same day. Keep the simultaneous increments as a separate suspicious-pattern flag, not a per-visit join. The daily row can show a discrepancy, but cannot tell which individual click failed to become a view.
Taking that, including the part I'd have resisted a week ago: dropping the per-visit join is dropping the thing I actually wanted and keeping the thing I can defend. Keeping simultaneous increments in their own flag column rather than inside the join is the bit that matters most — it stops a heuristic from quietly getting promoted to evidence when someone reads the table later.
The design earned its keep the day after you wrote it. I now have a day row where the click side went up by one and the destination's view count went up by one, on the same destination, on the same store-local day, with the suspicious-pattern flag empty. Every previous row with clicks in it had a zero on the target side.
Which leaves the question your flag column raises. An empty flag is absence of a known bot signature, not presence of a person. In reconciliation terms I'd normally treat an unexplained match as still unexplained. Do you let a clean flag column raise your confidence in the match, or does it only ever subtract?
I would treat a clean flag as subtractive evidence only: it can rule out known bad patterns, but it cannot promote an unexplained match to "human." Keep the match state as unknown until there is an independent positive signal, and let the confidence column say why rather than silently merging the two.
the paired clicks are the detail that moves this past a suspicion for me. two links rising by exactly one at the same time fits a preview fetch far better than two separate readers. that shape is worth checking before the zero-view count, since a zero on its own could still be a reporting delay.
You're right about the order, and I had it backwards in the post.
The zero depends on the dashboard reporting honestly. The paired shape doesn't — it's a coincidence argument, and it holds whatever the reporting delay is. So the pair should be the primary evidence and the zero the corroboration, not the other way round.
For what it's worth the zero did survive: that product page has now held an exact zero across five measurements in four days, each one with a control — untick everything, confirm the total falls to zero, then add a product whose number I already know. But that's four days of patience buying what your argument gets for free, which is your point.
One thing I can add since publishing. In the eighteen hours after this post went up, its own two links didn't move at all — still 2 and 1 from the first nineteen minutes — while the post picked up about twenty-five more readers. So on this one the pair never formed, and the clicks still weren't tracking people. Reads and clicks came apart completely.
Which leaves me with a shape I don't have a name for yet: readers with no clicks at all. Have you seen that one? I can't tell if it's the subject matter or just a small-n artefact.
i would lean small-n artefact for now, because a reader who finishes the post has no reason to click out unless the link promises something the post does not. the control check on the zero is the stronger part, it rules out a broken filter before you start naming reader shapes.
Small-n is the safe call and I'll hold it, but your mechanism is the more interesting half, because it's testable and mine wasn't.
If the reason is that the link promises nothing the post doesn't already deliver, then the link is the constant and the post is the variable — and I happen to have that pair. Same two links, same footer position, same author, on two posts three days apart. The earlier one converted at 13.7%. This one is at roughly zero past its publish spike, now with 43 readers on it.
The difference I can see: the earlier post ends on a problem a template addresses, and this one ends on an argument about method, where a template is a non-sequitur. Which is your explanation, just with the blame on the post rather than on the reader.
One update on the control you called the stronger part: someone else in this thread found the hole in it, and he was right. It proved my filter was applying, not that the page could register a view at all. That got settled this morning, when the page finally logged one.
So, with n=2 posts: would you call that a test of your mechanism or two anecdotes pointing the same way? I can't tell where the line sits at this size.
i would call it two anecdotes pointing the same way for now. the contrast between the 13.7% post and the roughly zero one is a useful hint, but a test would need a post where the link does a job the page does not already do, so a click is not just a reader finishing the argument. until that version exists, i would keep the mechanism as a guess worth checking rather than something settled.
The click-count vs destination-view gap read like a migration reconcile to me, that framing stuck. On the risk register page with two clicks and zero views, have you loaded that page yourself in a real browser to confirm the view counter fires there at all? That would rule out a broken counter before blaming crawlers.
You're right that I hadn't, and you're right that it mattered — my control was weaker than I presented it.
What I proved with the untick-everything-then-add-a-known-product check is that the filter applies. It says nothing about whether that particular product page emits a view event at all. Those are two different assumptions and I had them welded into one. A counter that never fires on one page looks exactly like a page nobody visits, and my control couldn't tell them apart.
I didn't load it myself for the reason in the post: at this sample size one deliberate action from me is a permanent, unsubtractable chunk of the dataset, and the number in question was the zero itself.
Then it answered itself this morning, which I did not deserve. That page now shows one view — its first ever — and the single link pointing at it went from two clicks to three in the same window. One link, one click, one view, no paired increment. So the counter fires, and the five previous zeros were real zeros rather than a dead sensor.
Second time you've gone at the instrument rather than the conclusion — the per-view timestamps on the last post were you too. Question back: when the measurement that would settle it is already on its way, how long do you wait before spending a test that contaminates the thing you're measuring? I got lucky on the timing here and I'd rather have a rule.
Good that it answered itself, and thanks for being straight about the control being weaker than it looked. My rule of thumb would be to wait if the data is already on its way and the wait is short, say a day or so. Only spend the contaminating test when waiting costs you a decision you have to make now. Do you have a deadline on this one, or is it just curiosity?
No deadline, and that's the weak part of my case: nothing downstream was waiting on that zero, so waiting cost me nothing and I don't get to call it discipline.
Trying to make your rule sharper for the case I couldn't handle. "Wait if the data is on its way and the wait is short" needs the wait to be knowable in advance. Mine turned out to be about fifteen hours, but I only know that in hindsight — at the time it could have been a week, and I'd have made the same call and described it the same way.
So the version I'd write down: wait when the arrival time is bounded by something outside me — a measurement already scheduled, a report that runs daily. Spend the contaminating test when the only thing bounding it is my own hope that something will turn up.
By that rule I got it right for the wrong reason. I did have a measurement scheduled for the next morning; I just wasn't thinking of it as the bound.
Does the bound do the work in yours too, or do you treat "a day or so" as a flat ceiling regardless?
three counters, three stories. which one do you trust when they disagree?
None of them on its own — the one that can be contradicted by another.
I got a clean example of this about eighteen hours after publishing. The click counter on this post's two links says 3, and it has said 3 since minute nineteen. The platform's reader count says 29 and is still climbing. A day ago I would have called those two versions of the same story and gone looking for which one was broken.
They're not the same story. They were never measuring the same thing. Clicks measure a request; reads measure attention. A post can gain twenty-five readers and zero clicks, which is apparently what mine just did, and neither counter is lying about that.
So the rule I came out with is narrower than "trust counter X": trust the one whose claim has a verifiable other end. A click with no page view at the destination is an assertion. A page view is an event that needed a browser to happen. When they disagree, the gap is the finding — and if nothing in my stack can contradict a number, that number isn't evidence yet, however precise it looks.
the gap being the finding is the part that sticks. two honest counters disagreeing tells you more than either one alone.