Besucher aus Frankfurt? Wie IP-Standorte wirklich entstehen

Warum so viele Besucher aus Frankfurt kommen

Frankfurt am Main hat rund 756.000 Einwohner (Hessisches Gemeindelexikon). In ganz Deutschland lebten am 1. Januar 2025 rund 83,6 Millionen Menschen (Eurostat). Auf die Stadt entfallen damit rund 0,9 Prozent der Bevölkerung (Hessisches Gemeindelexikon, Eurostat). Ein Onlineshop mit bundesweitem Publikum sollte in seiner Städteliste also nur einen kleinen Anteil Frankfurt sehen. Steht dort ein Vielfaches davon, ist das zuerst ein Hinweis auf die Messung und erst danach einer auf die Kundschaft.

Der Effekt ist nicht auf Frankfurt beschränkt. Je nach Netz und Datenquelle sammeln sich Besuche auch am Sitz eines Anbieters oder an einem anderen zentralen Ort. Gemeinsam ist diesen Fällen ein Muster: Ein einzelner Ort trägt einen Anteil der Besuche, der weit über seinem Bevölkerungsanteil liegt, und das auf fast jeder Website ähnlich. Ein echtes lokales Publikum sieht anders aus. Es hebt seine Stadt nur auf der Website an, die dort tatsächlich gelesen wird.

Für die Auswertung hat das Folgen, die über eine schiefe Grafik hinausgehen. Regionale Budgets, Standortseiten und Filialvergleiche stützen sich auf solche Tabellen. Wer dort Hessen weit vor bevölkerungsstarken Ländern sieht, zieht leicht falsche Schlüsse über die eigene Reichweite. Bevor es um Gegenmittel geht, lohnt deshalb ein Blick darauf, wie ein Ort überhaupt an eine Adresse kommt.

Woher eine IP-Adresse ihren Ort bekommt

Eine IP-Adresse enthält keinen Ort. Sie ist eine Nummer, die ein Netzbetreiber einem Anschluss zuteilt, oft nur für Stunden oder Tage. Den Ort ordnen erst Datenbanken zu, und die stützen sich auf Quellen sehr unterschiedlicher Güte. Vor allem diese prägen das Ergebnis:

Bei einem Anschluss mit fester Adresse und gepflegten Daten kann die Stadt stimmen. Bei großen Zugangsnetzen, deren Adressen aus Pools für das ganze Land kommen, kennt die Datenbank oft nur das Land oder einen zentralen Ort des Netzes.

Ein Teil dieser Unschärfe ist gewollt. Die Datenschutz-Grundverordnung nennt IP-Adressen ausdrücklich als Online-Kennungen, die natürlichen Personen zugeordnet werden können (DSGVO, Erwägungsgrund 30). Ein metergenauer Ort zu jeder Adresse wäre deshalb kein Qualitätsmerkmal, sondern ein Risiko für die Menschen hinter den Anschlüssen. Die Frage ist darum nicht, ob eine Auswertung grob ist, sondern wie offen sie das zeigt.

Geofeeds: Der Netzbetreiber sagt selbst, wo seine Adressen sind

Ein Geofeed ist eine einfache CSV-Datei. RFC 8805 beschreibt ein Format, mit dem ein Netzbetreiber eine Zuordnung von Adressbereichen zu vereinfachten Ortsangaben veröffentlicht (RFC 8805). Jede Zeile beginnt mit dem Adressbereich, danach folgen Ländercode nach ISO 3166-1, Regionscode nach ISO 3166-2, Stadt und Postleitzahl. Pflicht ist nur der Adressbereich, alle anderen Felder dürfen leer bleiben (RFC 8805).

Bemerkenswert ist, was das Format nicht will. Es erlaubt bewusst nur grobe Ortsangaben (RFC 8805). Die Postleitzahl ist als veraltet markiert, neue Feeds sollen sie wegen ihrer Genauigkeit nicht mehr enthalten (RFC 8805). Ein Betreiber kann für einen Bereich auch ausdrücklich gar keinen Ort angeben, indem er alle Ortsfelder leer lässt. RFC 8805 folgt damit demselben Grundsatz wie der Datenschutz: lieber weniger über einen Anschluss sagen als zu viel.

