How Accurate Is IP-Based Location, Really?
Your analytics says the proposal was read from Warsaw. Your client’s office is in Kraków. Before you conclude the link was forwarded — and change what you say on Monday’s call — you need to know how much that word “Warsaw” is actually worth.
Less than the interface implies, and wrong in a way that does not average out.
Country and city are two different products
They arrive in the same row of the same table and they have wildly different error rates. The vendors themselves are candid about this and publish the figures.
MaxMind publishes a per-country accuracy table for GeoIP2 City; DB-IP publishes comparable numbers for its own database. Read either one and the same shape appears: country resolution sits in the high nineties, and “correct city, within fifty kilometres” sits far lower and swings enormously between countries.
The gap between those two figures is the whole story. Treating them as one field called “location” — one column, one confidence, one visual weight in the interface — is the root mistake, and almost every dashboard makes it.
The error is systematic, not random
This is the part that matters, and the part that gets left out of every vendor comparison.
Random error is survivable. Collect enough samples and it cancels. But an IP address frequently resolves to the point where its network is registered or terminates, rather than to the subscriber sitting at the end of it — so an entire region’s readers do not scatter randomly. They pile into one city: the capital, or wherever their provider terminates traffic.
A reader two hundred kilometres from Warsaw does not get a random wrong city. They get Warsaw. So does everybody near them.
Two consequences follow, and both are the opposite of what people assume:
- More data does not help. The bias is in the mapping, not in the sampling, so a thousand readings of "Warsaw" are exactly as wrong as one.
- Two readers showing the same city is not evidence that they are in the same place. It may only be evidence that they use the same provider.
Four situations where the answer is close to meaningless
- Mobile networks. Carrier-grade NAT means thousands of subscribers share one public address, anchored at a gateway that can be in a different city — or a different half of the country — from any of them.
- Corporate VPN. A reader working from home through their employer’s network appears at head office. This is extremely common among exactly the people who read proposals.
- Consumer VPNs and privacy relays. The address is chosen by the reader, or by their operating system, and is deliberately not where they are.
- Business and satellite ISPs. Blocks registered nationally rather than regionally resolve to whichever city the registration names, for every customer.
The specific wrong conclusion this causes
The failure mode is not “the dashboard showed a slightly imprecise city”. It is this:
The document was read from a city my client is not in. Therefore somebody else read it. Therefore it was forwarded.
Sometimes that is exactly right, and a forward is genuinely one of the most valuable things you can learn. But the other explanations are at least as likely: the provider’s hub, working from home, the office VPN, a train, a hotel, a phone.
The cost of being wrong is high precisely because the conclusion is actionable. You do not merely hold a slightly incorrect fact — you change your approach on the strength of it.
The working rule: location can support a conclusion you already have other evidence for. It cannot be the evidence.
An address is not a person
A related error, made at the level of data modelling rather than interpretation: an IP address is a poor identifier and should never be used as one.
- Two colleagues behind one office connection are one address and two readers.
- One person on a phone, a laptop at home and the office wifi is three addresses and one reader.
- A residential address reassigned by the provider overnight is one address and, over a week, several unrelated households.
An address is a fact about a network path at a moment in time. A network path is not a person, and a system that quietly treats it as one will merge strangers and split individuals, both silently.
Never splice two sources
A subtle failure worth knowing about if you build this yourself. Suppose your country comes from one source — say a network edge that reports it — and your city comes from another, a local database keyed on the address. Print them side by side and you can produce a city that is not in the country next to it.
That output is worse than a blank. A blank is honestly uninformative and a reader treats it accordingly. A contradiction is confidently wrong, and a reader has no way to notice unless they happen to know the geography. Take both fields from one source, or take neither.
How to display a number you do not fully trust
If you are going to show it at all, the hedge has to travel with the value. Quixli labels the city dimension as approximate, states the error rate above the rows, and prefixes every individual value with an approximation sign.
That last detail is the one that matters and the one most often skipped: a caveat in a tooltip is a caveat that does not exist. Screenshots get pasted into threads, rows get read out loud on calls, and numbers get quoted six weeks later with none of the surrounding interface. Whatever hedge you attach has to survive being separated from its context, which means it has to be part of the value.
The country, by contrast, can be shown plainly. It has earned that.
What to actually do with it
- Treat the country as evidence and the city as a hint.
- Never use a city on its own to conclude a document was forwarded. Look for a second reader or a second device instead — those are much stronger signals.
- Do not use an address as an identity, in your product or in your head.
- If you are shown a city with no hedge on it, assume the tool has not thought about this and discount accordingly.
- If the field is blank, that is a tool declining to guess. It is the most honest thing a location column can say.
Related: why time spent reading is usually wrong — the other number on the same screen that deserves this level of suspicion.