how cookie-less tracking actually works
The short version
- A cookie-less visitor id is a random string in localStorage on your own domain, derived from nothing about the person
- localStorage is not a cookie in the way that matters: nothing sends it automatically, and only script running on your origin can read it
- Because the id is scoped to one browser on one domain, journeys break in three ordinary places: a second domain, an emailed link and a week of Safari without a visit to your site
- A first-party cookie would break in exactly those same three places, so the repair is server side either way
- What cookie-less does not settle is whether you need a consent banner. Storage is storage, and that question belongs to whoever advises you
The script mints a random string, keeps it in the browser's own localStorage under your domain, and sends it along with each page view. That is the whole identifier, and it names a browser rather than a person.
Almost everything worth knowing about cookie-less analytics falls out of that. It is why the count includes people who would have refused a banner, why somebody walking from your marketing site to your app can arrive as two strangers, and why keeping one journey in one piece has to be done on the server. So here is how cookie-less tracking actually works, including the parts a vendor page leaves out.
What a cookie-less visitor id actually is
A cookie-less visitor id is a random value the tracking script generates in the browser and stores in localStorage under your own domain. In Tiny Funnel it is 16 random bytes from the browser's own crypto API, written out as 32 hex characters. Nothing about the person goes into it: not their device, not their fonts, not their screen size, not their address.
That last point is the one people assume is a marketing line, so be blunt about it. The id is not computed, it is rolled. There is no fingerprint here, rotating or persistent, and nothing to recompute if the value is lost. Lose it and you have lost that visitor, which is the honest cost of not fingerprinting anybody.
It also has a lifetime rather than tenure. The stored value carries the date of the last visit, a visit refreshes it, and an id idle for roughly six months is discarded. A browser that stops coming back is forgotten on its own.
Why localStorage is not a cookie
The difference is not the word, it is what the browser does with the value on its own initiative. The web storage spec scopes localStorage to a single origin and gives it no expiry mechanism at all, which is where both halves of this table come from.
| A cookie | localStorage | |
|---|---|---|
| Who can read it | The server, and script on that domain | Script on that one origin |
| What sends it | The browser, automatically, on every request to the domain, images and fonts included | Nothing. Your script reads it and decides to send it |
| Scope | The domain, usually including subdomains | One origin. example.com and www.example.com are two separate stores |
| Expiry | Whatever the writer set | None in the API. Any lifetime is one the script imposes on itself |
| What removes it | Clearing cookies, or the expiry | Clearing site data, and in Safari seven days of browsing without a visit |
The consequence that matters is the third-party one. A third-party cookie is written by a domain that is not the one in the address bar, and it goes back to that domain from every site carrying the same script, which is what makes a cross-site profile possible. An id in your own localStorage cannot: only your origin can read it, and it travels only where your script sends it.
And it is still storage on somebody's device, written so that you can count them. That is the sentence to carry to whoever advises you, and it is why nobody here will tell you that a banner is unnecessary.
An id names a browser on a domain, so journeys fracture
Scope is the whole story: the id names one browser on one origin, and a funnel is usually longer than that. Three ordinary things break it:
A second domain. Somebody reads /pricing on your marketing site and signs up on app.example.io. Two origins, two stores, two ids, one person, and a funnel reporting that nobody who saw the price ever bought, which is a drop-off that is not real. Apex to www is the same hop, so it happens inside what you think of as one site.
An emailed link. Somebody asks for a sign-in link on a laptop and opens it on a phone. The phone has never seen your script, so it mints a visitor whose entry page is your own /welcome URL, and your top of funnel fills with people who apparently arrived at the finish line. This is the one that made us build the rest of this list.
A week of Safari without a visit. Since 2020, WebKit has deleted every form of script-writable storage, localStorage named explicitly, after seven days of Safari use without user interaction on the site. The clock runs on their browsing, not on their absence, so somebody who reads your sales page on Tuesday and buys the following Wednesday is two visitors.
The thing to take from that list is that a first-party cookie would fail all three in exactly the same way. Cookie scope is the same scope, a script served from another origin can only set the client-side kind Safari caps on the same seven days, and no identifier written in one browser has survived a link opened in a different one. Cookies are not the fix, which is why the fix lives on the server.
The three cookie-less ways to stitch a journey back together
None needs a cookie, and all three are ordinary engineering rather than anything clever. The identity docs are the full version.
A handoff in the URL, between your own domains. When a visitor clicks from one of your funnel's allowed domains to another, the script attaches the id to the destination link, and the arriving page reads it, strips it back out of the address bar and carries on as the same visitor. The domains are the ones you listed in your Install panel, and a link to anybody else's site is never touched.
Your own user id. Once somebody signs in you know who they are better than any tracker will, so you hand that over: the id you already key that person by, dropped into your signed-in pages. This is the stitch that survives a phone and a laptop, because it describes the person rather than the browser.
An event matched from your backend. When the conversion finishes on the server, your backend posts it as a server event and it is attached to the visitor who caused it, matched on your own user id ahead of the browser token and the address it arrived from. That is a subject of its own, and tracking a conversion that happens in a webhook covers what to send and what happens when nothing matches.
However the connection is made, the two records merge: steps are pooled, the earlier visit keeps the entry page and referrer, and the funnel counts one person.
What cookie-less tracking still cannot promise
Four things, and a tool that hides them is selling you something.
- Cleared storage is a new visitor. Exactly as a cleared cookie would be. Nothing recomputes the id, because nothing computed it
- Private mode gets a per-page id. With localStorage blocked the script falls back to an id that lives as long as the page does. That visit is counted and joins up with nothing else
- A conversion posted from your backend cannot start a journey. It joins a browser the script has already seen, or it is dropped. Nothing arrives out of nowhere with an entry page and a referrer attached to it
- Nothing here decides your consent question. That depends on where you are and what you do with the data, and anyone answering it from a marketing page is guessing at both
What we can tell you is exactly what the script does, which is the useful half anyway. No cookies. First-party only, nothing shared with ad networks, no cross-site tracking, no fingerprinting. A random id in localStorage with roughly a six-month idle life, and a visitor record dropped after 18 months without a return visit.
When you turn click capture on it records clicks on buttons, links and form controls, never prose and never a typed value. Take that list to whoever advises you.
What you get in exchange
Two things, and for most people running a funnel they are worth the trade.
Everyone is counted. No consent wall stands between your visitors and the count, so the rate you read is the rate rather than the rate among people who click accept. It is a measurement argument before it is a taste argument, which is why the only place we make it on the home page is a joke about cookie banners. It applies to attribution too: a referrer split over a consented sample describes the people who clicked accept, not your traffic.
Bots mostly do not get in. Not because of a blocklist, which we do not keep, but because an event only exists if a real browser executed the script. On the same property on the same day (2026-08-06), a server-side first-party tracker counted 1,183 top-of-funnel visitors to Tiny Funnel's 190, and the two agreed exactly from onboarding onward, where every visitor is signed in.
Frequently asked questions
What is cookie-less tracking? Counting visitors without a cookie, using a random id the script writes to localStorage on your own domain instead. Nothing is written to a cookie, nothing is readable by another site, and no attribution is worked out from device characteristics.
How does a cookie-less tool know it is the same visitor? It reads the random id it wrote to localStorage on your domain the last time that browser visited. If the id is gone, or the visitor is in a different browser, it does not know, and it says so by counting a new visitor rather than guessing.
Is cookie-less tracking accurate? For counting visits and funnel steps, yes, and often more accurate than a consent-gated tool, because nothing is filtered out before counting. It is weaker at joining one person up across devices, which is what stitching exists to repair.
Do I still need a consent banner if the tool does not use cookies? That is not a question a vendor can answer for you. Storage is storage, whatever it is called, and your obligations depend on where you operate and what you do with the data. Ask whoever advises you, and hand them the list of what the script stores.
How long does a cookie-less visitor id last? Until the visitor clears site data, or roughly six months of not returning, whichever comes first. Safari is shorter in practice: a week of use without visiting the site removes it.
What is the difference between first-party and third-party tracking? First-party means the identifier belongs to the domain in the address bar and is readable only there. Third-party means one domain reads the same identifier across many sites, which is what builds a profile of somebody.
The trade, stated plainly
You give up recognising a person across every device they own without being told who they are. You get a count that includes everybody, an identifier describing nothing about them, and a mechanism you can explain to a customer in two sentences.
Where the gaps are, they get closed deliberately: your own user id for the person, a URL handoff for your own domains, a server event for the conversion the browser never sees. That is what cookie-less tracking looks like when somebody is honest about it, and it is enough for the question most people are actually asking: where these visitors came from, how far down the funnel they got, and how many bought. That is the question this one is built to open on, and getting there is one script tag and a walk through your own flow. You can track one funnel free for seven days without a card.