Das Web braucht einen Standard für Beobachtungsstandpunkte: Warum Datensätze aus dem öffentlichen Web erfassen sollten, wo die Daten beobachtet wurden

Data Provenance hat traditionell eine grundlegende Frage beantwortet: Woher stammen diese Daten?

Bei einem Datenbankeintrag kann das Quellsystem gemeint sein. Bei Forschungsdaten kann es das Experiment, das Instrument oder die Forscherin oder der Forscher sein, die die Daten erzeugt haben. Bei einem Web-Datensatz bedeutet es meist die Seite, die Domain, die API oder die URL, von der die Informationen erfasst wurden.

Doch das moderne Web wirft eine weitere Frage auf, die zunehmend genauso wichtig wird: Wo wurden die Daten beobachtet?

Ein Suchergebnis, das in London angezeigt wird, kann sich von derselben Anfrage in New York unterscheiden. Ein Händler kann je nach Standort des Besuchers einen anderen Preis, Lagerbestand, eine andere Währung oder einen anderen Verkäufer anzeigen. Eine Anzeige, die über einen ISP sichtbar ist, erscheint über einen anderen möglicherweise nie. Ein mobiler Besucher erhält womöglich eine andere Seite als ein Desktop-Besucher.

Dennoch erfassen viele öffentliche Web-Datensätze nur das Ergebnis, ohne die Bedingungen festzuhalten, unter denen es beobachtet wurde. Wir glauben, dass sich das ändern muss.

Bei geografisch und kontextuell variablen Webdaten sollte der Vantage Point unserer Ansicht nach zu einem festen Bestandteil der Data Provenance werden. Wir verwenden den Begriff Vantage-Point-Provenance, um diesen Beobachtungskontext zu beschreiben.

Die wichtigsten Erkenntnisse

• Traditionelle Data Provenance erfasst häufig die Quelle von Webdaten, ohne die Bedingungen festzuhalten, unter denen sie beobachtet wurden.
• Dieselbe URL kann je nach Geografie, Netzwerkidentität, Gerät und Session-Status unterschiedliche Preise, Suchergebnisse, Anzeigen, Bestände oder Inhalte liefern.
• Ein sinnvoller Vantage-Point-Standard kann mit Zeitstempel, angefordertem Vantage Point, validiertem Austrittsland und -stadt, ASN oder Netzbetreiber, Client- oder Gerätekontext, Session-Status, Ziel-URL und Validierungsstatus beginnen.
• Die Konfiguration von Residential Proxys kann Teil des Provenance-Datensatzes sein, da sie hilft, die Umgebung zu definieren, in der eine Beobachtung gemacht wurde.
• Ein webspezifisches Provenance-Profil kann auf W3C PROV-O aufbauen und sich an der Betonung detaillierter Provenance in den FAIR-Prinzipien orientieren, anstatt bestehende Frameworks zu ersetzen.

Data Provenance hat einen blinden Fleck: den Beobachtungskontext

Das Konzept der Data Provenance ist bereits etabliert. Das NIST Research Data Framework definiert Provenance als die dokumentierte Geschichte eines Datenobjekts, einschließlich wo, wann, wie und von wem es erzeugt, erfasst oder verarbeitet wurde. Arbeitsmaterialien für NISTs sich entwickelndes Data Governance and Management Profile listen ebenfalls das Verwalten von Metadaten, Data Provenance und Data Lineage unter den vorgesehenen Aktivitäten des Datenlebenszyklus-Managements auf.

Das ist wichtige Arbeit. Provenance ermöglicht es Organisationen, Vertrauen aufzubauen, Fehler zu untersuchen, Prozesse zu reproduzieren und nachzuvollziehen, wie sich Informationen verändert haben. Doch die Erfassung öffentlicher Webdaten führt eine ungewöhnliche Unterscheidung ein.

Es gibt den Ursprung der Information und es gibt die Beobachtung der Information. Angenommen, ein Datensatz erfasst https://example.com/product/123 als Quelle eines Produktpreises.

