Cookieless tracking measures website traffic without storing an identifier on the visitor's device. Instead of reading back a cookie it set earlier, the server derives a short-lived, one-way identifier from request data such as the IP address and user agent. It counts visits and sessions reliably, but counts people only approximately.
Cookieless tracking is web measurement that identifies a visit without writing a cookie, a localStorage entry, or any other value into the browser. The identifier is computed on the server and scoped to a single site, so it cannot follow anyone across the web. It cannot follow anyone across devices either.
This article is about measurement: analytics, sessions and attribution on a site you own, not ad targeting or identity graphs.
![]()
One correction up front, because it changes the whole argument. Chrome never removed third-party cookies. The deadline everyone planned around was cancelled twice, and the replacement technology was cancelled too. Cookieless measurement is still worth doing, just not for the reason you were told.
What actually happened to third-party cookies
Google announced on 22 July 2024 that it would not deprecate third-party cookies in Chrome. The Privacy Sandbox update: "Instead of deprecating third-party cookies, we would introduce a new experience in Chrome that lets people make an informed choice that applies across their web browsing."
Then, on 22 April 2025, Google cancelled that too. The follow-up on next steps for tracking protections in Chrome confirmed it "will not be rolling out a new standalone prompt for third-party cookies." No deprecation, no choice screen, and that's still the position in mid-2026.
The third act is the one almost nobody has covered. On 17 October 2025 Google retired most of the Privacy Sandbox, citing "low levels of adoption." Attribution Reporting, Topics, Protected Audience, Shared Storage and IP Protection were all shelved; only CHIPS, FedCM and Private State Tokens continue. The Chromium ticket is blunt about the code: "Deprecate in M144 and then remove in M150," per the intent to deprecate the Topics API. Chrome 150 ships in July 2026. The six-year effort to build a cookie replacement is being deleted from the browser this month.
So the cookiepocalypse never happened. What did happen is that the other two rendering engines moved on without Chrome.
| Browser | Third-party cookies | Cookies written by JavaScript | What that means for your reports |
|---|---|---|---|
| Chrome (~69.5% of use) | Allowed by default; deprecation cancelled 2024, prompt cancelled 2025 | No restriction | Cookie analytics still works, subject to consent and ad blockers |
| Safari (~15.3%) | Blocked outright since March 2020 | Capped at 7 days, or 24 hours after a link-decorated arrival | A returning visitor after 8 days is counted as brand new |
| Firefox (~3.4%) | Partitioned per site since June 2022 | Allowed, but isolated to the site that set them | Cross-site identity is already dead here |
| Edge and other Chromium browsers | Chromium defaults | No restriction | Behaves like Chrome |
WebKit put Safari's position in one line when it shipped full third-party cookie blocking in March 2020: "Cookies for cross-site resources are now blocked by default across the board." Firefox partitioned instead. Total Cookie Protection, default since June 2022, "works by creating a separate 'cookie jar' for each website you visit."
So why bother? The two costs that pushed people toward cookieless were never about Chrome. A banner that follows the law rather than nudging past it loses an average of 60% of visit data, according to etracker's 2025 cookie consent benchmark, and Safari breaks first-party cookie analytics on its own. That's a data-quality argument, and it survives every reversal Google makes.
What cookieless tracking is (and what it is not)
Start with the thing the term is defined against. A cookie is a small named value a browser stores for a domain and sends back on later requests to it. First-party or third-party depends on who set it relative to the page you're looking at.
- A first-party cookie is set by the site in the address bar. You're on
example.com,example.comsets a session cookie: first-party. - A third-party cookie is set by another domain embedded in that page. The same ad network on a thousand sites reads the same cookie on all of them, which is how one identity gets stitched across the web. That's what cross-site tracking is, and the thing browsers actually went after.
Cookieless tracking means the measurement never depends on a value read back out of the browser. The identifier is computed per request on the server, so there's nothing to expire, nothing to clear, and nothing to consent to storing.
Three things it's routinely confused with:
- Cookieless is not server-side. Server-side tracking moves collection to your own endpoint instead of a third-party script. Good idea for other reasons, and entirely compatible with setting cookies: plenty of server-side setups set a first-party cookie on the way through.
- Cookieless is not consent-free. European law is written around storing or reading information on a device, not around the word "cookie." More below, because it's where most vendor copy goes wrong.
- Cookieless is not fingerprinting. Device fingerprinting builds a stable identifier from screen size, fonts, canvas rendering, hardware and dozens of other signals. It replaces the cookie with something a user cannot see, clear or opt out of. That's a step backwards for privacy, not a privacy-enhancing technology, and regulators treat it as in scope for consent. TinyAnalytics doesn't rely on it, and I'd be sceptical of any tool selling it as a privacy feature.
How cookieless visitor counting actually works
I've spent most of the last decade on front-end teams at Microsoft, and I co-founded TinyAnalytics, so this is the part I can speak to first-hand: what a cookieless identifier is made of, and what each choice costs you.
The shape is the same everywhere I've looked at it. A request arrives, the server hashes a handful of values it already has, and the output becomes the visitor key for that window. Nothing goes back to the browser. The inputs commonly include the IP address, the user agent, the hostname, and a site identifier so that two sites never produce the same key for one person. Beyond that the implementations diverge, and the divergence matters.
Where they diverge most is identifier lifetime: how long one person keeps the same key, and what resets it. Some vendors mix a rotating secret into the hash, which caps that lifetime — rotate it, destroy the old value, and yesterday's identifiers can't be recomputed or linked to today's. Others rely on the inputs themselves changing. Either way, the question to ask a vendor is not "do you use cookies" but where that dial is set, because it decides both how private the identifier is and how much returning-visitor accuracy you are giving up.
Two vendors publish theirs, which makes the pattern verifiable rather than something to take on faith. PostHog documents its formula as a server-side hash of team ID, a daily salt, IP, user agent and hostname, with the salt deleted once that day's events are processed. Siteimprove documents a Visitor Hash built from a hashed IP plus headers including browser type, version and language, with IPs "immediately truncated and hashed."
In TinyAnalytics the identifier is derived server-side and scoped to a single site. Our documentation describes it as a SHA-256 hash of the request IP address and the user agent, producing a 12-character cookieless ID, with VPN and privacy-relay traffic derived from a coarse network bucket — a /24 block for IPv4, /48 for IPv6 — rather than the exact address. Raw IPs aren't retained: the IP is an input to the identifier and a source for coarse location, then it's discarded. There's no shared identity graph across customers, so a visitor on one tracked site isn't linkable to the same visitor on another. Nothing is written to the device for analytics, so there's no analytics cookie to consent to, expire or clear. The script is under 6.5 KB gzipped.
One documented exception, because "nothing stored on the device" has to be exact: feature flags keep a persistent browser ID so a visitor stays on the same variant between visits. That's sticky assignment, not a cross-site profile, but browser storage can still affect a consent analysis.
The cookieless methods, compared
Not everything sold as "cookieless" behaves the same way. A companion post walks through the cookieless tracking methods individually.
| Method | Likely in scope of ePrivacy Art 5(3)? | Writes to the device? | Survives Safari ITP and ad blockers? | Works across sessions? | Works across devices? |
|---|---|---|---|---|---|
| Server-derived one-way identifier | Often — see note | No | Yes for ITP; ad blockers can still block the script | Within the salt window only | No |
| First-party cookie set by JavaScript | Yes | Yes | No — capped at 7 days, 24 hours after a UTM arrival | Yes, until the cap | No |
| localStorage / sessionStorage / IndexedDB | Yes | Yes | No — cleared on the same 7-day rule | Yes, until cleared | No |
| Server-side collection endpoint | Depends what it reads back | Only if it also sets a cookie | Better against blockers; ITP still applies to any cookie it sets | Depends on the identifier used | No |
| Device fingerprinting | Yes, and treated as high-risk | No, but that's the problem | Often yes, which is why it persists | Yes | Sometimes |
| Contextual and probabilistic modelling | No | No | Yes | Aggregate only | Aggregate only |
Authenticated ID (login, identify()) |
Yes, plus a GDPR legal basis | Usually a session cookie | Yes | Yes | Yes |
"Often" in the first row isn't a dodge: EU regulators have said an identifier derived from an IP address can fall under the consent rule unless the provider can show the IP didn't come from the user's device. The localStorage row surprises people. Swapping a cookie for localStorage buys nothing on Safari, because WebKit deletes all script-writable storage after seven days without user interaction, and nothing legally either, because the rule is about storage rather than cookies.
Cookieless does not mean consent-free
This is the correction that matters most.
The European rule is Article 5(3) of the ePrivacy Directive, written around storing information on, or gaining access to information stored in, a user's terminal equipment. The word "cookie" doesn't appear in the operative test. The EDPB made that explicit in Guidelines 2/2023 on the technical scope of Article 5(3), final on 7 October 2024: "Article 5(3) ePD does not exclusively apply to cookies, but also to 'similar technologies'."
Three consequences that break common vendor claims:
- Pixels and tracking links are in scope. The guidelines treat collecting identifiers through a tracking pixel or a decorated URL as "gaining of access" to information on the device. Moving collection server-side doesn't by itself move you outside the rule.
- IP-only tracking is not a loophole. The EDPB: "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."
- localStorage, IndexedDB and the data layer are storage. Same rule, same analysis.
What does get you an exemption is narrower than "we don't use cookies." France's CNIL sets the conditions out in Sheet n°16 on analytics for websites and applications: limited to audience measurement and A/B testing, not cross-referenced with other processing, scoped to one site or app publisher, last byte of the IP truncated, expiry within 13 months. Those conditions are cumulative. Meeting five of six is not meeting them.
![]()
California works differently. The CCPA, as amended by the CPRA, runs on notice and opt-out rather than prior consent, and its regulations require businesses to honour opt-out preference signals sent by a browser. A setup that satisfies CNIL is usually comfortable under CCPA; the reverse isn't true. We've mapped GDPR, CCPA and PECR side by side separately.
The older story that cookie-based analytics is simply illegal in Europe is out of date, and repeating it is a credibility problem rather than a selling point. The 2022 decisions did happen. Austria's authority found a site using Google Analytics "has therefore not ensured an adequate level of protection in accordance with Article 44 of the GDPR" in a decision published through the EDPB, and Italy's Garante reached a similar conclusion on Articles 44 and 46 in its provvedimento of 9 June 2022, holding a truncated IP to be personal data. Both rested on the absence of a US adequacy decision, which the EU adopted in July 2023 and the General Court upheld on 3 September 2025, confirming per the Court's press release that "the United States of America ensured an adequate level of protection." An appeal is pending. The transfer gap is closed for now; the consent question underneath it never went away.
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.
First-party data and privacy
First-party data refers to information collected directly from users through their interactions with a brand's own channels—such as website visits, purchases, and customer feedback. Sourced directly from users, this data is not only reliable and accurate but also ethical, as it is gathered with users' express consent.
Two things make it the stable foundation in 2026, and neither is the Chrome deadline. It doesn't depend on cross-site identity, which Safari and Firefox already killed and no browser is bringing back. And you collect it as a by-product of running the site rather than buying it.
Key reasons for the growing importance of first-party data
- Reliability and accuracy: First-party data, sourced directly from users, is more trustworthy than third-party data which bases itself on external sources.
- Cost-effective: Gathering first-party data can be more economical than relying on third-party data sources.
- Enhanced customer relationships: The utilization of first-party data can build stronger connections with consumers, as it allows brands to tailor experiences based on individual preferences and behaviors.
What it doesn't do is solve the counting problem. A rotating identifier is still rotating whether or not you also run a CRM. First-party data gives you a stronger identity layer for the people who choose to sign in, which is a different thing from measuring everyone who visits.
The honest caveat: "first-party" describes where data came from, not whether you're allowed to collect it. First-party cookies are still storage under Article 5(3). Two sites can both run first-party analytics and land in different places legally, depending on what they send and where it goes.
One more distinction. Compliant banners lose data because they're honest, not because they're badly built: etracker found they record about 14 percentage points less consent than banners using manipulative nudging. A high consent rate is more often evidence of a pushy banner than a trusted brand.
What cookieless tracking cannot tell you
Most pages on this topic claim cookieless measurement improves data accuracy. It doesn't. It trades one set of errors for another, and you should pick it with the trade in front of you.
Each failure mode, with its cause:
- Distinct people merge into one. Everyone behind the same corporate NAT, VPN exit node, university network or office router shares an IP. On the same browser version, a hashed identifier can't tell them apart, so a B2B site with large enterprise accounts undercounts and can't tell by how much.
- One person splits into several. Move from office wifi to mobile data, or update the browser mid-week, and the hash changes. Same human, two entries.
- Attribution breaks at the salt boundary. When the rotating secret is destroyed, Monday's identifier can't be matched to Friday's. You keep the sessions and lose the thread between them. Not a bug: reversibility is what rotation exists to prevent.
- There is no cross-device join. Phone at breakfast, laptop at work, tablet in the evening: three visitors, with no way to know otherwise without a login.
- Ad blockers still apply. Cookieless doesn't mean unblockable. Blocking happens at the script or request level, before any of this matters.
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. For signed-in products, identify() gives stable cross-device identity by letting you pass your own user ID.
Cookieless attribution: what still works
Attribution is where this gets interesting, because the answer isn't "you lose it." It's "you switch models."
Deterministic attribution links a conversion to specific identified touchpoints: this person clicked this ad, then this email, then bought. It needs a persistent identifier across the whole window, which a cookieless setup doesn't have beyond its salt boundary.
Unlike deterministic tracking which leans on direct user interactions and identifiable data, probabilistic tracking uses statistical models to estimate the likelihood of different touchpoints influencing a conversion. This approach comes particularly handy in environments where direct tracking is limited or unviable, such as mobile marketing.
![]()
Key features of probabilistic tracking
- Data analysis and pattern recognition: Probabilistic tracking uses extensive data analysis to identify user behavior patterns, enabling marketers to estimate which interactions may have led to conversions.
- Flexibility in attribution: Probabilistic tracking offers a dynamic solution for marketers seeking to understand, and in turn optimize their campaigns without needing to directly link them to individual user actions.
- Privacy compliance: Relying majorly on aggregated data without involving individual identifiers makes probabilistic tracking better aligned with privacy norms such as GDPR and CCPA.
Benefits of adopting probabilistic tracking methods
- Continuous improvement: As probabilistic methods are based on ongoing data collection and analysis, the accuracy of inferences continually improves over time.
- Graceful degradation: Deterministic models fail hard when the identifier breaks; probabilistic ones lose precision gradually, which suits the conditions cookieless creates.
- Adaptability in changing environments: With privacy regulations intensifying and traditional tracking methods becoming less relevant, probabilistic tracking offers a necessary alternative for marketers to continue producing actionable insights without compromising on user privacy.
The catch is that the output is an estimate with a confidence interval, presented in most tools as a single number. If you're allocating a large paid budget on it, know the model's assumptions. Most teams do fine with something simpler: single-session funnel analysis on first-touch source, deterministic within the session and not pretending to more precision than it has.
When cookie-based or logged-in tracking is the better choice
I'd rather say this here than have you find out after switching.
Consented cookie-based measurement wins when your main question is 90-day multi-touch attribution across devices for a large paid budget. A consented first-party cookie, or a server-side setup behind a consent gate, gives a longer and more coherent journey than any cookieless identifier can. You measure fewer people, but you measure them properly. The Safari caveat still bites, so this means server-set cookies.
An authenticated identity model wins when most of your value happens behind a login. Passing a stable user ID through identify() gives accurate cross-device, long-window identity in a way a cookieless identifier structurally cannot. That's a bridge across the limitation, not a denial that it exists, and it only covers people who signed in.
GA4 wins when you're spending heavily in Google Ads and need the native integration, or want Consent Mode v2 with conversion modelling to fill gaps from denied consent. Nothing cookieless replicates that. If your complaint about GA4 is reporting lag rather than privacy, GA4 data delay is a different problem with a different fix.
An open-source tool wins when you need source access or self-hosting. TinyAnalytics is closed-source and hosted-only, so that rules us out. Plausible is open source, EU-hosted, self-hostable, and ships a smaller script than we do at 2.5 KB. Umami is open source and self-hostable too. Both are written up head-to-head in TinyAnalytics vs Plausible and TinyAnalytics vs Umami.
How to move a site to cookieless measurement
Four steps, and a warning about what your dashboard looks like on day two.
- Record your baseline first. 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, then watch Realtime until your own visit appears; the TinyAnalytics docs cover framework-specific cases. Run both tools side by side for two weeks.
- Re-check what your banner needs to gate. 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.
- Recalibrate what you report. Unique visitors won't match the old number and shouldn't. Sessions, pages, sources and conversion rates will be close.
What breaks: cross-device journeys, multi-week user paths, and any dashboard whose headline number was "users." What doesn't: traffic trends, source and campaign performance, landing pages, session funnels, and anything behind a login.
Frequently asked questions
1. Does cookieless tracking require consent?
Sometimes, and "we don't use cookies" isn't the test. Article 5(3) of the ePrivacy Directive covers storing or accessing any information on a device, and EDPB Guidelines 2/2023 confirm it reaches pixels, local storage, URL tracking, fingerprinting and IP-derived identifiers. A setup that stores nothing on the device has an easier path to the analytics exemption, and CNIL Sheet n°16 lists the conditions. Your obligations still depend on your jurisdiction and configuration.
2. How accurate is cookieless tracking?
Accurate on visits and sessions, approximate on people. Pageviews, sessions, sources, landing pages and conversion rates are counted the way a cookie-based tool counts them. Unique visitors are an estimate: people sharing an IP and browser can merge, and one person switching network or browser can split in two. Treat the trend as reliable and the headcount as directional.
3. What is cookieless tracking?
Cookieless tracking refers to methods of tracking user behavior online without relying on traditional third-party cookies. This approach utilizes first-party data, privacy-enhancing technologies, and probabilistic tracking methods to gather insights about user interactions while respecting their privacy. Rather than setting a cookie, the server derives a one-way identifier from request data and scopes it to a single site.
4. Did Google actually get rid of third-party cookies in Chrome?
No. Google cancelled the deprecation in July 2024, cancelled the replacement choice prompt in April 2025, and retired most Privacy Sandbox technologies in October 2025. Chrome allows third-party cookies by default in 2026. Safari has blocked them since 2020 and Firefox partitions them per site, so cross-site identity is dead in those browsers regardless.
5. Why is first-party data important in a cookieless world?
First-party data matters because it is collected directly from users through their interactions with a brand's own channels, such as websites and apps. This type of data is more reliable and accurate than third-party data, and it allows marketers to create personalized experiences while ensuring compliance with privacy regulations. It still needs a legal basis: first-party doesn't mean consent-exempt.
6. How can businesses ensure compliance with data privacy regulations like GDPR and CCPA?
To ensure compliance with regulations like GDPR and CCPA, businesses should:
- Obtain explicit consent from users before collecting their data.
- Implement privacy-enhancing technologies that facilitate ethical data collection.
- Clearly communicate how user data will be used and provide options for users to manage their preferences.
The two regimes ask different questions, though. Under GDPR and ePrivacy, work out whether your setup stores or accesses anything on the device, and check the CNIL exemption conditions if you think you're exempt. Under CCPA and CPRA, focus on notice at collection, opt-out of sale or sharing, and honouring browser opt-out signals.
7. What are privacy-enhancing technologies (PETs)?
Privacy-enhancing technologies (PETs) are tools and methods that allow businesses to track user behavior while minimizing the collection of personal information. PETs help ensure compliance with privacy regulations by anonymizing data, managing user consent, and utilizing server-side tracking techniques. Device fingerprinting is often listed among them and doesn't belong there: it produces a durable identifier from device characteristics a user can't see or reset, which is a stronger form of tracking than the cookie it replaces.
8. How does probabilistic tracking work?
Probabilistic tracking uses statistical models to estimate the likelihood that various touchpoints influenced a conversion. Instead of relying on direct user identifiers, it analyzes patterns in aggregated data to infer which interactions may have led to desired outcomes, making it an effective method in a cookieless environment.
9. How can brands build trust with consumers regarding data privacy?
Brands can build trust by:
- Being transparent about their data collection practices.
- Clearly explaining how consumer data will be used.
- Demonstrating a commitment to protecting consumer privacy through ethical practices.
Publish specifics rather than adjectives: name the fields, the retention period, the subprocessors. Avoid banner designs that make rejecting harder than accepting, and don't claim a compliance guarantee you can't evidence.
10. What are the benefits of adopting ethical analytics?
Adopting ethical analytics provides several benefits, including:
- Enhanced customer loyalty due to increased trust.
- Improved engagement through personalized experiences based on first-party data.
- Compliance with evolving privacy regulations, reducing the risk of penalties.
- A competitive advantage in the marketplace by appealing to consumers who prioritize ethical practices.
11. Does server-side tracking avoid consent requirements?
No. Server-side collection changes where the request is processed, not whether information was read from the device. EDPB Guidelines 2/2023 treat collecting identifiers through pixels and tracking links as gaining access to information on the terminal equipment. Server-side setups also frequently set a first-party cookie, which puts them back under the storage rule.
12. What should marketers focus on moving forward in a cookieless world?
Marketers should focus on:
- Investing in first-party data collection strategies.
- Embracing privacy-enhancing technologies for ethical tracking.
- Communicating transparently with consumers about data usage.
- Measuring what your consent rate and Safari's storage caps already cost you, rather than planning around a deprecation that isn't coming.
Key takeaways
- Emphasis on first-party data: The growing importance of first-party data cannot be overstated. It allows marketers to create personalized experiences while respecting user privacy, ultimately building stronger customer relationships.
- Adoption of privacy-enhancing technologies: Implementing PETs enables businesses to track user behavior ethically and comply with regulations like GDPR and CCPA. This not only protects consumers but also enhances brand reputation.
- Engagement through transparency: Consumers are increasingly seeking brands that prioritize data privacy. By being transparent about data collection practices, businesses can build trust and loyalty among their audience.
- Privacy-friendly practices: Cookieless tracking promotes user privacy by desisting from collecting sensitive data like names or email addresses.
- Honest reporting: Cookieless visitor counts are useful estimates, not exact counts. State that limit wherever the number appears.
Recommendations for businesses
- Invest in ethical data practices: Companies should prioritize ethical data collection methods that respect consumer privacy. This includes being transparent about how data is collected, used, and shared.
- Use technology for compliance: Adopting privacy-enhancing technologies is a practical route through data privacy obligations while still gathering the measurement you need.
- Focus on building trust: Brands should actively communicate their commitment to protecting consumer data. This transparency will not only enhance customer loyalty but also differentiate them in a competitive marketplace.
Where this leaves you
The deadline stories were wrong. Third-party cookies are still in Chrome, the Privacy Sandbox meant to replace them is being deleted from the browser this month, and any article still opening with "as third-party cookies are phased out" hasn't checked since 2024.
The case for cookieless measurement survived all of it on different ground. Safari caps script-written cookies at seven days, or 24 hours after a UTM-tagged arrival, so first-party cookie analytics is already degrading for a sixth of the web. Compliant consent banners cost an average of 60% of visit data. Against that, a server-derived identifier gets you near-complete coverage of visits, sessions and sources, and asks you to give up precise headcounts and cross-device journeys. That's the trade: good for most sites, bad for a few, and worth naming either way.
If you want to see it on your own traffic, TinyAnalytics is one script tag and a generous free plan. 95% of TinyAnalytics customers use the Free plan. Start free.

