Why IP Geolocation Accuracy Makes or Breaks Ad Tech

bigdatacloud·August 25, 2025

In privacy-first advertising, IP geolocation is often the only scalable, non-intrusive signal available for audience localisation and geo-compliance. There is no cookie, no device fingerprint, no consent required. The IP address is simply there, with every request. For ad tech — targeting, bidding, pacing, eligibility enforcement, and attribution — that makes geolocation accuracy not a nice-to-have but a direct driver of commercial outcomes.

This article explains why accuracy matters more than most practitioners realise, what is theoretically achievable at country and city level given how the internet actually works, how to read vendor accuracy claims critically, and why the way uncertainty is reported matters as much as the accuracy figure itself.

Why one percentage point of accuracy is not a rounding error

At scale, small accuracy differences compound into large budget consequences. Consider a concrete example.

A geo-targeted campaign with a monthly media spend of $1,000,000 at a $10 CPM delivers 100 million impressions. If city-qualified traffic converts 20% better than non-qualified traffic — a conservative assumption for most geo-sensitive campaigns — then each additional percentage point of city-level accuracy shifts one million impressions into the correct geography. Even with modest CTR and conversion rate assumptions, that shift generates tens of thousands of dollars in incremental monthly revenue, and six figures annually at enterprise budgets.

The same logic applies in the other direction. A provider with 70% city-level accuracy versus one with 73% might seem negligibly different. At 100 million impressions, that gap is 3 million impressions served to the wrong audience — wasted spend, diluted relevance, and attribution noise that compounds every downstream decision.

MaxMind's own materials illustrate this clearly. The difference between the free GeoLite2 and the paid GeoIP2 is often a few percentage points at city level — but those few points at $1,000,000/month represent 3 to 5 million correctly placed impressions, with corresponding conversion uplift that can produce six-figure annual ROI before changing anything else in the funnel.

What accuracy can IP geolocation theoretically deliver?

IP geolocation estimates where an IP address serves users. It does not track a device. The achievable accuracy is bounded by how the internet actually works, not by the sophistication of any particular provider.

The most important constraint is that "one IP equals one person at one location" is false by design in the modern internet. Carrier-grade NAT means many users share a single public IP, and assignments change. VPNs and proxies deliberately show the exit node rather than the user. Anycast addresses — used by DNS resolvers, CDN edge nodes, and other infrastructure — can be served from multiple locations simultaneously. These are not user addresses and are not a meaningful accuracy concern for ad tech; nobody is trying to geolocate Cloudflare's DNS resolver for audience targeting.

Routing policy adds a further layer of complexity. Internet paths are asymmetric and driven by cost, not geography. A packet originating in Berlin may route through Amsterdam or Frankfurt depending on peering agreements that have nothing to do with physical distance. This is why latency-based triangulation — measuring how long it takes for a probe to receive a response — is a fundamentally unreliable basis for geolocation. Latency reflects routing policy, not physical location.

For a detailed explanation of these structural limits, see How accurate can IP geolocation get?

Realistic expectations by network type

Country-level identification on typical web audiences is very high with any well-engineered dataset — often 97% or above. Edge cases exist (roaming, enterprise VPNs, anycast), but country is a tractable problem.

City-level accuracy is more variable and depends heavily on the network type of the traffic being geolocated:

  • Fixed broadband with relatively static IP assignment: often strong at city level, sometimes suburb level, though privacy-respecting providers cap reported precision to an area rather than a precise point.
  • Dynamic consumer broadband: generally good at city level; suburb accuracy is situational depending on the ISP's pool geography.
  • Mobile and CGNAT traffic: frequently city or metro at best; often region or state-scale. The reason is not routing infrastructure — it is that a single shared IP address may be in use by thousands of subscribers simultaneously, spread across a wide geographic area. There is no single correct location for such an IP. Any point estimate is a statistical summary of a genuinely distributed population, and the confidence area reflects that spread honestly.

To understand what "good" city-level accuracy looks like across a realistic global traffic mix, consider an optimistic but defensible breakdown: VPN and hosting traffic represents roughly 5% of web requests and yields 0% true-city accuracy by definition (you see the exit node, not the user); wired residential and business traffic represents roughly 35% and achieves perhaps 90% correct city; mobile and CGNAT traffic represents roughly 60% and achieves perhaps 70% correct city at best.

The aggregate: 0.05 × 0 + 0.35 × 0.90 + 0.60 × 0.70 = 73.5%.

A global city-level accuracy in the 60–75% range is credible across mixed traffic. Claims of 95%+ city-level accuracy worldwide should prompt rigorous scrutiny of what traffic mix was tested, how the ground truth was established, and what proportion of the full IP space the test covered. Uniform high global figures typically reflect samples skewed toward static wired addresses in well-mapped urban markets — the easiest fraction of the problem.

Two structural trends are making city perfection progressively harder, not easier. Consumer VPN usage has become mainstream rather than a niche behaviour, meaning the portion of traffic with deliberately obscured location is growing. And mobile traffic continues to account for an increasing majority of page requests globally — precisely the network type where CGNAT and centralised egress most constrain city-level precision.

How leading providers describe accuracy — and how to read those claims

Accuracy claims across the industry vary significantly in what is actually being measured and how it is reported.

Some providers market high global city-level figures — "97% city-level accuracy", "99.99% country-level" — as headline numbers. These should be treated as marketing ceilings rather than operational baselines. A figure derived from a sample of static residential addresses in major US and European cities will not reflect performance on real-world traffic that includes mobile, CGNAT, VPN, and dynamic assignment.

