What is data sovereignty in analytics?

Data sovereignty means your organization retains full ownership and control over where customer data is stored, who can access it, how long it is retained, and how it can be exported. ClickStream ensures data sovereignty through per-site AES-256-GCM encryption of contact fields, edge-side PII scrubbing before analytics storage, automated retention enforcement, and per-tenant encrypted Parquet exports (Paid, on request).

How should PII be handled in a clickstream analytics platform?

PII in clickstream data — emails, phone numbers, IP addresses — should be hashed or encrypted at collection, stored with per-tenant encryption keys, and subject to configurable retention policies. ClickStream hashes PII at the edge before storage and provides 90-day TTL defaults with customizable retention windows.

What is AES-256-GCM encryption and why does it matter for analytics?

AES-256-GCM is a symmetric encryption standard that provides both confidentiality and data integrity verification. ClickStream uses per-site AES-256-GCM keys to encrypt stored contact fields (email, phone, name), and derives per-tenant keys for encrypted data exports — so even in a storage breach, one tenant's PII cannot be decrypted with another tenant's key.

Data Sovereignty & PII Architecture | ClickStream Whitepaper

Abstract

Data sovereignty is not a feature; it is an architectural decision that must be made at the foundation of any analytics platform. ClickStream's data architecture ensures that personally identifiable information (PII) is encrypted at rest with AES-256-GCM using per-site encryption keys, hashed with a dual-hash strategy (SHA-256 for internal identity resolution, MD5 for ad-tech compatibility), automatically scrubbed after a configurable 90-day TTL, and exported on request in per-tenant-encrypted Parquet format from ClickStream-managed Cloudflare R2 infrastructure (both packages). This whitepaper details every layer of the privacy architecture, from the encryption envelope to GDPR Article 17 (right to erasure) compliance, CCPA opt-out mechanics, and Schrems II positioning for EU-US data transfers.

The Data Sovereignty Threat Model
AES-256-GCM Per-Site Encryption
Dual-Hash PII Strategy
90-Day TTL Auto-Scrubbing
Parquet Exports to R2
Data Classification Tiers
GDPR Compliance Architecture
CCPA/CPRA Compliance
Schrems II and EU-US Data Transfers
Right to Erasure Implementation
Conclusion

1. The Data Sovereignty Threat Model

Most analytics platforms operate on a trust model where the customer sends their visitor data to a vendor-controlled infrastructure, hopes the vendor handles it properly, and has no meaningful audit capability. This model has failed repeatedly: data breaches at third-party analytics providers, unauthorized data sharing with advertising networks, and regulatory penalties for customers who delegated data processing to non-compliant vendors.

ClickStream's data sovereignty architecture addresses four threat categories:

Vendor breach: If ClickStream's infrastructure is compromised, per-site encryption ensures that an attacker cannot decrypt any customer's stored contact fields or encrypted exports without that customer's specific encryption key — and analytics storage holds only hashed identifiers, never raw PII.
Cross-customer leakage: Multi-tenant analytics platforms risk data mixing between customers. Per-site encryption keys, per-tenant HMAC identity hashing, and tenant-scoped analytics indexes keep each customer's data isolated — two tenants' data cannot be joined, and one tenant's PII cannot be decrypted with another's key.
Regulatory exposure: GDPR, CCPA, LGPD, and other regulations impose strict requirements on data processing, retention, and deletion. The architecture enforces compliance automatically, not through policy documents.
Third-party data sharing: Ad-tech integrations historically leaked PII to third parties. The dual-hash strategy ensures that only irreversible hashes leave the encrypted envelope, never raw PII.

2. AES-256-GCM Per-Site Encryption

Every customer site in ClickStream receives a unique 256-bit AES encryption key. PII is neutralized at the edge before storage: analytics storage holds hashed identifiers only (HMAC-SHA-256 and MD5 email hashes, hashed phone, SHA-256 IP hash — never raw values), while raw contact fields are AES-256-GCM encrypted with per-site keys and gated behind an audited, password-protected reveal workflow.

2.1 Encryption Envelope

// Encryption at the edge worker async function encryptPII(plaintext: string, siteKey: CryptoKey): Promise<string> { const iv = crypto.getRandomValues(new Uint8Array(12)); // 96-bit IV const encoded = new TextEncoder().encode(plaintext); const ciphertext = await crypto.subtle.encrypt( { name: 'AES-GCM', iv: iv, tagLength: 128 }, siteKey, encoded ); // Concatenate IV + ciphertext + auth tag const result = new Uint8Array(iv.length + ciphertext.byteLength); result.set(iv); result.set(new Uint8Array(ciphertext), iv.length); return btoa(String.fromCharCode(...result)); }

2.2 Key Management

