GPP vs TCF vs the US Privacy string live on different OpenRTB fields, and one does not fill the others.

TCF is a flag plus a string, and the string is not under regs

On OpenRTB 2.6, regs.gdpr is an integer: 0 means no, 1 means yes, omitted means unknown. user.consent is the TCF string, on user, not on regs, and not an object. In 2.5 both lived under ext. A 2.6 reader that finds them only at regs.ext.gdpr and user.ext.consent does not treat those paths as the core fields.

regs.gdpr 1 with no user.consent says consent is unresolved. Most bidders will skip personalization or skip the bid. The string has to decode as TCF. A value of 1 in the consent field is not a TC string. The privacy reference is the path list.

Identity does not override this. user.eids and user.buyeruid still depend on whether the request was allowed to send an id. A populated eid next to an unresolved GDPR flag is not a consented match.

The US Privacy string is legacy, and GPP needs the section id

regs.us_privacy is the IAB US Privacy string, for example 1YNN. It began as regs.ext.us_privacy and became first-class in 2.6. IAB Tech Lab has deprecated that string in favor of GPP. It still appears on live requests. Keep parsing it. New work should emit GPP. Sending only us_privacy does not fill regs.gpp.

GPP arrived in snapshot 2.6-202211. regs.gpp is the encoded string, which can bundle regional sections. regs.gpp_sid is the integer array of section ids that apply to this transaction. The spec says it generally contains exactly one value. Sections 3 and 4, header and signal integrity, do not need to be listed. Without gpp_sid, a bidder cannot tell which section governs the request. A string alone is not the pair.

Many pipelines send us_privacy and GPP together during the transition. That is two fields on purpose. Dropping the legacy string before every buyer reads GPP hides the signal from the buyers who still look at regs.us_privacy. Dropping GPP because the legacy string is present hides it from buyers who already moved. Read both on the request you captured. Do not assume one path's CMP write landed on Prebid, TAM, and Open Bidding. Those are three assemblies.

coppa is not any of these strings

regs.coppa is its own integer flag. It is not a TCF string, not a US Privacy string, and not a GPP section. A children's request does not become compliant because gpp parsed. Set coppa on its own, and do not infer it from us_privacy or from a GPP section id you did not read.

Spec JSON types gdpr and coppa as integers. true is protobuf JSON. A CMP bridge that emits booleans will fail a spec-json check and pass a proto-json check, or the reverse. Pick the dialect of the pipe before you call the privacy block valid. The same request can be legal GPP and an illegal GDPR type.

Half a pair is the production miss. gdpr 1 without user.consent, gpp without gpp_sid, us_privacy left in ext on a 2.6 reader. Each one looks populated in the CMP log and empty to the bidder that reads the current path. Capture the bid request, not the CMP debug panel, when you audit which signal left the page.

What to put on a 2.6 request

• EU: regs.gdpr and, when it is 1, user.consent as a TC string.
• Move both off ext when the snapshot is 2.6.
• US state and the current multi-jurisdiction string: regs.gpp and regs.gpp_sid.
• Keep regs.us_privacy only while a buyer still reads it. Do not treat it as GPP.
• Pin a snapshot of 2.6-202211 or later before you expect GPP to be in the catalog.
• Do not send an eid you were not allowed to send. Consent and identity travel together.

Three paths can carry three different strings for one user

Prebid can put regs.gpp on the request the page built. TAM and Open Bidding build their own requests. A CMP write into ortb2 does not copy itself onto those bodies. One path can have a TCF string, another only us_privacy, and a third nothing. Buyers are not contradicting each other. They saw different requests. Capture each path before you claim the user consented once.

GPP section ids are how a bidder picks the section inside a bundled string. Sending the string without gpp_sid, or sending a sid that is only the header section, leaves the applicable section unnamed. During a transition, send the legacy US Privacy string and the GPP pair. Dropping either early is how half the buyers go dark while the CMP UI still looks complete.

Further reading

• Privacy signals
• GPP section updates
• 2.5 paths still under ext