Price Scraping: Funktionsweise, Rechtslage, Make or Buy

Wie Price Scraping Stufe für Stufe funktioniert, welche Unterscheidungen rechtlich zählen, warum es im Maßstab schwierig wird und wann sich Kaufen statt Bauen lohnt.

Was ist Price Scraping?

Price Scraping ist die automatisierte Erfassung öffentlich angezeigter Produktpreise von Websites — Händler-Produktseiten, Marktplatz-Listings und Preisvergleichsportale — und ihre Umwandlung in strukturierte Datensätze, die mit dem eigenen Katalog vergleichbar sind. Ein Price Scraper ruft die Seite ab, extrahiert Preis und zugehörige Felder und schreibt sie mit Zeitstempel in einen Datensatz.

Es ist die Erhebungsschicht unter der Wettbewerbspreisbeobachtung. Alles, was ein Pricing-Team danach tut, hängt daran, wie gut dieser Schritt gemacht ist.

Wie funktioniert Price Scraping?

Sechs Stufen. Teams, die selbst bauen, unterschätzen meist die letzten drei.

• Discovery. Die zu erfassenden URLs finden — über Kategorieseiten, Sitemaps, Suche oder eine SKU-Startliste. Das ist Crawling und ein anderes Problem als die Extraktion; die Abgrenzung steht in Daten-Crawling vs. Daten-Scraping.
• Abruf. Die Seite holen. Moderne Handelsseiten rendern Preise häufig clientseitig; eine einfache HTTP-Anfrage liefert Markup ohne Preis, und ein Headless Browser wird nötig.
• Parsing. Preis, Währung, Streichpreis, Aktion, Verfügbarkeit, Verkäufer, Versand und Lieferschätzung extrahieren. Strukturierte Daten in der Seite (JSON-LD, Microdata) sind stabiler als CSS-Selektoren, wo vorhanden.
• Normalisierung. Währung, Mehrwertsteuerbehandlung, Einheiten und Packungsgrößen vereinheitlichen. Ein Preis ist nicht vergleichbar, solange unklar ist, ob Steuer und Versand enthalten sind.
• Zuordnung. Jedes Angebot auf ein kanonisches Produkt auflösen. Die Produktzuordnung entscheidet, ob der Datensatz nutzbar ist.
• Lieferung und Monitoring. In Warehouse, Feed oder API schreiben — und die Pipeline selbst überwachen, denn der Normalfall des Scheiterns ist der stille Bruch.

Ist Price Scraping legal?

Allgemeine Einordnung, keine Rechtsberatung — die Antwort hängt von Jurisdiktion, Erhebungsumfang und Vorgehen ab. Lassen Sie ein konkretes Vorhaben juristisch prüfen.

Die praktisch relevanten Unterscheidungen:

• Öffentlich versus zugangsbeschränkt. Informationen zu erfassen, die eine Seite jedem Besucher zeigt, wird deutlich anders bewertet als Zugriff hinter Login oder Paywall. US-Verfahren drehten sich im letzten Jahrzehnt wiederholt um diese Linie, am sichtbarsten im langen Streit zwischen hiQ Labs und LinkedIn, in dem Gerichte zurückhaltend waren, das Scrapen öffentlich sichtbarer Seiten als unbefugten Systemzugriff zu behandeln. Zugriff mit Zugangsdaten ist eine völlig andere Frage.
• Vertrag und Nutzungsbedingungen. Bedingungen, die Sie aktiv akzeptieren — durch Kontoerstellung, Klick oder Login — können binden, unabhängig davon, dass die Daten öffentlich sind. Die europäische Rechtsprechung hat genau das betrachtet: eine Datenbank ohne Sui-generis-Schutz kann dennoch über die vertraglichen Nutzungsbedingungen geschützt sein.
• Datenbank- und Urheberrecht. In der EU kann das Sui-generis-Datenbankrecht wesentliche Entnahmen schützen, auch wenn einzelne Fakten nicht urheberrechtsfähig sind. Preise selbst sind Fakten; die großflächige Reproduktion einer strukturierten Sammlung ist eine andere Frage.
• Personenbezogene Daten. Die DSGVO greift, sobald Sie personenbezogene Daten erheben — Verkäufernamen, die Personen identifizieren, Rezensentenprofile, Kontaktdaten. Produktpreise sind keine personenbezogenen Daten, Rezensentenidentitäten schon. Erheben Sie nur, was Sie brauchen.
• Last und Zugangskontrollen. Aggressives Crawlen, das einen Dienst beeinträchtigt, sowie das Umgehen technischer Zugangskontrollen verschieben ein Projekt in deutlich riskanteres Terrain — unabhängig davon, ob die Daten öffentlich sind.

Die praktikable Haltung: nur öffentliche Daten erheben, Robots-Direktiven und Rate Limits respektieren, authentifizierte Bereiche meiden, keine personenbezogenen Daten ohne Zweck sammeln, Herkunftsnachweise führen und vor dem Skalieren eine Freigabe einholen.

