CTV Geo-Targeting by IP: Whose Address Is It?

CTV geotargeting almost always comes from one thing: the IP address on the ad request, looked up in a geolocation database. A television has no GPS and no logged-in location. Whether a country-targeted campaign actually stays in that country depends on three questions most media plans never ask. Whose IP address is the ad server looking at? How good and how current is the database? And what happens when the answer is "unknown"?

At country level, IP geolocation is reliable when done properly: MaxMind, the most widely used provider, states 99.8% country accuracy for its commercial databases. Below country it degrades quickly, and city or postcode targeting from IP alone deserves scepticism. But accuracy is rarely where CTV geotargeting fails. It fails earlier, when the address being looked up belongs to a server rather than a household, when country codes in two formats are compared, or when a missing country is quietly treated as a match.

I know this because country targeting in LtvAdx was not working until recently, in two opposite ways at once. This post covers how location reaches a CTV ad decision, where it goes wrong, what we found in our own system and how we fixed it, and the questions to ask any platform before trusting a geo-targeted CTV buy.

Where does location come from in CTV?

On a phone, an ad can use GPS with the user's permission. On the web, a browser exposes an IP address and sometimes a location the user has shared. A connected television offers neither in any useful form. The device sits on a home network, and the only location signal that reliably reaches an ad server is the public IP address of that network.

That address arrives in one of three ways:

• As the source of the request, when the device or its player asks the ad server directly for a VAST response.
• In a header, when something sits in between and forwards the original address, typically X-Forwarded-For.
• In the bid request, for programmatic demand, as device.ip and often an already-resolved device.geo object filled in by the seller.

Once an address is known, the ad server looks it up in a geolocation database that maps IP ranges to countries, regions and cities. The CTV geotargeting guide covers the commercial side of local and regional buying. This post is about the plumbing underneath it.

Whose IP address is it?

This is the question that decides whether geotargeting works at all, and the answer changes with the delivery architecture.

Client-side ad insertion. The player on the television requests the ad itself. The request comes from the household's router, so its source address is the household's. This is the easy case.

Server-side ad insertion. The stitcher requests the ad on the viewer's behalf. The request now comes from the stitcher's server in a data centre. Unless the stitcher passes the viewer's address along, every viewer appears to be wherever that data centre is. A campaign targeted to one country can then serve to the whole world, or to no one, depending on where the stitcher happens to run. The SSAI explainer covers why so much CTV is delivered this way, and our post on SCTE-35 and live stitching covers the live case.

A proxy or edge in front of the ad server. Almost every production ad server sits behind a load balancer, gateway or CDN. The connection the ad server sees comes from that proxy, not from the viewer. The viewer's address is in X-Forwarded-For, and the ad server has to read it from there, taking the first address in the list, and only trusting that header when it was set by its own infrastructure. Getting this wrong gives every request the proxy's location.

Carrier networks and VPNs. Some households sit behind carrier-grade NAT, where many customers share one public address, and some viewers use VPNs. Country is usually still right for the first and deliberately wrong for the second. Neither is fixable from the ad server's side, and both are a small share of television viewing compared with the architectural cases above.

There is a fraud angle here too. Server-side insertion means the ad server trusts a forwarded address it cannot verify, and spoofed SSAI traffic exploits exactly that. Our post on CTV ad fraud in SSAI covers it.

What a misresolved address costs, worked through

Take a $50,000 campaign targeted to one country, with exclusion of unknown locations switched on. Suppose 40% of the eligible inventory reaches the ad server through an SSAI partner that does not forward viewer addresses. Two things can happen, depending on where that partner's servers are.

Campaign budget                         $50,000
Inventory via non-forwarding SSAI           40%

Case A: stitcher runs OUTSIDE the target country
  Those requests resolve to the wrong country → excluded
  Eligible inventory shrinks to                  60%
  Result: under-delivery, or the remaining 60%
          bid up to spend the budget