Aspect	Implementation
Key generation	256-bit random key generated at site onboarding
Key storage	Cloudflare Workers KV, encrypted at rest by Cloudflare
Key access	Encryption keys are scoped per site
Key deletion	Key destruction can be requested through support, rendering the encrypted PII envelope undecryptable
Algorithm	AES-256-GCM with 96-bit IV and 128-bit authentication tag

2.3 What Gets Encrypted

Not all data requires encryption. ClickStream classifies fields into three categories:

Category	Examples	Treatment
PII (encrypted)	Email, phone, IP address	AES-256-GCM encrypted before storage
Pseudonymous (hashed)	Visitor ID, session ID, device signature	Already pseudonymous; stored as-is
Behavioral (plaintext)	Scroll depth, click count, page URL, scores	Non-identifying; stored in plaintext for analytics

The encryption boundary is the critical design decision: encrypt everything that could identify a natural person, hash everything that serves as an identity linkage, and leave behavioral data unencrypted for analytics performance.

3. Dual-Hash PII Strategy

When a visitor provides an email address (through form submission, login, or checkout), ClickStream generates two irreversible hashes:

3.1 SHA-256 (Internal Identity)

// SHA-256 for internal identity graph const sha256Hash = await crypto.subtle.digest( 'SHA-256', new TextEncoder().encode(email.toLowerCase().trim()) ); const internalId = Array.from(new Uint8Array(sha256Hash)) .map(b => b.toString(16).padStart(2, '0')) .join('');

The SHA-256 hash is used exclusively within ClickStream's identity graph. It links visitor sessions, resolves cross-device identities, and powers the behavioral profile. SHA-256 is cryptographically secure and computationally infeasible to reverse.

3.2 MD5 (Ad-Tech Compatibility)

// MD5 for ad-tech identity sync (DSPs, demand-side platforms) const md5Hash = md5(email.toLowerCase().trim());

The MD5 hash is retained for future interoperability with ad-tech systems. Cross-channel DSP activation for ad placements is coming soon; ClickStream currently resolves and builds audiences, exports them, and integrates with CRMs. While MD5 is not cryptographically secure (collision attacks exist), it does not expose raw PII.

3.3 Hash Comparison

Attribute	SHA-256 (Internal)	MD5 (Ad-Tech)
Purpose	Identity graph resolution	Ad platform audience matching
Security level	Cryptographically secure	Industry-standard (not collision-resistant)
Stored where	D1 identity graph	Stored as a hash in analytics storage; sent to the enrichment vendor only when enrichment is enabled (opt-in, default OFF)
Reversible	No	Theoretically via rainbow tables
Shared externally	Never	Only to configured ad-tech partners

The raw email address is encrypted with AES-256-GCM and stored in the PII envelope. The hashes exist independently. Even if the encryption key is lost, the hashes remain functional for identity resolution.

4. 90-Day TTL Auto-Scrubbing

All behavioral event data has a default time-to-live (TTL) of 90 days. After 90 days, event-level data is automatically and irreversibly deleted from both the Analytics Engine and D1.

4.1 What Gets Scrubbed

Data Type	TTL	After Expiry
Raw event data (page views, clicks, etc.)	90 days	Permanently deleted from Analytics Engine
Behavioral scores per session	90 days	Expire from the scores Analytics Engine dataset; aggregated scores retained
IP addresses (encrypted)	90 days	Deleted; IP-based geo already resolved at write time
Identity graph edges (probabilistic)	7–90 days by signal type	Edges decay automatically; a 90-day PII scrub cron and graph-wide erasure remove personal data
Aggregated analytics	No TTL	Retained indefinitely (non-identifying)
Parquet exports	90 days	Export files in ClickStream's R2 are automatically deleted 90 days after creation

4.2 Scrubbing Implementation

Auto-scrubbing is implemented as Cloudflare Cron Triggers: an hourly retention purge (with stricter windows for GDPR-strict and HIPAA compliance profiles) plus a nightly export-cleanup job:

// Scheduled retention purge (Cron Trigger, illustrative) export default { async scheduled(event, env, ctx) { const cutoff = Date.now() - (90 * 24 * 60 * 60 * 1000); // Delete expired events from D1 await env.DB.prepare( `DELETE FROM events WHERE created_at < ?` ).bind(cutoff).run(); // Delete expired sessions await env.DB.prepare( `DELETE FROM sessions WHERE last_active < ?` ).bind(cutoff).run(); // Delete expired PII envelopes await env.DB.prepare( `DELETE FROM pii_store WHERE created_at < ?` ).bind(cutoff).run(); // Analytics Engine handles its own TTL natively } };

5. Parquet Exports to R2

ClickStream's export pipeline writes analytics data to ClickStream-managed Cloudflare R2 in Apache Parquet format — Snappy-compressed, Hive-partitioned, and encrypted per tenant with a key derived from your own site key. Raw-event Parquet exports are available on request on both packages today; campaign CSV exports are self-serve on both packages.