Warum ist das im Maßstab schwierig?

• Clientseitiges Rendering. Der Preis wird nach dem Laden per JavaScript eingesetzt; ein naiver Scraper erfasst nichts oder den falschen Wert.
• Bot-Abwehr. Rate Limiting, Fingerprinting, Challenge-Seiten. Verantwortlich damit umzugehen heißt zurücknehmen, nicht eskalieren.
• Geografie und Währung. Preise unterscheiden sich je Land und je IP innerhalb eines Landes. Ohne kontrollierten Geo-Kontext mischt Ihr Datensatz still Märkte.
• Variantenexplosion. Farbe, Größe, Packungsmenge und Verkäufer verändern den Preis. Zusammenfalten verliert das Signal, nicht falten begräbt es.
• Layout-Drift. Händler bauen um. Ein selektorbasierter Scraper degradiert leise, was schlimmer ist als laut zu scheitern.
• Aktualität gegen Kosten. Stündliche Erfassung über 100.000 SKUs ist ein anderes Engineering-Problem als tägliche über 5.000.
• Stiller Qualitätsverlust. Eine Pipeline, die 0 statt null zurückgibt oder den Cache der Vorwoche liefert, wirft keinen Fehler. Sie macht nur Ihre Preise falsch.

Selbst bauen oder einkaufen?

Selbst bauen lohnt, wenn Scraping zum Kern Ihres Produkts gehört, Sie ungewöhnliche Quellen brauchen und die Wartung dauerhaft besetzen können — Wartung ist 80% der Gesamtkosten, nicht die Extraktion.

Einkaufen lohnt, wenn Sie Preise brauchen, um Preisentscheidungen zu treffen, und nicht, um ein Datengeschäft zu betreiben. Der ehrliche Vergleich ist dann nicht Lizenzgebühr gegen null, sondern Lizenzgebühr gegen Entwicklerzeit, Proxy-Kosten und die Kosten von Entscheidungen auf einem Feed, der vor drei Wochen brach und niemandem auffiel.

Zwei Zwischenoptionen werden oft übersehen:

• Ein Scraper-API — Orchestrierung und Zeitplanung bleiben bei Ihnen, Rendering, Blocking und Parsing übernimmt ein anderer. Unser E-Commerce-Scraper-API deckt diese Schicht ab.
• Ein Managed Feed — Sie erhalten normalisierte, zugeordnete Daten nach Zeitplan und berühren die Erhebung nie. Das ist Web-Datenerfassung als Dienstleistung oder fertige Mitbewerber-Preisdatenbanken, wo die Quellen bereits abgedeckt sind.

Wie sehen gute Preisdaten aus?

Ob gebaut oder gekauft — bestehen Sie je Datensatz auf diesen Feldern:

• Kanonische Produkt-ID plus die SKU und GTIN der Quelle
• Aktueller Preis, Streichpreis und laufende Aktion, mit Währung und Steuerbehandlung
• Versandkosten und Lieferschätzung
• Verfügbarkeit und Verkäuferidentität
• Marktplatz, Land und URL
• Erfassungszeitstempel und Matching-Konfidenz

Die letzten beiden lassen Teams weg und können später nicht ohne sie arbeiten. Ohne Zeitstempel lässt sich über Aktualität nicht argumentieren; ohne Matching-Konfidenz lässt sich eine echte Preislücke nicht von einem Zuordnungsfehler trennen.

Typische Fehler

• Extraktion für das ganze Problem halten. Die harten Teile sind Zuordnung, Normalisierung und Wartung.
• Kein Pipeline-Monitoring. Alarme auf Abdeckung und Null-Quote je Quelle und Tag sind nicht optional. Kaputte Scraper melden sich nicht.
• Märkte mischen. Ein Datensatz mit DE-, AT- und CH-Preisen ohne Länderfeld erzeugt unsinnige Vergleiche.
• Versand ignorieren. Günstigster Preis plus teure Lieferung ist nicht das günstigste Angebot — Ihre Wettbewerber wissen das.
• Mehr scrapen als nötig. Jede zusätzliche Quelle ist dauerhafte Wartung. Fangen Sie mit den Wettbewerbern an, die Ihr Volumen wirklich bewegen.
• Keine juristische Prüfung. Die technische Arbeit ist meist leichter als die Freigabe; holen Sie die Freigabe zuerst.

Wie fängt man an?

Eine Kategorie und die fünf relevanten Wettbewerber darin. Täglich erfassen, Historie ab Tag eins speichern und die Matching-Quote instrumentieren, bevor irgendein Dashboard gebaut wird.

Wenn das Ziel Preisentscheidungen sind und keine Datenplattform, überspringen Sie die Zwischenschritte: Mitbewerber-Preisdatenbanken und das Scraper-API liefern denselben Input ohne Wartungslast. Was mit dem Output zu tun ist, steht in Price Intelligence; die dichteste öffentliche Quelle für Wettbewerbspreise behandeln die Preisvergleichsportale.