Every cookie, and which page sets it
v0.5
There are four places a browser meets us, and each sets a different, short list. Nothing here follows you between sites, and none of it is sold or handed to an advertiser.
This site
- Referral and campaign tags (
ss_attrib) — if you arrive from a link carrying a referral or campaign tag, the tag is stored so a signup weeks later is credited to the right place. First arrival wins; a later visit does not overwrite it. It carries no name, no address and no identifier we can trace to a person. - Site analytics — the page-view count comes from Cloudflare Web Analytics, which sets no cookie at all. It reports totals, not people, and builds no profile.
- The bot check — sign-up, sign-in, the password-reset form and guest booking load Cloudflare Turnstile, which sets its own short-lived cookie for the length of the challenge.
A studio's booking site
- Your account (
__Host-customer-auth.*) — set when you sign in to book or to look at your bookings. Six cookies at most, covering the session, the two-factor step and a device you asked us to remember. They are marked__Host-, which means they are locked to the one hostname that set them and cannot be written by another studio's site. - A password-locked storefront (
sf_access) — a studio can put its site behind a password before it opens. Entering the password sets a signed cookie so the next page does not ask again. - The studio's own analytics — a studio may add its own tracking tags, such as an advertising or chat vendor. Those set that vendor's cookies on that studio's site, and the studio chooses whether to ask you first. Where it requires consent, a decline is remembered in your browser and no tag is loaded. A decline is final for that browser whatever the studio's setting says.
Checkout
The page holding the card form runs no theme script and no analytics or advertising tag; the only outside scripts there are the card processor's and the bot check. It carries a signed token in its own address and, if you are signed in, the same account cookies as the rest of the storefront. A studio's tracking is switched off there on purpose: a replay of a checkout would carry that token with it.
The studio console
- Staff sign-in (
__Host-staff-auth.*) — the same six-cookie set as a customer account, on the console's own hostname. A browser can hold up to five staff accounts at once, each with its own cookies. - Product analytics — the console records which features studio staff use, through PostHog, which keeps its identifier in a cookie and in browser storage. It runs for signed-in staff only, and never on a storefront or on checkout.
Turning them off
The sign-in cookies are what keeps you signed in, so blocking them means signing in on every page. Everything else can be blocked in your browser without breaking a booking. Clearing site data removes all of it, including a remembered decline of a studio's tracking.
Contact
Questions about cookies: [email protected]. See also the privacy policy.