5.1 Export Format

Attribute	Value
Format	Apache Parquet (columnar)
Compression	Snappy
Partitioning	Hive-style (year=/month=/day=/hour=)
Schema	Mirrors Analytics Engine blob/double mapping
PII handling	Exports carry hashed identifiers only; files are AES-256-GCM encrypted with a per-tenant key; GDPR-erased visitors are excluded
Storage location	ClickStream-managed R2 infrastructure
Retention	90 days; export files in ClickStream's R2 are automatically deleted 90 days after creation

5.2 Export Path Structure

r2://raw-clickstream-lake/{clientId}/ year=2026/month=03/day=10/hour=14/events.parquet year=2026/month=03/day=10/hour=15/events.parquet

Parquet is an open columnar format readable by DuckDB, Apache Spark, Pandas, Polars, Amazon Athena, and any Parquet-aware SQL engine — so exported data is never locked to ClickStream's tooling. Raw-event exports are fulfilled on request for Paid plans today; campaign CSV exports are self-serve on Paid.

6. Data Classification Tiers

ClickStream classifies all data into four tiers with progressively stricter handling requirements:

Tier	Classification	Examples	Encryption	TTL	Export
Tier 1	Direct PII	Email, phone, name	AES-256-GCM	90 days (or custom)	Encrypted in export
Tier 2	Indirect PII	IP address, precise geolocation	AES-256-GCM	90 days	Encrypted or omitted
Tier 3	Pseudonymous	Visitor ID, session ID, hashes	None (already pseudonymous)	Cookie lifetime up to 400 days	Included
Tier 4	Behavioral / Aggregate	Scores, page URLs, timestamps	None	90 days (events) / indefinite (aggregates)	Included

ClickStream's architecture addresses GDPR requirements structurally, not through policy alone:

GDPR Article	Requirement	ClickStream Implementation
Art. 5(1)(e)	Storage limitation	90-day TTL with automated scrubbing
Art. 5(1)(f)	Integrity and confidentiality	AES-256-GCM encryption at rest
Art. 6	Lawful basis	Consent gates with a consent-receipt audit trail
Art. 7	Conditions for consent	SDK checks consent before setting cookies
Art. 15	Right of access	Erasure API today; access requests handled via support
Art. 17	Right to erasure	Cascade delete across all data stores
Art. 20	Data portability	CSV exports self-serve (Paid); Parquet raw-event exports in open format on request (Paid)
Art. 25	Data protection by design	Encryption, hashing, TTL, and minimization are architectural defaults
Art. 28	Processor obligations	DPA available under commercial agreements; published sub-processor list
Art. 32	Security of processing	AES-256-GCM + TLS in transit + isolated worker environments
Art. 33	Breach notification	72-hour breach notification commitment in the DPA
Art. 35	Data protection impact assessment	DPIA template provided to customers

8. CCPA/CPRA Compliance

California's CCPA and its successor CPRA impose specific requirements for opt-out mechanics and data selling prohibitions:

Do Not Sell My Personal Information: ClickStream never sells your visitors' data — behavioral data collected on your sites is computed and stored for your exclusive use, and no code path feeds tenant analytics into any data product. Ad-tech integrations receive only irreversible hashes, never raw PII.
Right to Delete: Implemented identically to GDPR Art. 17. Cascade deletion across all data stores.
Right to Know: Access requests are handled via support; the identity graph resolves all identifiers linked to the data subject so responses cover the full record.
Opt-out signals: ClickStream's consent gates and do-not-sell flags let customers honor visitor opt-outs, including opt-out preference signals such as Global Privacy Control (GPC). When a visitor opts out, no cookies are set and only session-level, non-identifying data is collected.
Sensitive personal information: By design, ClickStream does not collect sensitive personal information — edge-side scrubbing redacts fields such as SSNs and financial account numbers before storage.

9. Schrems II and EU-US Data Transfers

The Schrems II ruling invalidated the EU-US Privacy Shield, creating uncertainty around transatlantic data transfers. ClickStream's architecture is designed to minimize transfer risk:

9.1 Data Localization

Cloudflare's edge network processes requests at the nearest edge location to the visitor. For EU visitors, that typically means EU edge locations such as Frankfurt, Amsterdam, Paris, or Dublin.

9.2 Supplementary Measures

Measure	Implementation
Encryption in transit	TLS for all connections
Encryption at rest	AES-256-GCM with per-site keys
Pseudonymization	SHA-256 hashing of PII at ingestion
Data minimization	Only necessary fields collected; 90-day TTL
Access control	Encrypted PII is revealed only through an audited, password-gated decrypt workflow
Transparency	A published sub-processor list, updated with notice; enrichment vendors receive data only if you opt in

