Cookieless Analytics: How It Works and Why You Need It

Every cookie consent banner on the internet exists because of a simple fact: if your website sets cookies, EU law requires you to ask permission first. And when you ask permission, 30-50% of visitors say no.

That means cookie-based analytics tools — including Google Analytics 4 — systematically undercount your traffic by a third or more. The data you base your marketing decisions on is structurally incomplete.

Cookieless analytics solves this. No cookies, no consent banner, no data loss. But how does it actually work? And what are the trade-offs?

What cookies do in traditional analytics

Before we can understand cookieless tracking, we need to understand what cookies actually do in analytics.

Traditional analytics tools like Google Analytics set two main cookies:

1. A visitor identifier cookie (e.g., _ga) — a unique ID stored in the visitor's browser that persists across sessions. This is how GA knows that the person visiting today is the same person who visited last week. The _ga cookie lasts 2 years.

2. A session cookie (e.g., _ga_<container>) — tracks the current browsing session. It expires after 30 minutes of inactivity.

These cookies enable two critical analytics features:

• Unique visitor counting — without a persistent identifier, the analytics tool cannot distinguish between one person visiting 10 times and 10 different people visiting once.
• Multi-session attribution — if someone clicks a Google ad on Monday and buys your product on Thursday, the cookie connects those two events so you can attribute the sale to the ad.

The problem is that the ePrivacy Directive (and GDPR, when cookies contain personal data) classifies these as non-essential cookies. You cannot set them without informed consent. And informed consent requires a cookie banner.

How cookieless analytics works

Cookieless analytics tools replace cookies with a combination of techniques. The most common approach — and the one used by DataSaaS, Plausible, Fathom, and most privacy-focused tools — is daily-rotating hash-based identification.

The hashing approach

Here is how it works, step by step:

1. Collect non-identifying signals. When a visitor loads a page, the analytics server receives several pieces of information that are naturally part of any HTTP request: the visitor's IP address, their User-Agent string (browser and OS), and the website's domain.

2. Combine with a daily salt. The server generates a random salt value that rotates every 24 hours. This salt is never stored — when it rotates, there is no way to regenerate it.

3. Hash everything together. The server creates a SHA-256 hash of: IP address + User-Agent + website domain + daily salt. This produces a fixed-length string like a3f2b8c1d4e5... that uniquely identifies a visitor for that day only.

4. Use the hash as a daily visitor ID. All pageviews from the same IP + User-Agent combination on the same day get grouped under the same hash. This enables accurate unique visitor counting within a single day.

5. The salt rotates at midnight. When the daily salt changes, the same IP + User-Agent combination produces a completely different hash. Yesterday's visitor cannot be linked to today's visitor. There is no persistent identifier.

Here is a simplified representation of the process:

visitor_hash = SHA-256(
  ip_address +
  user_agent +
  website_domain +
  daily_salt
)

# Same inputs + same salt = same hash (within 1 day)
# Same inputs + different salt = different hash (cross-day)

Why this is not a cookie

A cookie stores data in the visitor's browser. The hash approach stores nothing on the client side. The identification happens entirely on the server, using data that the visitor's browser already sends with every HTTP request.

This distinction matters legally. The ePrivacy Directive specifically regulates "the storing of information, or the gaining of access to information already stored, in the terminal equipment." A server-side hash of data that was already transmitted as part of the HTTP request does not meet this definition.

Why this is not personal data

Under GDPR, IP addresses are considered personal data. But the hash is a one-way function — you cannot reverse a SHA-256 hash to recover the original IP address. The daily salt ensures that even if an attacker obtains the hash, they cannot use it to track a visitor across days.

The raw IP address is processed in memory to compute the hash, but it is never stored. The analytics database only contains the hash, the page URL, the referrer, and other non-identifying metadata.

Accuracy: how close is it to cookie-based tracking?

Cookieless analytics is not a perfect replacement for cookies. There are accuracy trade-offs, and understanding them helps you decide whether they matter for your use case.

What cookieless tracking does well

Daily unique visitor counts are highly accurate. Within a single day, the hash-based approach correctly identifies unique visitors with the same accuracy as cookies. If someone visits your site five times in one day, they count as one unique visitor.

Pageview counts are identical. Every pageview is recorded regardless of the identification method. Cookieless tracking does not miss pageviews.

Traffic source attribution is accurate for same-session visits. If someone clicks a link from Twitter and arrives on your site, the referrer is captured in the HTTP request. No cookie needed.

