CTV Consent Signals: GPP, TCF and US Privacy

A CTV ad request can carry five kinds of privacy signal: the GDPR flag with a TCF consent string, the older US Privacy string, a Global Privacy Platform (GPP) string with its section IDs, a COPPA flag, and the device’s do-not-track or limit-ad-tracking setting. On a TV there is no browser and no cookie banner, so every one of them has to be collected by the app’s consent tool and added to each ad request, usually through macros in the VAST tag or the server-side insertion session. When a signal says the viewer may not be identified, the ad should still play, chosen contextually from the channel, the content, the country and the device, with no household ID and no advertising ID sent to buyers. Most CTV consent problems are not legal puzzles. They are plumbing: a string that never reaches the ad server, or reaches it from a server in the wrong country.

This post explains each signal, where it goes in OpenRTB 2.6, what changes on a TV compared with the web, and what an exchange should do with each one. I also describe what we built into LtvAdx at the end of October, including one signal we pass on but do not yet act on ourselves. It is practical guidance, not legal advice.

Why consent is harder on a TV

On the web, a consent tool runs in the page, writes the viewer’s choices to a cookie, and the ad scripts on the same page read them. Almost none of that carries over to connected TV.

• No cookies. Identity on a TV is a device advertising ID, an app’s own login, an operator’s subscriber record or, least reliably, an IP address. The post on CTV identity without cookies covers each.
• The consent tool lives in the app. Each FAST channel app or CTV app needs its own consent screen, and the result sits in the app, not somewhere an ad server can read.
• Ad tags are fixed strings. A VAST tag pasted into a player is the same for every viewer. A consent string is different for every viewer and changes when they change their mind. It has to be inserted into each request at the moment it is made.
• Servers make many of the requests. With server-side ad insertion, the request for an ad comes from the stitching server, not the TV. Unless the stitcher forwards the viewer’s signals, the ad server sees none of them, and it sees the server’s country rather than the viewer’s.
• The device has its own switch. TV platforms offer a limit-ad-tracking setting. The viewer may never see your consent screen and still have said no at the device level.

So the question for a CTV publisher is less “which consent tool?” and more “does every ad request, from every path, carry what the tool collected?”

The five signals and where they go

OpenRTB 2.6 has a field for each of these, mostly in the regs object:

Signal                OpenRTB 2.6 field        Values
────────────────────  ───────────────────────  ─────────────────────────────────
GDPR applies          regs.gdpr                1 yes, 0 no, absent = unknown
TCF consent string    user.consent             The viewer's TC string
US Privacy string     regs.us_privacy          e.g. "1YNN" (deprecated by IAB)
GPP string            regs.gpp                 The viewer's GPP string
GPP sections in use   regs.gpp_sid             e.g. [7] US National, [8] California
COPPA                 regs.coppa               1 = child-directed
Do not track          device.dnt               1 = do not track
Limit ad tracking     device.lmt               1 = tracking must be limited

On a VAST tag, the same signals travel as query parameters. Common names are gdpr, gdpr_consent, us_privacy, gpp, gpp_sid, coppa, dnt and lmt. Those are the names the LtvAdx VAST tag reads; other ad servers use similar ones, sometimes with their own macros to fill them.

TCF: the European consent string

The Transparency and Consent Framework from IAB Europe encodes a viewer’s choices as a TC string: which purposes they agreed to and which vendors may act on them. For personalised advertising, three purposes matter:

• Purpose 1: store and/or access information on a device.
• Purpose 3: create profiles for personalised advertising.
• Purpose 4: use profiles to select personalised advertising.

If any of the three is missing, the viewer should not be targeted as a known household. An exchange can also require consent for its own vendor ID on the Global Vendor List. LtvAdx is not on the list yet, so we check the purposes only, and we say so in our EU consent help article. If that changes, the string will also need consent for our vendor ID.

The harder question is when GDPR applies at all. A request may carry gdpr=1, gdpr=0, or nothing. Nothing is the common case on CTV, and OpenRTB defines it as “unknown”. Treating unknown as “does not apply” is the easy mistake. Our rule is that a request with no gdpr value is covered if the viewer is in the EU, the EEA, the UK or Switzerland, judged from the address that made the request. And gdpr=0 is the publisher’s statement that GDPR does not apply to that viewer, so it should be sent only when that is true.

