IP-Based Household IDs: What CGNAT Breaks in CTV

An IP address is a poor household ID, and on many networks it is simply wrong. Internet providers increasingly put many customers behind one public address using carrier-grade NAT (CGNAT), so hundreds of unrelated homes can appear as one. A CTV system that treats that address as a household will count strangers as one family: a frequency cap fills after a few impressions and blocks everyone else, reach shrinks, and an attribution match credits a campaign for a neighbour's purchase. Use the identifiers that exist first: the publisher's own household or subscriber ID, an operator's mapping, then the device advertising ID. Fall back to IP only where exactly one known household uses that address, and leave that fallback off by default. When nothing identifies the viewer, serve a contextual ad and treat them as unknown.

We built this order into LtvAdx after a code review, before release, caught our own IP fallback merging CGNAT viewers. This post explains how shared addressing works, what it does to each part of a TV campaign, and how to check whether a vendor's "household" is really a household.

Why CTV reached for the IP address in the first place

Television has no cookies. A connected TV app can send a device advertising ID, if the platform provides one and the viewer has not limited it, but that identifies one device. A household usually has several. So the industry needed something that ties a family's TV, phone and laptop together, and the IP address looked like the answer: all the devices on a home's Wi-Fi share one public address.

For a while, on fixed broadband in markets with plenty of IPv4 addresses, that was a fair approximation. Identity graphs were built on it, and it remains common. The household ID guide and the post on CTV identity without cookies cover the broader picture.

The problem is that the assumption underneath it, one address for one home, is breaking.

What CGNAT is

There are not enough IPv4 addresses for every connected home. Carrier-grade NAT is how providers cope. Instead of giving each customer a public address, the provider puts many customers on a private range, reserved for the purpose by RFC 6598, and shares a smaller set of public addresses among them. It is the same trick your home router uses for your devices, one level up.

To the outside world, including your ad server, every customer behind that gateway has the same public IP.

How common is it? A multi-perspective measurement study found that more than 17% of the access networks it examined, and more than 90% of cellular ones, relied on carrier-grade NAT, with the highest rates in Asia and Europe. It also recorded providers sharing one public address among as many as 128 subscribers. That study is several years old, and the pressure on IPv4 has only grown. In markets where most homes get broadband from mobile-first or fibre newcomers, shared addressing is normal rather than exceptional.

Even without CGNAT, IP addresses are less stable than they look.

• Dynamic addresses change. Many home connections get a new address from time to time, so yesterday's household may be someone else's today.
• Mobile hotspots and 5G home broadband sit on cellular networks, where sharing is the norm.
• Apartment blocks, hotels, hostels and offices often put everyone behind one connection.
• VPNs and privacy relays replace the home's address altogether.
• IPv6 is different but not simple. A home usually gets a whole prefix, so a device's full address is not the household; the prefix is closer to it.

What a shared IP does to a campaign

Treating an address as a household does not just add noise. It breaks specific things in specific directions.

Frequency caps fill up and stop delivery

Suppose a campaign has a household cap of three impressions a week, and 128 homes share one address. A system that treats them as one household stops serving after three impressions in total. The other 125 homes never see the ad. Your reach falls, and the campaign under-delivers on a network where the audience is perfectly real. Nothing in the report says why.

The caps themselves are working as designed. The identity under them is wrong. The frequency capping guide covers how caps should work, and the post on ad fatigue covers why they matter to viewers.

Reach is understated, or invented

One address with 128 homes behind it counts as one household, so reach is too low. And one home on a dynamic address that changes weekly counts as several, so reach is too high. Both errors can sit in the same report, and they do not cancel out in any useful way. The post on reach curves shows how much depends on that number.

Attribution credits the wrong home

IP-based attribution matches an ad exposure on a TV to a website visit or purchase from the same address. On a shared address, a neighbour's purchase can be credited to an ad that your household saw, or to one nobody in that home saw. On a large shared address, almost any campaign with reach will appear to drive conversions. The match rate looks healthy and the lift is fiction. The post on CTV attribution and the guide to lift test sample sizes explain why a holdout is the honest test.

Targeting reaches the wrong people

An audience segment attached to an address is applied to everyone behind it. A segment of "new parents" built from one home's activity is applied to all 128. Addressable buys then pay a premium for what is effectively untargeted delivery.

Privacy gets worse, not better

If a viewer opts out and the system stores that opt-out against an IP address, the choice can leak to strangers on the same address, or fail to follow the viewer when the address changes. Opt-outs should live on a stable identifier. A shared address is also a poor basis for anything that could reveal what a particular household watched.

Money can move to the wrong party

Where an operator shares revenue based on its subscribers, a viewer wrongly matched to one of those subscribers through a shared address moves money to the wrong account. That was one of the reasons we changed the default.

What one shared address costs: a worked example