Case B: stitcher runs INSIDE the target country
  Every SSAI request resolves to the target → eligible
  Including viewers who are actually abroad
  Result: the restriction does not apply on 40%
          of the buy, and nothing in the report says so

The percentages are illustrative. The structure is not. Case A looks like a supply problem and gets investigated as one. Case B looks like a campaign that delivered perfectly. For an advertiser with a legal reason for the restriction, Case B is the dangerous one, because it produces a clean report. The only way to tell which case you are in is to know, per supply path, whose address is being looked up.

The country targeting that targeted nothing

Here is what we found in LtvAdx, because it shows how geotargeting can fail completely without anything appearing broken.

The VAST endpoint read the viewer's country from a single request header. That header was meant to be set by our edge. The edge never set it. Every direct request therefore arrived with no country at all.

What happened next depended on the campaign, and produced two opposite failures:

• Campaigns sold with a country target but not set to exclude unknown locations served everywhere. A missing country was not a mismatch, so it passed the filter. An India-only campaign would have run worldwide.
• Direct-sold campaigns with country targets, which correctly excluded unknown locations, could never serve. Every request was unknown, so every request was excluded.

Programmatic demand had a separate problem. Inbound bid requests carried the country in OpenRTB's three-letter format, "IND", while campaigns were targeted with two-letter codes, "IN". The two never matched, so country-targeted programmatic demand was never eligible either.

None of this raised an error. Reports showed impressions, campaigns showed as active, and the targeting field in the interface held exactly what the advertiser had entered. The setting was stored correctly and evaluated against nothing.

How we fixed it

The rewrite resolves country in a fixed order, with each step explicit:

1. Country header set by our own edge     → use it (override)
2. Else first address in X-Forwarded-For  → look it up
3. Else the connection's source address   → look it up
4. Private or reserved address            → unknown
5. Lookup fails or database unavailable   → unknown (never an error)

Bid requests:  device.geo.country alpha-3 → alpha-2 ("IND" → "IN")
               missing country → look up device.ip

Unknown country: EXCLUDE from country-targeted campaigns (default)
                 or PASS, a deliberate per-deployment choice

Three decisions in that list deserve explanation.

Lookups fail open, but unknowns are excluded. If the geolocation database is missing or a lookup throws, the request is not rejected; the country is simply unknown. Then the unknown-country policy decides. We default to excluding unknown requests from country-targeted campaigns, because for most advertisers a country target is a restriction rather than a preference. Alcohol, gambling, pharmaceutical and political advertisers can be legally restricted by geography, and for them serving outside the target is worse than not serving. The political and healthcare guides cover those rules. Campaigns with no country target are unaffected either way.

Every unknown is counted. Each request that ends up with no country is recorded as its own outcome in our serving ledger. If the unknown share rises, a header has stopped arriving or a database has gone missing, and we can see it the same day rather than when an advertiser asks why delivery fell.

SSAI uses the viewer's address, captured once. When a viewer starts an SSAI session, the device's address and user agent are recorded with the session and the country is resolved then. Every ad decision in that session uses the viewer's location, never the stitcher's own address. This also avoids re-resolving on every playlist poll.

How accurate is IP geolocation?

Accurate enough at country level, and much less so below it.

MaxMind states that its commercial GeoIP2 databases identify the country correctly 99.8% of the time (MaxMind on geolocation accuracy). Its free GeoLite databases are less accurate than the paid ones. Country accuracy is high because whole address blocks are allocated by regional registries and assigned to networks in specific countries, so getting the country wrong requires an unusual setup.

City and postcode are different. IP blocks are assigned to an internet provider's regional infrastructure, not to houses, and the location recorded for a block is often the provider's point of presence. An independent validation of MaxMind's free city database across 24 countries found it placed 45.8% of addresses within 10 kilometres, against the 50.0% MaxMind reported for the same countries (Radboud University, 2021). Half of addresses within 10 kilometres is useful for regional analysis. It is not a basis for selling a postcode-targeted campaign as precise.

