Trust and data

Your data

• Viewer analytics set no cookies. The only cookie on a demo page is the access-gate cookie (dm_gate_*), set after a viewer unlocks an email-gated demo and disclosed in our Cookie Policy; the analytics beacon reads the email out of it so the session is attributed to the viewer who typed it.
• We do not store a viewer's IP address, User-Agent, or referrer with these events. The IP is used to rate-limit the endpoint and is hashed before it reaches storage, so what is kept is a digest we cannot reverse.
• A viewer can switch measurement off. If their browser sends Global Privacy Control or Do Not Track, or the link carries the parameter analytics=0, we record nothing.
• We identify a viewer only when they identify themselves — by submitting a form in the demo, by passing an email gate, or through an email parameter on the link they were sent. We do not fingerprint devices, and the analytics session id is a random value held in memory that cannot recognise a returning viewer.
• What a viewer typed is masked while the page is being captured, inside the browser, before anything is uploaded. Masking is on by default, and password and card fields are dropped whether or not the author leaves it on.
• Redacted means gone — when you use the opaque fill. A fill removes the covered text from the page we publish: the words are not in the bytes we serve on the share page, in a hub, or in an offline export. Blur is different and is the editor's default tool, so the editor labels it Cosmetic where you pick it — it softens the pixels, and the words stay in the page source where they can still be read. When something must actually be gone, use the fill.
• A queued push to a connected CRM stops holding what the viewer typed the moment it succeeds: the contents are erased in the same write that marks the delivery done.
• Deleting a lead erases the lead record, the viewer-identity records tied to it, and the copies sitting in the CRM and webhook delivery queues. Two things it does not reach: answers typed into an in-demo form are stored with the demo rather than the lead, and remain until that demo is deleted and purged; and copies that already left us — a notification email your team received, or a record already pushed to a CRM you connected.

AI

• AI is optional. Capturing, editing, publishing, sharing, and playing a demo require no AI call. With no AI provider configured, the AI affordances are not rendered at all and every other feature works unchanged.
• The model never authors HTML. An AI edit is a list of find-and-replace text pairs; our server locates the real text nodes in your demo and builds every operation itself. Nothing the model returns can introduce markup, scripts, or attributes.
• You accept edits one row at a time. Each proposed change is shown as a before-and-after diff with its own checkbox, and nothing is written until you apply the rows you picked.
• Viewer data cannot reach the model. Prompts are assembled at a single place in the code from a closed allowlist of author content — your demo's own text and the instruction you type. Lead records, form answers, and session analytics are not reachable from that path, and a record carrying them is rejected before a prompt is built.
• One provider. Our AI features call Anthropic's API, and no other AI vendor is wired into the product.

How it is built

• The frame that plays your captured page never runs scripts. Its sandbox grants same-origin access only — the token that permits script execution is never added — and scripts and event-handler attributes are stripped out of captured HTML before it is stored. Two independent layers, either of which alone would stop it. The one frame that does allow scripts is the third-party overlay embed you opt into (a scheduler or form you add to a step), which runs on that vendor's own origin and never on your captured page.
• Webhooks are signed. Every delivery carries an HMAC-SHA256 signature over the timestamp and the body, so your endpoint can verify it came from us and reject a replayed request. Rotating a secret sends both signatures during a grace window, so you can roll it without dropping events.
• Workspaces are separated in the query. Every server action that touches workspace data runs with an authenticated organisation context, and those reads are filtered to that organisation.

What you control

• Access, per link: publish a demo as a public link, behind a password, or behind an email gate; set an expiry; turn search indexing off; disable a link at any time. The email gate has two levels — check the address against your domain allow and block lists, or additionally email a six-digit code that must be entered before the demo opens. The domain check alone does not prove the person owns the address; the code does.
• Masking: on by default when you capture. You can choose to show typed values on a demo; password and card fields stay masked either way.
• Export: any demo as a single offline HTML file, your leads as CSV, and your workspace audit log as CSV. An exported file plays without the link's password, gate, or expiry — treat the file as the content itself.
• Deletion: delete a lead from the leads view at any time — see above for what that reaches and what it does not.

What we do not claim

• We hold no third-party security certification and no completed audit report, and we do not describe DemoMate as certified or compliant under any security or privacy framework. If your procurement process requires an audit report, we cannot supply one.
• We do not run live copies of your application. A DemoMate demo is a captured snapshot, so nothing here should be read as a claim about live or sandboxed environments.
• We have not completed a screen-reader audit, so we make no accessibility conformance claim.
• We do not identify the company a viewer works for. Company reveal is not switched on, and no visitor data is being enriched.

Questions

Privacy questions go to [email protected]; anything else to [email protected]. The binding documents are our Privacy Policy, Cookie Policy, and Terms of Service.