What statistics without cookies can tell you
A view count is a small, honest number. It says something arrived, roughly from where, and nothing else. Disappointment with analytics starts where people expect the second half of a sentence that was never there.
Why the usual numbers are wrong for a bio link
Client-side analytics recognises a returning visitor by something stored in the browser: a cookie, an entry in local storage, an id in IndexedDB. On a laptop, in Chrome, that works well enough. On a link-in-bio page it works badly, because such a page is almost always opened inside somebody else’s app.
Instagram and TikTok show links in an embedded WebView. It has its own storage, separate from the system browser, and that storage is short-lived. The same person, tapping the same link on Tuesday and on Thursday, arrives with an empty jar both times. The tool reports two new visitors, and it is not lying — it has no way of knowing otherwise.
So the ratio of new to returning visitors on such a page is meaningless. Totals are undercounted too, because content blockers work inside the WebView as well.
What a server-side count sees
Counting on the server means recording that a request arrived, before any script runs. The page counts itself, so there is nothing to block and nothing to download. You get a number that is always there, and lose detail.
| Cookie-based tool | Server-side count | |
|---|---|---|
| A visit happened | Yes, if the script ran | Yes, always |
| Rough location | Yes | Yes, from the address |
| Kind of device | Yes | Yes, from the request |
| The same person tomorrow | In theory; not in a WebView | No, by design |
| Which link was tapped | Yes, if instrumented | Only through a redirect |
| Where the visitor went next | Sometimes | No |
| Behaviour on other sites | With third-party data | No |
The last column is short on purpose. The count knows a request arrived, roughly which country it came from, and what kind of device asked. It does not know who you are, what you did next, or anything about the rest of your browsing.
A hash that lives for one day
Unique visitors still have to be told apart somehow. Without cookies it is usually done like this: take the visitor’s address, mix in a secret that changes at midnight, hash the result, and store only the hash. On tapmy.link the salt rotates at Kyiv midnight and the rows are deleted after ninety days.
Within one day, two requests from the same address produce the same hash and count as one visitor. The next day it produces a different hash, unrelated to yesterday’s. Nothing stored can be turned back into an address, and nothing connects a person to themselves across the boundary of the day.
That is a real limitation, not a footnote in small print. You cannot ask how many of Monday’s visitors came back on Friday: the data to answer it was deliberately never created. Uniques over thirty days are a sum of daily uniques, not thirty days of following the same people.
The one place a tap can be counted
There is one exception to all of this, and it comes from the shape of the web rather than from any cleverness. A link that points straight at its destination leaves nothing to observe: the browser follows the address in the markup and the request never reaches us. A link with a short path of its own — mia.tapmy.link/shop — points at us first, and so does one that sends an iPhone to the App Store and an Android phone to Google Play. We answer both with a redirect. Answering a request is exactly the moment a tap can be counted.
So a short link is counted the way a page view is: on the server, before any script runs, with no cookie, under the same salt that changes at midnight and the same ninety days. Nothing is added to the page for it — no beacon, no click handler, nothing that breaks with scripts disabled. If the page has UTM tagging switched on, those tags travel with the visitor and are read by the destination’s own analytics, never by ours, and any tag you wrote by hand is left as you wrote it.
It is opt-in, one link at a time, and it costs something. A link that still points straight at its destination keeps that address in the markup, so it works whatever happens to us, and it is not counted at all. Shortening trades that directness for a number. Most pages end up with two or three short links — the ones a decision actually hangs on — and leave the rest alone.
The banner nobody needs
Consent rules in Europe are generally tied to what is written to or read from the visitor’s device, rather than to analytics as an activity. A page that sets no cookie has nothing to ask about. Hence the difference: some sites greet you with a banner, and others honestly manage without one.
Hence a small asymmetry: a dashboard needs a session cookie, because signing in is impossible without one, while the public page sets none at all.
How to read the number you actually have
Views and uniques over seven and thirty days answer fewer questions than people expect, and answer those few well. The discipline is to ask only those.
- Compare weeks, not days. A Tuesday is not a Wednesday, and one day carries too little traffic to mean much.
- Treat a spike as a question, not an answer. Something happened — a video did well, someone shared a post. The number tells you when.
- Watch the ratio of views to uniques. Many more views means people return within the day; roughly equal numbers mean one look each.
- Never read a view as a click. It counts arrivals at the page, not taps on the links inside it.
- Write down what you changed and when. Statistics without a record of your own actions are just a shape on a chart.
A view count will never tell you which link was tapped: that is a different measurement, and here it exists only where a link was given a short path of its own. Knowing where the boundary runs beats pretending the number is richer than it is.