Features
Consent-aware by construction
Every destination receives exactly what the visitor agreed to — evaluated for each event, in the browser and again on the server — so compliance is not a banner setting you hope is right.
Consent state and derived signals
Example data: Static example state — not live traffic, no real customer data.Purposes
- Strictly necessarygranted
- Analyticsgranted
- Marketingdenied
- Personalizationdenied
Consent Mode v2
analytics_storagegrantedad_storagedeniedad_user_datadeniedad_personalizationdenied
Block reasons the policy engine reports
consent_missing- no consent signal for the event yet
consent_denied- the visitor declined
purpose_not_granted- destination needs a purpose that was not granted
gpc_opt_out- Global Privacy Control set
destination_paused- kill switch or circuit breaker
inferred_data_not_exportable- inferred consent never reaches ad platforms
Purposes come from your CMP; everything else is derived, never guessed.
Example consent state: analytics granted, marketing denied — and the Consent Mode v2 flags and block reasons derived from it.
The gate sits in front of every destination
Consent is not a banner integration but a policy engine: purposes, regions, destination requirements and click-id capture are evaluated for every event in the browser and again on the server.
Each destination declares the purpose it needs. When an event arrives, Track compares the consent snapshot with that requirement: analytics destinations receive events with analytics consent, advertising destinations only with marketing consent. A withdrawal stops sends immediately, and nothing stored before consent is replayed afterwards.
How it is built
The technical decisions behind the capability — the proof after the benefit.
01
CMP adapters and API
TCF 2.2, GPP and Global Privacy Control, Cookiebot, OneTrust and Usercentrics adapters, plus a consent API for custom banners.
02
Consent Mode v2, purpose-based
Google consent signals are derived from purposes; advanced mode is available only with a documented legal review note.
03
Evidence
Deduplicated consent snapshots are stored with each event so you can prove what was granted when.
Consent per tag versus a policy engine
Where the decision is made — and whether you can prove it later.
| Consent per tag versus a policy engine | Consent handled per tag | Policy engine in Track |
|---|---|---|
| Decision point | Each tag's trigger, configured by hand | Every event, every destination, in the browser and on the server |
| Server-side events | Sent regardless of the banner | Same purpose check as browser events |
| Withdrawal | Takes effect on the next page load, if at all | Stops sends immediately; no replay of earlier events |
| Evidence | None | Consent snapshot stored with each event |
What you can verify
Product facts you will find in the dashboard, the docs and the audit log.
- Inferred consent is never exported to advertising platforms
- Withdrawal stops sends immediately
- Server purchases stay operational, never advertising without consent
Questions
- Which regions are supported?
- Strict opt-in for the EU/EEA/UK/CH by default; per-region policies can be configured, but never weaker than the legal baseline without an explicit decision.
More capabilities
Built on the same signed configuration and event schema.
- AI-guided setup
Describe your site, confirm each step, publish a signed configuration.
- Server-side event router
One event, every platform: browser and server delivery with shared deduplication.
- Event debugger and lineage
See every event with its consent snapshot, routing decision and vendor response.
- Data quality and health score
A single score with explainable components and issues that link to their fix.
- Click ids and attribution done right
Capture only the ids the destination needs, only with consent, only for the documented window.
Try it on your domain
Create a site, install one snippet and let the assistant configure the first destination in minutes.