Consent

Coming soon. Web tracking isn't generally available yet — today it runs only on pages and forms published from the app. See Overview for what's live now.

Tracking respects three things, in this order: the visitor's browser do-not-track setting, the consent choice you've collected, and only then your tracking configuration.

You have three ways to handle consent, and you should pick one deliberately rather than let the default decide for you.

Most common, and the one to choose if you use OneTrust, Cookiebot, Osano, Termly, Axeptio, or anything similar.

Your existing banner stays in charge. Tell it to switch tracking on when the visitor accepts, and off when they decline. Whoever installed your banner wires this up once — the instructions are in Installing the script.

⚠️ This needs one setting on the script tag: data-require-consent="true". Without it the script starts tracking on page load, and your banner's "decline" would arrive after the fact. It's a single attribute, but leaving it off quietly defeats the whole arrangement.

Until your banner says yes, nothing is stored and nothing is sent. No cookies, no identifiers, no page views. Views that happen while the visitor is still deciding are held briefly in memory and either sent when they accept, or thrown away if they decline.

Option 2 — use the built-in banner

If you don't already have a cookie banner, you can switch ours on with a single setting. It's deliberately plain: a short message, an accept button, and a decline button, with fixed English wording — there's no setting yet to customise the text.

It's off by default — it only appears once you turn it on. Turning it on doesn't add a separate download either way: the banner ships as part of the one small script you're already loading (about 5.2 KB gzipped, in total), not a separate request that only banner-visitors pay for.

This is the right choice if you need a consent banner and don't want to buy one. It is not a full consent-management platform: it doesn't categorise cookies, produce audit logs, or handle consent for other tools on your site. If you need those, use option 1.

Tracking begins immediately on page load. Do-not-track is still respected — that can't be switched off — but nothing waits for permission.

This is the default if you don't configure anything, and it is the right choice only where you're confident consent isn't required for first-party analytics cookies in the places your visitors are. That varies by jurisdiction and it changes; it's a question for your legal advisor, not a setting to pick by feel.

While a visitor hasn't decided:

  • No cookies are set. Not even the visitor ID.
  • No email or phone is captured, even if they submit a form.
  • Page views are held in memory, not sent, up to a small limit.
  • If they accept, the held views are sent and tracking continues normally.
  • If they decline, the held views are discarded and no identifiers are stored — only the fact that they declined, so they aren't asked again.

If a visitor declines after previously accepting, their stored identifiers are deleted from their browser straight away.

Do-not-track

If a visitor's browser sends a do-not-track signal, nothing is sent at all — no page views, no identification, regardless of your consent setup or their banner choice. This is always on and cannot be disabled.

It's worth knowing that most browsers no longer expose this setting prominently, so in practice it affects a small number of visitors.

A question worth asking

Consent choices are stored per browser, not per person. Someone who accepts on their phone and declines on their laptop is two separate decisions, and their laptop visits stay anonymous. That's the correct behaviour — a consent choice belongs to the browser it was made in — but it does mean your identified visitor numbers will be lower than your total visitor numbers, sometimes substantially.