Architectural Overview: The Dilemma of Cookie Rejection in Analytics<\/h2>\n
In modern web analytics, explicit opt-in consent banners (CMP) result in substantial measurement gaps. When users reject tracking cookies or navigate via browsers enforcing aggressive Intelligent Tracking Prevention (ITP), traditional client-side identifiers such as _ga<\/code>, _gid<\/code>, or Matomo visitor IDs are blocked or stripped. Consequently, every pageview from an unconsented user is recorded as an isolated, single-event session, rendering funnel conversion rates, attribution models, and user journey analytics statistically meaningless.<\/p>\n
To restore analytical continuity without infringing upon GDPR, ePrivacy, or TTDSG\/TDDDG regulations, Server-Side Synthetic Session Stitching<\/strong> can be implemented. Unlike persistent cross-site tracking or fingerprinting, synthetic session stitching operates entirely within a server-side proxy or edge worker (such as Server-Side GTM, Cloudflare Workers, or custom PHP\/Node.js endpoints). By calculating an ephemeral, daily-rotating cryptographic hash from non-persistent network attributes\u2014such as a truncated IP subnet, User-Agent, and a server-generated daily salt\u2014sessions can be accurately reconstructed for statistical aggregation while ensuring zero persistent client-side storage and preventing cross-day user identification.<\/p>\n\nPath of a synthetic ID: the truncated IP, two stable headers and the daily salt are hashed into a session ID. Nothing is written to the browser \u2014 and once the salt rotates, the ID of the previous day can no longer be reproduced.<\/figcaption><\/figure>\n
Generating a GDPR-compliant synthetic session identifier requires three fundamental safeguards:<\/p>\n
\n
IP Subnet Truncation:<\/strong> Full IP addresses must never be hashed directly, as they remain personal data. IPv4 addresses must be masked to the \/24<\/code> subnet (e.g., 192.0.2.0<\/code>), and IPv6 addresses to the \/48<\/code> subnet.<\/li>\n
Dynamic Daily Salt:<\/strong> A cryptographic random salt must be generated on the server and rotated automatically at midnight (UTC) at the latest. This guarantees that hashes expire completely within 24 hours at most, making multi-day tracking mathematically impossible.<\/li>\n
One-Way Hashing:<\/strong> Attributes must be combined and processed via an irreversible hashing algorithm such as SHA-256.<\/li>\n<\/ol>\n
The following production-ready JavaScript implementation demonstrates how to generate a privacy-compliant synthetic session ID within a Server-Side GTM custom variable or Cloudflare Edge Worker without writing any HTTP Set-Cookie<\/code> headers:<\/p>\n
For WordPress v7.0.2 infrastructures utilizing custom REST API ingestion or server-side measurement endpoints, the synthetic session calculation can be integrated into a helper utility within functions.php<\/code>:<\/p>\n
Step 4: Mapping Synthetic IDs to Analytics Platforms<\/h3>\n
Once generated, the ephemeral session ID must be passed to the downstream analytics endpoint in place of the missing cookie ID:<\/p>\n
\n
Google Analytics 4 (GA4):<\/strong> Map the generated value to the client_id<\/code> parameter in Server-Side GTM while explicitly setting the parameter non_personalized_ads=1<\/code> and stripping user IP headers.<\/li>\n
Matomo \/ Piwik PRO:<\/strong> Assign the hash to the server-side visitor ID property (_id<\/code> or cid<\/code>) and force Cookieless Mode in the measurement configuration.<\/li>\n
BigQuery Raw Exports:<\/strong> Store the identifier inside a dedicated column (e.g., synthetic_session_id<\/code>) to separate cookie-based sessions from server-stitched sessions during SQL data modeling.<\/li>\n<\/ul>\n
Step 5: Quality Assurance and Compliance Auditing<\/h3>\n
To verify that synthetic session stitching operates correctly without violating privacy mandates, validation must be conducted across three vectors:<\/p>\n
\n
Network Header Verification:<\/strong> Inspect server responses using browser developer tools (F12) to confirm that no Set-Cookie<\/code> HTTP headers are transmitted when consent is declined.<\/li>\n
Collision and Stability Testing:<\/strong> Generate test requests from identical subnet ranges and verify that different User-Agent strings yield distinct hashes, while sequential pageviews from the same browser resolve to an identical session ID.<\/li>\n
Midnight Salt Expiration Audit:<\/strong> Simulate a daily salt reset and verify that all generated session IDs immediately change, confirming that cross-day user profiling is impossible.<\/li>\n<\/ol>\n
Summary and Measurable Added Value<\/h2>\n
What is achieved:<\/strong> Replacement of broken, single-event pageviews for unconsented traffic with an ephemeral, server-side session reconstruction model that functions without storing cookies or processing unmasked personal IP addresses.<\/p>\n
Resulting added value:<\/strong><\/p>\n
\n
Restoration of Funnel and Journey Analytics:<\/strong> Statistical conversion rates, bounce rates, and multi-step navigation paths remain approximately measurable for visits without cookie consent as well.<\/li>\n
Less intrusive than cookie tracking, but not exempt:<\/strong> Nothing is stored on the user device. The hash of subnet and browser headers nevertheless remains pseudonymous and therefore personal data despite the daily salt (GDPR Recital 26); processing it requires a legal basis, and whether it is permissible without consent has to be assessed case by case.<\/li>\n
Zero Advertising Contamination:<\/strong> By expiring identifiers daily and stripping persistent cross-site profiles, analytical reporting accuracy is preserved without enabling invasive retargeting or profiling.<\/li>\n<\/ul>\n
\n
Questions and answers<\/h2>\n
How reliably does the hash separate visitors who share a network?<\/h3>\n
Only as reliably as the inputs differ. The hash merges all requests that come from the same \/24 subnet and carry the same User-Agent, and also the same Accept-Language. In a corporate network, on hotel Wi-Fi or behind a mobile operator\u2019s carrier-grade NAT, many people share one address, and common devices with an up-to-date browser often send identical User-Agent strings. Those visits merge into a single synthetic session. Chromium has also reduced the User-Agent string, so it distinguishes less than it used to.<\/p>\n
Conversely, a single visit falls apart when the inputs change along the way: a phone moving from Wi-Fi to the mobile network gets a different subnet, and a browser update changes the User-Agent. Both create a new identifier in the middle of the visit.<\/p>\n
The reconstructed sessions are therefore an estimate with errors in both directions. The dedicated BigQuery column the article proposes makes it possible to analyze this share separately, for example by setting conversion rates of sessions with and without a cookie side by side instead of mixing them.<\/p>\n
Why must the daily salt never be stored or backed up?<\/h3>\n
Because it is the only thing protecting the hashes from being reversed. The space of possible inputs is small: there are only about 16.8 million IPv4 subnets of size \/24, and common User-Agents can be listed, so with the salt known, every identifier of that day can be traced back to a subnet and a browser by trying the combinations. In the PHP example the salt sits in the database as a transient, in the options table when no persistent object cache is in use, and therefore in every database backup, where it outlives its day.<\/p>\n<\/div>\n
![\"Generation](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/cookieless-synthetic-session-stitching-en.png\")