If you’ve ever opened GA4 and thought, “Since when did we get so many users in Frankfurt?” — you’re not alone.
What we’re seeing more and more is this: location-based reporting is getting fuzzier, not because your audience changed overnight, but because privacy tools are now normal behaviour. VPNs are everywhere, and Apple’s iCloud Private Relay makes it even easier for people to browse while hiding parts of their network identity.
For CRO teams, this matters because we use data to decide what to fix, what to test, and who to target. If the “where” of your users is unreliable, it can throw off reporting, segmentation, and even personalisation.
This post is the practical, not-too-technical version: what VPNs change, what they don’t, and a measurement plan that keeps decisions sane.
Why this is happening more now
VPNs used to be niche. Now they’re mainstream — for privacy, security on public Wi-Fi, work setups, and “just because.” Some surveys still show fluctuations year-to-year, but the broader point holds: lots of people know what VPNs are, and a meaningful chunk of users have them on.
On top of that, Apple’s iCloud Private Relay (part of iCloud+) is designed to make Safari browsing more private by obscuring IP address and routing details. Even when it tries to preserve region-level location, it can still reduce the precision and stability you’re used to relying on.
What VPN usage actually breaks (and what it doesn’t)
Let’s keep it simple.
What gets messy
1) Location reporting (especially city-level)
Most analytics platforms infer location from IP address. If a user connects via a VPN, they can appear to be browsing from the VPN server location — which might be a different city or even a different country.
This is why you’ll sometimes see strange “top cities” that look like data-centre hubs (or you’ll see a city spike that doesn’t match any campaign change).
2) Geo-based segments and targeting
If you segment funnels by city/region, or run experiments that only target certain geos, your segment sizes and results can get noisier. It doesn’t mean geo is useless — it means we treat it more cautiously.
3) Personalisation that relies on IP
Anything that guesses the user’s location from IP (currency defaults, store locator, shipping rules, “near you” content) can misfire for VPN-heavy audiences.
What usually stays reliable
1) On-site behaviour patterns
Rage clicks, confusion points, scroll depth, and drop-off patterns still show up. Users behave like humans even when their location is masked.
2) Core conversions (if implemented properly)
Purchases, lead submissions, trial starts — your conversion events still fire. The bigger risk is instrumentation quality, not VPNs.
3) Your ability to run CRO
CRO doesn’t depend on perfect location data. It depends on clear outcomes and clean measurement.
Why CRO teams get tripped up by this
This is where we see teams spiral:
-
“Sydney traffic dropped” → but overall revenue didn’t drop.
-
“Our US campaign quality got worse” → but CRM-qualified leads stayed steady.
-
“This experiment only wins in [city]” → but that city is basically a VPN/data-centre magnet.
The danger isn’t the data being imperfect. The danger is treating imperfect data as truth and making confident decisions off it.
The measurement plan: how we adapt without overcomplicating things
Here’s the approach we recommend (and what we do in practice).
1) Decide what you won’t over-trust
We usually downgrade these from “decision metrics” to “directional metrics”:
-
City-level performance
-
Small-sample geo segments
-
Any “geo story” that doesn’t line up with campaign targeting changes
It doesn’t mean we ignore it — we just stop letting it drive major roadmap calls on its own.
2) Add a “location uncertainty” lens to reporting
You can’t reliably detect every VPN user — and we shouldn’t try to be creepy about it.
But you can build a simple dashboard view that flags suspicious patterns like:
-
sudden spikes from “weird” cities that don’t match your audience
-
cities known for data-centre traffic (you’ll see the same ones pop up across many properties)
-
geo changes that happen without any corresponding channel mix change
This creates a healthy habit: when geo looks strange, we sanity-check before we react.
3) Anchor decisions in “first-party truth”
When geo gets fuzzy, we shift decision-making closer to outcomes we can verify:
-
backend orders / revenue
-
CRM-qualified leads
-
product activation milestones
In other words: we don’t argue about “users in Melbourne.” We optimise for “qualified leads” or “orders completed.”
4) Protect your experiments from geo noise
For A/B testing and CRO iteration:
-
Primary metric: pick one business outcome (purchase rate, qualified lead rate, activation rate)
-
Guardrails: choose metrics that catch bad wins (refund/cancel rate, support contacts, lead quality proxy)
-
Segments: check device + browser as standard; treat geo splits as “nice to know,” not “proof”
5) When location matters, ask the user (don’t guess)
If geo drives the experience (currency, shipping, store availability), the safest pattern is:
-
let users confirm with a store selector or postcode
-
keep it simple and reversible (“Not in Sydney? Change location”)
This beats making a confident wrong guess from IP.
Quick checklist: is VPN usage messing with your data?
-
Are your “top cities” suddenly unfamiliar or strangely consistent week to week?
-
Do you see spikes from well-known data-centre hubs?
-
Did geo mix change without paid targeting changes?
-
Do geo-based conversion rates swing wildly while overall conversion is steady?
If yes: treat location as fuzzy, not broken — and follow the plan above.
The takeaway
VPNs and privacy tools are changing what “location” means in analytics. That’s not a reason to stop optimising. It’s a reason to stop over-weighting geo and double down on outcomes we can trust.
If you want to turn this into a proper internal playbook, we can help you:
-
audit geo drift + instrument reliability
-
update dashboards so teams don’t get whiplash
-
adjust test segmentation so results stay clean