Do Temporary Session Identifiers (Session IDs) Require Consent Under GDPR?
A common question around privacy-compliant analytics is whether temporary Session IDs fall under “tracking technologies” that require user consent.
The short answer: it depends on how the Session ID is implemented.
Any statement on this page about how Sealmetrics meets a criterion is a self-assessment, not a certification. No supervisory authority certifies or validates analytics tools, and Sealmetrics holds no third-party security certification. This page is general regulatory analysis, not legal advice.
When Session IDs Do Require Consent
A temporary Session ID requires consent if:
- It is stored in a cookie or similar persistent storage
- It can be used to recognize a user over time
- It can be combined with other identifiers to reconstruct a profile
- It is used for tracking across multiple domains
In these cases, the Session ID becomes a personal identifier, making consent mandatory under:
- GDPR (Article 4(1))
- ePrivacy Directive (Article 5(3))
- Local guidelines (CNIL, AEPD, ICO…)
When Session IDs Do Not Require Consent
Regulators such as CNIL (France) and AEPD (Spain) explicitly allow “cookie-less session identifiers” for audience measurement, as long as they meet strict conditions:
Conditions for Consent-Free Session IDs
- Used exclusively for audience measurement (no marketing / profiling)
- No cross-site tracking
- Not persistent → disappears after the browser session ends
- Not stored in cookies or localStorage
- Cannot be combined with other identifiers to re-identify the user
- No fingerprinting techniques
If all these requirements are met, the Session ID is considered non-identifying, and consent is not required.
How Sealmetrics Ensures Compliance
How the identifier is built. The tracker computes, in the browser, a hash of standard device characteristics — user agent, timezone, languages, screen resolution, colour depth, dark-mode and reduced-motion preferences, CPU core count and device memory — combined with the site's account ID. That hash is a device fingerprint: it is stable for the same browser. It is never written to the device (no cookie, no localStorage, no sessionStorage). On the server, before anything is stored, it is re-keyed with a server secret and a daily salt; the salt rotates every day and is destroyed on rotation, so the stored identifier changes daily and two days of the same device cannot be re-linked — not even by Sealmetrics. The raw hash is never stored. The live session lasts 2 hours of inactivity in server memory; the daily pseudonym is kept in the per-hit log for 1 day. See What We Track vs What We Don't.
Against the conditions above:
- ✔ Used exclusively for audience measurement — no marketing or profiling
- ✔ No cross-site tracking — the account ID is part of the hash, so the same browser yields different identifiers on different sites
- ✔ Nothing stored on the device — no cookies, localStorage or sessionStorage
- ✔ No persistent stored identifier — the stored value changes every day and cannot be linked across days
- ✔ No personal identification — no IP, user ID or other identifier is stored alongside it
Fingerprinting condition — stated plainly. The identifier is computed from device characteristics read in the browser, so Sealmetrics does not claim "no fingerprinting techniques" in absolute terms. What it does claim is that no fingerprint is stored or persists: the hash is never stored as sent, and the stored value is re-keyed daily with a salt that is then destroyed. Reading those browser properties is also an "access" to terminal equipment under Art. 5(3), so the consent exemption rests on the audience-measurement criteria described in Analytics Cookies: Consent Exemption Requirements, not on nothing being read.
Under the GDPR, stated plainly. While the day's salt exists, Sealmetrics could in principle recompute the identifier, so it is pseudonymised data, not anonymous data. It is processed under legitimate interest (Art. 6(1)(f)), kept in the per-hit log for 1 day, and becomes unrecoverable once the salt rotates — not even Sealmetrics can reconstruct it. Reports are always aggregated.
Session IDs are used only within the active session to group hits — never to track or identify users across days.
Summary
| Scenario | Requires Consent? | Why |
|---|---|---|
| Session ID stored in a cookie | Yes | Persistence = identification |
| Temporary ID without cookies | No | Cannot identify the user |
| Cross-site session tracking | Yes | Considered profiling |
| Sealmetrics session tracking | No (self-assessed) | Nothing stored on the device; stored identifier re-keyed daily and not linkable across days |
The identifier is never stored on the device, the stored value is re-keyed every day, and it never joins hits across days — the basis of Sealmetrics' self-assessment against the audience-measurement exemption criteria.
Primary sources
- ePrivacy Directive 2002/58/EC — Art. 5(3): consent to store or access terminal-equipment data — eur-lex
- GDPR (Regulation 2016/679) — Art. 4(1) defines personal data; Recital 26 excludes anonymous data — eur-lex
- EDPB Guidelines 2/2023 — technical scope of Art. 5(3): what counts as storage or access — edpb.europa.eu
- CNIL — audience-measurement exemption, including the session-identifier conditions — cnil.fr
- AEPD — Guía sobre el uso de las cookies, analytics-cookie exemption conditions — aepd.es
Related documentation
- GDPR and Cookieless Analytics — the wider GDPR case for cookieless, non-identifying measurement.
- Does Sealmetrics comply with CNIL guidelines? — the CNIL first-party session-ID exemption in detail.
- CNIL Self-Assessment: Sealmetrics Compliance — the session-ID condition assessed criterion by criterion.
- Legal FAQ — Sealmetrics Compliance Questions — how the Session ID and Source ID are computed and used.
- How Attribution Works Without a User-ID — attribution without persistent user identifiers.