GPP: one string for many laws

The Global Privacy Platform, from IAB Tech Lab, was built because a separate string per law was not going to scale. A GPP string has a header and one or more sections, each for a jurisdiction, and gpp_sid says which sections apply to this request. OpenRTB 2.6 says it will generally contain one value.

The GPP section list currently runs to 27 IDs. The ones a North American or European CTV publisher is most likely to meet:

ID   Section                      Notes
───  ───────────────────────────  ───────────────────────────────
2    TCF EU v2                    The TC string, inside GPP
5    TCF Canada
6    USP v1                       Deprecated: the old US Privacy string
7    US National (MSPA)           One section for all US states
8    California
9    Virginia
10   Colorado
...  (one section per state)      20 state sections, IDs 8 to 27

The practical choice for US inventory is between the national section, 7, and the state sections. The national section is simpler for a publisher to implement. State sections are more precise. Either way, the viewer’s state has to be known or assumed, which on a TV usually means an IP lookup, with all the inaccuracy that brings. The post on CTV geo-targeting by IP explains how wrong that can be, especially through a stitcher.

The US Privacy string is the predecessor: four characters, such as 1YNN, where the third character says whether the viewer opted out of the sale of their data. IAB has deprecated it in favour of GPP, and GPP lists its section as deprecated, but many buyers and exchanges still read it. That matters for the next section.

An honest note on GPP at LtvAdx

Today, the LtvAdx ad server decides with the TCF string, the US Privacy string, COPPA, do-not-track and limit-ad-tracking, and the household opt-out list. A GPP string is passed on to outside buyers untouched, but our ad server does not decode it to make its own decision. A request whose only US signal is a GPP opt-out is not served contextually by us on that basis, although every buyer we pass it to receives it.

If you send requests to LtvAdx, send the US Privacy string alongside GPP for now. It is deprecated, but it is the signal we act on, and sending both costs nothing. We would rather tell you this than have you assume the GPP string is doing work it is not. When the ad server decodes GPP, this section will say so, with the date.

COPPA and children’s channels

Children’s programming is common on FAST services, and in the US the Children’s Online Privacy Protection Act restricts collecting and using personal information from children under 13. In OpenRTB the signal is regs.coppa=1.

The flag on its own is fragile, because it depends on every request carrying it. A safer design makes the channel itself decide. On LtvAdx, a channel marked as kids content, or rated TV-Y, TV-Y7 or TV-Y7-FV, is always served contextually, whether or not the request says COPPA, and buyers are told COPPA applies. The CTV kids advertising guide covers the content rules that go with it.

Device settings: limit ad tracking and do not track

TV platforms let viewers limit ad tracking, and some reset or blank the advertising ID when they do. OpenRTB describes device.lmt as the commercially endorsed “Limit Ad Tracking” signal, where 1 means tracking must be limited. It is the one choice a viewer can make once and have apply to every app on the device, which is why our viewer opt-out guide points viewers to it first.

Your player or SDK usually has access to this setting. Make sure it reaches the ad request as lmt=1. A request with an advertising ID and no lmt value is read as permission to use the ID.

Consent screens built for a remote control

The consent screen is where the strings come from, and a TV makes it awkward. Nobody wants to read a privacy notice from three metres away with a five-button remote. That is not an excuse for a screen that only works one way. A few practical points, none of them legal advice:

• Make refusing as easy as accepting. If “Accept” is one press and “Reject” is six presses through a settings menu, the choice is not a fair one, and regulators in Europe have said as much about web banners. Put both options on the first screen, at the same size.
• Do not pre-select the answer. On a TV the focused button is the pre-ticked box. Starting focus on “Accept” nudges viewers in a way they barely notice.
• Keep the choice per profile where the app has profiles. A shared living-room TV may have several viewers. If your app knows who is watching, store the choice with that profile.
• Read the current string before every break. A viewer can change their choice mid-programme. A string cached when the app opened is out of date the moment they do.
• Give a way back. A settings entry that reopens the consent screen, so a viewer can withdraw consent as easily as they gave it.

Operators and subscriber data

Cable and IPTV operators bring a different kind of signal: subscriber records rather than app consent screens. An operator’s subscribers may have opted out through the operator’s own account settings or customer service, and that choice needs to reach the ad server too.