That is why LtvAdx targets by country and does not offer city or postcode targeting from IP. For buyers who need local precision, household-level data matched with consent, or inventory that is local by nature such as a regional channel or a local linear zone, is more defensible than an IP lookup dressed up as a postcode. Our HouseholdID and addressable linear posts cover those routes.

What IP geolocation can prove, and what it cannot

For regulated advertisers it is worth being precise about what a country resolved from an IP address establishes.

It establishes that the household's internet connection is registered to a network operating in that country. That is strong evidence of where the viewer is, and it is the standard basis for geographic restriction across digital advertising. It does not establish who is watching, how old they are, or whether they are a resident or a visitor. Restrictions that depend on those things need other controls: content and channel rules for audiences of children, covered in the kids advertising and COPPA guide, and category exclusions for sensitive products.

It is also only as good as the path that delivered the address. A country resolved from a forwarded header is only as trustworthy as whoever set that header. Inside your own infrastructure, that is fine. From an unknown intermediary, it is a claim. That makes two checks worth running on any stack, ours included: whether a country header or forwarded address sent from outside can reach the ad server unaltered, and whether the edge overwrites those headers rather than appending to them. A country you cannot attribute to your own infrastructure is better recorded as unknown than trusted.

The honest summary for a compliance file is that IP-based country targeting is a reasonable and widely used control, that it should be tested on every supply path, and that its failure modes are architectural rather than statistical. A 99.8% accurate database looking up the wrong address is 0% accurate.

Location and household identity are different things

It is tempting to treat a household's IP address as its identity as well as its location, and plenty of CTV targeting does exactly that. It works poorly for both jobs at once.

As location, an IP address is good at country level and coarse below it. As identity, it changes: providers reassign addresses, households change provider, and carrier-grade NAT puts many homes behind one address. A household graph built on IP alone merges different homes and splits the same home over time. Our posts on CTV identity without cookies and HouseholdID cover how identity is built more durably, and the identity page describes how LtvAdx resolves households.

The practical rule is to use the IP address for what it is good at, a current, coarse location at the moment of the request, and to use a household identifier for frequency, measurement and audiences. Mixing the two produces frequency caps that leak when an address changes and location targeting that inherits the identity graph's mistakes.

The database goes stale, and the licence says so

IP address blocks move. Providers buy and sell ranges, reassign them between regions and open new networks. A geolocation database is a snapshot, and it drifts from reality from the day it is built.

MaxMind's licence for its free GeoLite data makes freshness a legal obligation as well as a quality one. Users must use updated databases promptly and destroy old versions within 30 days of an update being released (GeoLite EULA). The practical answer is to automate it: a scheduled download that replaces the file the ad server reads, with a check that the new file loaded. A database copied into a server once and forgotten is both less accurate and out of licence within a month.

If you run your own ad server, this is the operational item most likely to be missed, because nothing breaks when the database gets old. Lookups keep returning answers. They are just slightly worse ones, more of them each month.

Country codes: the boring bug

The "IND" versus "IN" problem above is worth a section of its own, because it is the most common geotargeting bug in programmatic CTV and the easiest to prevent.

ISO 3166-1 defines country codes in two letter forms: alpha-2 ("IN", "US", "GB") and alpha-3 ("IND", "USA", "GBR"). OpenRTB 2.x specifies alpha-3 for device.geo.country. Most targeting interfaces, geolocation databases and reporting tools use alpha-2. Comparing one with the other fails silently: no error, no warning, just a campaign that never matches. The fix is to normalise every incoming country code to one format at the edge, before any comparison. The OpenRTB best practices post covers the other fields where formats differ between sellers.

How to test whether geotargeting is working

Checking that the targeting field contains the right country tells you nothing. Here is what does.

