Privacy in the embed

This page describes what actually happens on a visitor's device when a mado demo is embedded — not a policy summary, the mechanism.

No cookies, no persistent storage

The player sets no cookies and writes nothing to localStorage, sessionStorage, or IndexedDB. Session identity is a random id generated fresh on every page load and held only in memory — it is not written anywhere, and it disappears the moment the tab closes or the page reloads.

How unique viewers are counted without a cookie

Unique-viewer counting happens server-side, from a daily-rotating hash of (IP address + user agent + demo id). The raw inputs are never stored — only the hash. Because the secret behind it changes every day and the demo id is part of it, a stored hash cannot be linked to the same visitor on another day or on another demo. That is the whole mechanism, and it's why embedding a mado demo doesn't require adding it to your own consent banner.

What is sent, and when

The player emits one event per interaction — a step view, a hotspot tap, a completion — batched every couple of seconds. Each event carries the demo id, the step id, a coarse device class (phone / tablet / desktop), the referring page, the tracked-link label when the viewer arrived through a link such as ?for=acme (a name the creator chose), and a country when the network in front of our server supplies one. It never carries anything typed into the host page, and it never reads the host page's DOM beyond mounting itself.

Bots

Suspected bot traffic is flagged with a reason and excluded from every visible count — it is never silently deleted, and the dashboard says how many views were excluded.

Redaction

Anything an author redacts before publishing is removed from the pixels of the published asset at publish time. It is not a box drawn over an intact image — there is nothing underneath to reveal.