On LtvAdx, an operator marks a subscriber who has opted out with an optedOut flag in its subscriber upload. From the moment the file is processed, that subscriber is put in no audience segment and gets contextual ads only. Subscribers also drop out of targeting if the operator stops uploading them, so stale records do not keep a household targetable forever. The viewer opt-outs article lists every route an opt-out can take, including a signed link from a publisher’s own app that applies the opt-out immediately.

Getting the signals into every request

Here is a VAST request with every signal filled in. The values are illustrative, not real strings:

https://ads.ltvadx.com/vast?channelId=CHANNEL_ID
  &breakType=MID_ROLL
  &householdId=HOUSEHOLD_ID
  &gdpr=1
  &gdpr_consent=TC_STRING_FROM_YOUR_CMP
  &us_privacy=1YNN
  &gpp=GPP_STRING_FROM_YOUR_CMP
  &gpp_sid=7
  &coppa=0
  &dnt=0
  &lmt=0

Three rules prevent the most common failures:

1. Fill per request, never hard-code. A consent string written into a tag is one viewer’s choice applied to everyone. If your own ad server builds the URL, use its consent macros so each request gets the current viewer’s values. The wrapper integration guide lists the parameters.
2. Let the device make the request where you can. If one of your servers fetches the tag, the ad server sees that server’s country. A server in Frankfurt makes every viewer look European; a server in Virginia hides that a viewer is in Paris. Either way, GDPR is applied to the wrong people.
3. Make the stitcher forward everything. For SSAI, the session request must carry the same signals, plus the viewer’s IP and user agent from a stitcher the exchange trusts. LtvAdx believes forwarded addresses only from stitchers vetted for that publisher’s account, so a forged header cannot move a viewer to another country. The SSAI explainer and the SSAI setup guide cover the session.

To check a live request, decode the strings you are sending. IAB Tech Lab links to a GPP decoder from its GPP page, and a TC string can be decoded with any TCF-compatible tool. Then compare what was decoded with what the viewer chose on screen.

What should happen when a viewer says no

The worst outcome of a missing consent is an empty break. The right outcome is a contextual ad. On LtvAdx, when any signal rules the household out, that request is served as an anonymous viewer:

• No household or audience targeting, no retargeting, no addressable delivery.
• No frequency capping by household, because there is no household.
• The viewer is not counted in reach.
• Campaigns that target channel, content, location, device or time can still win, and do.

Outside buyers get a request that reflects the decision, not only what the player sent:

"device": {
  "ip": "203.0.113.0",      // network only: IPv4 /24, IPv6 /48
  "ua": "...",
  "lmt": 1                 // set when the household has opted out
  // no "ifa", no "ifa_type"
},
"regs": {
  "gdpr": 1,                // set from the viewer's country if the player sent nothing
  "coppa": 1                // on a kids channel
}

The point of telling buyers what was decided is that a DSP cannot be expected to repeat your country lookup or know that a channel is for children. If the exchange decided the request is contextual, the request should say so in fields every buyer reads.

What this means for advertisers

If you buy CTV with household targeting, part of your delivery will be contextual, and that is the system working, not failing. Plan for it:

• Addressable reach is smaller than total reach. Audience segments and retargeting can only match viewers who may be identified. The audience segments guide and the retargeting guide explain match rates.
• Frequency caps cannot see contextual viewers. A household cap does not count impressions served without a household, so frequency on contextual delivery is uncapped. The frequency capping guide and the post on reach curves show what that does to effective reach.
• Run a contextual line alongside the addressable one. Channel, genre and daypart targeting reaches the viewers your segments cannot, without guessing at their identity.
• Be careful with attribution built on IP matching. It is weakest exactly where consent is absent. The post on IP-based household IDs explains why, and the attribution guide covers sounder methods.

We do not publish a share of contextual delivery across the exchange, because it varies hugely by publisher, region and how well each player passes signals, and a network average would mislead more than it informs. Your own reports are the number to watch.

Political ads raise the bar further

Political and issue advertising carries its own targeting rules on top of ordinary consent. The EU regulation on political advertising, which has applied since October 2025, restricts targeting using personal data to cases where the viewer has given explicit consent for that purpose, and bans targeting on sensitive data such as political opinions altogether. US states set their own rules for election ads. A consent string that permits personalised advertising in general is not the same as consent for political targeting. The safest default for political ads on CTV is contextual delivery: channel, programme, region and daypart. The CTV political ads guide covers disclosure and the rest.

