Visitors from Frankfurt? How IP locations really come about

Why so many visitors seem to come from Frankfurt

Frankfurt am Main has about 756,000 inhabitants (Hessisches Gemeindelexikon). On January 1, 2025, about 83.6 million people lived in Germany as a whole (Eurostat). The city therefore accounts for about 0.9 percent of the population (Hessisches Gemeindelexikon, Eurostat). An online store with a nationwide audience should see only a small Frankfurt share in its city list. If the share is several times that, it points to the measurement first and to the customers only second.

The effect is not limited to Frankfurt. Depending on the network and the data source, visits also pile up at a provider's headquarters or at another central location. These cases share a pattern: a single place carries a share of visits far above its share of the population, and it looks similar on almost every website. A genuinely local audience looks different. It lifts its city only on the website that is actually read there.

For analysis, the consequences go beyond a lopsided chart. Regional budgets, location pages and branch comparisons rely on these tables. Anyone who sees Hesse far ahead of populous states easily draws the wrong conclusions about their own reach. Before looking at countermeasures, it is worth looking at how an address gets a location in the first place.

Where an IP address gets its location from

An IP address contains no location. It is a number that a network operator assigns to a connection, often only for hours or days. Databases add the location, and they rely on sources of very different quality. These shape the result most:

For a connection with a fixed address and well-maintained data, the city can be right. For large access networks whose addresses come from pools for the whole country, the database often knows only the country or a central location of the network.

Part of this vagueness is intentional. The General Data Protection Regulation explicitly names IP addresses as online identifiers that may be associated with natural persons (GDPR, Recital 30). A pinpoint location for every address would therefore not be a quality feature but a risk for the people behind the connections. The question is therefore not whether an analysis is coarse, but how openly it shows it.

Geofeeds: the network operator states where its addresses are

A geofeed is a simple CSV file. RFC 8805 describes a format with which a network operator publishes a mapping of address ranges to simplified location information (RFC 8805). Each line starts with the address range, followed by a country code under ISO 3166-1, a region code under ISO 3166-2, the city and the postal code. Only the address range is required, all other fields may stay empty (RFC 8805).

What the format deliberately avoids is notable. It intentionally allows only coarse location data (RFC 8805). The postal code is marked as deprecated, and new feeds should no longer include it because of its granularity (RFC 8805). An operator can also state explicitly that a range has no location at all by leaving all location fields empty. RFC 8805 thus follows the same principle as data protection: better to say too little about a connection than too much.

# Example with documentation addresses (RFC 5737, RFC 3849)
192.0.2.0/24,DE,DE-NI,Hannover,
198.51.100.0/24,DE,DE-BY,,
2001:db8:100::/48,DE,,,
203.0.113.0/24,,,,

The first line places a range in Hanover, the second only in Bavaria, the third only in Germany. The last line states explicitly that there is no location for this range. If entries overlap because a small range sits inside a larger one, consumers should use the more specific entry (RFC 8805).

Where a geofeed is located is defined by RFC 9632. The operator enters the file's URL in the registry next to the address range, in the geofeed: attribute (RFC 9632). Anyone using the data must discard lines outside the referring range, so that nobody publishes locations for addresses they do not manage (RFC 9632). A signature using the routing certificate infrastructure (RPKI) is optional.

inetnum:   192.0.2.0 - 192.0.2.255
netname:   EXAMPLE-NET
country:   DE
geofeed:   https://example.net/geofeed.csv

The country: line in the registry entry stays in place but loses its meaning for the location. RFC 9632 explains this with large providers whose headquarters are very far from most of their deployments (RFC 9632). Exactly this gap between headquarters and deployment is what placeholder locations are made of.

How widespread geofeeds are

Geofeeds solve the problem only where they exist. A study analyzed the registry data of all five registries in February and March 2024 (arXiv 2502.08849). The result is sobering: only 0.25 percent of registry entries for IPv4 ranges and 0.30 percent of entries for IPv6 ranges referred to a geofeed (arXiv 2502.08849). About 82 percent of the IPv4 entries with a geofeed were in the RIPE NCC database (arXiv 2502.08849), the registry responsible for Europe.