Das sagt uns, woher die Information stammt. Es sagt uns nicht, ob der Sammler die Seite von Chicago, Paris oder Singapur aus aufgerufen hat. Es sagt uns nicht, ob die Anfrage über einen Residential-ISP oder ein Cloud-Rechenzentrum kam. Es sagt uns nicht, ob die Seite als mobiler Nutzer angesehen wurde, ob bereits eine Session bestand oder ob die Antwort die erwartete Seite war und nicht ein Lokalisierungs-Redirect oder eine Bot-Challenge.

Bei modernen Webdaten kann dieser Kontext die Beobachtung erheblich beeinflussen.

Source Provenance sagt uns, woher Informationen stammen. Vantage-Point-Provenance fügt die Bedingungen hinzu, unter denen sie beobachtbar wurden. Wir brauchen beides.

Dieselbe URL bedeutet nicht immer dasselbe Web

Die Annahme, dass eine URL auf eine einzige, universelle Darstellung von Information abgebildet wird, ist zunehmend überholt. Moderne Websites passen Antworten anhand einer Vielzahl von Signalen an.

Geografie kann Preise, Verfügbarkeit, Sprache, Suchergebnisse, Verkäufer, Werbung, regulatorische Hinweise oder Consent-Flows sowie den Zugang zu lizenzierten Inhalten beeinflussen. Netzwerkidentität kann Betrugserkennung und Anti-Bot-Systeme beeinflussen. Der Gerätetyp kann Seitenlayouts verändern und sogar bestimmen, welche Informationen angezeigt werden. Cookies und Session-Verlauf können Empfehlungen, Personalisierung und Authentifizierungsstatus beeinflussen.

Betrachten wir einige alltägliche Aufgaben der Datenerfassung:

• Eine Price-Intelligence-Plattform prüft einen Händler aus den Vereinigten Staaten und aus Deutschland. Die URL ist identisch, aber Produktpreis, Lagerstatus, Versandoptionen und verfügbarer Verkäufer können sich unterscheiden.
• Eine SEO-Plattform misst ein Google-Ergebnis aus Miami und aus London. Die Anfrage ist identisch, aber organische Ergebnisse, Local Packs, Anzeigen und andere SERP-Funktionen können sich unterscheiden.
• Eine Ad-Verification-Plattform prüft eine Kampagne aus mehreren Städten. Die Seite des Werbetreibenden hat sich nicht verändert, aber die ausgelieferte Anzeige kann vom Standort und Netzwerk des Betrachters abhängen.

Das sind keine Randfälle. Es sind Eigenschaften des Webs, wie es heute existiert. Ein Datensatz, der einfach URL plus Ergebnis erfasst, kann daher den Inhalt bewahren, während ein Teil der Beweise verloren geht, die zur Interpretation erforderlich sind.

Was ein Vantage-Point-Provenance-Standard erfassen sollte

Die Antwort muss kein riesiges Metadatenschema sein, das an jede Anfrage angehängt wird. Ein sinnvoller Standard könnte mit einer kleinen Menge von Feldern beginnen, die die Bedingungen erfassen, die eine Beobachtung im öffentlichen Web am wahrscheinlichsten beeinflussen.

