The three signals
TCF 2.2 (IAB Europe): the CMP exposes __tcfapi and a TC string. It encodes per-purpose consent (purposes 1 to 11), per-vendor consent, legitimate-interest signals and special features. Version 2.2 removed legitimate interest as a legal basis for purposes 3 to 6 (personalised ads and content), requires CMPs to show the number of vendors, and introduced a mandatory re-consent cadence. TCF 2.2 is a framework for vendors listed on the Global Vendor List; a first-party tag manager is not a GVL vendor and reads the purposes to gate its own routing.
GPP (IAB Tech Lab): __gpp exposes a GPP string composed of sections — the TCF EU section, the TCF Canada section, US national and US state sections (California, Virginia, Colorado, Connecticut, Utah and others). Each US section encodes opt-outs for sale, sharing and targeted advertising plus sensitive data flags.
GPC (Global Privacy Control): a browser-level signal — Sec-GPC: 1 request header and navigator.globalPrivacyControl === true. Under CPRA and several state laws it must be honoured as an opt-out of sale or sharing. It carries no per-purpose detail.
Mapping to purposes
Track normalises every signal into four purposes: necessary, analytics, marketing, personalization. The mapping is conservative — a purpose is granted only when the signal positively grants it:
| Purpose | TCF 2.2 (__tcfapi) | CMP callback / SDK consent call | GPC |
|---|---|---|---|
| analytics | purposes 1 (storage), 7 and 8 (measurement) consented | analytics granted | unaffected |
| marketing | purposes 1–4 consented | marketing granted | denied when Sec-GPC: 1 or navigator.globalPrivacyControl |
| personalization | purposes 5 and 6 consented | personalization granted | denied when GPC is set |
| necessary | always | always | always |
Where several signals are present, the most restrictive wins. A visitor with a TC string granting everything but a GPC signal set gets marketing and personalization denied. GPP US-state sections are not interpreted purpose by purpose: for US visitors the purposes come from the CMP callback, and the GPC signal — from the browser or from the GPP API — is honoured as an opt-out.
What the SDK actually does
- On load it checks for
__tcfapi,__gppandnavigator.globalPrivacyControl, subscribes to TCF change events and reads the GPC signal the GPP API exposes. - For CMPs that do not implement TCF, the site passes the purposes through the SDK's consent call; the SDK normalises them and ignores unknown purposes.
- Every event carries a consent record: the granted purposes, the source (TCF, GPP, the CMP integration, the API or the server), the policy version, a timestamp, the region when known and the GPC flag. The collector stores it, the policy engine evaluates it per destination, and the DSAR export includes it.
- When consent changes, subsequent events use the new state, and identifiers tied to a withdrawn purpose are removed from storage immediately.
The SDK never sets consent. It has no "accept all" call and no default of granted when a CMP is missing: without a signal, only necessary applies, and the site's own consent banner integration is the way to grant more.
Server-side sources
Events from webhooks and imports have no CMP in the loop. The system that sends them supplies the consent state it recorded for that person — at sign-up, at checkout, on the lead — and the policy engine applies it exactly as for browser events. An event that arrives without consent information carries only the necessary purpose: it is stored as first-party data and reaches no advertising destination. What Track never does is assume marketing consent because the order came from a shop.
Verification
The consent page in the app shows, per site, the CMP detected, the share of sessions with each purpose granted, the share with GPC set and any sessions where signals conflicted. The event debugger shows the consent record on every event and the policy decision per destination, so "why did this purchase not reach Meta?" has an answer in one click.