Why IP Geolocation Isn't 100% Accurate (And How to Handle It on Shopify)

Every blog post and product page about IP geolocation quietly drops a number: "99% accurate at the country level." It sounds reassuring. The implication: configure a country block, lean on the geolocation data, move on.

In practice, that number does the heavy lifting of obscuring what actually matters. Country-level accuracy is genuinely high — 95-99% across major databases. But the failures cluster in specific ways that disproportionately hit fraud-prevention decisions. State and city accuracy is significantly lower. And the 1-5% of country-level errors aren't random.

This guide covers how IP geolocation works, where the inaccuracies come from, the failure modes affecting fraud controls specifically, and how to operate gracefully despite imperfect data.

How IP geolocation actually works

There's no single source of truth for which IP belongs to which country, state, or city. The geolocation databases your fraud app uses — MaxMind GeoIP, IP2Location, ipinfo, DB-IP, others — assemble data from multiple sources:

RIR allocations. The IANA delegates IP blocks to regional registries (ARIN for North America, RIPE for Europe, APNIC for Asia), who delegate to ISPs. The original allocation tells you roughly which region a block is "for."

ISP-reported routing. ISPs publish BGP announcements telling the internet where their blocks are advertised. More current than the original allocation.

Crowdsourced and observational data. Databases observe traffic patterns, reverse-DNS records, ping latency from known reference points, user-supplied data.

Customer self-reporting and feedback. When users report "this IP shows me as country X but I'm in country Y," databases incorporate corrections.

The output: a database mapping every public IP to a country, often a state, sometimes a city, with additional metadata (ISP, ASN, connection type, anonymizing flags).

Different databases produce different answers for the same IP. Two reputable databases will agree on country 95%+ of the time, on state 75-90%, on city 60-80%. The further down you drill, the more disagreement.

Where the inaccuracies come from

Several structural factors keep geolocation imperfect:

Dynamic IP allocation

The same IP that served a customer in California last week might be assigned to a customer in Texas this week. Residential ISPs rotate addresses across their region. Databases lag.

Mobile carrier gateways

A customer using a mobile network in Australia might appear from a gateway IP that geolocates to Singapore. Mobile geolocation is consistently worse than fixed-line.

Corporate VPNs and global networks

A multinational company might have UK employees appearing to come from a US-hosted VPN exit. The IP geolocates to the US even though the user is physically in the UK. "Correct" in the sense that the traffic does emerge from the US gateway, but wrong for fraud-decision purposes.

Satellite internet

Starlink and other satellite providers route to ground stations in different countries from the user. A Starlink user in rural Brazil might appear from a North American IP because that's where the relevant ground station sits.

Anonymization services

VPNs, proxies, TOR exits, residential proxies — deliberately misrepresent the user's location. Geolocation databases flag known anonymization (when known) or report the apparent location.

Cloud and CDN traffic

Some traffic legitimately passes through cloud or CDN infrastructure before reaching your store. IP geolocates to the data center, not the original user.

iCloud Private Relay

Apple's relay service deliberately obscures user location, rotating through relay nodes. Users from anywhere appear from anywhere else.

The failure modes that hurt fraud controls

These systematic errors produce specific patterns affecting fraud decisions:

False positives on travelers and expats

A US customer on vacation in Paris uses hotel WiFi and appears from France. Country-level blocks catch them. Risk scores elevate because billing country doesn't match IP country. Almost any traveler with non-trivial IP geolocation will trigger something.

False positives on mobile users

Mobile geolocation drifts. A customer in Indonesia might appear from Singapore. A user in Mexico City might appear from a different state. Mobile traffic is disproportionately affected by every geographic control.

False negatives on VPN users

A fraudster routing through a VPN exit in your home country looks completely local. Country-level controls miss them. The VPN-detection layer should catch them — but VPN detection depends on databases being up to date about which IPs are VPN exits, and they're never fully current.

Misattributed mobile carriers

A mobile carrier might route through a regional hub that geolocates differently from where the user is. Your traffic data shows "lots of orders from Singapore" when it's actually orders from across SEA routed through a Singapore gateway.

Database drift on small regions

Smaller countries, rural regions, emerging markets have worse geolocation accuracy — less data, slower update cycles. Stores serving these markets see disproportionate geolocation noise.

Operating gracefully despite the imperfections

The right operational stance: assume geolocation is informative but not authoritative, and design controls accordingly.

Use geolocation for triage, not verdict

A high-risk country signal should elevate the order for review, not auto-cancel. The cases where geolocation is wrong are exactly the cases where automated action causes the worst outcomes — frustrated travelers, lost expat customers, blocked legitimate users.

Combine geolocation with other signals

An order with unexpected IP country and mismatched billing/shipping and fresh email and new payment method is much higher confidence than any one of those alone. Single-signal decisions over-rely on the weakest data.

Whitelist generously

Known customers, repeat buyers, customers with proven order history — let them through regardless of IP-country drift. The cost of letting a fraud order through against an established customer is much smaller than blocking a long-term customer with an inconveniently-located VPN.

Build a feedback loop

When you cancel orders based on geolocation, track outcomes. If a customer reaches out to clarify, log it. After 60 days, review: how many cancellations were genuinely fraud? How many were geolocation errors? Calibrate thresholds based on actual hit rate.

Update your geolocation database regularly

Most fraud apps refresh geolocation data daily or weekly. If yours doesn't, the data drifts. A geolocation database six months stale will produce significantly more false positives.

When geolocation surprises you

A specific pattern worth flagging: when your geolocation says something that doesn't match the rest of the order signals, the geolocation is the data point most likely to be wrong.

A customer who placed three orders to a US billing address, all shipping to the same US address, now has an order with IP geolocating to Romania. Is this fraud (account takeover, fraudster using stolen account)? Or geolocation drift (customer traveling, customer using a VPN, ISP rotated their IP)?

The right answer isn't to assume one or the other — it's to make sure your controls produce the right action for both. Hold the order, contact the customer, confirm intent. Friction is small; cost of either error is large.

When to invest in better geolocation

Most stores use whatever geolocation their fraud app provides and never think about it. That's usually fine. Signals you'd benefit from better data:

• Sustained geolocation complaints. Customers regularly report being blocked from countries they're not in
• Emerging-market customer base. Some markets have notably poor geolocation in cheaper databases
• City-level dependency. Your fraud strategy requires precise city detection

How Shieldy handles geolocation

Shieldy Fraud Filter uses commercial-grade IP geolocation databases (MaxMind GeoIP2) with daily updates. The key things to know:

• Country-level geolocation accuracy: 99%+
• State/province accuracy: 85-90% depending on country
• City-level accuracy: 75-85% in major metros, lower in rural areas
• Anonymizing service detection: includes commercial VPNs, residential proxies, datacenter proxies, TOR exits, iCloud Private Relay
• Whitelist priority: any IP/email/customer on the whitelist bypasses all geolocation-based rules

Shieldy specifically distinguishes Private Relay traffic from VPN traffic — important because iPhone users on Private Relay are usually legitimate high-AOV customers. Most fraud apps treat them as VPN. Don't.

A practical close

Trust geolocation for what it does well (country attribution at scale, broad geographic trends, anonymizing-service detection). Don't trust it for what it does badly (precise sub-national location for individual orders, mobile traffic location, edge cases with VPN/corporate/satellite infrastructure).

Use it as one signal among several. Calibrate thresholds against measured outcomes. Maintain a generous whitelist for known-good customers. Update your geolocation database regularly.

The merchants who operate well don't fight the imperfections — they design around them.