Feld	Was erfasst werden sollte	Warum es wichtig ist
Zeitstempel	Wann die Beobachtung stattfand, vorzugsweise mit einem standardisierten UTC-Zeitstempel.	Webinhalte ändern sich ständig. Ohne Zeitangabe ist selbst ein ansonsten vollständiger Provenance-Datensatz schwer zu reproduzieren.
Angeforderter Vantage Point	Die von der Erfassungsinfrastruktur angeforderten Geografie- und Netzwerkselektoren, sofern zutreffend.	Angeforderte Parameter beschreiben den beabsichtigten Beobachtungskontext und unterscheiden die Erfassungsabsicht vom tatsächlich genutzten Austrittspunkt.
Validierte Austrittsgeografie	Das Land und, sofern verfügbar, die Stadt, die mit der tatsächlichen Austritts-IP der Anfrage verknüpft sind.	Der vom Ziel gesehene Austrittspunkt kann vom angeforderten Standort abweichen, wenn Fallback-Verhalten zulässig ist. Der validierte Austrittskontext ist das, was die Beobachtung tatsächlich darstellt.
ASN / Netzbetreiber	Die mit der Austritts-IP verknüpfte ASN und, sofern verfügbar, der entsprechende ISP oder Netzbetreiber.	Das Land allein reicht möglicherweise nicht aus. ASN- oder Betreiberkontext hilft, die Netzwerkumgebung zu beschreiben, aus der die Beobachtung stammt.
Client-/Gerätekontext	Relevante Client-Eigenschaften wie Mobil- oder Desktop-Profil, Browserfamilie oder -Engine, Betriebssystemprofil, Viewport oder das normalisierte Browserprofil des Erfassungssystems.	Client- und Gerätekontext können Seitenlayouts verändern und in manchen Fällen bestimmen, welche Informationen angezeigt werden.
Session-Status	Ob die Anfrage eine neue, persistente oder authentifizierte Session verwendet hat und ob Cookies oder Session-Status beibehalten wurden. Die Klassifizierung sollte erfasst werden, nicht Zugangsdaten oder rohe Cookie-Werte.	Session-Bedingungen können die von einer Website zurückgegebene Seite grundlegend verändern, während gleichzeitig die Speicherung sensibler Authentifizierungsdaten vermieden wird.
Ziel-URL	Die exakt angeforderte URL, einschließlich relevanter Parameter.	Die Zielressource ist Teil des Quellkontexts, der zur Interpretation und Reproduktion einer Beobachtung nötig ist.
Validierungsstatus	Ob die zurückgegebene Antwort als der beabsichtigte Inhalt validiert wurde.	Eine erfolgreiche HTTP-Antwort kann dennoch ein CAPTCHA, ein Redirect, eine Consent-Seite, eine Blockseite, eine leere Antwort oder eine unerwartete Lokalisierung sein.

Zusammen ergeben diese Felder ein nützlicheres Modell:

Beobachtung = Inhalt + Quelle + Zeit + Vantage Point + Client-/Session-Kontext + Validierung.

Auf dieser Ebene sollte Provenance für öffentliche Webdaten unserer Ansicht nach zunehmend operieren.

Residential Proxys sollten Teil des Provenance-Datensatzes sein, nicht nur des Erfassungs-Stacks

Residential Proxys werden meist als Infrastruktur diskutiert. Ein Sammler benötigt Daten aus Deutschland, also wird der Traffic über eine deutsche IP geleitet. Ein Workflow benötigt eine persistente Identität, also wird eine Sticky Session verwendet. Ein Datensatz erfordert Ergebnisse auf Stadtebene, also fordert das Erfassungssystem eine bestimmte Stadt an.

Diese Beschreibung ist technisch korrekt, aber unvollständig. Wenn der Proxy bestimmt, wo und über welches Netzwerk eine Beobachtung erfolgt, dann ist seine relevante Konfiguration Teil der Messumgebung.

Wissenschaftliche Forscherinnen und Forscher dokumentieren experimentelle Bedingungen, weil diese Bedingungen ihre Ergebnisse beeinflussen können. Die Erfassung öffentlicher Webdaten sollte dieselbe Denkweise übernehmen.

Mit unserem Residential-Proxy-Netzwerk können Anfragen nach Land, Region, Stadt oder ASN gezielt gesteuert werden, während Erfassungssysteme zwischen Rotation pro Anfrage und Sticky Sessions wählen können. Shifters Geo-Targeting wird pro Anfrage konfiguriert, und bei strikter Übereinstimmung kann sichergestellt werden, dass die exakt angeforderte Geografie eingehalten wird, wenn es darauf ankommt. Auch das Session-Verhalten ist eine Entscheidung pro Anfrage.

Diese Steuerungsmöglichkeiten gelten normalerweise als Erfassungsparameter. Wir sind der Meinung, dass sie zunehmend auch als Provenance-Parameter betrachtet werden sollten. Das bedeutet nicht, dass ein Proxy beweist, dass eine Beobachtung korrekt ist. Es bedeutet, dass die Konfiguration hilft, die Bedingungen zu erklären, unter denen die Beobachtung zustande kam.

Unsere Proxy-Benchmarks zeigen, warum der Vantage Point wichtig ist