An illustration, not data from any campaign. Take a broadband provider that shares each public address among 100 subscribers, and a campaign capped at three impressions per household per week. Compare what the system believes with what happened.

                                  Address treated     Each home treated
                                  as one household    separately
────────────────────────────────  ──────────────────  ─────────────────
Homes actually behind the address 100                 100
Impressions allowed per week      3                   300
Homes that can see the ad         up to 3             100
Reach the report shows            1 household         100 households

Multiply that across the addresses a provider operates, and a campaign on that network is capped at a hundredth of the delivery it could have had. The advertiser sees under-delivery. The publisher sees unfilled breaks. Neither sees the cause, because every system in the chain reports that it behaved correctly.

The error also shows up as a strange pattern in reports: delivery that looks fine on cable and fixed-line networks and collapses on one or two providers. If a campaign under-delivers on a specific network and nowhere else, check how that network assigns addresses before you change the bid.

Why this varies so much by market

A US planner who has used IP-based household graphs for years may reasonably say they work well enough. On long-established cable networks with plenty of IPv4 addresses, they often do.

Move the same method to a market where most homes came online after IPv4 ran short, or where broadband is delivered over mobile networks, and it degrades badly. That covers much of Asia, Africa and Latin America, and a growing share of 5G home broadband everywhere. So an identity graph with a strong record in one country may be close to meaningless in another, and a vendor's global match rate tells you little about the market you are buying.

If you are planning across countries, ask for match quality by country and by network, not one blended figure. The same applies to anything built on top of the match, including audience segments and retargeting.

Does IPv6 solve it?

Partly, and more slowly than it seemed it would. IPv6 has enough addresses that sharing is unnecessary, and a home typically receives its own prefix, so the network part of the address can stand in for the household. Many providers now offer it.

Three problems remain. Devices on IPv6 usually change the last part of their address regularly for privacy, so the full address is not stable; only the prefix is. Some providers rotate the prefix too. And a home on IPv6 often also uses a shared IPv4 path, so the same home can appear through two very different addresses. Our own rate limits treat an IPv6 address by its /64 prefix for that reason. For identity, a prefix is a better guess than a shared IPv4 address, but it remains a guess, and it should sit in the same place on the ladder.

A better order: the identity ladder

The answer is not to abandon identity. It is to prefer the identifiers that really do point at a household, and to know which one you used. LtvAdx resolves a household in this order, and stops at the first that works:

1. The publisher's own first-party list, where one exists
2. A household ID sent by the app, from a publisher that holds one
3. An operator + subscriber ID (a set-top box mapped to its household)
4. A device or advertising ID, already linked in the identity graph
5. The IP address, only if exactly one known household uses it (off by default)
6. Nothing: an anonymous request, served a contextual ad

The resolver notes which source matched, because not every match is equally good. A subscriber ID from a pay-TV operator is close to certain. A device ID is good for one screen. An IP address is a guess, and it should be labelled as one.

Publishers hold a real advantage here. A logged-in streaming app knows its subscribers, so its own ID, often called a PPID, is stronger than anything the ad tech can infer. That is why step one exists. Publisher list uploads are built but not yet switched on, and when they are, a publisher's first-party data will match only on that publisher's own inventory. It will not follow the viewer across the network.

Device IDs have rules of their own. The IAB Tech Lab's guidelines for identifiers on OTT platforms recommend sending the ID along with its type, such as rida for Roku or aaid for Android, and a limit-ad-tracking flag. A viewer who has limited tracking should be treated as unidentified, even if an ID arrives. The deal ID guide and the OpenRTB best practices post cover how these fields travel in a bid request.

When IP can be used, and how to keep it safe

Dropping IP entirely is a real cost in a market where few other identifiers exist. So we kept it available, with three restrictions.

Off by default. The fallback is a setting that has to be turned on deliberately. It has not been turned on for production.

Only where exactly one known household uses the address. The backend publishes an address only when a single household is known on it. If two appear, it is not used. That removes the worst case, though not every case: an address where only one household happens to be known may still be shared with people who are not.

After everything else. It is the last rung, used only when no stronger identifier exists.

Even then, I would not use an IP match for attribution or for anything that bills differently. For a frequency cap it can do modest good. For proving a sale, it cannot.

The mistake that changed our default

In the first version of our identity work, the ad server could resolve a household from an IP address whenever it had seen one there. A review in October, before that work was released, flagged what this would do behind CGNAT: every viewer behind a shared address would merge into one household. Frequency caps would have counted them together, and operator revenue share could have been credited to the wrong subscriber.

Finding it before release is the cheapest possible moment. We made three changes: the fallback now defaults to off, a household is resolved from an address only where exactly one known household holds it, and the resolver reports which source matched.

The same review found a related problem. Viewers who had given no consent, and should only have received contextual ads, would still have been identified to outside demand platforms. Identity and consent are two separate questions, and that defect came from treating them as one. The ad server now resolves the household first and applies the consent check afterwards, so a viewer without consent is served a contextual ad and passed to outside bidders with no identifier.

