Why your click counts are wrong, and what to do about it
Send a short link to a colleague on a corporate mail system and watch the counter move before they have opened the message. Nobody clicked anything. A security gateway fetched the URL to see where it goes. That request was real, and every shortener has to decide what to tell you about it.
Who is actually hitting your links
Why filtering them out is guesswork
A redirect endpoint sees a method, a path, some headers and a source address. It does not see whether a person was present. Every bot-detection technique is therefore a heuristic, and each one fails in a way that matters.
Matching user agent strings catches only the bots honest enough to declare themselves, which is the harmless half. Filtering by address range means maintaining a list of every cloud provider and mail vendor, which goes stale weekly and discards genuine visitors behind corporate VPNs along the way. Timing heuristics that treat a burst of similar requests as automated will cheerfully delete your real traffic on the one day a post does well.
Each technique moves your number by an amount nobody can quantify. A dashboard that applies several of them shows a figure that is neither the raw count nor the human count, with no way to tell how far it travelled from either. Being wrong in an unknown direction is worse than being wrong in a known one.
A click figure is the number of redirects the service handled and successfully recorded. Automated traffic is included, because it genuinely happened. Nothing is filtered, so nothing is distorted by an unmeasurable amount, and what the number means is written next to it rather than implied by a word like “visitors”.
The quieter problem: data you never collected
Bots are the famous issue. Gaps are the one that actually misleads people. Analytics writing can fail while redirects keep working perfectly: a database lock held too long, a disk filling, a maintenance window, a retention sweep that already removed the day you are asking about. The visitor reached their destination and no record of it exists.
Most dashboards render that as a zero. A zero is a claim, and in this case a false one: it says nothing happened, when the truth is that nobody was writing it down. Worse, it propagates. Average that zero into a weekly figure and the error spreads across six days that were measured correctly.
The fix is unglamorous and effective. Record, per period, whether the data is trustworthy, and show it.
Five labels instead of one number costs almost nothing to store and removes an entire category of confident wrong conclusions.
Unique clients are an estimate, and should say so
Counting distinct anything without storing per-visitor identifiers means a probabilistic sketch: a small fixed-size structure that answers “roughly how many distinct values did you see” within a few percent. c1k.me keeps one per link per day, derived from a salted value that expires daily and is never stored.
That design has two honest consequences. A visitor returning tomorrow counts again, because yesterday's salt is gone. And a seven-day unique figure is a sum of seven daily estimates rather than a true distinct count across the week, which is why the interface labels it as such instead of quietly presenting a smaller, cleverer-looking number.
The alternative is a durable per-visitor identifier, which means tracking people. That trade is available from other products and is not made here.
How to read the numbers usefully
And ignore any single day labelled uncertain. That is what the label is for.
Why nobody does this
Honest analytics look worse. A dashboard admitting that Tuesday is uncertain and that uniques are estimates reads as less capable than one showing six confident decimal places. The confident version is not more accurate; it is more filtered, and the filtering is invisible.
A product with a sales motion cannot easily ship the honest version, because the demo loses. A five euro service with no demo can. That is most of the reason this page exists at all.