9.3 EU-Only Processing Option

Organizations can contract for EU-only (or US-only) data residency, restricting processing and storage to the selected region.

10. Right to Erasure Implementation

When a data subject exercises their right to erasure (GDPR Art. 17 or CCPA right to delete), ClickStream executes a cascade deletion across all data stores:

10.1 Deletion Flow

Request received: Via customer API or ClickStream dashboard. Identifier: visitor ID, email hash, or raw email.
Identity resolution: The identity graph resolves all linked identifiers (visitor IDs, session IDs, email hashes, device signatures) for the data subject.
D1 deletion: All rows in all tables referencing any of the resolved identifiers are deleted.
PII envelope destruction: The encrypted PII envelope for the data subject is deleted.
Analytics Engine: Event-level data in Analytics Engine is flagged for exclusion from queries (Analytics Engine does not support row-level deletion, but TTL will naturally expire these events within 90 days).
Parquet exports: Erased visitors are excluded from every future export — deletion propagates into the export pipeline automatically.
Confirmation: A deletion receipt with timestamp and scope is returned to the customer.

10.2 Deletion Timing

Data Store	Deletion Time	Method
D1 (relational)	Immediately on processing	SQL DELETE with cascade
Workers KV (PII envelope)	Immediately on processing	KV delete
Analytics Engine (events)	Up to 90 days (TTL)	Query-time exclusion + natural expiry
Parquet exports	Excluded from all future exports	Deletion propagates into the export pipeline; stored exports expire within 90 days

11. Conclusion

Data sovereignty cannot be bolted on after the fact. It must be architectural. ClickStream's approach — per-site AES-256-GCM encryption, dual-hash PII strategy, 90-day automatic scrubbing, on-request per-tenant-encrypted Parquet exports, and structural GDPR/CCPA compliance — ensures that data sovereignty is not a marketing claim but a cryptographic reality.

The key principles are simple: encrypt everything identifying, hash everything that serves as a linkage, automatically delete everything beyond the retention window, and keep exports in open formats — campaign CSV self-serve on both packages, raw-event Parquet on request on both packages. No compliance theater.

In a regulatory landscape that is tightening globally — the EU AI Act, Brazil's LGPD, India's DPDP Act, China's PIPL — organizations need analytics infrastructure that is not just compliant today but architecturally resilient to future regulation. ClickStream's privacy-first architecture provides that foundation.

Data Sovereignty & PII Architecture

Abstract

Table of Contents

1. The Data Sovereignty Threat Model

2. AES-256-GCM Per-Site Encryption

2.1 Encryption Envelope

2.2 Key Management

2.3 What Gets Encrypted

3. Dual-Hash PII Strategy

3.1 SHA-256 (Internal Identity)

3.2 MD5 (Ad-Tech Compatibility)

3.3 Hash Comparison

4. 90-Day TTL Auto-Scrubbing

4.1 What Gets Scrubbed

4.2 Scrubbing Implementation

5. Parquet Exports to R2

5.1 Export Format

5.2 Export Path Structure

6. Data Classification Tiers

8. CCPA/CPRA Compliance

9. Schrems II and EU-US Data Transfers

9.1 Data Localization

9.2 Supplementary Measures

9.3 EU-Only Processing Option

10. Right to Erasure Implementation

10.1 Deletion Flow

10.2 Deletion Timing

11. Conclusion

Own Your Data. Protect Your Revenue.

Data Sovereignty & PII Architecture

Abstract

Table of Contents

1. The Data Sovereignty Threat Model

2. AES-256-GCM Per-Site Encryption

2.1 Encryption Envelope

2.2 Key Management

2.3 What Gets Encrypted

3. Dual-Hash PII Strategy

3.1 SHA-256 (Internal Identity)

3.2 MD5 (Ad-Tech Compatibility)

3.3 Hash Comparison

4. 90-Day TTL Auto-Scrubbing

4.1 What Gets Scrubbed

4.2 Scrubbing Implementation

5. Parquet Exports to R2

5.1 Export Format

5.2 Export Path Structure

6. Data Classification Tiers

7. GDPR Compliance Architecture

8. CCPA/CPRA Compliance

9. Schrems II and EU-US Data Transfers

9.1 Data Localization

9.2 Supplementary Measures

9.3 EU-Only Processing Option

10. Right to Erasure Implementation

10.1 Deletion Flow

10.2 Deletion Timing

11. Conclusion

Related Whitepapers

First-Party Cookies Are the Gold Standard for Identity

Edge-Computed Behavioral Intelligence

Cross-Device Identity Resolution

Fraud Detection via Behavioral Biometrics

Identity Attribution in Cybercrime Investigations

Own Your Data. Protect Your Revenue.