> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Ad Consent Signals: TCF, GPP, GPC & us_privacy
> How Orbit ingests the standardized ad-tech consent signals — IAB TCF v2.2, IAB GPP, Global Privacy Control, and the CCPA us_privacy string — and translates them into per-destination gating on your Meta, TikTok, and Google ad connectors.
# 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 CCPA `us_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
| Signal | Format | Regime | What it encodes |
| -------------------------------- | ------------------------------------------------------- | ------------------------------ | ----------------------------------------------------------------------------------------- |
| **IAB TCF v2.2 TC string** | Base64url core segment, e.g. `COwg...` | EU / UK opt-in (GDPR) | Per-purpose consent bits (24 purposes), CMP identity, special-feature opt-ins, timestamps |
| **CCPA `us_privacy`** | 4-character string, e.g. `1YNN` | US opt-out (CCPA/CPRA) | `Y`/`N`/`-` flags for notice-given, opt-out-of-sale, and LSPA coverage |
| **Global Privacy Control (GPC)** | `Sec-GPC: 1` header or `navigator.globalPrivacyControl` | US opt-out (CCPA + state laws) | A universal "do not sell/share my data" opt-out signal |
| **IAB GPP** | `~`-separated header + sections, e.g. `DBABMA~bQVJ...` | Multi-regional wrapper | A container that carries regional strings (TCF, US state sections) in one payload |
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.
```bash theme={null}
curl -X POST https://api.orbit.devotel.io/api/v1/cdp/ad-consent/decode \
-H "Authorization: Bearer $ORBIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"us_privacy": "1YYN",
"gpc": true,
"tc_string": "COwgHhPOwgHhPOAcUvENBeCoDPAACDAABiAAB4AA",
"gpp_string": "DBABMA"
}'
```
```json theme={null}
{
"data": {
"signals": {
"tcf": { "version": 2, "purposesConsent": [1, 3, 4, 7, 8], "...": "..." },
"usPrivacy": { "noticeGiven": "Y", "optOutSale": "Y" },
"gpp": { "present": true, "version": 1, "sections": [] },
"gpc": true,
"regime": "mixed",
"saleOptOut": true,
"hasAnySignal": true
},
"google_consent_mode_v2": {
"ad_storage": "denied",
"ad_user_data": "denied",
"ad_personalization": "denied",
"analytics_storage": "granted"
},
"meta": {
"limited_data_use": true,
"data_processing_options": {
"data_processing_options": ["LDU"],
"data_processing_options_country": 0,
"data_processing_options_state": 0
}
},
"tiktok": { "limited_data_use": true },
"destinations": {
"meta_capi": { "restricted": true },
"tiktok_capi": { "restricted": true },
"google_ads": { "restricted": true }
}
}
}
```
Every response is derived from the same decoders the delivery routers
call, so the preview you get here is exactly what the pipeline will do.
***
## 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 CCPA `us_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/state `0/0`) and
TikTok `limited_data_use: true` whenever the decoded signals restrict
processing.
* Events carrying no consent-signal keys forward exactly as before — no
consent-mode fields are attached.
What the decode endpoint reports for a given signal bundle is the
gating those routers apply. There is one translation, so the preview
equals production.
***
## 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](/compliance/consent-management) — the
per-contact consent ledger the fanout check reads.
* [Consent default policy](/compliance/consent-default-policy) — the
tenant-owned knob that decides what a contact with no ledger row may
receive.
* [DSAR](/compliance/dsar) — the CCPA opt-out-of-sale
(`opt_out_sale`) request flow this signal set complements.
* [Your Tenant Compliance Posture: The Toggle Map](/compliance/posture-overview) —
where the ad-consent signal surface sits among the rest of the
tenant-owned controls.
Nothing on this page weakens or bypasses the standing compliance rules:
an explicit opt-out, a suppression entry, revoked consent, or an erasure
beats any decoded signal, always.
Orbit enforces; it does not advise. The platform decodes the signals
you forward and gates destinations accordingly — it never decides that
an event is "compliant." Honor the signals your CMP or SDK sends, and
choose your posture with counsel. This page is not legal advice.
***
## Related references
* [Consent Management & Receipts](/compliance/consent-management)
* [Consent default policy](/compliance/consent-default-policy)
* [DSAR](/compliance/dsar)
* [Your Tenant Compliance Posture: The Toggle Map](/compliance/posture-overview)