What Heatlytics records, and who can see it

This describes how the product works, not a legal commitment. Where something isn’t there yet, it says so at the bottom of this page.

In the visitor’s browser, before anything is sent

No setting changes this, including a “show password” toggle.

An explicit rule can unmask these.

Long numbers are masked here too. Everything else is yours to mark, so go through your pages once.

Your own rules: Mask or block elements with an attribute or a selector, or mask all page text. Images inside a masked area become empty boxes.
URLs: Query parameters you list are replaced in recorded URLs, including links inside the page.
A best guess: Card and bank fields are recognised from the field’s words, in its name or label. A field called something unusual may not be, so check yours.

90 days for analytics data

30 days for replays

These are the defaults. Both are set for the whole deployment.

Heatlytics doesn’t store them, and its ingest service doesn’t log them. Country and city come from Cloudflare’s location headers.

An Owner or Admin can delete a user’s sessions, replays, events and properties in an environment. A hashed proof of the deletion is kept.

Roles: Owner, Admin, Member and Viewer, across the organisation or per project. Every page and action checks the role on the server.
Sign-in: Email and password, with attempts limited per email and per address. Passwords are stored hashed, and invites are single-use and expire.
Keys and domains: Each environment has its own public key, which you can rotate, and can be limited to domains you allow.
On your site: The script tag can pin an integrity hash, so the browser refuses it if its bytes change. The script uses no eval.

Heatlytics holds no security certifications. If any of these matter to you, ask us in a demo, and we’ll tell you where each one stands.

Bring it to the demo. If we can’t answer it, we’ll say so.