Where cookieless tracking loses accuracy

Multi-day unique visitor counts are overcounted. Because the daily salt rotates, a visitor who comes on Monday and Tuesday is counted as two unique visitors. Cookie-based tools would count them as one. In practice, this means your monthly unique visitor count will be 10-20% higher than cookie-based tools would report. This overcount is consistent, so trends are still accurate — you just need to interpret absolute numbers accordingly.

Multi-session attribution is impossible. If a visitor discovers your site through organic search on Monday, returns directly on Wednesday, and buys on Friday — cookieless analytics cannot connect those three sessions. It sees three different visitors. Cookie-based tools (when the visitor accepts cookies) would see one visitor with a three-session journey.

IP address changes break identification. If a visitor switches from Wi-Fi to mobile data, their IP address changes. Within a single day, they would be counted as two visitors. This is an edge case but worth noting.

Shared IP addresses cause undercounting. Corporate networks and university campuses often route hundreds of users through a single IP address. If two people on the same network use the same browser, they produce the same hash and get counted as one visitor. This is the opposite of the overcounting problem — and in practice, the two effects partially cancel each other out.

How significant are these accuracy differences?

To put numbers on it: a website with 10,000 true monthly unique visitors might report approximately 11,500 unique visitors with cookieless tracking (a 15% overcount due to daily salt rotation). The same website using GA4 with a cookie consent banner in the EU might report 5,500-7,000 unique visitors (a 30-45% undercount due to consent rejection and ad blockers).

The cookieless report is closer to reality. More importantly, the overcounting bias is consistent — it does not distort comparisons between traffic sources, pages, or time periods. A 15% overcount applied uniformly to all data preserves the relative relationships that matter for decision-making.

The consent banner trade-off

Here is the key insight: the accuracy loss from cookieless tracking is far smaller than the accuracy loss from cookie consent rejection.

• Cookieless tracking overcounts unique visitors by ~15%.
• Cookie consent rejection undercounts all metrics by 30-50%.

A 15% overcount in unique visitors is a known, consistent bias that you can mentally adjust for. A 30-50% undercount in all your data — pageviews, traffic sources, conversions, everything — is a systematic blind spot that distorts every decision you make.

For most websites, cookieless tracking with no consent banner produces significantly more useful data than cookie-based tracking with a consent banner.

Legal compliance: GDPR, ePrivacy, and beyond

Cookieless analytics does not automatically make you GDPR-compliant. But it eliminates the most common compliance headaches.

ePrivacy Directive (cookie law)

The ePrivacy Directive requires consent before storing or accessing information on a user's device. Cookieless analytics does not store anything on the user's device, so the consent requirement does not apply. No banner needed.

GDPR

GDPR regulates the processing of personal data. Cookieless analytics tools that hash IP addresses (rather than storing them) generally avoid processing personal data altogether. The hash is a one-way function that cannot be reversed to identify an individual.

However, GDPR compliance depends on the full picture:

• Data transfers. If the analytics server is in the US, the EU-US Data Privacy Framework applies. Tools hosted entirely in the EU avoid this complexity.
• Data retention. Even hashed data should have a defined retention period.
• Legal basis. Most privacy-focused analytics tools rely on "legitimate interest" as their legal basis, which is valid when no personal data is processed and the intrusion on user privacy is minimal.

CCPA (California)

The CCPA applies to businesses that collect personal information of California residents. If your analytics tool does not store IP addresses or set cookies, it generally does not trigger CCPA obligations.

nFADP (Switzerland)

Switzerland's new Federal Act on Data Protection (nFADP) aligns closely with GDPR. Cookieless analytics that avoids personal data processing is generally compliant.

Practical advice

No analytics tool can guarantee legal compliance on its own — compliance depends on your full data processing landscape. But cookieless analytics removes the most common legal trigger (cookies) and the most common compliance burden (consent management). For most small to mid-size websites, this is sufficient.

If you operate in a heavily regulated industry (healthcare, finance, government), consult a data protection specialist regardless of which analytics tool you use.

Data Protection Authority decisions

Several EU Data Protection Authorities have issued opinions relevant to cookieless analytics. The French CNIL has published guidance stating that audience measurement tools that do not track users across sites and do not share data with third parties can operate under a "legitimate interest" basis without consent — provided they meet specific criteria including data minimization and limited retention. The Austrian DSB and Italian Garante have issued rulings against Google Analytics specifically, further incentivizing the switch to privacy-first alternatives.

