Cookieless tracking identifies a visit without writing anything to the browser. The server takes attributes the request already carries, usually the IP address and the user agent, hashes them one way into a short identifier, discards the raw IP, and stores the event. It counts visits accurately and people approximately.
Cookieless tracking is web measurement in which the visitor identifier is computed on the server from request attributes instead of being stored on, or read back from, the visitor's device. The identifier is scoped to one site, so it cannot follow anyone across the web, and it expires by recomputation rather than by cookie lifetime.
I co-founded TinyAnalytics, a cookieless analytics product, so read the product references here with that in mind. This post covers the mechanism: what happens on a request, which methods exist, what each one costs you legally, and where the numbers go wrong.
The pressure behind all of it is well measured. According to Pew Research Center, 81% of US adults say they feel very or somewhat concerned about how companies use the data they collect about them, from a probability-based survey of 5,101 adults in May 2023. That figure is US-only.
| Cookie-based tracking | Cookieless tracking | |
|---|---|---|
| Where the identifier lives | On the visitor's device | On the server, recomputed per request |
| Survives Safari's tracking prevention | No: script-written storage is deleted after 7 days without interaction | Yes: nothing on the device to delete |
| Visitor can clear it | Yes | No, because nothing was stored |
| In scope of ePrivacy Article 5(3) | Yes | Often yes: the rule covers information, not cookies |
| Consent banner needed | Usually | Depends on jurisdiction and configuration, not on the word "cookieless" |
| Cross-site profile possible | Yes, with third-party cookies | No, the identifier is scoped to one site |
| Unique-people count | Exact until the cookie is cleared or capped | An estimate that merges and splits |
How does cookieless tracking work?
Cookieless data collection is, as the name suggests, a way to collect data from users without using cookies. Traditional HTTP cookies are small pieces of data stored on the user's device that keep track of their activities and preferences. Cookieless tracking eliminates the need for those stored values.
The core principle doesn't divert too far from that. It still revolves around tracking user behavior, but instead of storing information on the user's device, the tracking data is stored server-side. That works where cookies are not supported, or most notably, where cookies have been rejected by the user due to privacy concerns.
Unlike cookie tracking, cookieless tracking does not result in any data being stored on the user's device, and it sidesteps the hassles of cookie expiration and deletion. That second point is not theoretical. WebKit documents three separate caps: 24 hours on script-set cookies after a link-decorated arrival, 7 days where it detects CNAME or IP cloaking, and deletion of "all cookies created in JavaScript and all other script-writeable storage after 7 days of no user interaction with the website."
One correction, because most articles on this topic still lead with the opposite. Chrome did not remove third-party cookies: Google confirmed in its Privacy Sandbox update of 17 October 2025 that it will "maintain our current approach to offering users third-party cookie choice in Chrome." Cookies are eroding through Safari and Firefox defaults, ad blockers and consent refusal, not a Chrome deadline. That market story sits in our companion post on cookieless tracking. Most tools built on the mechanism are sold as Google Analytics alternatives, which is why how they identify a visitor matters more than how they describe themselves.
What are the advantages of cookieless tracking?
Four, and they are narrower than most vendor pages claim.
- User privacy: Unlike traditional cookies that store data on the user's device, cookieless tracking copies the user's activity data to the server, keeping the user's device data-free.
- Control over data: It gives businesses greater control over user data, as everything is stored server-side.
- Coverage: Measurement that needs no analytics-cookie banner records roughly everybody. Consented cookie measurement records whoever clicked accept.
- Durability: Nothing on the device means nothing for a browser cap, a private window or a cleared cache to take away.
What is not on that list is regulatory compliance. Cookieless is an input to a compliance position, never the position itself, and the consent section below explains why.
What actually happens on a cookieless request?
Six things happen between the browser issuing a request and a row appearing in a report. Almost every page on this topic stops at step three.
- The tracking script fires, sending the page path, referrer and screen size to the collection endpoint. It reads no stored value back out of the browser.
- The server receives what the request already carried. The source IP address and the
User-Agentheader arrive with every HTTP request; nothing had to be planted earlier to get them. - Automated traffic is filtered out. This happens before identification, and skipping it is why cookieless visitor counts get argued about.
- An identifier is derived one way. In TinyAnalytics that is a SHA-256 hash of the request IP address and the user agent, producing a 12-character cookieless ID. The full derivation is documented in cookieless analytics identity.
- The raw IP is discarded. Our docs put it plainly: "The raw IP address is never stored — only the resulting hash, which can't be reversed back into an IP."
- The event is written against that identifier, and the next request repeats the process from scratch.
Step three deserves its own numbers. On one site we run, TinyAnalytics filtered out 37,175 automated requests in July 2026 against 61,022 human pageviews. On a second, the machines won outright: 23,045 bot requests against 16,535 human pageviews. Those are two different denominators (bots as a share of raw page requests, humans already bot-filtered), so read them as scale rather than a ratio you can subtract.
Step four is where vendors differ, and where disclosure separates them. PostHog documents its literal hash inputs, including a daily salt, which is the standard the rest of the category should be held to. The question worth asking any vendor is not "do you use cookies" but how long does one person keep the same identifier, and what resets it.
That second question has real consequences, and the tools that answer it publicly show why. Fathom documents a SHA-256 of the IP address, user agent, hostname and a site-specific salt that rotates every 24 hours at midnight UTC, which means a visitor who comes back the next day is counted as a new one by design. That is not a flaw; it is a deliberate ceiling on how long anyone can be followed. Short identifier lifetimes buy privacy and cost you returning-visitor accuracy, and any vendor that won't tell you where its dial is set can't tell you what its numbers mean.
TinyAnalytics documents one refinement I haven't seen another vendor publish. For VPN and privacy-relay traffic, where the address rotates constantly, the identifier comes from a coarse network bucket, a /24 block for IPv4 and /48 for IPv6, rather than the exact IP. That keeps a relay user from fragmenting into a dozen visitors, at the cost of grouping more strangers together.
What are the four cookieless tracking methods?
Four, and they are not interchangeable. Server-side tracking is one, where the tracking script records activities on the server rather than placing cookies on the user's device. Web fingerprinting is another, where the user's device properties are used to create a unique identifier. The other two are the server-derived identifier described above and authenticated identity for signed-in products.
| Method | What it identifies | Writes to the device? | EU consent posture | Accuracy |
|---|---|---|---|---|
| Server-derived one-way identifier | A visit, grouped into a visitor for a short window | No | Article 5(3) usually engaged; an audience-measurement exemption may apply | Good on visits, approximate on people |
| Server-side collection endpoint | Whatever identifier you feed it | Only if it also sets a cookie | Depends what it reads back; moving collection server-side changes nothing on its own | Depends on the identifier used |
| Device fingerprinting | A device, often across sites | No, and that is the objection | In scope, and regulators are openly hostile | 33.6% of fingerprints unique in the wild |
Authenticated ID (identify()) |
A person, across devices | Usually a session cookie | In scope, plus a GDPR lawful basis | Exact, for signed-in users only |
Two pages ranking for this query list localStorage and sessionStorage as cookieless methods. They are not. Both write to the device exactly as a cookie does, both are deleted by the same seven-day WebKit rule, and localStorage has no expiry of its own. Swapping a cookie for localStorage buys you nothing technically and nothing legally.
Why is cookieless tracking not consent-free?
Because European law is not written around cookies. There are two independent tests, in this order, and almost no page on this topic states both.
Test 1 — ePrivacy Article 5(3). The ePrivacy Directive governs "the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user." Two details break most vendor claims. The trigger is information, not personal data. And "gaining access" counts independently of storage, so reading something can engage the rule even when you store nothing.
The EDPB Guidelines 2/2023 on the technical scope of Article 5(3), adopted 7 October 2024, apply that test to the techniques in the table above. JavaScript instructing the browser to send requests is in scope (para 33). User-agent header data is in scope (para 43). Hashing does not exempt an identifier (paras 61–63). On IP-only tracking, para 55: "Unless the entity can ensure that the IP address does not originate from the terminal equipment of a user or subscriber, it has to take all the steps pursuant to the Article 5(3) ePD."
Test 2 — GDPR. Separately, is the result personal data, and do you have a lawful basis? A hash of IP plus user agent is pseudonymous, not anonymous, so the first answer is usually yes and you owe an answer to the second. Legitimate interest is defensible for aggregate pageview counting and gets harder as you build per-visitor profiles.
Now the half the consent-banner vendors leave out. Article 5(3) applying does not automatically mean consent is required. Para 56 is explicit that "the applicability of this article does not systematically mean that consent needs to be collected," and that an exemption has to be assessed. France's CNIL sets conditions for an audience-measurement exemption in Sheet n°16 on analytics, and the UK now has a statutory statistical-purposes exception, described in the ICO's guidance on exceptions to the storage and access rules. Both are conditional, and meeting most of the conditions is not meeting them. We map the regimes side by side in GDPR, CCPA and PECR.
So: cookieless removes the cookie, which removes the most obvious trigger and often removes the banner. It doesn't remove the analysis.
TinyAnalytics is designed to support privacy-friendly analytics. Your consent and compliance obligations still depend on your jurisdiction, configuration, and the data you choose to send. What we collect and how we handle it is documented in our trust center. This is product information, not legal advice.
Why is fingerprinting the method to avoid?
Of the four, I'd rule this one out on both legal and technical grounds. Fingerprinting builds an identifier from screen size, fonts, canvas rendering, installed plugins and hardware traits: characteristics a visitor cannot see, clear, or opt out of. It replaces the cookie with something harder to escape than the cookie.
Regulators say so directly. According to the UK Information Commissioner's Office, "fingerprinting is not a fair means of tracking users online because it is likely to reduce people's choice and control over how their information is collected," and "businesses should not consider fingerprinting a simple solution to the loss of third-party cookies and other cross-site tracking signals." The fair nuance: the ICO treats fingerprinting purely for network management as likely exempt. The tracking purpose is what fails, not the technique in the abstract.
The technical case is just as bad. The largest real-world measurement, 2,067,942 fingerprints collected from a top-15 French website, found only 33.6% were unique: 35.7% on desktop and 18.5% on mobile. The famous 83.6% and 89.4% figures came from self-selected privacy-aware volunteers before 2023, which is why they don't survive a general audience.
Our own data adds the argument nobody else makes. Headless browsers were the largest category of automated traffic on both sites we measured in July 2026: 49% of bot requests on one, 83% on the other. Classification comes from user-agent and behavioral signals, so it is imperfect and some automated traffic is never identified at all. The direction is the point. A headless browser presents a consistent, machine-perfect device signature, which is precisely what fingerprinting keys on. The traffic it identifies most confidently is disproportionately the traffic that was never a person.
What does cookieless tracking get wrong, and in which direction?
Cookieless tracking gets visits right and people approximately right, and every error traces back to a hash input. Our docs name both directions: "several people behind one network (a household or office) on the same browser build collapse into one visitor," and "one person moving from Wi-Fi to cellular, or updating their browser, can look like a new visitor."
| Input | What changes it | Which way the count moves |
|---|---|---|
| Source IP | A household or office behind one NAT | Undercount: several people become one visitor |
| Source IP | Moving from Wi-Fi to cellular mid-session | Overcount: one person becomes two |
| Source IP | A VPN or privacy relay rotating the address | Coarse /24 and /48 bucketing holds it together; relay exit changes may still split it |
| User agent | A browser update rewriting the UA string | Overcount: the identifier forks |
| User agent | A managed fleet on one identical browser build | Undercount: devices become indistinguishable |
Three other limits deserve the same confidence as the benefits. Cross-site tracking: following users across multiple websites becomes impossible without third-party cookies, which is what cross-site tracking is and exactly what browsers set out to break. Granular segmentation: without cookies, certain granular segmentation and precisely targeted ads may suffer, potentially impacting campaign performance. Attribution: attribution of conversions to specific marketing efforts becomes less precise.
One problem no identification strategy fixes: across 48 markets, two in five consumers report using no ad blocker or anti-tracking service, which means roughly three in five use one in some form. That's self-reported installation, not measured blocking, and blocking happens at the request level, before identification matters at all.
Cookieless visitor counts are useful estimates, not exact counts. People on the same network and browser can merge; one person changing networks or browsers can split. identify() gives signed-in products stable cross-device identity. And "nothing is stored on the device" has one documented exception: feature flags keep a persistent browser ID so a visitor stays on the same variant. That's sticky assignment, not a cross-site profile, but browser storage can still affect a consent analysis.
The estimate is consistent even though it isn't exact, which is the part critics miss. Across roughly 1,000 client sites in the TinyAnalytics 2026 portfolio dataset, cookieless identification classified 62–63% of visitors as new in every month from January to July 2026, moving no more than a point and a half between 63.1% in January and 62.2% in July. That portfolio is about 85% B2B SaaS and English-skewed, so it isn't a cross-section of the web, and its July column covers 1–21 July only. Stable enough to trend, not precise enough to count.
Which cookieless tracking tools should you consider?
The useful column isn't the brand promise, it's how each tool actually identifies a visitor. Here it is, filled in.
| Tool | How it identifies a visitor | Writes to the device? | Open source? |
|---|---|---|---|
| TinyAnalytics | SHA-256 of the request IP and user agent, derived server-side into a 12-character ID | No, except feature flags | No, hosted only |
| Plausible | Server-side hash of IP and user agent | No | Yes, and self-hostable |
| Matomo | First-party cookie by default; can be configured to derive the ID from request attributes instead | Yes, by default | Yes, and self-hostable |
| Fathom Analytics | SHA-256 of IP, user agent, hostname and a site-specific salt, rotated every 24 hours | No | Hosted product is closed source |
| Simple Analytics | Cookieless; identification inputs are not published in detail | No | No, hosted only |
| TWIPLA | Website-intelligence platform, formerly Visitor Analytics; offers a cookieless mode with inputs not published in detail | No | No, hosted only |
A few notes the table can't carry.
- TWIPLA is a website-intelligence and analytics platform, not a social-media tool, despite a widely copied claim that says otherwise (including an earlier version of this post).
- Fathom Analytics makes user privacy its prime concern, providing the website metrics you need without tracking personal data. Simple Analytics focuses on simplicity and transparency, delivering primary metrics without cookies.
- Matomo, previously known as Piwik, is an open-source web analytics platform that gives you full control over the data. Its customization depth suits organizations that prioritize data sovereignty. Note that it is cookie-based unless you change that: Matomo's own FAQ says it "uses cookies to store a unique visitor ID," and that with
disableCookies()it "will still be able to determine unique visitors based on IP address and other footprints, but this will be inaccurate." - Plausible is a simple, privacy-focused alternative that does away with cookies. It is open source, EU-hosted, self-hostable, and ships a smaller script than we do at 2.5 KB, per Plausible's own documentation. We put the two side by side in TinyAnalytics vs Plausible.
These tools are not one-size-fits-all, and your requirements should guide the choice. If you need source access or self-hosting, an open-source product is the right answer and we are not it.
How do you move a site to cookieless tracking?
Four steps, and one warning about what your dashboard looks like on day two.
- Record your baseline. Sessions, unique visitors, top sources and conversion rate for the last full month. Without it you'll spend a week arguing about whether traffic dropped.
- Install the script and confirm the first visit. One tag in the document head (ours is under 6.5 KB gzipped), then watch Realtime until your own visit appears. The TinyAnalytics docs cover framework-specific cases. Run both tools in parallel for two weeks.
- Re-check what your consent banner gates. If your analytics stores nothing on the device and sends no personal data, the analytics-cookie section may no longer apply. Confirm that against your own configuration and jurisdiction rather than against a vendor's marketing page.
- Recalibrate what you report. Unique visitors won't match the old number and shouldn't. Sessions, pageviews, sources and conversion rates will land close.
What breaks: cross-device journeys, multi-week user paths, and any dashboard whose headline metric was "users." What doesn't: traffic trends, source and campaign performance, landing pages, session funnels, and anything behind a login.
Frequently asked questions
What exactly is cookieless tracking?
Cookieless tracking is a method of collecting user data and insights without using traditional cookies. The visitor identifier is computed on the server from attributes the request already carries, rather than stored in the browser and read back later. Interest in it comes from stricter privacy rules, browser storage limits and consent refusal, not from Chrome removing third-party cookies, which it did not do.
How does cookieless tracking work?
The tracking script sends a request; the server reads the source IP address and user agent that came with it, filters automated traffic, derives a one-way hash from those attributes, discards the raw IP, and writes the event against the resulting identifier. In TinyAnalytics that hash is SHA-256 and the output is a 12-character cookieless ID. Nothing is read back out of the browser, so there is no value to expire or clear.
What is the difference between cookie and cookieless tracking?
A cookie is a value the site stores on the device and reads back on later visits, which makes the identifier durable but also visible, clearable, and capped by browsers. A cookieless identifier is recomputed server-side on every request, so it survives storage limits but merges people who share a network and browser. Durability versus disclosure: that's the trade.
Does cookieless tracking comply with GDPR?
No tracking method is "GDPR compliant" as a property of the method. Two questions decide it. Under ePrivacy Article 5(3), is storage or access to information on the device engaged, and does an exemption such as France's audience-measurement conditions or the UK's statistical-purposes exception apply? Under GDPR, is the result personal data and do you have a lawful basis? A hash of IP and user agent is pseudonymous, not anonymous, so it usually needs an answer to the second. TinyAnalytics is designed to support privacy-friendly analytics. Your consent and compliance obligations still depend on your jurisdiction, configuration, and the data you choose to send.
How accurate is cookieless tracking?
Accurate on visits and sessions, approximate on people. Pageviews, sessions, sources, landing pages and conversion rates are counted much as a cookie-based tool counts them. Unique visitors are an estimate: a household or office behind one router on the same browser build collapses into one visitor, and one person switching from Wi-Fi to cellular can appear as two. Cookieless visitor counts are useful estimates, not exact counts. For signed-in products, identify() restores stable cross-device identity.
What tools can I use for cookieless tracking?
TinyAnalytics, Plausible, Fathom Analytics, Simple Analytics, Matomo and TWIPLA all offer cookieless measurement, and they don't identify visitors the same way. Compare them on the mechanism, not the marketing: does the tool derive its identifier server-side, write one to the device, or fingerprint the browser? The table above answers that for each.
The bottom line
Cookieless tracking derives the visitor identifier from what the request already carries instead of from what the browser was told to remember. That buys immunity to storage caps and clearing, and it costs precise headcounts, cross-device journeys and long attribution windows. It doesn't buy an exemption from consent law, and it doesn't make fingerprinting acceptable.
To see the trade on your own traffic, TinyAnalytics is one script tag and a generous free plan. Start free.
