Die Onsite Search zählt zu den wichtigsten Funktionen für die Benutzerführung auf E-Commerce-Plattformen. Wir sprechen hierbei von einer Produktsuche im Shop und gefundenen Produkten beziehungsweise Artikeln. Von der grundsätzlichen Funktionsweise gibt es jedoch viele Gemeinsamkeiten zwischen einer Suchlösung für Dokumente und einer Suchlösung für Produkte. Viele Produktsuchen bauen auf Technologien wie Solr/Lucene auf, die ursprünglich nicht für Ecommerce-Anwendungen entwickelt wurden, sondern generell zum Durchsuchen großer Datenmengen gedacht sind. Da Shops mittlerweile oft über einen umfangreichen Content-Bereich verfügen, der von der Suche mitberücksichtigt werden sollte, überschneiden sich die Anforderungen zunehmend.
Mit unserer Blogserie Grundwissen Ecommerce Onsite Search möchten wir helfen, Grundwissen im Bereich interne Suche mit dem Schwerpunkt Produktsuche aufzubauen. Die Serie besteht vorerst aus drei Teilen. Heute starten wir in Teil eins mit Erklärungen zur grundsätzlichen Funktionsweise einer Produktsuche. Dabei klären wir die folgenden Fragen:
- Was ist der Suchindex?
- Was ist die Query?
- Wie wird eine Suchanfrage verarbeitet?
Teil zwei unserer Suche-Grundwissen-Serie beschäftigt sich mit Synonymen. In Teil drei geht es dann um das Suchergebnisranking, um Kampagnen und die After Search Navigation mit Filtern.
Funktionsweise Ecommerce Onsite Search
Für die Funktionsweise einer Produktsuche gilt grundsätzlich: Es gibt eine Suchanfrage (Query), die mit dem Suchindex (Index) abgeglichen wird. Die Suchlösung gibt dann eine Liste der gefundenen Produkte für die Query zurück. Das Ranking, also in welcher Reihenfolge die Artikel zurückgegeben werden, wird dabei ebenfalls von der Suche an den Shop zurückgespielt. Außerdem übergibt die Suche die relevanten Filter (Faceted Search) für das Suchergebnis. Der Kunde kann über diese das Suchergebnis weiter einschränken. Proprietäre Suchlösungen bieten zahlreiche Konfigurationsoptionen zum Thema Filter, aber auch Open Source Suchlösungen wie Solr bieten umfangreiche Möglichkeiten bei der Facettierung.
Der Suchindex
Jede Suchlösung generiert sich einen Suchindex aus den vorliegenden Produktdaten. Der Index beschleunigt die Suche, da nicht die komplette Datenstruktur nach einer Information durchsucht werden muss. Vielmehr enthält der Index einzelne Begriffe und Verweise auf dazu passende Produkte.
Die Produktdaten müssen der Suche meist in einem bestimmten Format (in der Regel eine CSV) übergeben werden. Das kann zum Beispiel über einen FTP-Server laufen. Je nach Suchlösung gibt es Grundvoraussetzungen an die zu übergebenden Daten: beispielsweise wie die Datenfelder benannt sein müssen, welches Trennzeichen verwendet wird oder in welchen Format Zahlen übergeben werden (10,99 vs. 10.99).
Die Suche generiert sich aus den Produktdaten regelmäßig einen Index, der bei einer Suchanfrage durchsucht wird. Sobald es eine Änderung an den Produktdaten des Shops gibt, muss auch der Index neu gebaut werden, da sonst die Suchergebnisse nicht mit dem Sortiment übereinstimmen. Die meisten Suchlösungen bieten auch inkrementelle Updates des Suchindex an, um Zeit bei der Reindexierung zu sparen. Das bedeutet, dass der Index nur dort geändert wird, wo Abweichungen bei den Produktdaten vorliegen (zusätzliche, bearbeitete oder gelöschte Informationen).
Query
Die Query ist die Suchanfrage, die an den Suchserver geschickt wird. Im Prinzip entspricht die Suchanfrage dem, was der Kunde in das Suchfeld eingegeben hat. Tatsächlich werden aber wesentlich mehr Queries ausgeführt. Setzt der Kunde beispielsweise auf der Suchergebnisseite einen Filter, löst das in der Regel eine neue Query aus, ohne dass der Kunde seine Formulierung im Suchfeld geändert hat.
Viele Shops nutzen die Suche auch zur Abbildung ihrer Navigation. Die Produktlisten werden dann über Queries an den Suchserver zusammengestellt. Ein Beispiel: Anstatt auf der Kategorieseite „Neue Damenhosen“ alle Produkte händisch per Artikelnummer und manuell nach Neuheit sortiert zuzuordnen, definiert man eine Query, die alle passenden Artikel anzeigt. In diesem Beispiel wären es alle Artikel aus der Kategorie „Hosen“ mit der Geschlechtsangabe „Damen“ sortiert nach „Neuheit“.
Query Time vs. Index Time
Das Konzept von Query und Index führt dazu, dass man zwischen Query Time und Index Time unterscheiden muss. Query Time bezeichnet den Zeitpunkt, an dem der Suchbegriff abgeschickt wird. Index Time ist der Zeitpunkt, zu dem der Suchindex erstellt wurde.
Es macht zum Beispiel einen großen Unterschied, ob eine Suchlösung die Synonyme zur Query Time oder zur Index Time berücksichtigt. Synonyme zur Query Time bedeutet, dass die Synonyme direkt nach Abschicken der Suchanfrage greifen. Das heißt, ein konfiguriertes Synonym führt dazu, dass mehrere Suchen ausgeführt werden. Gibt es beispielsweise ein Synoym „Laptop = Notebook“ und der Kunde gibt „Notebook“ in das Suchfeld ein, werden tatsächlich zwei Queries ausgeführt, nämlich „Notebook“ und „Laptop“. Das Suchergebnis beinhaltet dann alle Notebooks und Laptops. Fredhopper und FACT-Finder arbeiten beispielsweise mit Synonymen zur Query Time.
Synonyme zur Index Time bedeutet, die Synonyme werden nur in den Index geschrieben. Das heißt vereinfacht ausgedrückt, alle Notebooks werden im Index auch als „Laptop“ hinterlegt und alle Laptops auch als „Notebook“. Wenn der Kunde dann „Notebook“ sucht, findet er über die Synonyme im Index auch die Laptops. Der Nachteil liegt hier darin, dass nach jedem angelegten Synonym der Index neu aufgebaut werden muss.
Hier zwei Abbildungen, die den Unterschied zwischen Synonymen zu Query Time und zur Index Time verdeutlichen:
Analyzer und Tokenizer
Um die Vielfalt der unterschiedlichen Suchanfragen korrekt beantworten zu können, gibt es einige gängige Verfahren um die Suchanfragen zu verarbeiten:
Analyzer verarbeiten die Suchanfrage (Query Time) und die Produktdaten (Index Time). Ein Analyzer besteht wiederum aus beliebig konfigurierbaren Tokenizern und Filtern. Tokenizer dienen dazu, aus der kompletten Suchphrase (Query) verschiedene Suchbegriffe (Tokens) zu machen. Also beispielsweise aus „Hose Blau“ → „Hose“ und „Blau“. Bei einer Produktsuche möchte man nicht nach der genauen Zeichenkette „Hose Blau“ suchen, sondern nach jedem Artikel, der in der Kategorie „Hosen“ verortet ist und als Farbe „Blau“ hinterlegt hat.
Tokenizer können auch an bestimmten Zeichen trennen wie etwa „damen-hose“ in „damen“ „hose“. Filter wiederum ersetzen, löschen oder verändern einzelne Tokens oder Zeichen. So werden Umlaute ersetzt, Sonderzeichen gelöscht oder ganze Stopwords entfernt.
Stopwords
Begriffe, die für die Suche nicht relevant sind oder nicht relevant sein sollen, werden in einer Liste als Stopwords definiert. Typische Stopwords sind „mit“ oder „für“. Bei Suchanfragen wie „Hose für Herren“ oder „Bluse mit Kragen“ werden die Stopwords gestrichen, um möglichst alle Artikel zu finden. Verzichtet man auf Stopwords, würde die Suche folglich nur die Produkte finden, die tatsächlich irgendwo in den durchsuchten Produktdaten wie der Produktbeschreibung oder im Produktnamen die Begriffe „für“ oder „mit“ aufweisen können. Viele relevante Artikel würden so nicht gefunden. Eine Ausnahme sind semantische Suchen wie SEMKNOX oder Celebros. Sie streichen diese Begriffe nicht einfach sondern erkennen die Bedeutung von „mit“ und „für“ und nutzen diese Information bei der Beantwortung der Suchanfrage.
Stemming
Stemming ist ein Mechanismus, der Begriffe auf ihren Wortstamm reduziert. Dadurch sollen Singular, Plural und Deklination des Suchbegriffes bei der Suche ignoriert werden. Das heißt, die Suchanfragen „blauer hose“, „blaue hosen“ und „hose blau“ sollen dieselben Artikel zurückgeben.
Durch das Stemming werden die drei Suchanfragen wie folgt verarbeitet: „blauer hose“ → „blau hos“, „blaue hosen“ → „blau hos“ und „hose blau“ → „hos blau“. Die Onsite Search sucht folglich nach „hos“ und „blau“ und findet dadurch alle relevanten Artikel im Index.
Voraussetzung ist, dass das Stemming auch zur Index Time angewandt wird. Denn sonst würde die Query „hos blau“ lauten, die passenden Artikel wären jedoch ungestemmt als „hose blau“ im Index. Dann würde die Suche sie nicht finden. Hier einige Beispiele für Stemming:
- „rot“, „rotes“, „roter“, „rote“ → „rot“
- „schuh“, „schuhe“ → „schuh“
- „töpfe“, „topf“ → „topf“
Das Stemming kann mitunter zu unpräzisen Suchergebnissen führen. Hier einige Beispiele für ungünstiges Stemming:
- „küche“, „kuchen“ → „kuch“
- „hacke“, „hack“ → „hack“
- „buche“, „bücher“ → „buch“
- „mixer“ → „mix“
Das Suchergebnis von „Buche“ würde dann alle Bücher im Shop enthalten oder die Suche nach „Kuchen“ würde auch „Küchen“ ausspielen. Aus diesem Grund bieten einige Suchlösungen an, Stemmingausnahmen anzulegen. „kuchen“, „hacke“ und „buche“ sollen beispielsweise nicht gestemmt werden.
Auch beim Stemmen von Datenfeldern ist Vorsicht geboten. Markenangaben wie „Adidas“, „Nike“, „Apple“ etc. sollten nicht gestemmt werden, da sonst zu viele irrelevante Produkte in den Suchergebnissen erscheinen.
Kompositazerlegung (Decompounding)
Die Kompositazerlegung ist vor allem in der deutschen Sprache relevant. So wird „damenhose“ in „damen hose“ aufgesplittet. Die Zerlegung basiert bei allen uns bekannten Suchlösungen auf einem Wörterbuch, das die geläufigsten deutschen Wörter enthält. Die Funktionsweise unterscheidet sich jedoch je nach Suchlösung.
Unscharfe Suche (Fuzzy Matching)
Über die unscharfe Suche beziehungsweise Fuzzy Matching sollen auch Treffer generiert werden, wenn die Suchanfrage nicht exakt mit den Begriffen in den Daten übereinstimmt. So fängt man unterschiedliche Schreibweisen, Falschschreibweisen und Vertipper ab.
Für das Fuzzy Matching kommt häufig die Levenshtein-Distanz zum Einsatz. Sie bestimmt die Ähnlichkeit von Begriffen über die Anzahl der Operationen, die man benötigt, um von Begriff A zu Begriff B zu kommen (durch Zeichen vertauschen oder entfernen). Definiert man beispielsweise eine maximale Levenshtein-Distanz von zwei, bekommt man für den Suchbegriff „hosse“ alle Produkte aus dem Index, die „hose“ oder „hosen“ enthalten. Fuzzy Matching über die Levenshtein-Distanz hat den Nachteil, dass auch falsche Treffer wie etwa „husse“ (Sofaüberzug) gefunden werden können.
In den meisten Fällen wird Fuzzy Matching für die Autokorrektur genutzt. Bei Vertippern und Falschschreibweisen werden dann Suchergebnisse für die richtige Schreibweise ausgegeben. Dabei ist es wichtig, die Veränderung der Suchanfrage dem Nutzer auf der Suchergebnisseite mitzuteilen. Bei semantischen Suchen (siehe unten) wird Fuzzy Matching nicht direkt auf die Begriffe in den Produktdaten, sondern auf die durchsuchte Ontologie angewandt.
Eine Alternative zur Levenshtein-Distanz bietet die phonetische Suche. Anstatt mit der Distanz der Zeichen zu arbeiten, berücksichtigt sie die Aussprache. So können über einen Suchbegriff wie „blliseh“ auch die passenden Plissee-Produkte („plissee“ in den Artikeldaten) gefunden werden. Die Levenshtein-Distanz wäre in diesem Fall recht hoch, „blliseh“ und „plissee“ hätten eine Distanz von vier. Für eine phonetische Suche sind sie aufgrund der Aussprache jedoch ähnlicher zueinander und die Suche findet die passenden Produkte.
Neben der Phonetik kann auch die Anordnung der Buchstaben auf der Tastatur eine Rolle spielen, um die Ähnlichkeit zu bestimmen. So sind auf der Tastatur nebeneinanderliegende Buchstaben sich ähnlicher, da hier ein Vertipper wahrscheinlicher ist. Wie bei der Levenshtein-Distanz kann es bei beiden Alternativmethoden zu unerwünschten Treffern kommen, da die Suche keine Bedeutungen kennt (eine Ausnahme stellen hier die semantischen Suchen dar), sondern lediglich die Begriffe nach vorgegebenen Kriterien vergleicht.
Autokorrektur
Die Autokorrektur ist eine besondere Art der unscharfen Suche. Bei einem Nulltreffer sucht die Produktsuche nach Begriffen in den Daten, die der Suchanfrage ähnlich sind und spielt die dazugehörigen Produkte aus.
Sucht ein Kunde beispielsweise nach Jacken, vertippt sich im Suchfeld und sendet dadurch die Query „Jakcen“ ab, würde dies einen Nulltreffer ergeben, da kein Artikel diesen Begriff enthält. Die Autokorrektur erkennt aber die Ähnlichkeit zu „Jacken“ und spielt das Suchergebnis für „Jacken“ aus. Sie kommuniziert dem Nutzer die Veränderung der Suchanfrage mit einem Satz wie „Die Suche nach ‚Jakce‘ hat keine Treffer ergeben, wir haben aber Treffer für ‚Jacke‘ gefunden“.
Die Kommunikation über die Veränderung der Suchanfrage ist für den Kunden entscheidend, da die Autokorrektur auch unsinnige Korrekturen durchführt. Dem User muss transparent gemacht werden, wie das Suchergebnis zustande kommt, um den Eindruck einer schlechten Suchfunktion zu vermeiden.
Semantische Suche
Eine semantische Produktsuche unterscheidet sich von einer klassischen Freitextsuche durch den Einsatz einer Ontologie. Das heißt, der Suche steht von Beginn an ein Netzwerk von Begriffen und deren Beziehungen zueinander zur Verfügung. Diese Produktontologie ist Grundlage, um semantische Suchanfragen beantworten zu können. Eine Produktontologie ist vergleichbar mit Informationsnetzwerken wie dem Google Knowledge Graph – nur deutlich kleiner und auf Produktdaten spezialisiert. Die Suche kennt also Bedeutungen einzelner Begriffe und nicht nur eine reine Kette vom Buchstaben.
In unserem nächsten Beitrag werden wir detailliert auf die Konfiguration von Synonymen eingehen.
