PilotFox

Privacy and data

How PilotFox counts visitors without cookies, what it stores and never stores, browser storage, opt-out and Global Privacy Control, replay masking and deleting data.

This page describes what the PilotFox script and app do with visitor data. It is 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. How each design choice helps under the GDPR is on GDPR-friendly by design; our own Privacy Policy and the Data Processing Agreement we sign as your processor are with the other legal pages.

Counting visitors without cookies

The script sets no cookies, and PilotFox reads none when it records a visit. Instead, the server computes a visitor id for each request:

  • It hashes a secret random value kept per site, the site's id, the visitor's IP address and the browser's user agent (with version numbers removed, so a browser update does not create a new visitor), and keeps 8 bytes of the SHA-256 result.
  • Because the secret is per site, the same person gets unrelated ids on two sites: visitors cannot be linked across sites.
  • In the default stable mode the id stays the same across days, so returning visitors, retention and user profiles work. In daily mode (Site settings → Privacy & identity) the secret changes 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.

IP addresses

The IP address is used while a request is processed (for the visitor id, the location, bot checks, exclusions and rate limits) and is then dropped. It is never stored with the events, in sessions, in the rate limiter (which keeps a keyed hash) or in server logs.

When you serve the script from your own domain, your server passes the visitor's address in a header, with a secret that proves the header comes from your server; that address is handled exactly the same way. Your visitors' cookies for your site are not forwarded.

What is stored for each event

KindFields
PageTime, hostname, path, query string (as your settings allow), page title, referrer and its domain, campaign (UTM) parameters, channel, affiliate slug.
Visitor and sessionThe hashed visitor id, a random session id, and the user id if you called identify.
LocationCountry, region, city, time zone and coordinates rounded to two decimal places (about 1 km), looked up from the IP address; the network (ASN) and whether it belongs to a data centre.
DeviceBrowser and its major version, operating system and its version, device type, screen size, language.
EventType, name and properties you send; for errors the message, stack trace, file, line and column; for web vitals the measurements.

Never recorded: form field values, typed input, the text people copy, cookies, and IP addresses. Outbound link text is cut to 200 characters. User traits are limited to 4 KB per user.

Query strings

Site settings → Privacy & identity controls what is kept of page URLs' query strings:

  • Store query string parameters: all (default), only UTM parameters, or none.
  • Strip parameters: up to 50 parameter names removed on the server before anything is stored, for example token or email.

Affiliate parameters are read before these rules apply, so affiliate tracking keeps working with query strings turned off (see Affiliates).

Storage in the visitor's browser

  • localStorage: pilotfox:uid (only after you call identify), pilotfox:optout (only after optOut()) and pilotfox:ignore (only after ?pilotfox_ignore=true).
  • sessionStorage: pilotfox:rs, whether this tab is recorded, only on sites with session replay on.

When storage is blocked, these values live in memory for the page. With a custom data-namespace, the keys start with that name instead of pilotfox.

Opt-out and Global Privacy Control

  • Global Privacy Control: browsers that send the GPC signal are not tracked (no events, no identify). This is on by default; Site settings → Privacy & identity can turn it off.
  • Opt-out: pilotfox.optOut() stops tracking in that browser for your site, in every open tab, and is remembered; pilotfox.optIn() undoes it. You can call these from your own consent banner. Setting window.__PILOTFOX_OPTOUT__ = true before the script loads also stops it for that page.
  • Your own browser: opening a page of the site with ?pilotfox_ignore=true in its address also stops tracking in that browser, and ?pilotfox_ignore=false undoes only that. Anyone can put the parameter in a link to your site, so it never undoes a visitor's optOut(); optIn() undoes both.

Session replay

Session replay records how a page changed so you can watch a visit back. It is off until you turn it on for a site (Site settings → Session replay), and then records a sample of tabs (100 % by default).

  • Every input is masked by default; password fields stay masked even if you turn that off. Hidden and file inputs and CSRF tokens are never recorded, editable text is always masked, and canvas content is not recorded.
  • The site's settings can mask the text of more elements or leave elements out entirely (CSS selectors), and your own markup can use the classes rr-mask (mask the text), rr-block (replace the element with an empty box) and rr-ignore (ignore typing in a field).
  • Pages skipped by data-skip, excluded paths and hostnames outside Allowed hostnames are not recorded.
  • pilotfox.optOut() stops a recording at once, in every open tab of the site, and discards what was not yet sent.

Bots

Requests that the bot filter recognises are kept apart from your analytics (unless you turn blocking off) and shown in the Bots report, with their user agent and which checks flagged them, but without IP addresses.

Who can see what

  • Members see only the sites and reports their role allows, and API keys only what their permissions allow. Customer emails from your payment provider are shown only to people who can see sessions.
  • Share links give read-only access to one site's dashboard, with an optional expiry, and can include sessions, users or replays only if you choose so. A public dashboard shows traffic statistics to anyone with its link, never sessions, users or replays.
  • Share-link and affiliate-portal tokens and API keys are stored as hashes; payment-provider keys (Stripe, Dodo Payments, Polar) and Google tokens are stored encrypted.

Erasing a user's data

On a user's page, Delete user data (editors and above) erases that user's events, sessions, replays, identity links and traits in a background job. Their payments stay in your revenue totals, as your own record of the sale, but lose every link to the user, their visits and their email. The same erasure is available through the API.

Deleting a site erases all of its events, recordings, payments and settings.

Last updated · Markdown version