# Cookieless analytics: options, trade-offs and consent

> Cookieless analytics options compared, from server logs to daily hashes and fingerprinting, with trade-offs and why cookieless isn't automatically consent-free.

Source: https://www.cookiesh.eu/blog/cookieless-analytics  
Published: 2026-09-29

## Key takeaways

- Cookieless analytics measures traffic without setting cookies, but that alone does not make it exempt from consent.
- The ePrivacy Directive covers storing and accessing any information on a device, including local storage and fingerprinting, not only cookies.
- Server log analysis and aggregate, identifier-free counting carry the lowest privacy risk, at the cost of returning-visitor and attribution data.
- Hashed IP addresses and user agents are pseudonymized personal data under GDPR, not anonymous data.
- Some national regulators allow narrow consent exemptions for audience measurement, so check local guidance before dropping the banner for analytics.

Cookieless analytics measures website traffic without cookies, using server logs, identifier-free page view counts, short-lived hashes or aggregate pings instead. It usually collects less personal data, and in some countries it can qualify for narrow consent exemptions. But it is not consent-free by default: the ePrivacy Directive covers storing or accessing any information on a device, which includes local storage and fingerprinting.

## What is cookieless analytics?

It is any measurement approach that does not rely on a persistent cookie to recognize a browser across visits. What replaces the cookie varies widely, from nothing at all to a short-lived hash or another storage mechanism, and that choice decides both data quality and legal position.

Classic analytics sets a first-party cookie holding a random client ID that lasts for months; see [types of cookies](/blog/types-of-cookies). That ID links page views into sessions, sessions into returning users and users into campaigns. Remove it and you lose the link between visits. "Cookieless" describes a technique, not a compliance status.

## What are the main cookieless analytics options?

Six approaches are common, with very different privacy and accuracy profiles.

| Approach | How visitors are recognized | What you get | Main drawback |
| --- | --- | --- | --- |
| Server or CDN log analysis | Not at all, or by IP address and user agent in logs | Requests, pages, referrers, errors; no client script | Misses cached pages and client-side events; bots are harder to filter |
| Aggregate page view counting | Not recognized | Page views, referrers, campaigns, device type | No unique visitors, sessions or cross-visit funnels |
| Daily rotating hash | Hash of IP, user agent and a salt replaced daily | Approximate daily unique visitors and sessions | No returning visitors across days; still personal data |
| Browser storage IDs | ID kept in local storage or IndexedDB | Close to cookie-based detail | Not cookieless in legal terms; same consent rules as cookies |
| Fingerprinting | Combined device and browser characteristics | Recognition without storing anything | Needs consent; hard for people to see or control |
| Cookieless pings (Google consent mode, advanced) | No cookies while consent is denied | Modeled conversions and trends | Legal position debated; modeling happens on the vendor's side |

On the last row: in Google's advanced consent mode setup, tags send cookieless pings when consent is denied, and Google uses modeling to fill the gaps. Whether that is acceptable without consent is debated; see [basic vs. advanced consent mode](/blog/basic-vs-advanced-consent-mode).

## Does cookieless analytics need consent?

Sometimes, and dropping cookies does not settle the question. Article 5(3) of the ePrivacy Directive covers both storing information on a device and gaining access to information already stored there, whatever the technology. Consent is required unless the storage or access is strictly necessary for a service the user explicitly requested, and analytics rarely meets that test on its own.

In practice:

- **Browser storage needs consent like a cookie.** An ID in `localStorage`, `sessionStorage` or IndexedDB is stored on the device.
- **Fingerprinting needs consent.** Reading screen size, installed fonts, canvas rendering and similar characteristics to recognize a device is accessing information on it, even though nothing is stored.
- **Scripts are not automatically out of scope.** A measurement script instructs the browser to read and send information. European regulators have read "gaining access" broadly, so do not assume a tool is exempt just because it sets nothing.
- **Personal data is a separate question.** In Planet49, the CJEU held that Article 5(3) applies whether or not the information is personal data. If the data does relate to identifiable people, GDPR applies on top, and you need a lawful basis under Article 6. Some teams consider [legitimate interest](/blog/legitimate-interest-and-cookies) for minimal analytics where no consent rule applies.

