DRAFT FOR COUNSEL REVIEW — NOT LEGAL ADVICE, NOT YET IN EFFECT. Prepared 2026-07-03 by the engineering team as an honest description of what the product actually does, for a lawyer to turn into an operative policy. Every technical claim below was checked against the code as of commit 3b50d5d; known gaps between aspiration and implementation are listed in MISMATCHES.md and must be resolved or reflected before this document is published. Placeholders are marked [BRACKETED].

Privacy Policy

Sonder ("we", "us") is a UX-friction analytics service operated by [COMPANY LEGAL NAME], [ADDRESS]. Contact: [privacy@DOMAIN] (interim: macklpgr@gmail.com).

This policy covers two very different groups of people, and we address them separately because different rules apply:

1. Customers and visitors — people who create a Sonder account, use the dashboard, or visit our website. For this data we are the controller.
2. End users of our customers' products — people whose interactions are captured by the Sonder SDK that a customer installed in their product. For this data we are a processor acting on the customer's instructions; the customer is the controller. If you are such an end user, your relationship is with the product you were using, and requests about your data should go to them (we give them the tools to honor those requests, described below).

1. Data we process as a processor (SDK data)

What the SDK collects

• Semantic interaction events: for each click, input, form change, submit, and navigation, a human-meaning label of the element (for example "Save changes"), its role (button, link, input…), a semantic selector, the nearest section heading, and the parametrized route (/settings/:id — never the raw ID in the URL path).
• Friction events: rage clicks (repeated clicks on the same element), dead clicks (clicks that visibly did nothing), and error clicks (a JS exception).
• State probes, only when a friction event fires: a small structured snapshot of what was on screen — whether an error message was visible and its (masked) text, whether a spinner or empty state was showing, whether the clicked control was disabled. Never a screenshot, never page HTML.
• Session and identity references: a random per-tab session ID (stored in sessionStorage, not a cookie; it does not persist across browser sessions and is not used to track people across sites), and — only if the customer calls identify() — a customer-chosen person identifier plus any traits the customer passes (masked as described below).
• Operational metadata: timestamps, event counts, the SDK build/release ID.

What the SDK does not collect

• No input values. The value of every form field is replaced with [masked] before it leaves the browser.
• No screenshots, no session video, no pixel or DOM recording, no raw HTML.
• No mouse-movement or scroll streams.
• No third-party cookies and no cross-site tracking of any kind.

Masking, twice

Text that reaches us is masked in the browser (emails, phone numbers, payment-card numbers, SSNs, and long digit runs are replaced with [masked]; sensitive JSON keys such as password, token, email are masked recursively; customers can force-mask any element with data-sonder-mask) and then masked again on our ingest server with the same rules before storage, as defense in depth. Payloads containing raw HTML are rejected or masked. Masking is heuristic; it is designed to prevent, not merely discourage, PII capture, but no pattern-based masking is perfect — which is one reason input values are never captured at all.

Retention and deletion

• Raw events are stored with a 90-day default retention. Workspace owners can configure retention between 1 and 730 days; a scheduled maintenance job purges data past the configured window and writes an audit record. [COUNSEL NOTE: raw event storage currently also carries a fixed 90-day table TTL; retention configured above 90 days is not honored for raw events today — see MISMATCHES.md #2. Do not publish a >90-day retention claim until resolved.]
• Delete by person: workspace owners can delete a person's data via the dashboard/API. This immediately deletes the person's derived session records and issue observations and writes an auditable deletion record. Raw masked events referencing that person ID are removed by the retention purge rather than immediately — see MISMATCHES.md #1; counsel should word the operative policy accordingly (for example: "derived records immediately; residual raw event data within the retention window, at most 90 days").
• Deleting a workspace deletes its control-plane records.

2. Data we process as a controller (accounts and website)

• Account data: email address, name, authentication identifiers (magic link, Google or GitHub OAuth via Supabase Auth), workspace membership and role.
• Billing data (paid plans): handled by Stripe; we do not store card numbers.
• Support and correspondence: what you send us.
• Website: the public marketing site is static and sets no analytics cookies. [If the Sonder SDK is later enabled on our own site — dogfooding — disclose it here.]

We use this data to operate the service, communicate with you, and bill you. We do not sell personal data and we do not run advertising.

3. Subprocessors

DeepSeek note (flagged deliberately): Sonder's issue diagnosis sends masked, run-length-encoded behavioral ribbons and issue summaries to the DeepSeek API (api.deepseek.com). Payloads are masked before storage and again before diagnosis, contain no input values, no screenshots, and no raw identifiers other than the customer-supplied person reference where present. DeepSeek is a PRC-headquartered model provider; its data-processing posture is a decision some buyers will scrutinize, so we state it plainly rather than burying it. [COUNSEL: confirm DeepSeek API data-retention/training terms and whether an opt-out or zero-retention tier is available; consider contractual and technical mitigations, or a "bring your own model endpoint" option, before enterprise sale.]

4. Data residency

All production data is stored and processed in the United States during beta. EU data residency is on the roadmap but is not available today; the architecture reserves a region field per workspace for this purpose. Customers with end users in the EU/UK are controllers and are responsible for their own lawful basis and transfer mechanism until an EU region and SCC-backed DPA are offered. See dpa-template.md.

5. Your rights

Customers and visitors may request access, correction, export, or deletion of their account data at [privacy@DOMAIN]. End users of customer products should contact the relevant product; we support customers in honoring such requests through the delete-by-person tooling and retention controls described above. [COUNSEL: add GDPR/CCPA-specific rights language, legal bases, and supervisory-authority details as applicable once the go-to-market geography is settled.]

6. Security

See the plain-English security overview. In short: TLS in transit, provider-managed encryption at rest (GCP, ClickHouse Cloud, Supabase), workspace-scoped row-level security, write-only client keys, hashed API keys, masking at edge and server, no replay video, and a deliberately small data surface.

7. Changes

We will post changes here and, for material changes affecting customers, notify account owners by email. [Effective date: NOT YET IN EFFECT — draft.]