MaxMind takes a more conservative and operationally useful approach: each IP lookup returns an accuracy radius in kilometres at approximately 67% confidence, along with per-country accuracy charts. The radius model is useful precisely because it makes uncertainty explicit and encodable into bidding logic, rather than presenting a single confident point estimate.

IPinfo's primary differentiator is their Probe Network — active network measurement using ping, traceroute, and protocol handshakes from over 1,300 distributed servers. This is a genuine and expensive technical undertaking. The fundamental limitation is that the IP addresses which respond to external probes are overwhelmingly routers, servers, and network infrastructure — not consumer devices. Consumer IP addresses sit behind NAT and CGNAT and do not respond to unsolicited probes. For ad tech, where the objective is to geolocate end users rather than map network infrastructure, this creates a meaningful gap between what the probe network measures and what you actually need to know. For a full technical analysis, see our dedicated comparison: BigDataCloud vs IPinfo.

BigDataCloud publishes a Daily IP Geolocation Accuracy Report — a provider-by-provider comparison updated every day using live, user-verified reference data, broken out by network type. This allows you to verify performance on real traffic at any time, rather than relying on claims made in sales materials. Each API response also returns a confidence area polygon alongside the point estimate, so uncertainty is explicit and can be incorporated into bidding and eligibility logic.

Why confidence areas matter more than accuracy figures alone

The standard model for geolocation output is a single point: latitude, longitude, city name. This model hides the most important information — how much you should trust that point for the specific IP you are looking at.

A static residential IP in a small town, consistently observed at the same location, should be treated very differently from a mobile carrier gateway that serves customers across three states. Both might return a city-level result. Only one of them actually carries meaningful city-level certainty.

The confidence area is a geographic polygon representing the actual range of locations an IP address has been observed in use. For a well-evidenced static IP, the polygon is tight and the confidence is high. For a mobile carrier pool spanning a wide area, the polygon is large — and that is honest information, not a limitation. It tells you that city-level targeting on that IP is a bet, not a certainty, and allows you to price that risk accordingly in your bidding logic.

MaxMind's accuracy radius model moves in the right direction — it acknowledges uncertainty per lookup. The confidence area polygon goes further: it reflects the actual geographic service area of the IP rather than a statistical confidence interval around a point estimate. For fraud detection, geo-eligibility enforcement, and audience qualification, the difference between "our point estimate might be 15km off" and "this IP has been observed anywhere in this region" is material.

Network classification and anonymiser signals

City-level accuracy behaves very differently across mobile, fixed residential, and hosting/infrastructure traffic. A provider that reports a single global accuracy figure without network-type breakdown is averaging over populations with fundamentally different characteristics — and the result tells you less than it appears to.

For ad tech, network classification matters operationally. Mobile traffic in CGNAT pools — where a single IP may be shared by thousands of users scattered across a wide area — warrants different confidence assumptions and different bid adjustments than fixed residential traffic with stable, long-lived IP assignments. Hosting and infrastructure traffic — which includes VPNs, proxies, datacentres, and residential proxy networks — should typically be priced lower, throttled, or excluded entirely depending on the campaign objective.

VPN detection specifically is worth addressing. Some providers market the ability to identify specific VPN providers by name. This is technically possible only for VPN IP ranges that have been explicitly observed and catalogued — which is always a partial list. There are thousands of VPN providers, their IP allocations change, and residential VPN services increasingly route through consumer address spaces that cannot be distinguished from regular traffic. The vendor name is also rarely the actionable signal: the question you actually need to answer is whether this traffic is from a real residential user or not, not which specific anonymisation service they are using.

A hosting likelihood signal answers the right question: whether an IP address belongs to infrastructure rather than a genuine residential or mobile user. This covers VPNs, proxies, Tor, datacentre addresses, and any other non-eyeball traffic under a single classification, including infrastructure that has not yet been observed serving VPN traffic and would therefore not appear on any reactive list. The Hazard Report API combines this proactive hosting likelihood assessment with reactive blocklist signals, providing a risk profile per IP that is useful for both audience quality and fraud prevention.

What to look for in a provider

The ad tech use case puts specific requirements on a geolocation provider that general-purpose accuracy benchmarks do not capture well.

The most important requirement is that uncertainty is reported per lookup, not just as a global average. A provider who tells you their overall accuracy is 75% has told you little about any individual IP. A provider who returns a confidence area or accuracy radius with each response allows you to make IP-specific decisions — applying stricter eligibility criteria for high-value geo-sensitive campaigns, pricing lower-confidence impressions down, and attributing outcomes to geographic segments with appropriate confidence intervals.

Network type classification is the second critical requirement. Mobile, fixed residential, and hosting traffic behave differently and should be handled differently. A provider who doesn't distinguish between them is aggregating over populations with very different accuracy profiles.

Transparency about methodology matters because it determines whether you can predict how a provider will perform on your specific traffic mix. Global benchmark figures are easy to optimise for with a well-chosen test sample. A daily public accuracy report across network types and regions, using live verified reference data, is much harder to game and much more predictive of real operational performance.

Finally, the rate of data refresh matters. The internet changes continuously — ISPs reallocate address blocks, mobile carriers reconfigure routing, new infrastructure is deployed. A geolocation database that updates weekly is stale for mobile and CGNAT traffic, where assignments and egress configurations change frequently. Providers who recalculate continuously from live routing and observation data will outperform those relying on periodic snapshots on exactly the traffic types that matter most.

For current accuracy figures by provider and network type, see the Daily IP Geolocation Accuracy Report. For IP geolocation with confidence areas, network classification, and hazard signals, see the IP Geolocation API package.