There are narrow national exceptions. France's CNIL has described conditions under which some audience-measurement tools can run without consent, and UK legislation passed in 2025 created an exception for some analytics storage, subject to conditions; see [UK GDPR and PECR](/blog/uk-gdpr-pecr-cookies). These rules are specific and still evolving, so check current guidance from your regulator, such as the ICO in the UK, before removing consent for analytics.

## How do I implement low-risk cookieless measurement?

Count pages, not people. A minimal page view beacon needs no cookie, no storage and no identifier:

```js
// Aggregate page view: no cookies, no storage, no identifiers.
const referrer = document.referrer ? new URL(document.referrer).hostname : null;

navigator.sendBeacon(
  'https://analytics.example.com/collect',
  JSON.stringify({ path: location.pathname, referrer }), // path only, no query string
);
```

If you need approximate daily unique visitors, a common technique is to hash the IP address and user agent with a random salt that is replaced every day and never stored. Once the old salt is gone, nobody can recompute yesterday's keys or link them to today's.

```ts
import { createHash, randomBytes } from 'node:crypto';

let salt = randomBytes(32);
let saltDay = new Date().toISOString().slice(0, 10);

export function dailyVisitorKey(ip: string, userAgent: string, site: string): string {
  const today = new Date().toISOString().slice(0, 10);
  if (today !== saltDay) {
    salt = randomBytes(32); // the old salt is discarded, never persisted
    saltDay = today;
  }
  return createHash('sha256').update(salt).update(`${site}|${ip}|${userAgent}`).digest('hex');
}
```

In production, share the salt across servers through a cache that expires it daily, never through a database or backup. While the salt exists, the key is pseudonymized personal data under GDPR, not anonymous data, and regulators differ on whether recognizing visitors from IP address and user agent counts as accessing the device.

A low-risk setup usually ticks these boxes:

1. No cookies, no browser storage and no fingerprinting techniques.
2. Query strings and URL fragments dropped before storage.
3. Raw IP addresses discarded after deriving a coarse country, if you need one at all.
4. Salts rotated and discarded daily, and raw inputs never logged.
5. Aggregate reporting only, with no cross-site tracking and no reuse for advertising.
6. Short retention for raw events, and a clear description in your privacy notice.

## What do you give up with cookieless analytics?

Mostly continuity across visits. Unique visitor counts become estimates, and a daily hash counts a returning visitor as new each day. Multi-day funnels, cohort retention and long attribution windows largely disappear, and person-level ad conversion tracking usually still needs consent.

Expect your numbers to differ from your previous tool, and annotate the switch date in your reports. For many content and marketing sites, aggregate trends are enough. Where you need more, a common pattern is cookieless counting for everyone, where lawful, plus full analytics for visitors who opt in, kept as separate datasets.

## Bottom line

Cookieless analytics is a strong default for privacy-respecting measurement, but treat it as "less data", not "no rules". Pick the approach that answers your real questions, avoid storing or reading identifiers on the device without consent, and check national guidance first. Tools like Cookiesh can cover the cases where consent is still required, keeping scripts in the analytics category blocked until visitors opt in, with banners geo-targeted by region.

*This article is general information, not legal advice. For decisions about your specific situation, consult a qualified privacy professional.*

## FAQ

### Is truncating IP addresses enough to make analytics data anonymous?

Usually not on its own. A truncated IP address combined with a user agent, timestamps and page URLs can still relate to an identifiable person. Treat the data as personal data unless a careful assessment shows otherwise.

### Do I need to mention cookieless analytics in my privacy notice?

Yes, if it processes personal data such as IP addresses or event data linked to identifiable people. Describe what you collect, why, your legal basis and how long you keep it, just as you would for cookie-based analytics.

### Can cookieless analytics measure conversions from ads?

Only at an aggregate level, for example by counting visits and sign-ups that arrive from a tagged campaign URL. Linking a specific ad click to a later purchase by the same person usually requires an identifier, which brings the consent question back.

## Sources

- [Directive 2002/58/EC (ePrivacy Directive), EUR-Lex](https://eur-lex.europa.eu/eli/dir/2002/58/oj)
- [Regulation (EU) 2016/679 (GDPR), EUR-Lex](https://eur-lex.europa.eu/eli/reg/2016/679/oj)
- [CJEU case C-673/17 (Planet49)](https://curia.europa.eu/juris/liste.jsf?num=C-673/17)
- [ICO (UK Information Commissioner's Office)](https://ico.org.uk/)