gpp_sid=7 Is US National. us_privacy=1YNN Is Not the Same Hop.

Prebid starts sending regs.gpp and regs.gpp_sid=7 on every California impression. The Floodlight tag on the same page still fires us_privacy=1YNN. QA checks both URLs, sees four characters on the pixel, and signs off.

Google Campaign Manager 360 reads GPP for US restricted data processing. It does not treat 1YNN as a stand-in for a US National section. Your bid path and your conversion path are on different generations of the same contract.

https://ad.doubleclick.net/activity;src=1234567;type=lead;cat=stand0;us_privacy=1YNN

That URL is well formed for the deprecated signal. It is not a GPP string. Nothing in those four characters tells a GPP decoder which section is in force.

Two US signals, two encodings

The legacy US Privacy string is exactly four characters: a version digit, then explicit notice, opt-out of sale, and LSPA coverage, each Y, N, or -. 1YNN is the textbook yes-notice, no-opt-out, no-LSPA value.

IAB Tech Lab deprecated that standalone parameter on 31 January 2024 in favor of the Global Privacy Platform. The replacement for US inventory is not a longer base64 blob with the same four characters pasted inside. It is the US National section inside a composite GPP string, with gpp_sid=7 naming that section on the wire.

GPP fixes a different grammar. The first section is a header whose first six bits are 3 (GPP Header field). US National is one encoded section among others, joined by tildes. The companion parameter gpp_sid carries the section ID or IDs in force for this transaction, normally one integer, at most two comma-separated.

Parameter	US role	Shape
us_privacy	Legacy CCPA / MSPA shortcut	Four chars, version 1 only
gpp + gpp_sid=7	US National (and related state sections inside the string)	URL-safe base64, header type 3
gpp + gpp_sid=2	TCF EU section	Same GPP envelope, different sid

gpp_sid=2 is TCF. gpp_sid=7 is US National. Swapping them is not a typo vendors paper over. CM360 will not accept a TC String through the GPP slot.

During migration you may send both us_privacy and GPP on the same URL. That is two keys for two generations, not a duplicate of the same signal. Duplicate consent parameters are a different failure: two gpp keys, or the same TC String copied into gdpr_consent and gpp with conflicting bits.

What fails in production is the split path: header bidding and the ad server macro map gpp and gpp_sid=7, while the server-side tag container, CAPI worker, or downloaded Floodlight template still maps only ${US_PRIVACY} and never ${GPP_STRING} / ${GPP_SID}. The page-level CMP output moved. The server hop did not.

Why 1YNN in gpp is worse than keeping us_privacy

Some teams try to "migrate" by placing 1YNN inside gpp. That fails the GPP contract immediately. A four-character literal is not URL-safe base64 with a type-3 header. Decoders report core.privacy.gpp_malformed or a wrong header type, not a graceful US National parse.

Keeping us_privacy=1YNN alongside a real GPP string is the documented cutover. Dropping GPP on the pixel while the CMP emits it in the bid request is how you look compliant on OpenRTB and silent on the conversion tag. Dropping us_privacy before every partner reads gpp_sid is how you look silent to legacy adapters still keyed on the four-character string.

OpenRTB 2.6 added regs.gpp and regs.gpp_sid next to regs.us_privacy. The encoding rules do not change because the container is JSON. An empty gpp with gpp_sid=7 in regs.ext while the pixel still carries only us_privacy is the same split path with a different user agent string.

Meta Limited Data Use (dpo, dpoco, dpost) is a product control on the Meta pixel and CAPI. It is not the IAB US Privacy string and it is not GPP. You may need LDU and GPP on US traffic. They do not substitute for each other.

How you catch it on the fired URL

I maintain Pixellint, an open source linter for pixels and conversion API payloads. The core privacy pack decodes GPP header bits and checks IAB consent grammar on live URLs.

Paste the fired impression or conversion pixel URL into the playground or run:

$ pixellint validate url 'https://example.com/px?id=1&us_privacy=1YNN'
rulepack: core
  warning core.privacy.us_privacy_deprecated
          us_privacy is deprecated in favor of GPP (31 January 2024).

That warning is expected during cutover. It becomes a migration finding when your CMP and Prebid path already emit gpp_sid=7 and this URL never picked up gpp.

A URL with GPP but no sid fails the GPP spec on its own:

$ pixellint validate url 'https://example.com/px?id=1&gpp=DBACNYA~...'
  error   core.privacy.gpp_sid_missing
          gpp is present but gpp_sid is missing.

Compare the pixel URL to the bid request capture in your HAR or exchange log. Consent on the wire is what each vendor receives on that hop, not the banner state in the page. If regs.gpp populated on the auction and the Floodlight activity URL still ends at us_privacy=1YNN, the trafficking bug is in the macro map, not the CMP.

For EU traffic on the same site, the parallel check is gdpr=1 with a TC String in gdpr_consent, not a TC String pasted into gpp (header type 2, not 3). The GPP guide and TCF v2 guide spell out which key owns which encoding.

Unexpanded macros (${GPP}, ${US_PRIVACY}) are template slots. Core privacy rules skip those on unfired creatives. After serve, the live request needs a decoded header type 3 and a populated sid for US National.

Where to go next

Re-download tags with GPP macros enabled if your ad server supports them. Confirm the fired URL carries gpp and gpp_sid=7 for US National, not an unexpanded ${GPP_STRING_xxxxx} token.

Keep gdpr and gdpr_consent for EEA inventory. TCF v2.3 adds mandatory disclosedVendors on new strings after 28 February 2026; policy version alone will not tell you whether a string is 2.3. The TCF v2.3 disclosed vendors note is about EU segment shape, not US National, but the same rule applies: read the segment the spec names, not a legacy shortcut on a different parameter.

When both paths are aligned, drop us_privacy on purpose for partners that read GPP, not by deleting the wrong macro while the bid stream still sends sid 7.

The core rulepack reference lists every privacy finding id. Pixellint is independent of IAB Tech Lab and Google. The rule ids cite their specs because that is where the wire contract lives.

The short version

gpp_sid=7 names US National inside GPP. us_privacy=1YNN is a deprecated four-character signal. They are not interchangeable, and you cannot paste one into the other.

If your CMP and bid path already emit GPP, the pixel and server-side collector must forward gpp and gpp_sid, not only us_privacy. Validate the fired URL, then compare it to the OpenRTB regs object on the same page view.