Supermarkt-Preisverfolgung mit Playwright
(sakisv.net)- Im Dezember 2022 wurde angesichts der hohen Inflation die Pipeline pricewatcher.gr aufgebaut, um die täglichen Preisänderungen bei den drei größten Supermarktketten Griechenlands zu verfolgen
- Da die Produktlisten erst nach JavaScript-Rendering und Infinite Scroll verfügbar waren, wurde statt
curloderrequests.get()Playwright eingesetzt, um den Browser zu steuern und Daten aus dem DOM zu extrahieren - Da die Ausführung nur auf einem alten Laptop zu langsam und AWS EC2 zu teuer war, wurde auf ein Modell umgestellt, bei dem Hetzner-Server nur bei Bedarf erstellt werden, drei Scraper parallel laufen und der Server anschließend wieder beendet wird
- Bei einem Supermarkt, dessen Akamai-Konfiguration nicht-residentiale IPs blockierte, wurde über einen Tailscale Exit Node die heimische IP genutzt; Fehler wurden per E-Mail-Benachrichtigung, strikter Transformation und Heuristiken zur Produktanzahl erkannt
- Mit einem 8-vCPU-Server und blockierten Bildanfragen wurde die Laufzeit verkürzt; die Kosten der letzten 31 Ausführungen lagen bei etwa €4,94 für Hetzner-Server, €0,09 für IPv4 und €0,00 für Cloudflare-R2-Speicher
Scraping JavaScript-basierter Supermarkt-Websites
- In einer Phase hoher Inflation im Dezember 2022 wurde pricewatcher.gr aufgebaut, um die Preisänderungen bei den drei größten Supermarktketten Griechenlands zu verfolgen
- Die E-Shops aller drei Supermärkte nutzten JavaScript-Rendering, und in manchen Bereichen wurden wie bei Infinite Scroll in sozialen Medien beim Scrollen weitere Produkte nachgeladen
- Mit einfachem
curloderrequests.get()ließen sich die Produktdaten nicht abrufen, daher wurde Playwright verwendet - Playwright steuert Browser programmatisch und erledigt per API unter anderem folgende Aufgaben
- neue Tabs öffnen und URLs aufrufen
- das DOM untersuchen
- Elementdetails abfragen
- Requests abfangen und untersuchen
- Playwright unterstützt Chromium, Safari und Firefox und kann mit Node, Java, .NET und Python verwendet werden
- Der Scraper sucht das
load more-Element des Infinite Scroll, scrollt wiederholt weiter und schließt anschließend in der Listeli.product-itemProdukte mit Ausverkauft-Markierung aus - Schließlich werden bei jedem Produkt Produktname, Preis, Bild, Link usw. geparst und derselbe Vorgang für die nächste Produktkategorie wiederholt
Auswahl einer täglichen Laufzeitumgebung
- Auf einem M1 MacBook Pro dauerte die vollständige Verarbeitung eines einzelnen Supermarkts 50 Minuten bis 2 Stunden 30 Minuten, und selbst bei paralleler Ausführung der drei Scraper gab es keinen spürbaren Unterschied
- Für Entwicklung und Tests reichte ein Laptop aus, es wurde jedoch eine dauerhafte Umgebung für die tägliche Ausführung benötigt
-
Nur ein alter Laptop
- Der erste Versuch lief auf einem alten Laptop aus dem Jahr 2013
- Die Spezifikationen waren ein 2,20-GHz-Dual-Core-Prozessor der M-Serie und 4 GB RAM, später auf 12 GB RAM erweitert
- Aber selbst ein „schneller“ Supermarkt brauchte mehr als 2 Stunden, also blieb die Leistung hinter den Erwartungen zurück
-
Ausführung in der Cloud
- Bei AWS wurde eine EC2-Instanz mit 4 Kernen und 8 GB RAM geprüft, doch für die Kosten eines Side Projects war das zu hoch
- Zum Zeitpunkt des Schreibens kostete
c5a.xlargeineu-north-1$0.1640 pro Stunde, also etwa $118.08 pro Monat oder $1,416.96 pro Jahr - Ein vergleichbarer Hetzner-Server,
cpx31, kostete $17.22 (€15.72) pro Monat bzw. $206.64 pro Jahr und war damit etwa siebenmal günstiger als AWS - Als endgültige Laufzeitumgebung wurde Hetzner gewählt
Tägliche Pipeline mit Concourse
- Der alte Laptop führte das Scraping nicht selbst aus, sondern übernahm als CI-Server die Rolle, Jobs an Hetzner-Server zu delegieren
- Als CI-Tool wurde Concourse verwendet
- Concourse beschreibt sich selbst als „a continuous thing-doer“
- Mit einem deklarativen Pipeline-Modell und Versionierung der Eingaben zielt es auf reproduzierbare Builds
- Die Pipeline läuft jede Nacht in folgender Reihenfolge
- Scraping-Server erstellen
- drei Supermarkt-Scraping-Jobs parallel ausführen
- nach Abschluss aller Jobs den Server zur Kostensenkung wieder beenden
- die Rohdaten jedes Scrapers an einen Transformationsjob weitergeben
- die transformierten Daten in pricewatcher.gr laden
- bei einem Fehler in irgendeinem Schritt eine E-Mail-Benachrichtigung senden
Umgehung von IP-Beschränkungen mit Tailscale Exit Node
- Der für Tests genutzte Supermarkt funktionierte normal, doch ein anderer Supermarkt stand hinter Akamai und hatte Firewall-Regeln aktiv, die Anfragen von nicht-residentialen IPs blockierten
- Benötigt wurde eine Struktur, die im Gegensatz zu einem üblichen VPN Anfragen so wirken lässt, als kämen sie von der tatsächlichen Heim-IP
- Mit Tailscale werden mehrere Geräte so verbunden, als befänden sie sich im selben Netzwerk
- Wenn in Tailscale ein Gerät als Exit Node festgelegt wird, können Anfragen anderer Geräte so konfiguriert werden, dass sie über diesen Knoten ins Internet gehen
- Der alte Laptop übernahm zusätzlich die Rolle des Exit Node für den Scraping-Traffic
- Eine weitere Variable bleibt, dass der verwendete ISP CGNAT nutzt, sodass die öffentliche IP nicht exklusiv einer einzelnen Person zugeordnet ist, sondern mit anderen Kunden des ISP geteilt wird
Fehlertypen und Erkennung
- Dieses Setup lief anderthalb Jahre lang und funktionierte insgesamt zuverlässig
- Scraping-Projekte sind zwangsläufig von Änderungen der Entwickler der Ziel-Websites betroffen
- Fehler lassen sich grob in zwei Arten einteilen
-
Brechende Änderungen
- Das sind Fälle, in denen der Scraper durch eine Website-Änderung sofort fehlschlägt
- Beispiele sind
- eine neu hinzugefügte Umfrage, bei der ein zusätzlicher Button geklickt werden muss
- ein vollständig geändertes Layout, das ein größeres Refactoring des Scrapers erfordert
-
Nicht brechende Änderungen
- Schwieriger sind Fälle, in denen der Scraper weiterhin normal läuft, die Daten aber falsch interpretiert werden
- Wenn sich zum Beispiel die Preisdarstellung ändert und der Dezimalteil in `` ausgelagert wird, können Chips für €1.99 als €199 geparst werden
- Um solche Änderungen zu erkennen, wurde die Transformationsstufe so aufgebaut, dass sie Eingaben möglichst strikt validiert
- Da die Pipeline täglich läuft, bleibt Zeit, Probleme zu prüfen, aber wenn während eines Urlaubs etwas kaputtgeht, bleibt das ein Unsicherheitsfaktor
Optimierung von Laufzeit und Stabilität
- Die Gesamtarchitektur ist seit dem Anfang fast unverändert geblieben, aber mehrere Teile wurden angepasst, um die Zuverlässigkeit zu erhöhen und manuellen Aufwand zu verringern
- Zu den Verbesserungen gehörten
- E-Mail-Benachrichtigungen bei Fehlern
- Heuristiken, die warnen, wenn bei einem bestimmten Supermarkt die Produktanzahl zu hoch oder zu niedrig ist
- Timeouts
- Retries, die nicht wieder ganz von vorn beginnen
- Der größte Engpass war die Laufzeit des Scrapings
- Je länger es dauert, desto höher werden die Kosten
- Wenn nach einem Fehler erneut von ganz vorn gestartet werden muss, ist das besonders unpraktisch
-
Größeren Server verwenden
- Der Server wurde von 4 vCPU und 16 GB RAM auf 8 vCPU und 16 GB RAM umgestellt
- Die Laufzeit sank um etwa 20 % und erreichte ungefähr das Leistungsniveau des MBP
- Da der Scraping-Server nur etwa 2 Stunden genutzt wird, war der Preisunterschied vernachlässigbar
-
Weniger abrufen
- Mit Playwrights
page.routewurden Bildanfragen blockiert .png- und.jpg-Requests wurden mit abort behandelt, sodass beim Laden der Produkte keine Bilder geladen wurden- Das machte das Scraping schneller und konnte außerdem Bandbreite sowie die Kosten der Ziel-Website geringfügig senken
- Mit Playwrights
Kosten auf Basis von 31 Ausführungen
- Laut der letzten Hetzner-Rechnung fielen folgende Kosten an
- 31 erstellte Server: €4.94
- 31 IPv4-Adressen für diese Server: €0.09
- Die Scraping-Daten werden in Cloudflare R2 gespeichert
- Das kostenlose 10-GB-Kontingent von Cloudflare R2 wurde noch nicht überschritten, daher lagen die Speicherkosten bei €0.00
- Die gesamte Pipeline kombiniert Playwright, Hetzner, Concourse, Tailscale und Cloudflare R2, um tägliche Preisänderungen in Supermärkten zu verfolgen
1 Kommentare
Hacker-News-Kommentare
Seit Anfang dieses Jahres mache ich etwas Ähnliches für Neuseeland. Ich scrape die Daten mit Playwright/Typescript und speichere sie als Parquet-Dateien im Cloud-Speicher, zeige sie aber noch nicht auf einer Oberfläche an
Der Großteil der Arbeit fließt darin, Reverse-Proxy-Dienste wie Akamai und Cloudflare zu umgehen. Als ich angefangen habe, dachte ich, das macht sonst niemand, aber inzwischen weiß ich von mindestens drei Startups in NZ, die dasselbe tun. Die Inflation scheint hier ziemlich viel Innovation ausgelöst zu haben
Das Muster ist wie erwartet. Supermärkte nutzen ihre üblichen Tricks, um Preise möglichst kompliziert zu machen, und trennen mit „sägezahnartigen“ Preisänderungen Menschen mit wenig Zeit von Menschen mit wenig Geld. Oft werden auch markentreue Kundschaft und preissensible Kundschaft getrennt; wenn es drei beliebte Schokoladenmarken gibt, ist jede Woche nur eine davon zu einem vernünftigen Preis zu haben
Besonders der Teil „Sie trennen markentreue Kundschaft und preissensible Kundschaft. Wenn es drei beliebte Schokoladenmarken gibt, ist jede Woche nur eine davon zu einem vernünftigen Preis zu haben“ interessiert mich
In AU tauchen viele solcher Scraper auf und verschwinden wieder, aber meist blocken die großen Supermarktketten sie. Es ist ein wiederkehrender Kreislauf aus Nützlichkeit und „Warum gibt es das nicht?“, obwohl es das tatsächlich schon mehrfach gab
Es hat weniger als 20 Stunden gedauert, den Crawler und die zugrunde liegende Infrastruktur zu bauen
Außerdem ist es noch nützlicher, weil es nur einen einzigen Marktplatz gibt, der die Preise mehrerer Läden zusammenführt
Guter Artikel. Auf meiner Preisvergleichsseite für Kontaktlinsen https://lenspricer.com/ hatte ich ähnliche Probleme, und sie läuft in etwa 30 Ländern. Ich kann sehr gut nachvollziehen, dass Websites, die ihr HTML ändern, ein echter Albtraum sind
Eine der größten Hürden am Anfang war es, dasselbe Produkt abzugleichen über mehr als 100 Websites hinweg. Man würde denken, Produktnamen seien eindeutig, aber alle schreiben sie auf ihre eigene leicht abgewandelte Weise. Das meiste lässt sich mit regulären Ausdrücken lösen, ein erheblicher Teil musste aber manuell gemappt werden, und für manches habe ich AI genutzt, allerdings alles selbst verifiziert
Die Scraper und die Infrastruktur zu bauen, ist vergleichsweise einfach. Schwer ist es, alle Scraper zu warten und herauszufinden, ob ein Produkt, das von einer Website verschwunden ist, an einem Scraper-Fehler, einer Sperre, einer Website-Änderung oder daran liegt, dass die Seite zum Crawl-Zeitpunkt gerade gewartet wurde
Ein spannendes Projekt, aber manchmal schwierig und voller nerviger Probleme, die man beheben muss
Die Preise sind völlig uneinheitlich, und die Erstattung läuft meist so, dass ungefähr 30 % per Post zurückgezahlt werden
Es scheint auch nur sehr wenige Shops zu geben, vielleicht sind also alle Links Affiliate-Links. Auf idealo.de finde ich auch niedrigere Preise
Costco ist dafür ziemlich bekannt; fast alle Elektronikartikel im Laden und viele andere Produkte haben dort angepasste SKUs. Oft ist sogar die Produktkonfiguration leicht anders
Ich habe in meiner Stadt eine ähnliche Website gebaut, die ziemlich viel Aufmerksamkeit bekommen hat. Ich scrape sogar Daten aus der App und von der Website und nutze dafür einen einzelnen Linode-Server mit 2 GB RAM, dazu 5 IPv4-Adressen und 1000 kostenlose IPv6-Adressen
Alle Produkte werden in Abständen von maximal 40 Minuten erfasst, im Schnitt etwa alle 25 Minuten. Ich nutze curl-impersonate und scrape nach Möglichkeit JSON. Bei 90 % des Markts kommen die Preise über Ajax-Aufrufe, und die übrigen 10 % lassen sich mit regulären Ausdrücken leicht aus HTML parsen
Ansehen kann man es unter https://www.economizafloripa.com.br
https://www.economizafloripa.com.br/?q=parceria-comercial
Nachdem ich diese Seite gesehen habe, wirkt das Projekt für mich eher wie „noch ein Versuch, Geld zu machen“ statt wie „ein nützliches Werkzeug für Menschen, die die Kontrolle von Unternehmen zurückholen wollen, die lebensnotwendige Güter verkaufen“. Natürlich ist das eure Sache, aber nach dem Lesen der Startseite hätte ich mit einer ethischeren Motivation gerechnet
Guter Beitrag
Ich denke, es ist am besten, Scraping und Parsing in getrennte Prozesse aufzuteilen. Wenn man das ursprüngliche JSON oder HTML speichert, kann man jederzeit zurückgehen, den Parser korrigieren und ihn erneut anwenden.
Ich habe als Teil meines Masterprojekts ein ähnliches System und eine Website für die Niederlande gebaut: https://www.superprijsvergelijker.nl/
Der Großteil des Scrapings in meinem Projekt besteht daraus, einfache HTTP-Aufrufe an JSON-APIs zu senden. Einige Websites verwenden Playwright-Instanzen, um gültige Session-Cookies zu erhalten und Bot-Schutz sowie CAPTCHAs zu umgehen. Die übrigen Crawler/Scraper, Parser und APIs sind in Haskell gebaut und laufen auf AWS ECS. Die Website ist in NextJS.
Die wichtigste Aufgabe, an der ich weiter arbeite, ist es, Produkte verschiedener Supermärkte zuzuordnen und die Preise auf einem Bildschirm aufzulisten. Ein Beispiel gibt es hier: https://www.superprijsvergelijker.nl/supermarkt-aanbieding/6...
Wenn für ein Produkt auch nur eine korrekte Barcode-Nummer angegeben ist, funktioniert es meistens gut.
Ich denke, die zwei großen Supermarktketten in Australien könnten schon allein dadurch eine duopolartige, wettbewerbsfeindliche Preisstruktur schaffen, dass beide lediglich KI-Algorithmen zur Preisanalyse betreiben. Solche Algorithmen werden am Ende wahrscheinlich in Richtung Kooperation tendieren, um den Gewinn zu maximieren.
Das lässt sich legal allein mit öffentlich verfügbaren Preisen machen, und illegal wäre es möglich, wenn man Einkaufskosten oder produktbezogene Margendaten teilt. Das Ergebnis wäre wohl ähnlich.
Zwei trainierte KIs würden auf multidimensionale, vielleicht sogar hochdimensionale Weise per Regressionsanalyse eine seltsame Form der Gewinnmaximierung betreiben, und die Verbraucher würden dann für den maximierten Gewinn von Unternehmen zahlen, die nach außen wie Konkurrenten wirken. Wenn man an solche Preisdaten kommt, braucht es nicht viel, um zwei auf ein Duopol fokussierte Machine-Learning-Implementierungen laufen zu lassen.
Die Argumentation ist, dass Verbraucher am Ende sogar höhere Preise zahlen, wenn alle Preise öffentlich sind. Dann würden Supermärkte ihre Preise auf den Punkt angleichen, an dem alle den maximalen Gewinn erzielen.
Supermärkte hier beschäftigen seit Jahren „Preisjäger“, also Leute, die in konkurrierende Läden gehen und die Preise aller Waren notieren.
In Norwegen sieht man oft, dass Supermarkt A in einer Woche einen bestimmten Artikel rabattiert und Supermarkt B in der nächsten oder übernächsten Woche mit einer ähnlichen Aktion Kunden anlockt.
Es klingt so, als könnte man automatische Prüfungen hinzufügen, um solche Änderungen zu erkennen. Wenn zum Beispiel eine Plausibilitätsprüfung fehlschlägt, synchronisiert man Preis-/Produktänderungen nicht.
Man könnte Kriterien setzen wie: Kein Preis darf sich um mehr als 100 % ändern, und die Zahl aktiver Produkte darf sich nicht um mehr als 20 % verändern.
Stattdessen habe ich solche Heuristiken verwendet, um zu prüfen, ob das Scraping erfolgreich war. Zum Beispiel, ob die Zahl der heute gescrapten Produkte ungefähr innerhalb von 10 % des Durchschnitts der letzten 7 Tage liegt.
Schwierig ist nicht das Scraping selbst, sondern das Umgehen immer ausgefeilterer Blockademechanismen.
Man muss ständig Residential Proxies rotieren, hochwertige verwenden und vermeiden, erkennbare Datenscraping-Muster zu zeigen. Manche Supermärkte zeigen im Network-Tab keine Netzwerk-Anfragen, sodass es nicht reicht, einfach nur API-Antworten mitzunehmen.
Selbst wenn man versucht, bei der mobilen App einen Man-in-the-Middle-Angriff einzusetzen, um Netzwerk-Anfragen und Daten zu sehen, wird man blockiert, wenn man sich nicht richtig tarnt.
Ich habe es ausprobiert, aber wegen der Kosten und der laufenden Entwicklungsarbeit entschieden, dass es sich nicht lohnt. Tatsächlich lassen einige Supermarkt-Preisvergleichsdienste einfach Niedriglohnkräfte scrapen.
Das ist ein Side Project, also würde ich es einfach einstellen und den gesamten Code und alle Daten veröffentlichen, wenn es zu viel Zeit frisst.
Ich frage mich aber, wie es möglich ist, dass Netzwerk-Anfragen nicht im Network-Tab auftauchen.
Für mich ist der schwierigste Teil, Produkte zwischen den Supermärkten zuzuordnen und zu vergleichen.
Es wäre gut, Preistransparenz für Produkte zu haben. Damit ließe sich das viel leichter nach Filiale und Region verfolgen.
Man könnte zum Beispiel den Preis von Hafermilch als Milchalternative nach Postleitzahl und Lebensmittelgeschäft vergleichen. Auch „Shrinkflation“, also gleichbleibende Preise bei sinkender Menge, ließe sich so verfolgen.
In diesem Sinne scheint ihr Preise zu verfolgen, aber ich frage mich, ob ihr auch die Kosten pro Gramm oder Unze erfasst. Hersteller oder Läden können den Preis gleich lassen und den Verbrauchern weniger Menge geben, daher frage ich mich, ob das Tool so etwas erkennen könnte.
Es ist aber eine Funktion, die sich problemlos ergänzen ließe, und wenn es Shrinkflation gegeben hat, könnte man zeigen, wann sie eingetreten ist.
Auf dem schwedischen Markt wird das schon seit mehr als 8 Jahren gemacht. Es gibt die Website https://www.matspar.se/, auf der Kundinnen und Kunden alle Produkte der großen Online-Händler durchsuchen, Preise vergleichen und die gewünschten Artikel in den Warenkorb legen können
Am Ende können sie den Gesamtpreis des Warenkorbs inklusive Versandkosten vergleichen und den Warenkorb dann an den gewünschten Händler übertragen, um die Bestellung abzuschließen
Ich bin Mitgründer und derzeitiger CTO und habe in dieser Zeit viel Scraping und Wartung gemacht. Wir scrapen täglich mehr als 30 Millionen Preise
Laut öffentlich zugänglichen Daten liegt der Umsatz des Unternehmens bei rund 400.000 US-Dollar bei 6 Mitarbeitenden: https://www.allabolag.se/5590076351/matspar-i-sverige-ab
Als ich in eine neue Gegend gezogen bin, habe ich Preise verfolgt, aber inzwischen finde ich es viel einfacher, immer bei Discountern oder zwei großen Läden einzukaufen, die dauerhaft niedrige Preise haben
In Europa wären das wahrscheinlich Aldi/Lidl
In den USA könnte es Costco/Trader Joe's sein
Online gibt es CamelCamelCamel/Amazon. Das betrifft keine Lebensmittel, sondern eher Gesundheit/Beauty/einige Elektronikprodukte
Wenn man direkt beim Hersteller kaufen kann, ist das manchmal sogar besser. Ich habe zum Beispiel eine bestimmte Seifenmarke, die ich mag, über eine Großhandelsseite in großen Mengen gekauft und weniger als die Hälfte des Einzelhandelspreises bezahlt. Shampoo war direkt in Gallonen ebenfalls deutlich günstiger als bei jedem Händler
Trader Joe's hat eine höhere Qualität, ist aber im Allgemeinen teurer