1. Send requests from known locations. A request from an address in the target country should be eligible for the campaign, and one from elsewhere should not. A VPN exit in each country is enough for a basic test.
2. Test the unknown case. Send a request with no resolvable address and confirm the campaign behaves as your policy says: excluded, or allowed.
3. Test through every path. Direct VAST, SSAI and programmatic resolve location differently. A test that passes on one proves nothing about the others.
4. Read the decision, not the delivery. A delivery report says an ad served. A decision trace says why it was eligible, including the country that was resolved. If your platform can show the resolved country per request, check it.
5. Watch the unknown share over time. A sudden rise means a header, proxy or database has changed underneath you.

The VAST inspector is useful for the first step, since it shows exactly what a given request receives.

Repeat the tests after any change to the edge: a new CDN, a gateway upgrade, a moved load balancer. Each of those can change which header carries the viewer's address, or whether it arrives at all, and none of them will mention geotargeting in its release notes. Geography is one of the few targeting dimensions that depends on infrastructure the media team never sees.

Questions to ask before trusting a geo-targeted CTV buy

Any buyer running a country-restricted campaign on CTV should be able to get straight answers to these:

• Where does country come from on each path: direct, SSAI and programmatic?
• On SSAI inventory, is the viewer's address forwarded, or is the stitcher's address being looked up?
• What happens to requests with no resolvable country in a country-targeted campaign?
• How old is the geolocation database, and how is it refreshed?
• Can I see delivery by resolved country, including the share that was unknown?

A platform that answers all five clearly has thought about it. A platform that points at the targeting settings in its interface has not checked whether those settings are evaluated against anything. Our CTV reporting guide covers what else a delivery report should show, and supply path optimisation covers why the same inventory can resolve differently through different sellers. For how LtvAdx makes the ad decision itself, see the ad server page.

Frequently asked questions

How does geotargeting work on connected TV?

Mostly by IP address. A connected TV has no GPS, so the ad server looks up the public IP address of the viewer's home network in a geolocation database. For programmatic demand, the seller may pass the address and a resolved location in the bid request. The method is reliable at country level and much less precise below it.

How accurate is IP-based country targeting?

High when the right address is used and the database is current. MaxMind states 99.8% country accuracy for its commercial databases, with its free databases somewhat less accurate. The larger risks are architectural: looking up a server's address instead of the viewer's, comparing country codes in different formats, or treating an unknown country as a match.

Does server-side ad insertion break geotargeting?

It can. With SSAI the stitcher requests ads on the viewer's behalf, so the request comes from a data centre. Unless the viewer's address is forwarded or captured when the session starts, every viewer appears to be where the stitcher runs. Ask any SSAI provider how the viewer's address reaches the ad decision.

Is city or ZIP code targeting from IP reliable on CTV?

Not very. IP blocks are assigned to providers' regional infrastructure rather than to homes, and independent validation has found free city-level data placing under half of addresses within 10 kilometres. For local campaigns, regional channels, local linear zones or consented household data are more defensible than postcode targeting from IP.

What should happen when a viewer's country is unknown?

It is a policy choice. Excluding unknown requests from country-targeted campaigns protects advertisers with legal or contractual geographic restrictions; allowing them increases fill at the cost of some delivery outside the target. Excluding is the safer default. Either way, the share of unknown requests should be measured, because a rise usually means something upstream changed.

Why do OpenRTB country codes cause targeting problems?

OpenRTB 2.x uses three-letter ISO country codes such as IND or USA, while most targeting systems and geolocation databases use two-letter codes such as IN or US. Comparing the two fails silently, so country-targeted campaigns never match programmatic requests. Normalising all codes to one format before comparison prevents it.

How often should a geolocation database be updated?

Regularly, ideally automatically. IP blocks move between providers and regions, so accuracy drifts from the day a database is built. MaxMind's licence for its free GeoLite data also requires using new releases promptly and destroying old versions within 30 days of an update.