Skip to main content

​
Fields never captured

Regardless of what a form asks for, the Pixel drops the value of any field whose name matches a sensitive pattern. The full list: password, secret, token, key, auth, credential, ssn, credit card, cvv, cvc Matching is case-insensitive and substring-based, so user_password and apiToken are both caught. Beyond that:
  • File uploads are never sent. File inputs are skipped entirely — the Pixel records nothing about the file, not even its name.
  • Password-typed inputs are excluded from form detection, so they never become part of a form’s mapped structure.
  • CMS password gates are ignored. A form that is exactly a Webflow-style gate (page + pass + path) is recognized as a gate rather than a lead form and skipped.
On submission, the filter matches on the field’s name, not its input type. A password input named something outside the list above — pwd, for example — is not recognized as sensitive. Name your sensitive fields to match the patterns above, or exclude the form with data-default-ignore.

​
Turning capture off

You have three levels of control, from broadest to narrowest. Paths excluded by default. The Pixel doesn’t capture anything on pages whose path contains /login, /signin, /account, /checkout, /oauth, or /admin/. Matching is a case-insensitive substring test on the path, so /my-account/settings is excluded too. Note that /admin/ needs the trailing slash — a page at exactly /admin is not excluded. A whole page. Add this to the page’s <head>:
A single form or region. Add data-default-ignore to a form, or to any element that contains it. The Pixel skips submissions, interactions, and detection for anything inside:
The Pixel respects visitor consent choices for two categories, and gates the corresponding tracking behavior accordingly: Form capture is never gated. Submitting a form is itself an affirmative visitor action, so submissions are always captured, regardless of consent state. Neither is form discovery — the background scan that finds which forms are on a page. Form capture can’t work without it: a form Default hasn’t discovered can’t be approved, so it can never capture anything. The scan reads the form’s own structure, not the visitor.

​
Default behavior

Out of the box, both categories are allowed — this is an opt-out model, not opt-in. Tracking runs normally until a visitor withholds consent through your site’s own consent tooling.
The Pixel doesn’t ship a consent banner or detect third-party consent tools (OneTrust, Cookiebot, and similar) automatically. If you need visitors to be asked before tracking runs, your own banner is responsible for asking and for telling the Pixel the answer — see Wiring up your consent banner below.
  • Analytics withdrawn: any identity already stored is cleared immediately, and no further identity is written to either cookies or sessionStorage — browser session storage is non-exempt storage too, so it isn’t used as a fallback. Pageview and session tracking stop. The visitor is still tracked for the current page in memory (so a single-session experience like the scheduler handoff keeps working), but nothing durable is written, and that in-memory state is gone once the page unloads.
  • Marketing withdrawn: Reveal won’t load going forward. If it had already loaded earlier in the session before consent was withdrawn, that can’t be undone retroactively — the setting only affects loads from that point on.
A grant made later is picked up without a page reload. Marketing consent loads Reveal on the spot, or — if the visitor is on a page where tracking is excluded, such as /checkout — on the next eligible page they visit. Have your consent banner call setConsent once the visitor makes a choice. Which call to use depends on which script you’ve installed:
You can pass either or both keys — omitted keys keep their current value. Calling window.__defaultPixel__.setConsent is safe even immediately on page load, before the async tracker script has finished loading: calls are queued and replayed automatically once it’s ready. The visitor’s choice is remembered (in a first-party cookie) so it persists across visits — you don’t need to re-collect it on every page load once your banner has made the call.
Marketing consent only has an effect where Reveal actually loads — the tracker snippet. On a page that loads only the standalone SDK (sdk.js) without the tracker, there’s no Reveal to gate, so setConsent({ marketing: false }) there is accepted but has nothing to do. Analytics consent applies everywhere.