1 Die Welt der Preisvergleichsportale 4
1.1 Der Onlinehandel von heute 4
1.2 Das Preisvergleichsportal idealo 4
1.3 Das Ziel des Bachelorprojektes 4
1.4 Die Microservice-Architektur des Scout-Softwaresystems
2 Die Extraktion Produktspezifischer Daten 6
2.1 Die technischen Anforderungen an den Parser 6
2.2 Die Positionsbestimmung der Produktattribute 6
2.3 Die Architektur des Parsers 7
2.4 Die Erstellung der Selektoren
3 Die Genauigkeitsmessung des Extraktionsalgorithmus 12
3.1 Die Testdaten der Evaluierung 12
3.2 Die Messergebnisse 12
3.3 Mögliche Fehlerquellen der Messungen
4 Der Ausblick und das Fazit
Das Literaturverzeichnis
Durch die Vielzahl von Onlineshops und Fülle an Angeboten verliert der Onlinekäufer schnell die Übersicht. Preisvergleichsplattformen wie idealo helfen dem Kunden das günstigste Angebot im Netz zu finden. Die Gewährleistung der möglichst vollständigen Markttransparenz ist eine grundlegende Herausforderung für idealo. Das von uns entwickelte Softwaresystem Scout, soll dabei helfen, den Produktkatalog von idealo auf Vollständigkeit zu überprüfen und fehlende Angebote aufzulisten. Ein wichtiger Prozessschritt ist dabei die Extrahierung von Produktinformationen, wie Produktname oder Preis, aus den einzelnen Webseiten. Die Schwierigkeit der Extraktion liegt darin, dass jeder Shop einen individuellen Aufbau besitzt und unterschiedlich strukturiert ist.
Das entwickelte Parser-Modul löst dieses Problem, indem es für jeden Shop eigene Regeln zur Extraktion der Produktinformationen verwendet. Dabei ist es nicht erforderlich, dass diese Regeln manuell erstellt werden müssen. Durch die Nutzung der bereits vorhandenen Angebote aus dem Bestand von idealo kann die Extrahierung der Struktur mittels maschinellen Lernens erfasst werden. Messungen, welche auf 50 verschiedenen Shops basieren, haben ergeben, dass die Produktinformationen mit einer Precision von über 95 Prozent bei einer Accuracy von etwa 50% extrahiert werden können.
Der Fernhandel ist bereits seit Urzeiten ein wichtiger Bestandteil der Gesellschaft. Durch die rasante Entwicklung des Internets und die steigende Anzahl der Onlinehändler vergrößert sich das Produktangebot. Heutzutage kann ein Käufer aus einer Vielzahl von Artikeln wählen und muss sich nicht, wie in der Urzeit, auf einen Händler oder auf die lokale Verfügbarkeit. beschränken.
In den letzten Jahren hat der Onlinehandel sowohl an Bedeutung für die Unternehmen, als auch für die Kunden gewonnen. Laut einer Statistik von Eurostat machte im Jahr 2017 der Onlinehandel 21% des Gesamtumsatzes deutscher Unternehmen aus und stellte somit einen nicht unerheblichen Anteil an der wirtschaftlichen Leistung dar[4]. Aus einer weiteren Untersuchung geht hervor, dass 2017 zwei Drittel der Deutschen regelmäßig online einkauften[3].
Diese Entwicklung bringt jedoch ein Problem mit sich: Mit der steigenden Auswahl an Produkten und vor allem Händlern verliert ein potenzieller Käufer schnell die Übersicht. Preisvergleichsportale versuchen deshalb die Markttransparenz wiederherzustellen. Ein Käufer sollte sich sicher sein können, das für ihn günstigste Angebot zu finden.
Das Angebot der Vergleichsportale wird von den Internetnutzern gut aufgenommen, wie eine Messung von 2017 zeigt: Für einen besseren Vergleich nutzen rund zwei Drittel der Online-Käufer die Möglichkeit, sich im Internet zum Produkt oder zum Preis zu informieren [1, 2]. In einem vom Nachrichtensender n-tv beauftragten Test1 hat das Deutsche Institut für Service-Qualität mehrere Preissuchmaschinen unter dem Aspekt des günstigsten Preises, der Aktualität des Preises und dem Nutzererlebnis verglichen. Im Ergebnis hat idealo.de in allen Kategorien den ersten Platz eingenommen, gefolgt von billiger.de und preis.de. Es wurde jedoch bemängelt, dass selbst beim besten Preisvergleich nur für die Hälfte der Produkte das günstigste Angebot angezeigt wurde.
Die Mission des Preisvergleichsportals idealo ist es, im Sinne der Kundenzufriedenheit den Vergleich stetig zu verbessern. Je mehr Angebote idealo vergleicht, desto sicherer kann sich der Kunde sein, tatsächlich das günstigste Angebot zu finden. Dazu schließt idealo Verträge mit mehreren Onlinehändlern ab. Diese Händler verpflichten sich, Daten zu ihren Angeboten an idealo zu übermitteln und zu aktualisieren. Für jeden vermittelten Kauf zahlen die Shops an idealo eine Provision. Diese Provision basiert auf CPC (Kosten pro Klick) oder CPO (Kosten pro tatsächlicher Bestellung).
Wie bereits in Kapitel 1.1 erwähnt, zeigt idealo bereits für 50%) der Produkte den günstigsten Preis. LTm auch zukünftig wettbewerbsfähig zu bleiben, arbeitet idealo daran, auch für die letzten 50%) der Produkte immer das beste Angebot liefern zu können. Dies erreicht idealo zum einen durch Vertragsabschlüsse mit weiteren Onlineshops und zum anderen durch die Sicherstellung, dass tatsächlich alle Angebote eines Vertragspartners gelistet werden.
Das Projektziel bestand darin, eine Software zu entwerfen, welche eine automatisierte Bestandsanalyse für gegebene Vertragspartner durchführt.. Mit. Hilfe des resultierenden
Berichtes soll es möglich sein, herauszufinden, welche Angebote des Onlinehändlers im Produktkatalog von idealo fehlen. Der Ergebnisbericht soll Informationen darüber enthalten, welche Produkte nicht vorhanden sind und zu welcher Preisregion die Produkte gehören. Durch diese Übersicht soll ein Mitarbeiter von idealo dazu befähigt werden, die Ursachen für das Fehlen der Angebote herauszufinden.
Mitarbeiter von idealo vermuten, dass ein unbeabsichtigtes Fehlen von Produkten möglicherweise durch einen fehlerhaften Importvorgang zu erklären sei. Zudem könnte es sein, dass ein Händler aufgrund spezieller Vertragsbedingungen bewusst nicht alle Produkte bei idealo führen möchte.
Für die Entwicklung dieser Softwarelösung hatten wir als fünfköpfiges Team neun Monate Zeit. Zudem wurde uns ein Betreuer von idealo zur Seite gestellt, welcher die funktionalen Anforderungen an die Software kommunizierte und als technischer Berater diente. Er begleitete uns während des gesamten Entwicklungsprozesses und unterstützte uns bei Fragen bezüglich der Systemarchitektur.
Wir haben uns dafür entschieden, das Gesamtsystem als Microservice-Architektur zu konzipieren. Die Microservice-Architektur ermöglicht es logisch gekapselte Komponenten zu entwickeln, welche sich sehr gut skalieren und erweitern lassen. Eine ausführlichere Begründung für diese Architekturentscheidung kann in der Bachelorarbeit von Dmitril Zhaman- akov nachgeschlagen werden [7]. Für die Implementierung der Architektur haben wir die Programmiersprache Java gewählt und verwenden diese in Kombination mit dem Spring- Framework2. Das entwickelte Gesamtsystem Scout, besteht aus drei zentralen Komponenten: dem Crawler, dem Parser und dem Matcher. In Abbildung 1 ist der Datenfluss zwischen den Komponenten dargestellt.
Der Crawler ist für das Herunterladen jeder einzelnen Seite eines durch den Nutzer spezifizierten Shops verantwortlich. Jonas Pohlmann hat sich im Projektverlauf intensiv mit verschiedenen Crawling-Frameworks auseinandergesetzt und diese in seiner Bachelorarbeit verglichen[5].
Die Funktionsweise der maschinenlernbasierten Matcher-Komponente wird in der Bachelorarbeit von Tom Schwarzburg näher beschrieben[6]. Der Matcher vergleicht die vom Parser gefundenen Angebote mit denen, die idealo bereits kennt und liefert einen Bericht, in dem alle fehlenden Angebote aufgelistet werden.
Damit, diese Komponente die geladenen Angebote mit dem Katalog von idealo vergleichen kann, muss das heruntergeladene HTML-Dokument. in ein Format gebracht werden, welches der Computer für den Vergleich nutzen kann. Diesen Schritt erledigt der Parser, welcher zwischen Crawler und Matcher agiert. Der Fokus dieser Bachelorarbeit liegt in der Beschreibung der Funktionsweise und des Aufbaus des Parsers.
Der Parser ist dafür verantwortlich die für den Vergleich relevanten Produktinformationen aus HTML-Dateien zu extrahieren und zu normalisieren. Dies sind wichtige Prozessschritte, da die Qualität der extrahierten Werte die Ergebnisse der Matcher-Komponente stark beeinflussen.
Die Herausforderung der Parser-Komponente besteht hauptsächlich darin, das heterogene Informationsschemata der verschiedenen Shops in ein homogenes, genormtes Schema zu bringen. Im Detail geht es darum, zu jedem Angebot den Titel, die Produktbeschreibung, den Preis, die Marke, die Kategorie, die Produktbilder sowie weitere eindeutige Merkmale im Format von idealo zu erfassen. Diese eindeutigen Merkmale sind zum Beispiel die standardisierte EAN (Europäische Artikelnummer), HAN (Händler Artikelnummer) und SKU (Stock keeping unit - eine Shop-spezifische Kennung).
Da die Crawler-Komponente viel Zeit benötigt um alle Seiten zu erfassen, spielt die Laufzeit des Parsers eine untergeordnete Rohe. Eine schnelle Verarbeitung der Seiten ist dennoch wünschenswert, um eine gute Skalier bar keit zu gewährleisten. Es gilt sowohl eine hohe Trefferzahl als auch eine hohe Genauigkeit zu erzielen, damit, die Ergebnisse des Parsers als zuverlässig eingestuft werden. Je genauer die Ergebnisse des Parsers im Format von idealo sind, desto einfacher sollte der Vergleich durch die Matcher-Komponente werden.
Die eigentliche Schwierigkeit der Datenextraktion hegt in der Bestimmung der Stehen, an denen die gewünschten Informationen vorhegen. Es gibt grundsätzlich zwei Möglichkeiten, wie man die Informationen aus den Angeboten extrahieren kann. Wir haben zwischen dem Shop-unspezifischen und den Shop-spezifischen Ansatz unterschieden.
Die Initiative Schema..org3 hat bereits 2011 einen Vorschlag zur Standardisierung von Produktwebseiten gemacht, welcher für eine shop-unspezifischen Lösung genutzt werden kann. Schema.org hat einen Standard entwickelt, den Webseitenbetreiber nutzen können, um bestimmte Daten zu markieren. Shop-Betreiber können zum Beispiel die Produktrezensionen, den Preis oder auch den Produktnamen hervorheben. Große Suchmaschinenanbieter wie Google, Microsoft oder Yandex können dadurch einfach relevante Informationen direkt in den Suchergebnissen anzeigen. Die Angebote der Onlinehändler werden somit einfacher gefunden. Laut einer Schätzung von idealo verwenden rund 40% der Shops diesen Standard. Diese Herangehensweise bezeichnen wir als Shop-unspezifischen Ansatz, da man generische Regeln verwenden kann, um die standardisierten Informationen zu erfassen. Eine Lösung zum Auslesen dieser Informationen ist recht einfach und schnell umsetzbar.
Alternativ zum Shop-unspezifischen Ansatz gibt es die shop-spezifische Herangehensweise, d.h. dass für jeden Onlineshop individuell angepasste Spezifikationen für die Extraktion ersteht werden. Die Regeln des Shop-spezifischen Ansatzes bilden eine Übermenge des Shop-unspezifischen Ansatzes. Die Umsetzung dieser Variante ist anspruchsvoller, da diese Spezifikationen zunächst ersteht werden müssten. Wir nehmen jedoch an, dass durch diesen Ansatz bessere Ergebnisse im Vergleich zu dem Shop-unspezifischen Ansatz gefunden werden.
Zu Beginn haben wir erste Versuche basierend auf dem Schema.org-Standard unternommen. Wir haben aber schnell feststellen müssen, dass die Schema.org-Parameter oft nicht richtig genutzt wurden. Das Nichteinhalten des Standards hatte zur Folge, dass die Qualität der extrahierten Daten nicht ausreichend war. Auch bei anderen Standards, welche bei der Strukturierung von Produktdaten im Internet helfen sollen, wie zum Beispiel JSON-LD4 (W3C) und das Open-Graph-Protokoll5 (Faeebook), konnten wir ähnliche Beobachtungen machen. Wir haben uns deshalb gegen den Shop-unspezifischen Ansatz entschieden.
Für die Umsetzung der Parser-Komponente haben wir zwei Annahmen getroffen, welche die Konzeption des Algorithmus beeinflusst haben. Wir nehmen an, dass jeder Shop aufgrund der Vielzahl von Angeboten ein Content Management System (CMS) zur Verwaltung seiner Angebote verwendet. Daraus resultierend gehen wir davon aus, dass sich durch die Verwendung eines CMS die Struktur der Angebote eines Shops ähnelt und diese Struktur erlernt werden kann. Außerdem erwarten wir, dass idealo aufgrund der Vertragsvereinbarungen für die zu untersuchenden Shops bereits eine gewisse Menge an Angeboten besitzt und die Produktattribute nicht manipuliert wurden.
Für die nachfolgenden Erklärungen werden die beiden Begriffe Regel und Selektor definiert. Eine Regel ist eine Sammlung von Selektoren für eine bestimme Produkteigenschaft. Jeder Selektor dieser Regel stellt eine Wegbeschreibung durch das HTML-Dokument. dar. Er führt zu dem gewünschten Element, aus dem das Produktattribut extrahiert werden soll. Der grobe Ablauf der Shop-spezifischen Datenextraktion kann in zwei Phasen untergliedert werden:
1. Die Generierung der Shop-spezifischen Extraktionsregeln/ Spezifikation
2. Die Anwendung der Regeln auf die vom Crawler erzeugten Seiten
In der ersten Phase werden die Regeln, welche für die Extraktion benötigt werden, mit Hilfe der Daten von idealo angelernt. Diese generierten Regeln werden in der zweiten Phase angewendet, sodass zu jeder Produkteigenschaft genau ein Wert zugeordnet wird. Für jede gecrawlte Seite werden die extrahierten Produktattribute abgespeichert. Die Logik der beiden Phasen spiegelt sich in der Architektur des Parsers wieder. Dieser Parser besteht aus dem Shop Rules Generator (SRG), der Parser-Komponente und dem URL-Cleaner. Die Parser-Komponente ist somit lediglich ein Bestandteil des Parsers. Um mögliche Verwirrungen zu vermeiden, wird im nachfolgenden genau zwischen diesen beiden Formulierungen “Parser” und “Parser-Komponente” unterschieden. Auf die Notwendigkeit des URL-Cleaners wird am Ende dieses Kapitels eingegangen. Die resultierende Architektur ist in Abbildung 2 dargestellt.
Die Parser-Komponente erhält ihre Eingaben, indem sie Nachrichten aus einer Queue konsumiert. Eine Nachricht enthält eine vom Crawler heruntergeladene Webseite. Der Crawler sendet zusätzlich zu jeder Seite, die Webadresse und die Identifikationsnummer des zugehörigen Shops mit. Nach dem Erhalt einer Nachricht, lädt, der Parser vom Shop Rules Generator (SRG) die Extraktionsregeln für den entsprechenden Shop. Sollten die Regeln noch nicht existieren, wartet der Parser solange, bis diese Regeln vom SRG erstellt wurden. Sobald der Parser die Regeln empfangen hat, werden die Produktattribute aus der gecrawlten Seite extrahiert. Zum Schluss werden die extrahierten Produktinformationen in einer Datenbank normalisiert abgespeichert. Der Matcher greift später auf diese Datenbank für den Vergleich zu.
Der Shop Rules Generator übermittelt auf Anfrage die Regeln für einen beliebigen Shop. Sollten diese Regeln noch nicht existieren, werden sie generiert. Während des Generierungsprozesses durchläuft der SRG mehrere Schritte. In Abbildung 3 ist der Datenfluss des Vorgangs abgebildet.
Abbildung 3: Datenfluss des Generierungsprozesses für einen Shop
Zuerst wird eine bestimmte Anzahl von Angeboten aus der idealo-Datenbank geladen. Die Anzahl der zu ladenden Angebote definieren wir als “Sample Size” und kürzen dieses mit SaS ab. Dieser Vorgang erfolgt über einen von idealo zur Verfügung gestellten API-Endpunkt, welcher den Datenbankzugriff über eine REST-Schnitt.stelle kapselt. Diese Vorgehensweise hat den Vorteil, dass wir die Infrastruktur von idealo nutzen können und keine Kopie der Angebotsdaten lokal speichern müssen. Zu jedem dieser Angebote liegen die Webadresse, sowie die Informationen über die in Kapitel 2.1 genannten Produktattribute vor. Außerdem wird für jedes Angebot das dazugehörige HTML-Dokument heruntergeladen. Um die Server der Onlineshops nicht durch zu viele simultane Anfragen zu strapazieren, wird nach jedem Download eine fest definierte Zeit gewartet. Für die Menge der heruntergeladenen HTML-Dokumente ist somit bekannt, um welche Angebote es sich handelt und welche konkreten Produktattribute erwartet werden.
Dieses Wissen wird für das Anlernen der Regeln genutzt. Dazu werden die Werte aller Produkteigenschaften in dem HTML-Dokument gesucht. Für jedes Vorkommnis eines Produktattributes wird ein Selektor erstellt, der den Fundort referenziert und einer Regel zugeordnet. Nachdem alle Regeln gesammelt wurden, werden diese bewertet. Alle Regeln, die einem bestimmtem Qualitätsmaß entsprechen, werden in einer finale Regelmenge zu-
[...]
1 https://disq.de/2014/20141004-Preissuchmaschinen.html
2 https ะ//spring.io/
3 https://schema.org/docs/about.html
4 https ะ//json-ld.org/
5 http ะ//www.ogp.me/
