Ad Consent Signals: TCF, GPP, GPC & us_privacy
A conversion tracked by your web or server SDK is only as lawful as the consent context forwarded with it. Browsers and consent managers convey that context in standardized strings: the EU sends IAB TCF v2.2 consent (TC) strings, US browsers pair the CCPAus_privacy string with a Global
Privacy Control (GPC) flag, and multi-region CMPs wrap both inside an IAB
Global Privacy Platform (GPP) string. When a tracked event fans out to an
ad connector without that context, platforms like Meta and TikTok receive
full-fidelity data the subject may have opted out of — and you have no
auditable record of which signal drove the decision.
Orbit ingests all four signals and translates them into the exact
gating fields each ad platform publishes: Google Consent Mode v2, Meta
Limited Data Use, and TikTok limited_data_use.
Forwarding consent context is a tenant-owned posture decision, not a
platform mandate. Orbit decodes what you send and gates destinations
accordingly; choosing which signals your properties must collect —
and honor — remains your responsibility, ideally with counsel. This
page is not legal advice.
The four signals
Send whatever your property captures on each event — either as top-level
event properties (
tc_string, gpp_string, us_privacy, gpc) or
under a nested consent object. The decoder accepts the common key
spellings (tcString, tcf, globalPrivacyControl, and so on).
The inspection endpoint
POST /api/v1/cdp/ad-consent/decode (owner, admin, or developer role)
decodes whatever signals you pass and returns both the normalized bundle
and the enforcement each destination would apply. Use it to validate the
consent context your client or server SDK attaches to tracked events
before those events fan out to the ad platforms.
How GPP is scoped — honestly
All four signals are ingested and validated. The consent decision is driven by the three fully decodable signals — the TCF v2.2 core string, the CCPAus_privacy string, and GPC — in the same combination browsers
actually send (GPC and us_privacy travel alongside the GPP string).
The GPP string itself is captured, its header is validated (Type=3), and
its sections are surfaced for forensics. Per-section field decoding —
reading the usnat SaleOptOut bit out of a Fibonacci-range section — is
deliberately not inferred. A GPP string alone never fabricates a
positive grant, and never turns itself into a restriction either: with
only a GPP string present, responses fall back to unspecified /
unrestricted rather than guessing.
Zero-drift parity with delivery
The inspection endpoint and the live ad connectors share the same pure decoders. The Meta Conversions API router and the TikTok Events router both decode the consent context on each event’s properties and attach the translated fields before forwarding:- Events with a TCF,
us_privacy, or GPC value on their properties get Meta Limited-Data-Use fields (["LDU"]with country/state0/0) and TikToklimited_data_use: truewhenever the decoded signals restrict processing. - Events carrying no consent-signal keys forward exactly as before — no consent-mode fields are attached.
Where this fits in the posture
This surface handles the ad-tech consent context — the standardized strings carried alongside an event. The consent decision for the destination fanout is still resolved by your tenant posture:- Consent Management & Receipts — the per-contact consent ledger the fanout check reads.
- Consent default policy — the tenant-owned knob that decides what a contact with no ledger row may receive.
- DSAR — the CCPA opt-out-of-sale
(
opt_out_sale) request flow this signal set complements. - Your Tenant Compliance Posture: The Toggle Map — where the ad-consent signal surface sits among the rest of the tenant-owned controls.