These regulatory decisions reinforce the legal advantage of cookieless tools, though they should not be treated as blanket legal advice for your specific situation.

Which tools offer cookieless tracking?

Not every analytics tool that claims to be "privacy-friendly" is actually cookieless. Here is a breakdown:

Fully cookieless (no consent banner needed)

• DataSaaS — Daily-rotating hash, no cookies, no personal data stored. Also offers native revenue attribution, which is unique among cookieless tools.
• Plausible — Daily-rotating hash, open source, well-documented privacy approach.
• Fathom — Cookieless with EU data isolation option.
• Simple Analytics — Cookieless, minimal data collection.
• Umami — Cookieless, open source, self-hosted option.
• Pirsch — Cookieless, server-side tracking option.
• GoatCounter — Cookieless, works without JavaScript.

Partially cookieless (configurable)

• Matomo — Can be configured for cookieless tracking, but cookies are enabled by default. Cookieless mode disables some features (returning visitor identification, cross-session attribution).

Cookie-based (consent banner required)

• Google Analytics 4 — Sets multiple cookies including _ga (2-year expiry). Requires consent banner in the EU.
• PostHog — Uses cookies for user identification. Requires consent banner.
• Clicky — Uses cookies. Requires consent banner.
• Mixpanel, Amplitude, Heap — Cookie-based product analytics tools. Require consent banners.

Setting up cookieless analytics

If you are switching from Google Analytics to a cookieless tool, the process is straightforward:

1. Remove your existing analytics script and cookie consent banner. If GA4 was your only reason for the consent banner, you can remove it entirely. If other tools on your site also set cookies (chat widgets, ad pixels), you still need the banner for those.

2. Add the cookieless analytics script. For DataSaaS, this is a single script tag:

<script
  defer
  data-website-id="your-website-id"
  src="https://datasaas.co/js/script.js"
></script>

3. Verify data is flowing. Visit your site, then check your analytics dashboard. Pageviews should appear within seconds for most tools.

4. Set up goals and events. Most cookieless tools support custom events for tracking signups, purchases, and other conversions.

5. Connect your payment provider (if applicable). If your analytics tool supports revenue tracking, connect Stripe or your payment provider to start seeing Revenue Per Visitor data.

The entire switch typically takes under 10 minutes. You lose historical data from your old tool, but you gain accurate data going forward.

The future of cookieless tracking

The trend toward cookieless analytics is accelerating. Google has repeatedly delayed and ultimately scaled back its plans to deprecate third-party cookies in Chrome, but the direction of travel is clear: the industry is moving away from cookie-based tracking.

Several developments are shaping the future:

• Server-side tracking is becoming more common. Instead of running a JavaScript tracking script in the browser, some tools offer server-side tracking that runs on your backend. This avoids both cookies and ad blockers.
• First-party data is becoming more valuable. As third-party cookies disappear, businesses that own their customer data (through direct relationships, email lists, and authenticated sessions) have a significant advantage.
• Privacy regulations continue to expand. The EU's ePrivacy Regulation (the successor to the ePrivacy Directive) will further tighten rules around tracking. Cookieless tools are better positioned for whatever comes next.

For website owners, the practical takeaway is straightforward: if you are still using cookie-based analytics, you are fighting against the regulatory current. Switching to cookieless analytics now means you will not have to scramble when the rules tighten again.

Cookieless analytics and revenue tracking

One concern teams have about cookieless analytics is whether it can support revenue attribution. If you cannot identify visitors across sessions, how can you attribute a purchase to the marketing channel that originally brought the visitor?

The answer depends on the tool. Most cookieless analytics tools do not offer revenue tracking at all — they focus purely on traffic data.

DataSaaS solves this by matching revenue data at the payment provider level rather than relying on cross-session visitor tracking. When a Stripe payment comes in, DataSaaS matches the customer's email to the session history, connecting the purchase to the original traffic source. This approach works even without cookies because the matching happens through the payment provider's data, not through browser-side identification.

The result is Revenue Per Visitor data — broken down by traffic source, landing page, country, and campaign — without requiring cookies or consent banners. This is currently unique among cookieless analytics tools.

---

Related reading:

• Cookieless Tracking in DataSaaS — how our implementation works
• DataSaaS vs Google Analytics — cookieless vs cookie-based analytics compared
• Revenue Per Visitor: The Metric Your Analytics Is Missing — combining cookieless tracking with revenue data
• 11 Best Google Analytics Alternatives in 2026 — the full market overview