Dasselbe Prinzip zeigt sich beim Proxy-Benchmarking. Wenn wir Residential-Netzwerke vergleichen, verlassen wir uns nicht ausschließlich auf die von Anbietern beworbenen Gesamt-Pool-Größen. Unsere Benchmarks messen die IP-Adressen, die zum Testzeitpunkt live und erreichbar sind, und die Ergebnisse werden nach einzelnen Märkten aufgeschlüsselt. Die Verfügbarkeit von Residential-IPs ändert sich kontinuierlich, daher sind Zeit und Geografie Teil dessen, was der Benchmark tatsächlich darstellt.

Unsere Methodik kontrolliert auch wichtige Erfassungsbedingungen. Das Benchmark-Programm verwendet feste Anfragevolumina, dasselbe Ziel, eine feste Nebenläufigkeitseinstellung und dieselbe Maschine oder denselben Server für vergleichbare Testläufe. Auch die paarweisen Benchmark-Seiten empfehlen, bei der Reproduktion eines Tests dieselbe Stunde zu verwenden.

Wir messen auch die Netzwerkstreuung, nicht nur die Anzahl der Adressen. Anbieter mit ähnlicher Anzahl erreichbarer IPs können sich dennoch erheblich in der Zahl der innerhalb eines Landes vertretenen autonomen Systeme unterscheiden.

Diese Methodik veranschaulicht ein umfassenderes Prinzip: Eine Messung wird aussagekräftiger, wenn man die Bedingungen kennt, unter denen sie erfolgte. Öffentliche Web-Datensätze verdienen dieselbe Disziplin.

Bessere Data Provenance bedeutet reproduzierbarere und überprüfbarere Web-Datensätze

Wenn der Vantage Point Teil der Data Provenance würde, entstünden praktische Vorteile im gesamten Datenökosystem.

• Für die Reproduzierbarkeit könnte ein anderes Team versuchen, nicht nur URL und Zeitstempel, sondern die annähernde Umgebung nachzustellen, aus der die Beobachtung stammte.
• Für Audits könnten Analystinnen und Analysten, die widersprüchliche Datensätze untersuchen, feststellen, ob zwei Beobachtungen aus unterschiedlichen Ländern, Netzwerken, Geräten oder Sessions erfasst wurden, bevor sie annehmen, dass eine davon falsch war.
• Für die Datenqualität könnten regionale Unterschiede von Extraktionsfehlern getrennt werden.

Die Auswirkungen werden für KI noch bedeutsamer. Trainingsdatensätze, Retrieval-Pipelines und Evaluierungsdatensätze hängen zunehmend von aktuellen Webinformationen ab. Doch die geografische Abdeckung spielt eine Rolle. Unsere Hinweise zu KI- und Machine-Learning-Datenerfassung spiegeln diese Realität bereits wider: Modelle und Agenten müssen unter Umständen Informationen so erfassen, wie Nutzerinnen und Nutzer in verschiedenen Regionen sie tatsächlich vorfinden, mit Erfassung aus mehreren Regionen und Abgleich gegen live erfasste Web-Ground-Truth.

Ohne Vantage-Point-Metadaten kann geografische Ungleichgewichtigkeit unsichtbar werden, sobald Informationen in einen Datensatz gelangen. Mit ihnen können Teams deutlich bessere Fragen stellen.

Wie viel Prozent dieses Datensatzes wurden aus den Vereinigten Staaten beobachtet? Welche ASNs waren vertreten? Haben mobile und Desktop-Erfassung unterschiedliche Ergebnisse geliefert? Sind scheinbare Widersprüche tatsächlich regionale Unterschiede? Das ist nicht nur Provenance. Es ist bessere Data Governance.

Ein Vantage-Point-Standard kann bestehende Data-Provenance-Frameworks erweitern

Es ist nicht nötig, Provenance von Grund auf neu zu erfinden. Der W3C-PROV-O-Standard bietet bereits ein Framework zur Darstellung und zum Austausch von Provenance-Informationen zwischen verschiedenen Systemen. Wichtig ist, dass das W3C PROV-O so gestaltet hat, dass seine Klassen und Eigenschaften für anwendungsspezifische Provenance-Details in verschiedenen Bereichen spezialisiert werden können.