The existing feeds are not all usable either. Of 1,547 geofeed URLs queried, 1,427 were reachable (arXiv 2502.08849). Of all lines in the downloaded files, about 10.5 percent were malformed and therefore unusable (arXiv 2502.08849). For analysis this means: a maintained geofeed is first-hand information, but so far it is the exception rather than the rule.

Placeholder locations: when the database only knows a collection point

Large access networks assign addresses from pools that do not have to be tied to a city. An address range can be used in Kiel today and in Freiburg later. A location database without reliable hints for such a range has a choice: give no location at all or a placeholder. The open location database that XICTRAQ® builds on knows only such a placeholder for some ranges, for instance the headquarters of the network operator where connections from across the country are pooled (XICTRAQ handbook).

For analysis, a placeholder is trickier than a gap. An empty cell stands out, a city does not. The dashboard then shows many visits from a city where hardly any of these visitors live. Typical signs of a placeholder location are:

• Disproportionate share: one place carries a share of a network's visits that is several times its share of the population.
• Same picture on many websites: the cluster appears regardless of industry and audience, not just for a single site.
• Nationwide network: the other visits from the same network are spread across the whole country.
• Central rather than typical place: the place is the operator's headquarters or a central point of the network, but not a place where the network would have particularly many customers.

The cross-check matters. University networks, for example, really are located in university towns, so a high share of a university town is not an error there. A website with a local audience rightly shows its city near the top. A placeholder becomes likely only when the pattern appears across the network and across websites.

Mobile networks, carrier-grade NAT, relays and VPNs

In mobile networks, and increasingly on fixed lines too, many devices often share one public address. The networks translate private addresses at central gateways to the Internet, a technique called carrier-grade NAT. A dedicated /10 address block was reserved for the link between these translators and customer equipment (RFC 6598). The website sees only the public address at the gateway, and its location is that of the network, not of the device. The Geo API feature page says as much: with mobile, VPN or carrier-grade NAT, the provider's location may appear.

IPv4 scarcity adds to this. The RIPE NCC handed out its last freely available IPv4 addresses in November 2019 (RIPE NCC). In the years before, an IPv4 transfer market had already emerged in its service region and carrier-grade NAT had become more common there (RIPE NCC). A range that was used in one region for a long time can be deployed somewhere completely different after a transfer before location databases notice.

Relay services shift the location on purpose. iCloud Private Relay sends requests through two separate relays run by different entities (Apple). The website sees an address from the service's range that several users in the same area may share (Apple). According to Apple, this address represents the coarse city-level location by default (Apple), and Apple publishes the list of these addresses with their locations. The Geo API flags such addresses with is_relay and works with a coarser radius of about 80 km for relay locations (XICTRAQ handbook).

With a VPN, the website sees the service's exit server, not the user. The same applies to corporate networks that route their traffic centrally: the field sales rep in Munich then appears at the location of the corporate gateway. Traffic from data centers generally carries the server's location but often comes from programs. How to keep such traffic out of the statistics is covered in the article on filtering bot traffic.

One source of error is often in-house. If the website sits behind a reverse proxy or a content delivery network and the measurement uses the proxy's address instead of the visitor's, all visits end up at the proxy's location. How to read the real visitor address from X-Forwarded-For safely is shown in the article on the real visitor IP behind proxies.

Reading accuracy radius and confidence

A location without uncertainty is a claim. The XICTRAQ® Geo API therefore returns an estimated radius in kilometers with every response and a confidence per field for country, region and city on a scale from 0 to 100 (XICTRAQ handbook). Both are open estimates, not a promise of precision. The radius follows the granularity reached (XICTRAQ handbook):

• about 25 km if the city comes from an operator or geofeed source,
• about 80 km for iCloud Private Relay locations,
• about 50 km if the city comes from the location database,
• 150 km if only the region is known,
• 600 km if only the country is known, including when a placeholder was discarded.

For the placeholder case, the core of the response looks like this. Region, postal code and coordinates are dropped together with the city because they come from the same record; the country stays:

{
  "country_code": "DE",
  "region": null,
  "city": null,
  "postal_code": null,
  "latitude": null,
  "longitude": null,
  "accuracy_radius_km": 600
}

Anyone integrating the API can use this to control how far to trust a location. For shipping notes, the country is enough. A branch finder should not suggest a location at a radius of 600 km but ask for the postal code instead. What a single address looks like can be checked beforehand in the free IP check, which also shows radius and confidence.

