Privacy and data handling
How PilotFox counts visitors without cookies and what it does with IP addresses.
These pages describe what the PilotFox script and server do with visitor data, as the code does it. They are not legal advice and not a privacy policy: whether you need consent or a notice depends on your site, your users and your law, so check with your own advisers.
- What is stored: the fields of each event, query strings, the visitor's browser storage, replays and bots.
- Access and deletion: who can see what, erasing a user's data, deleting a site, exporting data.
- Opt-out and excluding traffic:
optOut(),?pilotfox_ignoreand Global Privacy Control.
Counting visitors without cookies
The script sets no cookies, and PilotFox's tracking endpoints read none (a browser may attach cookies of PilotFox's own domain to a beacon; they are ignored). Instead, the server computes a visitor id for each request:
visitor id = first 8 bytes of SHA-256( site key ‖ site id ‖ IP address ‖ normalised user agent )- The site key is a secret random value kept per site. Because it differs per site, the same person gets unrelated ids on two sites: visitors cannot be linked across sites.
- The normalised user agent is the browser's user agent in lowercase with every version number replaced, so a browser update does not make a new visitor.
- The browser cannot choose or see its visitor id: it is computed on the server from the request itself.
Site settings → Privacy & identity chooses how long a visitor id lasts:
| Mode | Site key | Effect |
|---|---|---|
| Stable (default) | The site's secret | The same browser keeps its id across days, so returning visitors, retention and user profiles work. |
| Daily rotating | Derived from the site's secret and the current date (UTC) | A new id every day at midnight UTC. The most private option, but a visitor who comes back on a later day counts as new (unless you identify them), so returning-visitor and retention figures drop. |
A session is the visitor's activity until 30 minutes pass without an event, and reports count it once it has an event
other than a web-vitals measurement; see Concepts. Events sent from your server with
an anonymous_id get a visitor id from that id and the site's secret instead (never the daily key),
so they keep their id across days in both modes.
IP addresses
The visitor's IP address is used while a request is processed, and then dropped:
| Used for | Kept |
|---|---|
| The visitor id (above) | Only the id. |
| Location: country, region, city, time zone, approximate coordinates, network (ASN) | The derived fields, with coordinates rounded to two decimal places (about 1 km). |
| Bot checks, exclusions and rate limits | Rate limits keep a keyed hash of the address (an HMAC with the server's secret) for a short time, never the address. |
The address is never stored with events, in sessions, in session recordings, in the bot report or in the server's request logs, which redact it. The browser sends nothing about the address itself; the server reads it from the connection.
When you serve the script from your own domain, your server passes the visitor's address in
the X-PilotFox-IP header, with a secret that proves the header comes from your server. That address is handled
exactly the same way, and the recipes drop your visitors' cookies before forwarding.
Global Privacy Control
Browsers that send the Global Privacy Control signal are not tracked: no events, no identify, no recording. This is on by default; Site settings → Privacy & identity → Respect Global Privacy Control can turn it off. See Opt-out.