Privacy & security

Consent

The tracker never touches document.cookie. What it does before and after a visitor consents depends on the website's consent mode, set in Settings → Privacy:

The anonymous id is a hash of the visitor's IP address and browser with a salt that changes every day and is then destroyed, so a visitor cannot be followed from one day to the next — or identified at all once the day is over.

Tell the tracker about consent from your cookie banner, whenever the visitor decides:

// The visitor accepted analytics: identified features start at once, no reload.
seentics.consent(true);

// The visitor declined or withdrew: recording stops and every
// Seentics id in their browser is removed.
seentics.consent(false);

When consent is already known before the tracker loads — your banner remembered an earlier choice — set window.seenticsConsent = true before the script tag, or add data-consent="granted" to it. The tracker also remembers the last choice made through seentics.consent() itself.

For a cookie banner's inventory: after consent the tracker stores snc_vid (visitor id), snc_sid, snc_se and snc_ss (session), snc_rd (recording sample decision) and snc_cfg:* (the site's settings, so the next page starts faster) in localStorage, and snc_fs:* (funnel progress) and snc_hmshot:* (heatmap snapshot sent) in sessionStorage. snc_consent records the visitor's choice itself. None is set before consent in the default mode.

What is not collected

• No IP storage. The address is used in memory to look up a coarse location (country, region, city) in a database on our own servers, and is never stored.
• No typed input. Form fields and rich-text editors (anything contenteditable) are masked in recordings, always — it is not a setting that can be turned off.
• No cross-site tracking. A visitor ID is per site. There is no shared identity graph between the sites you track, or between customers.

What a recording does include

A recording is more than the DOM. Alongside the replay itself, Seentics stores the annotations that make one worth watching — and it is worth knowing what those are before you enable recording on a page that handles personal data.

• Console output. Calls to console.log/info/warn/error/debug, up to ten arguments each, truncated at 1,000 characters.
• Network requests. Method, URL, status and duration for every fetch and XMLHttpRequest. Request and response bodies are never read.
• JavaScript errors. Message, stack, file and line for uncaught errors and unhandled rejections.

All three are scrubbed before they leave the browser. URL credentials and fragments are dropped; query values under keys that look sensitive (token, password, api_key, email, otp, and similar) are replaced with redacted; and anything shaped like an email address or a bearer token is removed from console arguments, error messages and stack traces wherever it appears.

Both sidecars can be switched off on the tracker script tag, in which case the override is never installed at all — console and fetch are left untouched:

• data-capture-console="off" — no console capture.
• data-capture-network="off" — no request capture.

Keeping things out of recordings

Beyond input masking, mark elements you do not want captured. All three attributes are read from the DOM by the recorder:

• data-seentics-block — replaced by a placeholder; contents never captured.
• data-seentics-mask — the element still renders and animates, but its text is replaced with asterisks. Use it where the layout matters and the words do not.
• data-seentics-ignore — captured once, then changes inside it are not tracked.

See the tracker reference for examples.

Whole pages can be masked too, in Settings → Session replays → Text masking: every word on them is replaced with asterisks of the same length, in recordings and heatmap snapshots alike, so layout and clicks still show. Either all pages, or those matching a list of patterns — by default the ones that usually show a visitor's own details: /account, /profile, /settings, /checkout, /billing and /orders. It follows single-page-app navigation: route onto a masked page and the masking starts there.

Turning features off

Every feature has its own switch per website in Settings → Features: session recordings, heatmaps, funnels, automations and error tracking. A feature switched off is not loaded in your visitors' browsers at all — its code is never downloaded and none of its listeners run — and anything that still arrives for it is dropped, not stored.

Recordings and heatmaps also take page rules: an include list (only these pages) and an exclude list (never these pages), one URL pattern per line, such as /checkout/* or /account/*. Recordings can also be sampled; a visit is either recorded in full or not at all.

Data subject requests

When one of your visitors asks for their data, or for it to be erased, answer from Settings → Privacy → Visitor data request. Find them by their visitor id — what seentics.visitorId returns in their browser — or by the user id you passed to identify(). Export downloads everything held about them as JSON: their events, recordings, errors, profile and linked ids, and the automations that ran for them. Erase removes all of it, recording files included, at once.

The same is available over the API:

Deleting a website erases everything it collected, in every product. Deleting your account (Profile → Delete account) erases every website you own, and cancels your subscription. Encrypted backups expire within 30 days, after which no copy remains.

Retention

How long data is kept depends on your plan; the figure is on the pricing page. Older data is removed automatically once it passes that window.

Self-hosting

The strongest privacy answer is that the data never leaves your infrastructure. Point the tracker at your own host with data-api-host and no third party is involved at all.

Our own policies

Privacy notice · Data processing agreement · Subprocessors · Terms of service