Where the signals sit in the wider request

Privacy fields are only part of a bid request, and they interact with the rest. The household ID you send is what consent decides whether to use; the household identity explainer covers how it is built. The supply chain object, app bundle and seller IDs tell buyers who is passing the signals on. The OpenRTB best practices for CTV post covers those fields, and the TCF glossary entry is a short reference for the European framework.

How we built consent at serve time

Some decisions from the build, and one admission.

The admission first. Until 31 October 2026, the LtvAdx ad server did not act on these signals when it chose an ad. Publishers could pass them and they were forwarded, but the decision itself ignored them. That changed on 31 October, when consent enforcement went live with the rules in this post. If you integrated before then, nothing in your tag needs to change; the signals you were already sending now take effect.

Check in a fixed order and stop at the first no. COPPA or a kids channel, then do-not-track and limit-ad-tracking, then a US Privacy opt-out, then GDPR without valid consent, then the household opt-out list. Any one of them makes the request contextual.

Fail closed. The household opt-out list lives in a fast store that the ad server checks on every request. If that check fails, the request is served contextually, not as if the viewer had consented. It costs a little addressable delivery during an outage and avoids the one failure that matters.

Opt-outs outlive profiles. A viewer’s opt-out is kept even after their household profile expires, so a later data upload from an operator cannot quietly put them back. An operator can withdraw its own earlier opt-out statement, but not a request the viewer made themselves. The privacy and consent help article sets out what is kept.

Identifiers are never stored raw. Device IDs and IP addresses are stored only as keyed hashes, so the same device can be recognised without the ID itself being kept. The identity page describes the household graph built on them.

A checklist for CTV publishers

1. List every path an ad request takes: player VAST tag, VMAP, SSAI session, your own ad server as a wrapper.
2. For each path, confirm all eight parameters are filled per request from your consent tool and device settings.
3. Decode a real TC string and GPP string from a test device after making choices on screen.
4. Make sure requests come from the device, or that your stitcher forwards the viewer’s address from an IP the exchange trusts.
5. Send gdpr=0 only when you know GDPR does not apply.
6. Mark children’s channels as kids content, not only with a COPPA flag.
7. Send lmt=1 when the device setting is on.
8. Ask your exchange which signals it acts on and which it only forwards.

The last one is the question most publishers never ask, and the answer is rarely “all of them”. Ours is above. Viewers who want to opt out directly can use the Ad Choices page, and our privacy policy and GDPR page set out the legal terms. You can create an account to generate a VAST tag with every parameter in place.

Frequently asked questions

What is a GPP string?

A Global Privacy Platform string is IAB Tech Lab’s single format for a viewer’s privacy choices under many laws. It has a header and one section per jurisdiction, such as US National, California or the EU TCF. In OpenRTB 2.6 it goes in regs.gpp, with the sections that apply listed in regs.gpp_sid.

Is the US Privacy string still needed?

IAB has deprecated it in favour of GPP, but many buyers and exchanges still read it. Sending both is harmless. On LtvAdx it is still needed today, because our ad server acts on the US Privacy string and passes GPP to buyers without decoding it.

Does GDPR apply to CTV advertising?

Yes, when the viewer is in the EU or EEA, and the UK and Swiss equivalents apply there. A TV app that targets ads to a household processes personal data, so it needs a lawful basis such as valid consent. If a request does not say whether GDPR applies, the safe reading is to decide from the viewer’s location.

How do I pass a TCF consent string in a VAST tag?

Add gdpr=1 and gdpr_consent= followed by the viewer’s TC string from your consent tool, filled in for each request. If your ad server builds the tag URL, use its consent macros. Never write one viewer’s string into a fixed tag.

What happens to an ad request without consent?

It should still be served, but contextually: chosen from the channel, content, country and device rather than the household. No household or advertising ID is used or sent, frequency caps by household do not apply, and buyers receive only the viewer’s network rather than their full IP address.

What does lmt mean in a bid request?

device.lmt is the limit-ad-tracking signal from the device’s own settings. 1 means tracking must be limited under the platform’s rules, so the viewer should not be targeted or tracked as a known user. On a TV it is the one choice that applies across every app on the device.