OpenRTB protocol
Privacy signals in OpenRTB: gdpr, gpp, us_privacy, coppa
OpenRTB 2.6 carries privacy state in a handful of exact places: flags and strings on regs (coppa, gdpr, us_privacy, gpp, gpp_sid), the TCF consent string on user.consent, device-level signals on device.lmt and device.dnt, and identity in user.eids. Several of these moved out of ext in 2.6, which is where most integration bugs come from.
regs.coppa
regs.coppa is an integer flag indicating whether the request is subject to the COPPA regulations established by the US FTC, where 0 = no and 1 = yes. It arrived with the Regs object itself in OpenRTB 2.2 and has kept the same path ever since, making it the oldest regulatory field in the bid request. When it is 1, buyers are expected to disable behavioral targeting, ID collection, and retargeting for the impression.
regs.gdpr and user.consent
GDPR support entered OpenRTB in 2018 through the IAB GDPR advisory as a pair of extension fields: regs.ext.gdpr and user.ext.consent. OpenRTB 2.6 promoted both to first-class attributes, and the change log records each as "previously ext".
regs.gdpr: integer. 0 = not subject to GDPR, 1 = subject to GDPR, omission = unknown.user.consent: string. When GDPR applies, this holds the Transparency and Consent Framework (TCF) consent string, the base64-encoded structure a CMP produces. It is a string onuser, not an object, and not underregs.
A request with regs.gdpr: 1 and no user.consent tells bidders consent is unresolved; most will bid without personalization or not at all.
regs.us_privacy
regs.us_privacy is a string carrying the IAB US Privacy string (the CCPA signal, for example "1YNN"). Like the GDPR fields it began life as an extension, regs.ext.us_privacy, defined by the IAB CCPA/US Privacy OpenRTB extension in 2019, and became first-class in 2.6. IAB Tech Lab has since deprecated the US Privacy string in favor of the Global Privacy Platform, so treat this field as legacy: keep parsing it, but emit GPP for new work.
regs.gpp and regs.gpp_sid
The Global Privacy Platform fields were added in the 2.6-202211 update and are the current home for consent signals across jurisdictions.
regs.gpp: string. The encoded GPP consent string, which can bundle multiple regional sections (TCF EU, TCF Canada, US national, US state strings) in one value.regs.gpp_sid: integer array. The section ID(s) of the string that apply to this transaction. Per the spec it will generally contain one and only one value, and GPP sections 3 (header) and 4 (signal integrity) do not need to be included.
The two fields travel together. A gpp string without gpp_sid forces every bidder to guess which section governs the request, and many will discard the signal instead.
DSA transparency: regs.ext.dsa
The EU Digital Services Act disclosure fields are defined by an IAB Tech Lab community extension and, unlike the fields above, still live under ext. On the request, regs.ext.dsa carries dsarequired (0 = not required, 1 = supported, 2 = required, 3 = required and the publisher is an online platform), pubrender (whether the publisher will render the transparency notice), datatopub (whether transparency data should be sent for audit), and a transparency array of { domain, dsaparams } objects. The bid response answers in bid.ext.dsa with behalf, paid, its own transparency array, and adrender. Check the extension document for the current shape before wiring it; it is versioned separately from OpenRTB itself.
device.lmt and device.dnt
Two integer flags on device predate all of the regulation strings. device.dnt is the browser Do Not Track header (0 = tracking unrestricted, 1 = do not track). device.lmt is the commercially endorsed Limit Ad Tracking signal from mobile operating systems, with the same 0/1 semantics. On iOS traffic, lmt: 1 typically arrives alongside a zeroed device.ifa.
user.eids and how privacy signals gate them
user.eids is an array of EID objects, each naming an identity source and carrying one or more uids; 2.6 snapshots add inserter, matcher, and mm (match method, an AdCOM list). Extended IDs are exactly the data the rest of this page regulates: if regs.gdpr is 1, IDs may only be passed for vendors with consent in user.consent; if the GPP section or us_privacy string signals an opt-out, or coppa is 1, the array should be emptied. Sending a full eids array against an opt-out is a compliance bug that validation of structure alone will not catch, so audit the gating logic, not just the schema.
Signal map
| Signal | Path | First-class since | What consumes it |
|---|---|---|---|
| COPPA flag | regs.coppa | OpenRTB 2.2 | Buyers suppress behavioral targeting and restricted categories |
| GDPR applicability flag | regs.gdpr | 2.6 (regs.ext.gdpr before that) | Bidders decide whether TCF consent is required |
| TCF consent string | user.consent | 2.6 (user.ext.consent before that) | CMP-decoded vendor and purpose consent for every party |
| US Privacy (CCPA) string | regs.us_privacy | 2.6 (regs.ext.us_privacy before that) | Buyers honor opt-out of sale; superseded by GPP |
| GPP consent string | regs.gpp | 2.6-202211 | Multi-jurisdiction consent, one string, sectioned |
| GPP applicable sections | regs.gpp_sid | 2.6-202211 | Tells bidders which GPP sections govern this transaction |
| DSA transparency | regs.ext.dsa | IAB community extension (2023) | EU DSA disclosure requirements on request and bid |
| Limit ad tracking | device.lmt | OpenRTB 2.2 | OS-level signal; buyers drop device-ID targeting |
| Do not track | device.dnt | OpenRTB 2.0 | Browser header flag; same effect for web traffic |
| Extended IDs | user.eids | 2.6 (user.ext.eids before that) | Identity providers; must be gated by the signals above |
Common mistakes
- Sending
regs.ext.gdproruser.ext.consentin a 2.6 payload. Old SDKs and hand-rolled adapters keep the pre-2.6 paths alive; bidders reading only the first-class fields see no signal at all. rtblint flags moved fields withopenrtb.field.moved. - Sending
regs.gppwithoutregs.gpp_sid, or the reverse. The pair is only interpretable together. - Putting the TCF consent string in
regs. Consent belongs touser.consent;regsonly says whether GDPR applies. - Typing flags as strings (
"gdpr": "1").coppa,gdpr,lmt, anddntare integers, andgpp_sidis an integer array. See the common OpenRTB mistakes guide for more of these.
Frequently asked questions
Where does the GDPR flag go in OpenRTB 2.6?
regs.gdpr, an integer where 0 means the request is not subject to GDPR, 1 means it is, and omission means unknown. The TCF consent string itself goes in user.consent. Before 2.6 both lived in extensions (regs.ext.gdpr and user.ext.consent) per the IAB GDPR advisory; 2.6 promoted them to first-class fields.
Do I need gpp_sid if I send regs.gpp?
Yes. regs.gpp carries the encoded Global Privacy Platform string and regs.gpp_sid is the integer array of section IDs that apply to the transaction. Without gpp_sid a bidder cannot tell which jurisdiction's section governs the request. It generally contains exactly one value, and GPP sections 3 (header) and 4 (signal integrity) do not need to be listed.
Is regs.us_privacy still used?
It is still defined in OpenRTB 2.6 and still appears in live traffic, but IAB Tech Lab has deprecated the US Privacy string in favor of GPP. New integrations should carry US state privacy signals in regs.gpp with the applicable section IDs in regs.gpp_sid, and many pipelines send both during the transition.
Validate it
Paste a request into the bid request tester to check your privacy fields against a tracked 2.6 snapshot: moved paths like regs.ext.gdpr surface as openrtb.field.moved, unknown keys as openrtb.field.undefined, and wrong types on the flags are called out with their exact JSON path. The same checks run in CI via the CLI.