Consent comes after identity, and it wins

The order matters. A household can be recognised and still have no permission attached to it. In LtvAdx, these signals each remove the household from the request:

• A do-not-track or limit-ad-tracking flag
• A GDPR consent signal that does not grant the required purposes, or a missing or malformed one where consent is needed
• A US privacy string opting out of sale
• A child-directed flag under COPPA
• A stored opt-out against any identifier on the request

Live tests confirmed that the household is kept on a consented request and absent for each of those cases, including garbage consent strings. A broken signal counts as no consent, not as consent.

Opt-outs now work even for a household we have no record of. Before, an opt-out for an unknown household silently did nothing. Now it writes a tombstone, so the choice holds if that household appears later. The post on kids advertising and COPPA covers the child-directed rules.

Serving someone you cannot identify is fine

The objection to all this is commercial: if you remove weak matches, your addressable audience shrinks. That is true, and it is the honest number.

The alternative is selling a household match that is often false. A buyer who pays a premium for addressable delivery, then runs a lift test and finds nothing, does not come back. An anonymous viewer can still be reached well by what they are watching: channel, genre, daypart, platform and country. On FAST channels, that is frequently the better signal anyway, because what someone chooses to watch says more about them right now than a segment built from a shared address. The audience segments guide and the FAST channel monetisation guide cover selling on context.

Report the known-household share openly. A channel with 30% known households that sells on context and sells addressable only on that 30% will keep its buyers. Our post on measuring CTV ad avails shows how that share appears on a channel's card.

How to test a vendor's household claim

You can check most of this with a few direct questions.

1. What share of your household matches rests on IP alone? Ask for a breakdown by match source.
2. How do you handle shared addresses? "We filter data centres" is not an answer. Ask specifically about CGNAT and mobile networks.
3. How many households per IP does your graph allow? A graph with no limit is a warning sign.
4. How long does an IP-to-household link last? Long retention on dynamic addresses creates false matches.
5. How is an opt-out stored? It should sit on a stable identifier, and should survive an address change.
6. Can you run a holdout? A geographic or randomised holdout is the only attribution result worth paying for.

Then look at your own logs. Pick a campaign and count impressions per IP address per day. A handful of addresses with hundreds of impressions, spread across many device IDs, are shared. If your frequency caps are applied at that level, you have just found your under-delivery. The CTV reporting guide covers what to ask for.

A checklist for publishers and app developers

1. Send your own household or subscriber ID where you have one. It beats anything inferred.
2. Send the device ID with its type and the limit-ad-tracking flag, following the IAB guidance.
3. Forward consent signals correctly, including in server-side insertion. A stitcher that drops them turns every viewer into an unknown.
4. Forward the real viewer IP through your stitcher for country targeting and invalid traffic checks, even if it is not used for identity. The IP geotargeting post covers how.
5. Do not hash an IP and call it a household ID. Hashing does not change what it identifies.

The identity page describes how LtvAdx handles households, the publisher page covers what publishers send, the advertiser page covers buying, and you can create an account to get started.

Frequently asked questions

Can an IP address identify a household?

Only approximately, and on many networks not at all. Carrier-grade NAT puts many homes behind one public address, dynamic addresses change, and mobile hotspots, apartments and VPNs add more error. An IP address is a weak signal, best used as a last resort where exactly one known household has it.

What is CGNAT?

Carrier-grade NAT is how internet providers share a limited number of public IPv4 addresses among many customers. Customers get private addresses, and the provider's gateway translates them to a shared public one. To an ad server, everyone behind that gateway appears as one address.

How does CGNAT affect CTV advertising?

It makes unrelated homes look like one household. A frequency cap can fill after a few impressions and block everyone else on the address. Reach is undercounted, audience segments spread to strangers, and IP-based attribution can credit a neighbour's purchase to the wrong ad.

What is the best household identifier for CTV?

A first-party ID from a logged-in app or an operator's subscriber record is strongest. Device advertising IDs come next, though they identify one device rather than a home. IP addresses are the weakest and should be used last, if at all.

Should IP addresses be used for CTV attribution?

Treat IP-based attribution with suspicion. On shared addresses it matches ad exposure to purchases made by other people, so a campaign can appear to work when it does not. A randomised or geographic holdout test is the reliable way to measure lift.

What happens when a CTV viewer cannot be identified?

They should be served a contextual ad, based on the channel, genre, daypart, platform and country. That is a sound outcome, not a failure. Counting such viewers as unknown keeps your addressable numbers honest.

How do I know if my frequency caps are affected by shared IPs?

Check which identifier the caps use, then count impressions per IP per day in a campaign's logs. Addresses with very high counts spread across many device IDs are shared. If the caps are applied at address level, those homes are being blocked after the first few impressions.