Die FAIR-Datenprinzipien weisen in dieselbe Richtung. Damit Daten wiederverwendbar sind, sollten ihre Metadaten umfassend beschrieben, mit detaillierter Provenance versehen und an domänenrelevanten Community-Standards ausgerichtet sein. Die Chance besteht also nicht darin, bestehende Provenance-Standards zu ersetzen.

Sie besteht darin, innerhalb dieses breiteren Ökosystems ein webspezifisches Provenance-Profil zu definieren. Ein solches Profil könnte Felder wie angeforderten Vantage Point, validierte Austrittsgeografie, ASN oder Netzbetreiber, Client-Kontext, Session-Bedingungen, Zielressource, Zeitstempel und Validierungsstatus standardisieren.

Sobald diese Felder vorhersehbar werden, lassen sie sich für Scraping-Plattformen, Data Warehouses, KI-Pipelines und Datensatz-Herausgeber leichter bewahren und austauschen.

Die Web-Data-Branche sollte den Vantage Point zu einem erstklassigen Feld machen

Öffentliche Webdaten werden zunehmend genutzt, um folgenreiche Entscheidungen zu treffen. Sie treiben Price Intelligence, Werbeanalysen, Markenschutz, Finanzrecherche, SEO-Plattformen, KI-Systeme, Marktinformationen und autonome Agenten an.

Die Standards rund um diese Daten sollten widerspiegeln, wie das Web tatsächlich funktioniert. Scraping-APIs könnten Beobachtungsmetadaten zusammen mit dem zurückgegebenen Inhalt bereitstellen. Proxy-Anbieter könnten es einfacher machen, relevanten Netzwerk- und Geografiekontext automatisch zu erfassen. Datenpipelines könnten ihn neben jedem Datensatz bewahren, statt ihn nach der Erfassung zu verwerfen. Datensatz-Herausgeber könnten die Verteilung der Vantage Points dokumentieren, die zum Aufbau ihrer Korpora verwendet wurden.

Fazit

Nichts davon erfordert, jedes technische Detail jeder HTTP-Anfrage zu speichern. Es erfordert die Anerkennung eines wichtigen Prinzips: Wo etwas gesehen wurde, kann Teil dessen sein, was die Beobachtung aussagekräftig macht.

Ein Residential Proxy sollte daher nicht immer als unsichtbare Leitung zwischen Sammler und Website behandelt werden. Wenn Geografie, Netzwerkidentität oder Session-Verhalten die zurückgegebene Information beeinflussen können, werden die relevante Proxy-Konfiguration und der validierte Austrittskontext Teil des Provenance-Datensatzes.

Das Web ist geografisch, zeitlich und kontextuell variabel geworden. Unsere Datensätze müssen diese Realität anerkennen.

Die nächste Generation von Webdaten sollte nicht nur erfassen, was gesehen wurde und woher es stammte, sondern auch, wo der Beobachter stand, als er es sah.

Quellen und Referenzen

• NIST, Research Data Framework (RDaF) Version 2.0. Provenance-Definition und Framework für den Lebenszyklus von Forschungsdaten.
• NIST, Data Governance and Management Profile Working Session 2. Vorgesehene Aktivitäten des Datenlebenszyklus, einschließlich Metadaten, Data Provenance und Data Lineage.
• W3C, PROV-O: The PROV Ontology. Framework für den Austausch von Provenance-Informationen und Spezialisierung für anwendungsspezifische Bereiche.
• GO FAIR, FAIR Principles Overview. Wiederverwendbare Daten, umfassende Metadaten, detaillierte Provenance und domänenrelevante Community-Standards.
• Shifter, Residential Proxies geo-targeting documentation. Land, Region, Stadt, ASN, strikte Übereinstimmung und Fallback-Verhalten.
• Shifter, Residential Proxies sessions documentation. Rotation pro Anfrage und Sticky-Session-Verhalten.
• Shifter, 15 Residential Proxy Providers, Ranked on One Identical Test, 13. August 2026. Benchmark-Methodik, feste Anfragevolumina, Nebenläufigkeit, Zielort und Messung der Netzwerkstreuung.
• Shifter, Shifter vs Evomi Residential Proxy Benchmark. Paarweise Methodik, Messung von Live-IPs und ASN sowie Hinweise zur Reproduzierbarkeit.