# Beispiel mit Dokumentationsadressen (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,,,,

Die erste Zeile verortet einen Bereich in Hannover, die zweite nur in Bayern, die dritte nur in Deutschland. Die letzte Zeile sagt ausdrücklich, dass es für diesen Bereich keine Ortsangabe gibt. Überschneiden sich Einträge, weil ein kleiner Bereich in einem größeren liegt, sollen Nutzer den genaueren Eintrag heranziehen (RFC 8805).

Wo ein Geofeed liegt, regelt RFC 9632. Der Betreiber trägt die Adresse der Datei im Register beim zugehörigen Adressbereich ein, im Attribut geofeed: (RFC 9632). Wer die Daten nutzt, muss Zeilen verwerfen, die außerhalb des verweisenden Bereichs liegen, damit niemand Ortsangaben für Adressen macht, die er gar nicht verwaltet (RFC 9632). Eine Signatur über die Zertifikatsinfrastruktur des Routings (RPKI) ist optional.

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

Die Zeile country: im Registereintrag bleibt dabei stehen, verliert aber ihre Bedeutung für den Ort. RFC 9632 begründet das mit großen Anbietern, deren Sitz weit von den meisten ihrer Einsatzorte entfernt liegt (RFC 9632). Genau diese Lücke zwischen Firmensitz und Einsatzort ist der Stoff, aus dem Ersatzorte entstehen.

Wie verbreitet Geofeeds sind

Geofeeds lösen das Problem nur dort, wo es sie gibt. Eine Untersuchung hat im Februar und März 2024 die Registerdaten aller fünf Vergabestellen ausgewertet (arXiv 2502.08849). Das Ergebnis ist ernüchternd: Nur 0,25 Prozent der Registereinträge für IPv4-Bereiche und 0,30 Prozent der Einträge für IPv6-Bereiche verwiesen auf einen Geofeed (arXiv 2502.08849). Rund 82 Prozent der IPv4-Einträge mit Geofeed lagen in der Datenbank des RIPE NCC (arXiv 2502.08849), also bei der Vergabestelle, die für Europa zuständig ist.

Auch die vorhandenen Feeds sind nicht durchweg brauchbar. Von 1.547 abgefragten Geofeed-Adressen waren 1.427 erreichbar (arXiv 2502.08849). Von allen Zeilen der geladenen Dateien waren rund 10,5 Prozent fehlerhaft und damit nicht nutzbar (arXiv 2502.08849). Für die Auswertung heißt das: Ein gepflegter Geofeed ist die Angabe aus erster Hand, aber er ist bisher die Ausnahme und nicht die Regel.

Ersatzorte: Wenn die Datenbank nur einen Sammelpunkt kennt

Große Zugangsnetze vergeben Adressen aus Pools, die nicht an eine Stadt gebunden sein müssen. Ein Adressbereich kann heute in Kiel und später in Freiburg eingesetzt sein. Eine Ortsdatenbank, die für so einen Bereich keine belastbaren Hinweise hat, steht vor der Wahl: gar keinen Ort angeben oder einen Ersatzort. Die offene Ortsdatenbank, auf der XICTRAQ® aufbaut, kennt für manche Bereiche nur einen solchen Ersatzort, etwa den Sitz des Netzbetreibers, bei dem sich Zugänge aus dem ganzen Land sammeln (XICTRAQ-Handbuch).

Für die Auswertung ist der Ersatzort tückischer als eine Lücke. Eine leere Zelle fällt auf, eine Stadt nicht. Im Dashboard erscheinen dann viele Besuche aus einer Stadt, in der kaum einer dieser Besucher wohnt. Typische Merkmale eines Ersatzorts sind:

• Überproportionaler Anteil: Ein Ort trägt einen Anteil der Besuche eines Netzes, der ein Vielfaches seines Bevölkerungsanteils beträgt.
• Gleiches Bild auf vielen Websites: Die Häufung tritt unabhängig von Branche und Zielgruppe auf, nicht nur bei einem einzelnen Angebot.
• Bundesweites Netz: Die übrigen Besuche desselben Netzes verteilen sich über das ganze Land.
• Zentraler statt typischer Ort: Der Ort ist der Sitz des Betreibers oder ein zentraler Punkt des Netzes, aber kein Ort, an dem das Netz besonders viele Kunden hätte.