What a visitor map can prove and what it cannot

All of this leads to a simple ranking. The country is generally reliable because access networks mostly operate their connections within one country. The region carries medium uncertainty. The city is an approximation that can be accurate for some networks and systematically off for others. The network operator, by contrast, can usually be determined well and is often the most useful for troubleshooting.

Small numbers are a limit of their own, also for privacy reasons. In XICTRAQ® cookieless analytics, cities and regions appear in the location breakdowns only once a row covers a minimum number of distinct visitors. The analysis folds smaller rows into a catch-all row labeled "Übrige" (other). A missing city may therefore simply have too few visitors. This reduces the risk of re-identifying individuals through rare location combinations and is not a measurement error.

Anyone measuring through embedded third-party scripts may face a further coarsening in Chrome, described in the article on Chrome IP Protection. Even when measured in your own context, however, a city remains an approximation: the address arrives without that masking there, but its location still comes from the same registries, databases and geofeeds, with the same placeholders. The measurement context determines the address, not the accuracy of the location.

How XICTRAQ® handles placeholder locations

For the Geo API, the rule is documented in the handbook. The analytics evaluation uses the same geo service, and a dedicated job ensures that placeholder locations do not appear as cities. It runs weekly and proceeds as follows:

1. Measure the cluster: for every network, the job checks whether a place carries a share of sessions well above that place's share of the population.
2. Cross-check across websites: the cluster must appear similarly on most websites. A customer with a local audience lifts a place only on their own website and does not trigger anything.
3. Check the network area: the network must operate nationwide, or the place lies far outside the area of a regional network. Research networks are excluded because universities really are located in university towns.
4. Drop the place: for detected pairs of network and place, the geo service returns the country but no place. Region, postal code and coordinates are dropped as well.
5. Update stored data: page views stored before detection lose place, region, postal code and coordinates. The job creates a backup first.

Further rules complement this. If a network reports a geofeed for a place itself, its information takes precedence, and the stored data for that pair are not cleared. And a placeholder, once detected, stays on the list: after clearing, its visits arrive without a place and could otherwise no longer confirm it. The service treats satellite access the same way because its addresses are tied to the ground station.

XICTRAQ® collects the geofeeds weekly, directly via the references in the registries of several RIRs including the RIPE NCC, and accepts only lines within the referring address range, as RFC 9632 requires. During lookup, operator information takes precedence over the location database. In the dashboard, visits from placeholder locations still count toward the country but no longer appear under the placeholder in the city list. The visitor statistics do not store the IP address itself: it is used for the daily session identifier, the approximate geolocation and the assignment of the network operator, as described on the cookieless analytics page.

Checking location data step by step

For your own location statistics, a few steps are enough:

1. Compare share with population: Frankfurt am Main has about 0.9 percent of Germany's inhabitants (Hessisches Gemeindelexikon, Eurostat). If the city's share is several times that with a nationwide audience, a placeholder is likely.
2. Break down by network operator: if the cluster comes from one or a few large access networks, that points to a placeholder. The ASN and network lookup maps an address range to its operator.
3. Subtract data centers: server traffic carries the location of the data center. The data center check shows whether an address belongs to a hosting network.
4. Check your own access: office VPNs, test devices and service providers appear at the location of their gateway. My IP shows which address and location are visible from outside.
5. Check the proxy chain: if almost all visits appear at one single place, the measurement may be reading a proxy's address instead of the visitor's.
6. Add location from your own source: campaign parameters, branch selection or the postal code in the checkout say more about origin than any IP address.

The location of an address also works in the other direction. Some stores redirect to country pages or show different shipping costs based on the address's country. Anyone tracking competitor prices during a sales week therefore sees the version a page delivers for the address of the fetching server, not necessarily the one a customer in another country sees.

Better empty than wrong: evaluating origin honestly

IP locations are a useful approximation as long as it is clear how they come about. The country holds, the city is a hint, and a placeholder is not information at all but a gap with a place name. Network operators' geofeeds under RFC 8805 provide first-hand information but are still the exception (arXiv 2502.08849). Until they are more widespread, honesty in presentation helps most: empty fields instead of guessed cities, a radius instead of a pin.

What location statistics look like under these rules is shown in the live demo. The Geo API feature page describes fields and radii of the Geo API, the Geo API handbook the placeholder rule in full.