Privacy & Compliance

SnipForm is cookieless by architecture, not by configuration. This page is the technical reference for what the tracker does, what data exists on our servers, and how to reason about your compliance obligations when you use it. For the prospect-facing summary, see snipform.io/compliance; for the formal processor terms (GDPR Article 28, POPIA operator commitments, sub-processors, transfer safeguards), see the Data Processing Agreement, which is incorporated into the Terms for every customer.

How tracking works

The Signals tracker stores nothing on the visitor’s device:

• No cookies
• No localStorage or sessionStorage
• No fingerprinting scripts running in the browser

The script sends page views and events to SnipForm’s servers with request headers (page URL, title, referrer, viewport size). The session identifier only ever lives in a JavaScript variable that dies when the page unloads.

Session identity

Sessions are identified server-side:

1. The server derives a signature from the request’s characteristics (language, OS, browser, device class) and the visitor’s IP address.
2. That signature is hashed with a secret salt that is unique to your property and rotates every 24 hours (UTC).
3. The raw inputs, including the IP address, are discarded. Only the hash is kept.

Consequences of this design:

• Visits from the same device to your site on the same day are combined into one session.
• After the daily salt rotation, the same visitor produces an unrelated hash. Cross-day tracking is cryptographically impossible.
• The salt is scoped per property. Cross-site tracking is cryptographically impossible, even between two properties on the same SnipForm account.
• The hash cannot be reversed into an IP or device profile.

What a session stores

Group	Fields	Notes
Pages	Entry/exit URL, path, title, per-page view counts	Full URLs - keep PII out of your query strings
Referrer	Referring URL and domain
Attribution	UTM parameters, channel classification, click IDs
Device	Browser, OS, device class, viewport size	No user agent string is stored
Geo	Country, region, city	Resolved at the network edge; no IP is stored on the session
Behaviour	Time on site, scroll depth, view count, bounce

What a session does not store: IP address, user agent string, name, email, or any form field values. Bot traffic is the one exception: verified crawler sessions keep the reporting IP for bot verification.

Where personal data does exist

Two features handle personal data by design, under your control:

Contacts - if you call signals.identify() or the Contacts API, the email, name, and any traits you pass are stored and linked to sessions. You are the controller of this data; SnipForm processes it on your instruction.

Form submissions - submitted field values are stored so you can read them. Each submission also records the submitter’s device, coarse location, and a one-way hashed identifier derived from the IP - the raw IP is never stored; spam checks only need equality, and the hash provides it.

If you never identify visitors and never collect forms, your analytics contains no personal data records at all.

Deletion

Every level cascades completely:

Level	Mechanism
Single submission	Dashboard delete
Contact	Dashboard or DELETE via the Contacts API (contacts:write scope) - destroys every identifying field (email, name, phone, external id, metadata) and scrubs identify events; sessions keep only an anonymous reference
Form	Deletes all submissions, request logs, and related events
Property	Deletes all sessions, events, forms, submissions, and integrations
Account	Cascades through every property; a pre-delete audit lists everything that will be removed

Data is retained for the life of your account and removed by these tools - deleting a property or account deletes its data.

Data residency

All primary infrastructure is EU-resident: application servers and databases run on Google Cloud europe-west1 (Belgium), and analytics storage runs on Elastic Cloud in the same region. Transactional email and error monitoring also use EU regions. The full sub-processor list is on the compliance page.

Law by law

You are the controller of visitor data collected on your site (POPIA: responsible party); SnipForm is your processor (POPIA: operator).

Law	Position
GDPR (EU)	No cookies, no stored IPs, no cross-day or cross-site linkage, EU-resident processing, full deletion support. Most customers rely on legitimate interest for the anonymous analytics; identified Contacts and form data are yours to justify and delete.
ePrivacy / cookie banners	Consent rules trigger on storing or reading data on the visitor’s device. The default configuration does neither, and is designed to run without a cookie banner. Your final call depends on your jurisdiction and what else runs on your site.
POPIA (South Africa)	SnipForm acts as your operator: processing only on your authorisation, confidentiality, and notification if unauthorised access is suspected. Cross-border transfers land in the EU under GDPR-level protection, supporting a section 72 justification. Section 69 direct-marketing rules remain yours.
UK GDPR + PECR	Identical position to GDPR/ePrivacy. SnipForm’s operating company is UK-registered with EU hosting.
CCPA/CPRA + US state laws	SnipForm does not sell or share personal information for cross-context advertising and operates as your service provider.
PIPEDA / LGPD / Swiss FADP	Same processor posture; EU residency and deletion rights carry the load.

Opt-out and browser privacy signals

Visitor opt-out - the tracker ships an objection mechanism you can surface from your own privacy page or settings:

signals.optOut();    // stop tracking this visitor (persists across visits)
signals.optIn();     // clear the flag and resume immediately
signals.optedOut;    // current state (boolean)

Opting out stores a single localStorage flag - the only thing Signals ever writes to a device, at the visitor’s own request - and makes the tracker fully inert: no request leaves the page, and future page loads never initialize. This is the objection capability EU regulators’ consent-exempt audience-measurement conditions call for.

Global Privacy Control - browsers sending Sec-GPC: 1 are never identified: the identify endpoint becomes a quiet no-op for them (gpc: true in the response). Anonymous measurement is unaffected, because GPC governs the sale, sharing, and profiling of personal information - and anonymous sessions contain none to govern.

Practical guidance

• Keep PII out of URLs. Entry and exit URLs are stored with query strings. If your site puts emails or tokens in URLs, they will land in your analytics.
• Webhooks and automations send what you configure. Automation payloads include submission fields and request metadata; routing them to Slack, Zapier, or your own endpoint is a transfer you control.
• Identify deliberately. signals.identify() turns an anonymous session into personal data. Call it where you have a basis to, and use contact deletion when asked to erase someone.

This page documents engineering facts, not legal advice - your obligations depend on your use, your visitors, and your jurisdiction.