Identity and privacy

Torno separates anonymous visitors from identified Customers and enforces the boundary in collection and storage, not just in the interface. This page covers the Subject key, k-anonymous aggregation, Customers and Accounts, and the consent, retention, and data subject request mechanisms.

Two zones

Visitor behavior is cohort-only in every mode. There is no anonymous-profile view because no anonymous profile exists.

The Subject key

The SDK mints a random sub_… key on first touch and persists it first-party; where required consent is absent, no Subject record is created at all. A Subject is join plumbing, not a profile. It carries exactly what joins need: first-touch attribution (landing page, referrer, UTM and click IDs — filled once, consent permitting, and never rewritten by later campaigns), Experiment assignments recorded at exposure, the signup handoff, and the revenue join — the Subject key rides along in payment metadata so revenue can be attributed without identifying anyone early.

The limits are reported honestly. Clearing browser storage creates a new Subject, and Torno counts it as one instead of pretending to recognize a returning stranger. There is no cross-device stitching before signup. Deleting a Subject tombstones its key so it cannot resurrect.

k-anonymous aggregation

Visitor analytics come out as Cohort aggregates behind a k-minimum: the default is k = 25, the hard floor is 10, and only a human Workspace owner can change it. Below-k queries refuse without leaking through timing or partial content. Grouped results mask small cells — and neighboring cells where needed — so nothing can be recovered by subtraction. Aggregate responses never contain Subject keys, and there is deliberately no grantable agent scope for Subject-level analytics. See Analytics.

Customers and Accounts

A Customer exists only after your product calls identify on a Property in profile mode. In cohort-only mode, traits are dropped at collection and no Customer is ever created. Switching modes is forward-only: turning profile mode on does not backfill the past, and turning it off offers a governed bulk-erasure run rather than silent forgetting.

Reading an individual Customer requires the customer_read scope. Agents do not hold it by default; aggregate views work without it. For B2B, a reserved account trait rolls Customers up into optional Accounts without introducing a separate identity graph.

Consent

Consent resolves from one configured source — an SDK call, a consent-platform adapter, or server-side evidence — combined with a regional default posture, and unset state is treated conservatively. Every consent change is recorded as an append-only event with its source and evidence. Withdrawal stops future collection immediately; it does not claim to retroactively erase the past — that is what deletion is for. Event collection, Cohorts, ads conversions, and Customers all consult the same authority, so a preference recorded in one place cannot be ignored by another.

Retention

Every data class has a registered retention window and its own purge hook. Raw events default to 12 months. Shrinking a window first shows a blast-radius preview of what would be purged. Purge runs are idempotent and cursor-batched, and they leave evidence: counts and the policy version that applied.

Data subject requests

Export and delete requests can target a Customer, a Subject, a voice author, or a whole Workspace. Intake starts a due-date clock; a human verifies or rejects the request; execution fans out across every registered store with per-step status and retry; the audit record is permanent. Export produces a complete, expiring, scope-gated artifact. Delete leaves tombstones and receipts and preserves only permitted aggregates — Experiment results do not un-happen; they stop being traceable to a person.

Residency and inventory

Each Workspace records an immutable home region. Automatic regional routing of traffic is not available yet, and Torno does not claim otherwise; the product states its control-plane exceptions and connected providers instead. A data-processing inventory is generated from schema classification, alongside a subprocessor register. Torno describes these mechanisms in jurisdiction-neutral terms rather than claiming blanket compliance with any regulation — whether they satisfy your obligations is your counsel’s call, but the inputs to that call are inspectable.