English
Deutsch
PolskiCookieless Analytics: Why Synthetic IDs Do Not Reconstruct Sessions
Management Summary
Cookieless analytics tries to measure website activity without small browser records used for recognition. One approach calculates an identifier from network and browser details, but that does not reliably recreate individual visits: different people can be merged and one visit can split when a connection changes. The distinction matters for reports on customer journeys. Choosing the business question first can avoid unnecessary identification, since daily totals may need less recognition than individual paths.
Contents
- What a synthetic identifier actually connects
- Cookie rejection does not always produce a measured one-event session
- No cookie is not proof of anonymity
- A daily change does not erase stored data
- Why a universal code snippet is insufficient
- Limits of substitute identifiers in destination platforms
- A defensible measurement method
- Questions and answers
- Sources
Without a repeatable identifier, page views cannot readily be connected into visits. A hash of an IP subnet and browser attributes does not reliably solve this: different people can receive the same identifier, while one person can generate several. Such an identifier initially describes a group of equal inputs, not a verified session.
This article explains the technical limits of synthetic identifiers. Declining cookies does not authorize an alternative recognition mechanism.
What a synthetic identifier actually connects
A hash is a calculated code derived from input values. A typical method combines the network portion of an IP address, the browser’s User-Agent description, the preferred language and a daily changing value. Equal inputs produce an equal hash. That is a property of the calculation, not evidence of the same browser.
| Example | Result | Measurement error |
|---|---|---|
| Two employees share a corporate network, browser type and language. | Equal inputs and identifier | Two people merge. |
| A phone moves from Wi-Fi to mobile data. | Different network, new identifier | One visit can split. |
| A browser returns in the morning and evening. | Possibly the same daily identifier | Separate visits merge without an additional timing rule. |
| A visit crosses midnight. | New daily value, new identifier | An ongoing visit splits. |
These errors arise before hashing. A longer hash does not distinguish equal inputs. An output truncated to 16 hexadecimal characters also has only 64 bits; possible cryptographic collisions are separate from deliberately grouping identical attributes.
Cookie rejection does not always produce a measured one-event session
Behavior depends on the product and configuration. A fully blocked analytics tag sends no measurement events. Advanced Google Consent Mode can send signals without analytics cookies. Under suitable conditions, GA4 can provide modeled user and session metrics. Those are estimates rather than recovered individual journeys.
The claim that every rejected page view necessarily becomes a complete isolated session and makes every report worthless is therefore incorrect. The opposite promise, that a subnet hash restores actual journeys, is also incorrect. Observed events, modeled values and custom grouping require separate labels.
No cookie is not proof of anonymity
Hashing is not encryption. A shortened IP and browser attributes can still permit association or linking. Pseudonymization must therefore be distinguished from demonstrated anonymization. IPv4 /24 and IPv6 /48 are technical choices, not statutory anonymity thresholds.
Article 5(3) of the ePrivacy Directive is not limited to cookies. EDPB guidance also addresses IP-based tracking; the actual source and processing of information matter. Germany implements relevant requirements through section 25 TDDDG. Required consent or an applicable exception and the legal basis for subsequent personal-data processing need separate assessment.
A claim of “no processing of full IP addresses” would also be wrong for a function that receives the full address before truncating it. Networks, proxies and logs can create additional processing points. Checking only Set-Cookie response headers does not cover those paths.
A daily change does not erase stored data
A new daily value changes future hashes. Previously stored identifiers, events and links remain unaffected. Timestamps, accounts, URLs or other fields can still connect records. Cross-day association is therefore not mathematically impossible.
A salt is an additional value included in the hash calculation; it is normally not secret. A separately protected HMAC key can hinder guessing without the key, but cannot fix grouping errors or legal issues. Key storage, backups, access and deletion, as well as event retention, each need an explicit design.
A WordPress transient temporarily stores a value to avoid calculating or fetching it again. It is not reliable key storage: cached values can disappear early. Concurrent first requests can use different values when creation is not coordinated. Database and cache backups can preserve old values. Expiry and verified deletion of every copy are different things.
Why a universal code snippet is insufficient
IP addresses require a parser that recognizes their structure and valid shortened forms. Cutting colon-separated text handles compressed IPv6 and IPv4-mapped IPv6 incorrectly. Behind a proxy, REMOTE_ADDR often identifies the proxy; arbitrary forwarded headers can instead be manipulated. A missing address must not silently group all requests under a fallback value.
Node.js code using require(‘crypto’) is not a directly usable sGTM template. GTM has dedicated sandbox APIs. Cloudflare Workers have their own runtime and compatibility configuration. A copied hash generator also lacks permission checks, secure key management, event collection and tested destination mapping.
Limits of substitute identifiers in destination platforms
A GA4 client ID is not a session ID. Substituting a daily identifier as client_id changes identity behavior; non_personalized_ads=1 neither supplies missing consent nor implements Consent Mode by itself. Interface compatibility does not establish permitted processing.
Matomo documents exactly 16 hexadecimal characters for _id. A syn_ prefix followed by 16 hexadecimal characters does not match that format. Piwik PRO requires separate verification of its current interface; similar products are not interchangeable. Generating an identifier also does not automatically add a top-level column to the BigQuery export. A custom schema or explicitly modeled transformation is required.
A defensible measurement method
The required metric comes first. For daily totals, it may be sufficient to count events together early in processing without assigning them to recognizable visitors, provided the specific collection is permitted. Individual paths require reliable, permitted identifiers and a defined session model. Synthetic groups must not be presented as real people or complete journeys.
Evaluation uses synthetic cases or lawfully collected comparison data: shared networks, changing addresses, identical browsers, day boundaries and missing fields. Reports should identify merges, splits and unknown cases. A consented comparison population can differ from other visits and is not automatic proof of quality.
Questions and answers
Does a new identifier after midnight prove deletion?
No. That test shows only a changed calculation. Stored records and backups need separate deletion checks.
Is a daily identifier already a session?
No. A session needs defined timing and event rules. Even an inactivity threshold does not eliminate errors in the underlying recognition.
Sources
Related articles
