Skiscraper: Transparenz für dynamische Preise
Dynamisch problematisch
Auf den Preis der Kartoffel kann man sich verlassen. Ernte und Nachfrage lassen ihn hoch und runter blubbern wie Fonduekäse im Caquelon. Die unsichtbare Hand des Marktes bestimmt den Preis. Eine alte Leier. Nur unsichtbar ist die Hand des Marktes lange nicht mehr. Dynamischer Preis heißt das Werkzeug, mit dem direkt an den Variablen gedreht wird. Nicht um auf den Markt zu reagieren, sondern um ihn aktiv zu gestalten. Ein Schelm, wer da an Marktmanipulation denkt. Ein Schelm auch, wer an der Legitimität diese Werkzeugs zweifelt.
Den Kartoffelmarkt zu steuern, ist nicht ausgeschlossen, aber ambitioniert. Andere Märkte machen die Praxis offensichtlicher. Ziel dieses Projektes war es, durch die Schweizer Alpen für einmal mehr Transparenz in die Praxis der dynamischen Preisgestaltung zu bringen. Seit einigen Jahren ist für den Einheimischen und den Skitouristen klar: Auf den Preis für die Tageskarte eines Schweizer Skigebiets kann man sich nicht verlassen.
«Das dynamische Preissystem ist eine Lotterie. Das einzige Ziel ist es, Mehrerträge zu erwirtschaften.»
Sara Stalder, Stiftung für Konsumentenschutz
Mehr zu dynamischen Preisen in der Berichterstattung des Auftraggebers und Schweizer Konsumentenmagazins Beobachter: -Beobachter - Mit dem Beobachter günstiger auf die Piste
Transparenz durch Technik
Dynamische Preise zu überprüfen ist aufwändig. Vor allem, wenn man einen manuellen Ansatz wählt. Darum iat der Beoabchter an uns herangetreten, mit dem Auftrag, die dynamischen Preise automatisch zu überwachen. Konkret solle eine Infrastruktur aufgebaut werden, die die Tagespreise auf den WebsShopsystemen der Skigebiete extrahiert (scraped), diese aufarbeitet, in einer Datenbank speichert und schließlich für den Leser des Konsumentenmagazins Beobachter online visualisiert.
Die Lösung sollte schnell umsetzbar, effizient und verlässlich sein. Gleichzeitig musste eine Server-Infrastruktur aufgebaut werden, da eine solche im Unternehmen noch nicht vorhanden war. Das technische Konzept wurde in mehreren Meetings definiert und wird im Folgenden grob aufgezeichnet:
- Individuelle Scripts für rund 20 Skigebiet Webseiten, die öffentlich die aktuellen und künftigen Preise zur Verfügung stellt
- Eine ETL-Pipeline, die die Preis-Extraktion mehrmals am Tag plant und exekutiert
- Datenbank zur Speicherung und Aggregation der Preise
- API zum Abruf der Preise für weitere Analysen und als Schnittstelle zum Frontend
- Frontend/Widget zur Darstellung der Tagespreise je Skigebiet innerhalb der Beobachter Plattform
Herausforderungen
Im Laufe der Arbeiten am Projekt Skiscraper waren mehrere Hürden zu meistern:
Scraping Grundsätze
Die oberste Priorität beim Abruf der Daten ist der Respekt gegenüber dem Anbieter von Informationen resp. der Preisdaten. Das Geschäftsmodell muss in jedem Fall respektiert werden. Das heisst:
- Der automatisierte Abruf der Daten darf die Funktionalität der Dienstleistung niemals beeinträchtigen. Kein Massenabruf von Daten, die den Server überlastet und den Zugriff für den Kunden einschränkt oder verhindert.
- Die Bestimmungen des Anbieters, sofern kommuniziert, sind zu befolgen.
- Der Abruf von Daten über geschützte Bereiche bsp. eines Shops ist zu vermeiden. Bei öffentlich zugänglichen Daten ist ein automatischer Abgriff der Daten legitim, sofern die Belastung der Server, die eines konventionellen Zugriffs, nicht übersteigt.
Scraping individueller Shopsysteme
Die Shopsysteme der Skigebiete sind technisch divers. Einige setzen auf proprietäre Shopsysteme, andere auf Inhouse Lösungen. Die Webpräsenz jedes einzelnen Skigebietes wurde entsprechend separat analysiert und umgesetzt.
Best Practice im Datenscraping orientiert sich am folgenden Threefold. API -> Webscraping -> Prerendering
1\ Abstraktion der API
Es gilt abzuklären, ob die Daten direkt an der Schnittstelle zwischen Backend und Frontend abgegriffen werden können. In den meisten Fällen ließen sich Preisdaten direkt an der Quelle abgreifen, da sich die Betreiber an gängige Praxis und Standars bei der Entwicklung ihrer API halten.
2\ Webscraping
Ist die Application Prgramming Schnittstelle (API) komplex und für den Anwender undurchsichtig kann die klassische Extraktion der Preisdaten über die HTML-Webseite zum Erfolg führen. Der anhaltende Trend hin zu sogenannten Single Page Applications, also dem massiven Einsatz von Javascript zur Darstellung von Inhalten, verhindert eine klassische Extraktion über HTML. Diese Technik ist für automatisiertes Scraping ungeeignet, da die Inhalte dynamisch beim Nutzer im Browser erzeugt werden.
3\ Prerendering und Headless Browser
Ist das Shopsystem der Skigebiete also sehr client-lastig und gleichzeitig die API undurchsichtig, muss die Extraktion über andere Wege erfolgen. In einigen Fällen war es möglich, die Webseite mit den Tagespreise vor der Extraktion zu rendern, also den Inhalt dem Programm so zu präsentieren wie sie dem Nutzer im Browser dargestellt werden. In einem Fall war es nötig den Browser für die automatisiertes Preisabfrage komplett zu emulieren. Diese Methode ist Ressourcen hungrig und langsam, bietet aber auch in komplexen Fällen trotzdem den Zugriff auf die Daten.
Scraping Schedule
Regelmäßige Abfrage von Daten von Shopsystemen und/oder Webportalen, ist nur sinnvoll möglich, wenn sie automatisch und zuverlässig geplant werden kann. Es existieren diverse proprietäre Lösungen auf dem Markt, die jedoch den Kunden bei der Extraktion von Daten an den jeweiligen Anbieter bindet. Beim Projekt “Skiscraper” wurde ausdrücklich gewünscht, dass Planung und Ausführung des Datascrapings/der Datenextraktion flexibel mit einem offenen Ansatz verfolgt wird.
Wir entwickelten entsprechend eine autonome und quelloffene Lösung zur Planung und Ausführung der Preisextraktion. Der eingeschlagene Weg basiert auf einer OpenSource-Lösung, ergänzt durch Eigenentwicklungen.
Monitoring
Wer aus Dutzenden Quellen mehrmals täglich akkurat Preisinformationen abgreift, braucht ein zuverlässiges und genaues Warnsystem. Ohne Monitoring bleiben Fehler beim Datenabgriff, aber auch bei der Weiterverarbeitung und Speicherung der Daten, unentdeckt. Webseiten werden ständig verbessert und angepasst, entsprechend müssen sich auch die Datenscraper anpassen. Das führt im täglichen Betrieb unweigerlich zu Fehlern. So sind fehlende Skipasspreise kurzfristig ärgerlich. Die Programme zum Abgriff der Daten können jedoch relativ zügig an die neuen Gegebenheiten der Shopsysteme angepasst werden. Fehlt jedoch ein Warnsystem, bleiben Fehler im Abgriff länger unentdeckt und führen mittelfristig zu Lücken im Datensatz. Dadurch verliert dieser an Glaubwürdigkeit soll er später bsp. für grössere Analysen Verwendung finden.
Ein solcher Fauxpas ist unverzeihlich in der Aggregation von Daten; vor allem im Umfeld einer transparenten Medienberichterstattung. Die Monitoring Lösung von Datenscrapern muss also frühstmöglich konzipiert und umgesetzt werden.
Innerhalb des Projekts Skiscraper wurde, während der Entwicklung der API, frühzeitig eine Schnittstelle geschaffen, die jegliche Fehler im Scrapimg abfängt und schnellstmöglich an die Verantwortlichen über spezifische Kanäle wie Slack und Telegram weiterleitet. Das ermöglicht eine zeitnahe Reaktion und folglich die schnelle Anpassung der Datenscraper oder Infrastruktur.
Server Infrastruktur
Flexibiltät war eine weitere Prämisse in der Umsetzung der Infrastruktur. Der komplette Exktraktionsprozess musste so aufgebaut werden, dass er künftig nahtlos im Unternehmen des Kunden integriert werden kann. In der ersten Phase des Auftrags ist der Betrieb der Pipeline auf unseren Servern gewährleistet. Künftig ist aber die Infrastruktur beim Kunden verortet und muss entsprechend einfach migriert werden können.
Als kleinster gemeinsamer Nenner wurde der Industriestandart in der weitverbreitenden Docker Virtualisierung gefunden. Alle Aspekte der Pipeline, von der Extraktion über die Datenbank, bis hin zum Webwidget für die Visualisierung der Daten wurde mit Docker integriert. So kann die Infrastruktur leicht in on premise Systemen wie bsp. Kubernetes integriert werden.
Einfache Visualisierung
Der Fokus des Auftrags lag auf der Extraktions-Pipeline für Skipass-Preise. Die Visualisierung sollte vor allem schnell umsetzbar, wartungsfrei, einfach über ein iFrame integrierbar und künftig erweiterbar sein. Wir haben uns vorerst für eine einfache HTML-Tabelle entschieden, die mithilfe des Hypertext Frameworks HTMX umgesetzt. Dies ermöglicht einen adäquaten Ausbau der Visualisierung und UI in künftigen Iterationen.
Fazit
Innerhalb 8 Wochen wurde eine Datenscraping-Plattform aufgebaut, und parallel zur Entwicjlung in Betrieb genommen, welche autonom rund 20 Shopsysteme nach aktuellen Skipass-Preisen untersucht, diese extrahiert, in einer Datenbank speichert und dem Leser des Konsumentenmagazins Beobachter sowie Journalist:innen zur weiteren Analyse zur Verfügung steht. Nach 16 Wochen laufendem Betrieb, hat sowohl die Extraktion der Preise, die Überwachung der Pipeline sowie der Zugriff der Daten jederzeit funktioniert.
Probleme
In zwei Fällen war eine Anpassung der Pipeline nötig:
- Aufgrund eines Denial-of-service Vorfalls mussten IP-Adresse gesperrt und die Performance der Infrastruktur um rund 30% erhöht werden
- Ein Fehler in einem hauseigenen SSL-Zertifikat konnte mit der Umstellung auf die gebräuchliche Let’s Encrypt Dienstleistung zeitnah gelöst werden
Zukunft
Dieses Projekt veranschaulicht, wie Datenscraping genutzt werden kann, um Transparenz und Veränderung in einer Branche zu fördern. Die Herausforderungen, die unterwegs auftraten, waren nicht nur Hindernisse, sondern auch Gelegenheiten, um Ansätze zu innovieren und zu verfeinern. Blickt man voraus, so setzt das Projekt einen Präzedenzfall für andere Branchen, die vor ähnlichen Herausforderungen stehen. Das Projekt zeigt anschaulich, dass automatisierte Datengewinnung nicht zu mehr Intransparenz für den Nutzer, sondern, ganz im Gegenteil, zur Aufklärung des Konsumenten genutzt werden kann.