Wichtig ist die Gegenprobe. Hochschulnetze etwa sitzen tatsächlich in Hochschulstädten, ein hoher Anteil einer Universitätsstadt ist dort kein Fehler. Eine Website mit lokalem Publikum zeigt ihre Stadt zu Recht weit vorn. Ein Ersatzort ist erst dann wahrscheinlich, wenn das Muster netzweit und websiteübergreifend auftritt.

Mobilfunk, Carrier-Grade-NAT, Relay und VPN

Im Mobilfunk und zunehmend auch an Festnetzanschlüssen teilen sich häufig viele Geräte eine öffentliche Adresse. Die Netze übersetzen private Adressen an zentralen Übergängen ins Internet, ein Verfahren namens Carrier-Grade-NAT. Für die Verbindung zwischen diesen Übersetzern und den Routern der Kunden wurde eigens ein Adressblock der Größe /10 reserviert (RFC 6598). Die Website sieht nur die öffentliche Adresse am Übergang, und deren Ort ist der des Netzes, nicht der des Geräts. Die Funktionsseite der Geo-API sagt es entsprechend: Bei Mobilfunk, VPN oder Carrier-Grade-NAT kann der Provider-Standort erscheinen.

Hinzu kommt die Knappheit an IPv4-Adressen. Das RIPE NCC hat im November 2019 seine letzten frei verfügbaren IPv4-Adressen vergeben (RIPE NCC). Schon in den Jahren davor waren in seiner Region ein Transfermarkt für IPv4-Adressen entstanden und Carrier-Grade-NAT häufiger geworden (RIPE NCC). Ein Bereich, der lange in einer Region genutzt wurde, kann nach einem Transfer ganz woanders im Einsatz sein, bevor die Ortsdatenbanken das bemerken.

Relay-Dienste verschieben den Ort bewusst. iCloud Private Relay leitet Anfragen über zwei getrennte Relais unterschiedlicher Betreiber (Apple). Die Website sieht eine Adresse aus dem Bereich des Dienstes, die sich mehrere Nutzer derselben Gegend teilen können (Apple). Laut Apple bildet diese Adresse standardmäßig den groben Standort auf Stadtebene ab (Apple), und Apple veröffentlicht die Liste dieser Adressen samt Orten. Die Geo-API kennzeichnet solche Adressen mit is_relay und rechnet für Relay-Standorte mit einem gröberen Radius von rund 80 km (XICTRAQ-Handbuch).

Bei einem VPN sieht die Website den Ausgangsserver des Dienstes, nicht den Nutzer. Dasselbe gilt für Firmennetze, die ihren Verkehr zentral ausleiten: Der Außendienst in München erscheint dann am Standort des Firmen-Gateways. Verkehr aus Rechenzentren trägt in der Regel den Ort des Servers, stammt aber häufig von Programmen. Wie sich solcher Verkehr aus der Statistik heraushalten lässt, beschreibt der Beitrag zum Filtern von Bot-Traffic.

Eine Fehlerquelle liegt oft im eigenen Haus. Steht die Website hinter einem Reverse Proxy oder einem Content Delivery Network und wertet die Messung die Adresse des Proxys statt der des Besuchers aus, landen alle Besuche am Standort des Proxys. Wie die echte Besucheradresse aus X-Forwarded-For sicher gelesen wird, zeigt der Beitrag zur echten Besucher-IP hinter Proxys.

Genauigkeitsradius und Konfidenz lesen

Eine Ortsangabe ohne Unsicherheit ist eine Behauptung. Die Geo-API von XICTRAQ® liefert deshalb zu jeder Antwort einen geschätzten Radius in Kilometern und eine Konfidenz je Feld für Land, Region und Stadt auf einer Skala von 0 bis 100 (XICTRAQ-Handbuch). Beides sind offene Schätzwerte, keine zugesicherte Präzision. Der Radius folgt der erreichten Genauigkeit (XICTRAQ-Handbuch):

• rund 25 km, wenn die Stadt aus einer Betreiber- oder Geofeed-Quelle stammt,
• rund 80 km bei Standorten von iCloud Private Relay,
• rund 50 km, wenn die Stadt aus der Ortsdatenbank kommt,
• 150 km, wenn nur die Region bekannt ist,
• 600 km, wenn nur das Land bekannt ist, auch dann, wenn ein Ersatzort verworfen wurde.

Für den Fall des Ersatzorts sieht die Antwort im Kern so aus. Mit der Stadt fallen Region, Postleitzahl und Koordinaten weg, weil sie aus demselben Datensatz stammen; das Land bleibt stehen:

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

Wer die API einbindet, kann damit steuern, wie weit er einem Ort traut. Für Versandhinweise genügt das Land. Eine Filialsuche sollte bei einem Radius von 600 km keinen Standort vorschlagen, sondern nach der Postleitzahl fragen. Wie eine einzelne Adresse aussieht, lässt sich vorab im kostenlosen IP-Check ansehen, der Radius und Konfidenz mit anzeigt.

Was eine Besucherkarte belegen kann und was nicht

Aus alldem ergibt sich eine einfache Rangfolge. Das Land ist in der Regel belastbar, weil Zugangsnetze ihre Anschlüsse meist innerhalb eines Landes betreiben. Die Region trägt eine mittlere Unsicherheit. Die Stadt ist eine Näherung, die für einzelne Netze gut stimmen und für andere systematisch danebenliegen kann. Der Netzbetreiber ist dagegen meist gut bestimmbar und für die Fehlersuche oft am nützlichsten.

Kleine Fallzahlen sind eine eigene Grenze, auch aus Datenschutzgründen. In der cookielosen Analytics von XICTRAQ® werden Städte und Regionen in den Standort-Aufschlüsselungen erst ausgewiesen, wenn eine Zeile eine Mindestzahl verschiedener Besucher umfasst. Kleinere Zeilen fasst die Auswertung in der Sammelzeile „Übrige“ zusammen. Eine Stadt, die fehlt, kann also schlicht zu wenige Besucher haben. Das senkt das Risiko, einzelne Personen über seltene Standort-Kombinationen wiederzuerkennen, und ist kein Messfehler.

Wer über eingebettete Skripte fremder Anbieter misst, kann in Chrome eine weitere Vergröberung erleben, die der Beitrag zu Chrome IP Protection beschreibt. Auch im eigenen Kontext gemessen bleibt eine Stadt aber eine Näherung: Die Adresse kommt dort ohne diese Maskierung an, ihr Ort stammt trotzdem aus denselben Registern, Datenbanken und Geofeeds, mit denselben Ersatzorten. Der Messkontext entscheidet über die Adresse, nicht über die Genauigkeit des Orts.

So geht XICTRAQ® mit Sammelorten um

Für die Geo-API steht die Regel im Handbuch. In der Analytics-Auswertung arbeitet derselbe Geo-Dienst, und ein eigener Lauf sorgt dafür, dass Sammelorte nicht als Städte erscheinen. Er läuft wöchentlich und geht so vor:

1. Häufung messen: Für jedes Netz wird geprüft, ob ein Ort einen Anteil der Sitzungen trägt, der deutlich über dem Bevölkerungsanteil dieses Orts liegt.
2. Gegenprobe über Websites: Die Häufung muss auf den meisten Websites ähnlich auftreten. Ein Kunde mit lokalem Publikum hebt einen Ort nur auf seiner eigenen Website an und löst damit nichts aus.
3. Netzgebiet prüfen: Das Netz muss bundesweit tätig sein, oder der Ort liegt weit außerhalb des Gebiets eines regionalen Netzes. Forschungsnetze bleiben außen vor, weil Hochschulen tatsächlich in Hochschulstädten sitzen.
4. Ort weglassen: Für erkannte Paare aus Netz und Ort gibt der Geo-Dienst das Land aus, aber keinen Ort. Region, Postleitzahl und Koordinaten fallen mit weg.
5. Bestand nachziehen: Bereits gespeicherte Seitenaufrufe aus der Zeit vor der Erkennung verlieren Ort, Region, Postleitzahl und Koordinaten. Vorher legt der Lauf eine Sicherung an.

Dazu kommen weitere Regeln. Meldet ein Netz für einen Ort selbst einen Geofeed, hat dessen Angabe Vorrang, und der Bestand dieses Paars wird nicht geleert. Und ein einmal erkannter Sammelort bleibt in der Liste: Nach dem Leeren kommen seine Besuche ohne Ort an und könnten ihn sonst nicht mehr belegen. Satellitenzugänge behandelt der Dienst ebenso, weil ihre Adressen am Bodenstandort hängen.

Die Geofeeds holt XICTRAQ® wöchentlich direkt über die Verweise in den Registern mehrerer Vergabestellen ab, darunter das RIPE NCC, und übernimmt nur Zeilen, die im verweisenden Adressbereich liegen, so wie es RFC 9632 verlangt. Beim Nachschlagen haben die Angaben der Betreiber Vorrang vor der Ortsdatenbank. Im Dashboard zählen Besuche aus Sammelorten beim Land weiter mit, erscheinen in der Städteliste aber nicht mehr unter dem Ersatzort. Die IP-Adresse selbst speichert die Besucherstatistik nicht: Sie dient der Tageskennung der Sitzung, der ungefähren Geolokalisierung und der Zuordnung des Netzbetreibers, wie es die Seite zur cookielosen Analytics beschreibt.

Herkunftsdaten Schritt für Schritt prüfen

Für die eigene Herkunftsstatistik reichen wenige Handgriffe:

1. Anteil gegen Bevölkerung halten: Frankfurt am Main hat rund 0,9 Prozent der Einwohner Deutschlands (Hessisches Gemeindelexikon, Eurostat). Liegt der Stadtanteil bei bundesweitem Publikum um ein Vielfaches darüber, ist ein Ersatzort wahrscheinlich.
2. Nach Netzbetreiber aufschlüsseln: Stammt die Häufung aus einem oder wenigen großen Zugangsnetzen, spricht das für einen Ersatzort. Mit dem ASN- und Netz-Lookup lässt sich ein Adressbereich seinem Betreiber zuordnen.
3. Rechenzentren abziehen: Server-Verkehr trägt den Ort des Rechenzentrums. Ob eine Adresse aus einem Hosting-Netz stammt, zeigt der Rechenzentrums-Check.
4. Eigene Zugänge prüfen: Büro-VPN, Testgeräte und Dienstleister erscheinen am Ort ihres Gateways. Welche Adresse und welcher Ort nach außen sichtbar sind, zeigt Meine IP.
5. Proxy-Kette kontrollieren: Erscheinen fast alle Besuche an einem einzigen Ort, liest die Messung womöglich die Adresse eines Proxys statt der des Besuchers.
6. Ort aus eigener Quelle ergänzen: Kampagnenparameter, Filialauswahl oder Postleitzahl im Bestellprozess sagen mehr über die Herkunft als jede IP-Adresse.

Der Ort einer Adresse wirkt auch in die andere Richtung. Manche Shops leiten nach dem Land der Adresse auf Länderseiten um oder blenden andere Versandkosten ein. Wer in der Aktionswoche Wettbewerbspreise beobachtet, sieht deshalb die Fassung, die eine Seite für die Adresse des abrufenden Servers ausliefert, nicht zwingend die, die ein Kunde in einem anderen Land sieht.

Lieber leer als falsch: Herkunft ehrlich auswerten

IP-Standorte sind eine nützliche Näherung, solange klar ist, wie sie entstehen. Das Land trägt, die Stadt ist ein Hinweis, und ein Ersatzort ist gar keine Angabe, sondern eine Lücke mit Ortsnamen. Geofeeds der Netzbetreiber nach RFC 8805 liefern Angaben aus erster Hand, sind aber noch die Ausnahme (arXiv 2502.08849). Bis sie verbreiteter sind, hilft vor allem Ehrlichkeit in der Darstellung: leere Felder statt geratener Städte, ein Radius statt einer Stecknadel.

Wie eine Herkunftsstatistik nach diesen Regeln aussieht, zeigt die Live-Demo. Felder und Radien der Geo-API beschreibt die Funktionsseite Geo-API, die Ersatzort-Regel im Wortlaut das Handbuch zur Geo-API.