Kategorien
Magazin

Interview mit René Kriegler von OpenSource Connections (OSC)

René Kriegler von OpenSource Connections

René Kriegler leitet den Bereich E-Commerce bei OpenSource Connections (OSC). Vorrangiges Ziel des Teams von OSC ist es, seine Kunden zu befähigen, ihre Suche zu verstehen und zu optimieren, so dass die Suche zu einem treibenden Faktor bei der Verbesserung der Online-Verkäufe wird. René arbeitet seit mittlerweile 15 Jahren im Bereich Suche, unter anderem für einige der deutschen Top-10 E-Commerce-Seiten. Er ist Mitgründer und -organisator der Veranstaltung MICES (Mix-Camp E-Commerce Search), auf der seit nunmehr fünf Jahren die E-Commerce-Search-Community zusammenkommt. Renés technologischer Schwerpunkt liegt auf Open-Source-Technologien wie Solr und Elasticsearch. Er ist Gründer und Maintainer der Querqy-Bibliothek und Mitinitiator des Chorus-Projekts, das verschiedene Open-Source-Tools zu einem abgestimmten Paket zur Implementierung einer E-Commerce-Suche vereint.

Hallo René! Wir möchten heute mit dir vor allem über das Open-Source-Projekt Querqy sprechen, aber auch über das neuere Projekt Chorus. Querqy gibt es ja schon eine Weile und wir glauben im Bereich Suche im E-Commerce sollte man Querqy unbedingt auf dem Zettel haben. Beschreibe uns doch einmal was Querqy ist und was es mit dem neuen Projekt Chorus auf sich hat.

Querqy ist eine Open-Source-Java-Bibliothek für Solr und Elasticsearch, um Suchabfragen umzuschreiben, also „auf gut Deutsch“ ein Query-Rewriting-Framework. Das klingt erstmal sehr technisch, aber gerade für den Bereich E-Commerce-Suche bekommt man über das Query-Rewriting ein mächtiges Werkzeug, seine Suche für einzelne Suchanfragen ganz gezielt zu optimieren.

Möchte ich zum Beispiel für eine bestimmte Suchabfrage Produkte einer bestimmten Marke ganz oben anzeigen oder – das andere Extrem – Produkte einer Marke für diese Abfrage ausblenden, kann ich das über Query-Rewriting lösen. Ein anderes häufiges Problem, für das Querqy eine Lösung bietet, ist das „Zubehör-Problem“: Ich suche nach „smartphone“ und bekomme lauter Ladekabel auf den ersten Positionen. Das möchte man zwar am liebsten algorithmisch lösen, also mit dem allgemeinen Ranking-Algorithmus der Suchmaschine, und nicht spezifisch, pro Suchabfrage, aber leider schaffen das auch die besten Algorithmen nicht für alle Suchanfragen. Wenn es sich dann noch um eine sehr wichtige, häufige Suchabfrage handelt, kommt man um solch eine spezifische Lösung nicht herum.

Mit Query-Rewriting kann man nicht nur das Ranking optimieren, sondern auch das „Matching“. Das kann zum Beispiel durch das Einfügen von Synonymen in die Suchabfrage erfolgen – also zum Beispiel „Finde auch ‘laptop’, wenn jemand nach ‘notebook’ sucht“.

Das Rewriting kann man mit Querqy aber noch sehr viel weitertreiben. Wenn zum Beispiel jemand nach „notebook 15 zoll“ sucht und man ein Feld für die Bildschirmdiagonale in cm hat, ließe sich diese Abfrage umschreiben zu: „Finde
notebook oder laptop mit Bildschirmdiagonale von ca. 34 bis 42 cm aber bringe solche mit Bildschirmdiagonale nahe 38 cm nach oben“

Diese Funktionalität wird mit Hilfe von sogenannten Rewritern implementiert – also quasi einem kleinen Bausatz von Komponenten, von denen jede die  Suchabfrage jeweils auf eine spezifische Weise umbaut. Davon bringt Querqy schon einige mit, man kann aber auch für seine spezifischen Bedürfnisse seine eigenen Rewriter implementieren.

Mit Chorus können sich Teams viel früher den Lösungen für ihre spezifischen Suche-Probleme zuwenden – hier entsteht dann auch erst der eigentliche Nutzen aus der Entscheidung, eine E-Commerce-Suche auf Basis von Open-Source-Software zu implementieren.

Mit Querqy bekommt man schon mal ein sehr mächtiges Werkzeug, um die Qualität einer Suchanwendung zu verbessern. Allerdings ist dieses Werkzeug noch nicht sehr handlich. Will man zum Beispiel neue Synonym-Regeln anlegen, müsste man immer noch auf das Entwicklungsteam zurückgreifen. An dieser Stelle kommt nun Chorus ins Spiel. Dabei handelt es sich um ein abgestimmtes Ensemble von Open-Source-Tools zur Implementierung einer E-Commerce-Suche. Startet man Chorus, bekommt man eine kleine Suchanwendung, welche mehrere Tools integriert: Als Suchmaschine wird Solr mit integriertem Querqy gestartet. Mit SMUI – dem Search Management User Interface – kann man sofort loslegen, und ‘Searchandizing’-Regeln für Querqy pflegen. Also zum Beispiel Regeln für das Ranking und Matching, wie ich sie beschrieben habe. Zudem stehen noch eine Reihe von Tools wie Quepid oder ‘Rated Ranking Evaluator’ parat, mit denen man Suchqualität bewerten und optimieren kann.

SMUI - Search Managament Interface
SMUI (Search Management User Interface) ist eine grafische Oberfläche zur Pflege eigener Querqy Regeln. Damit kann das Search Management Team ohne Entwickler-Skills selbstständig Regeln erstellen und deployen.

Für uns als Chorus-Initiatoren war es wichtig, den Sucheteams mit Chorus einen Weg aufzuzeigen, die Entwicklungszeit, die man in einem Open-Source-Projekt normalerweise aufwendet, um mit kommerziellen Lösungen erstmal gleich zu ziehen, erheblich zu verkürzen. Mit Chorus können sich Teams viel früher den Lösungen für ihre spezifischen Suche-Probleme zuwenden – hier entsteht dann auch erst der eigentliche Nutzen aus der Entscheidung, eine E-Commerce-Suche auf Basis von Open-
Source-Software zu implementieren.

Was war für dich ausschlaggebend, Querqy zu entwickeln? Wie kam das Ganze ins Rollen?

Das war „produktiver Ärger“! Und dabei ging es eigentlich um zwei Dinge: Ich war damals vor allem mit Solr unterwegs, und sobald es bei Synonymen um solche ging, die sich auf mehrere Wörter beziehen, gab es Probleme. Sowohl mit dem Auffinden von Treffern als auch mit dem Ranking. Das war 2014, und selbst heute sind trotz beträchtlicher Fortschritte solche Multi-Wort-Synonyme sowohl in Solr als auch in Elasticsearch nicht 100%ig gelöst. Querqy löst diese Probleme seit seiner ersten Version vor allem dadurch, dass es einen expliziten Ort für das Umschreiben von Suchabfragen einführt, wo sich viele Operationen viel leichter als in Solr oder Elasticsearch anwenden lassen.

Der zweite Grund Querqy zu entwickeln lag darin, dass in einem Migrationsprojekt von einer kommerziellen Suche-Lösung zu Solr lange Zeit offen war, wie wir die ‘Searchandizing’-Features der kommerziellen Suchmaschine in Solr abbilden können. Wahrscheinlich jede kommerzielle Suchmaschine bietet die Möglichkeit, solche
Regeln zu pflegen, also zum Beispiel zu sagen: Wenn die Suchabfrage ‘iPhone’ ist, bringe Apple-Produkte nach vorn. Warum sollten die Open-Source-Suchmaschinen das nicht können?

Heute nutzen einige der deutschen Top-10-E Commerce-Sites Querqy und es ist auch zunehmend international verbreitet. Wir sehen gut 4000 Downloads pro Monat.

Wir konnten damals dann einen Kunden für die Idee gewinnen, in die Entwicklung von Querqy als Open-Source-Bibliothek zu investieren, und so nahm die Sache ihren Lauf. Heute nutzen einige der deutschen Top-10-E-Commerce-Sites Querqy und es ist auch zunehmend international verbreitet. Wir sehen gut 4000 Downloads pro Monat.

Du weist auch immer wieder darauf hin, dass Querqy einem nicht nur ermöglicht, Suchergebnisse manuell oder durch die Rewriter zu verbessern, sondern im Kern schon Vorteile beim Relevanzscoring im Bereich E-Commerce mitbringt. Das heißt, auch ohne die Pflege vieler Regeln und ohne ausgefuchste Rewriter könnte Querqy alleine als Query Handler schon Vorteile bringen?

Ja, das ist in der Tat so, wobei die Größe des Effekts von der konkreten Anwendung abhängt.
Hintergrund ist, dass die Ranking-Modelle in Lucene – also der Suche-Bibliothek im Kern von Solr und Elasticsearch – eigentlich für das Auffinden von Textdokumenten gedacht sind. Dabei geht es vorwiegend um unstrukturierte, oft auch längere Texte, in denen viele verschiedene Themen repräsentiert sind. Für die E-Commerce-Suche brauchen wir jedoch ein Ranking-Modell für strukturierte Daten, mit verschiedenen Feldern, die kurze Texte oder oft nur Namen und Bezeichnungen enthalten und bei denen ein einzelner Datensatz für genau ein Produkt steht. Querqy verbessert zumindest den Umgang mit Feldern etwas, und das tut es auch ohne einen einzigen Rewriter.

 Fachlich würde ich immer zu Querqy raten, da es vor allem für den E-Commerce-Bereich wichtige Features bereitstellt, für die es meines Wissens aktuell im Open-Source-Bereich keine andere Lösung gibt.

Gibt es eigentlich irgendeinen Grund, Querqy in einem Solr oder Elasticsearch E-Commerce-Suche-Projekt nicht zu nutzen?

Da fällt mir in der Tat kaum ein Grund ein. Sollte eine Suche die Solr-Suchesyntax an die Endnutzer weitergegeben haben – also zum Beispiel die Möglichkeit Feldnamen einzugeben, oder Operatoren wie AND und OR in die Query einzubauen – könnte es
schwierig werden. Aber das wäre eigentlich im E-Commerce eher ungewöhnlich und wohl auch eine „Bad Practice“. Fachlich würde ich immer zu Querqy raten, da es vor allem für den E-Commerce-Bereich wichtige Features bereitstellt, für die es meines Wissens aktuell im Open-Source-Bereich keine andere Lösung gibt.

Wie hoch schätzt du den Integrationsaufwand von Querqy ein?

Der Aufwand hängt vom konkreten Projektkontext ab. Ist man ohnehin im Rahmen einer Migration beim Neuaufsetzen der Suchmaschine, ist der zusätzliche Aufwand eigentlich zu vernachlässigen – Querqy verwendet grundsätzlich Konzepte, die aus Solr oder Elasticsearch vertraut sind. Zudem kann Chorus noch als zusätzliche Blaupause verwendet werden. Größere Aufwände sehe ich gelegentlich bei bestehenden Elasticsearch-Anwendungen. Das Zusammenbauen von Suchanfragen mit Bordmitteln ist aus meiner Sicht in Elasticsearch für E-Commerce-Anwendungen nicht optimal lösbar.
In der Konsequenz bauen sich Teams oft umfangreiche Komponenten zum Erstellen der Suchabfragen außerhalb von Elasticsearch. Daraus ergibt sich dann natürlich ein gewisser Aufwand bei der Umstellung auf Querqy, was dann diese Funktion ersetzt.

Welche Pläne habt ihr konkret für die nächsten Versionen von Querqy?

Wir denken in Querqy eigentlich nicht so sehr in Versionen, sondern versuchen sehr schnell zu releasen, wenn ein Feature implementiert wurde. Zu einem gewissen Grade werden diese Features auch durch die Pull-Requests – also durch die Zuarbeiten aus der Community – bestimmt. Aus Maintainer-Sicht wollen wir vor allem versuchen, das Erstellen eigener Query-Rewriter einfacher zu machen, so dass jedes Entwicklungsteam unkompliziert Rewriter für seine spezifischen Anwendungsfälle implementieren kann. Zudem gibt es erste Experimente, das Query-Rewriting mit Querqy ganz oder teilweise außerhalb der Suchmaschine zu lösen. Das wäre zum Beispiel in Fällen interessant, in denen das Rewriting zusätzliche, sich häufig aktualisierende Datenquellen benötigt,
oder wenn auf komplexere maschinen-gelernte Modelle zugegriffen werden soll.

Wenn du dir einfach so ein neues Feature für Querqy wünschen könntest, was wäre das?

Manchmal wünsche ich mir, dass Querqy nicht nur ein Query-Rewriting-Framework wäre, sondern auch gleich noch ein Framework, um flexiblere Ranking-Modelle in Solr und Elasticsearch zu implementieren. Vor allem in Hinblick auf ein besseres Ranking im E-Commerce.

Danke René für das Interview, die Einblicke in Querqy und Chorus und auch die Zeit und Energie, die du in die E-Commerce Search Community und Open-Source-Projekte steckst. Ich finde, das hat den deutschsprachigen Bereich Suche im E-Commerce in den letzten Jahren deutlich vorangebracht.

Alle Infos zu Querqy, SMUI, Chorus sind auf https://querqy.org zu finden. Infos zur Teilnahme oder zu den Inhalten der letzten Jahre der MICES Konferenz zum Thema Suche im E-Commerce findet man unter https://mices.co.

Wer Teil der E-Commerce-Suche-Community werden möchte oder Fragen und Anregungen hat, dem empfehlen wir den E-Commerce Search Slack Channel https://ecom-search.slack.com.

Die Webseite von OpenSource Connections https://opensourceconnections.com hält interessante englischsprachige Inhalte und Infos zu den Tools Quepid und Splainer bereit. OpenSource Connections bietet auch Trainings für Solr und Elasticsearch sowie für Learning to Rank in beiden Suchlösungen an.

Kategorien
Magazin

Wie Sie die Schwachstellen Ihrer Onsite-Search erkennen

Sebastian Russ - Produktmanager Onsite-Search bei Tudock

Zur Person

Sebastian Russ ist Produktmanager bei Tudock und beschäftigt sich intensiv mit den Themen Suche und Navigation in Onlineshops. Er verfügt über fundierte Kenntnisse verschiedener Suchtechnologien und analysiert die Suchkonfiguration und die Produktdaten im Zusammenspiel mit dem Suchverhalten. Dabei berät er Händler und Hersteller immer mit dem Ziel, das Einkaufserlebnis für den Kunden zu verbessern und entsprechende KPIs zu bestimmen, die den Erfolg messbar machen.

Hallo Sebastian. Kunden kommen zu Euch, wenn sie ihre interne Shopsuche optimieren lassen wollen. Doch wie erkennt der Shopbesitzer überhaupt, dass seine Produktsuche eine Überarbeitung nötig hat. Wie findet er die Schwachstellen der internen Suche seines Online-Shops?

Oft genügt es schon, sich erstmal in die Lage des Kunden zu versetzen. Ich nehme jetzt mal an, dass jeder der im E-Commerce arbeitet, auch selbst gelegentlich online einkauft oder zumindest nach Produkten oder Informationen sucht. Für die Onsite-Search ganz wichtig sind die KPIs. Das geht dann aber schon einen Schritt weiter.

Ich möchte kurz nachhaken, Du sagtest gerade Onsite-Search. Damit meinst Du die interne Suchfunktion, richtig?

Ja, genau. Onsite-Search umfasst alles, was mit der Suche nach Produkten zu tun hat. Streng genommen das Suchfeld, den Suggest, also die Vorschlagsfunktion einer Suche, und die Suchergebnisseiten mit den Filteroptionen, die Sortierung der Darstellung der Produkte etc. In der Praxis geht es dann über das Thema Ranking und Filter hinaus auch um die Kategorieseiten.

Danke für die Erläuterung! Zurück zu den angesprochenen KPIs. Was versteht man darunter und welche Rolle spielen diese beim Thema Suche?

KPIs bzw. Key Perfomance Indicators sind Leistungskennzahlen. Diese machen sichtbar, ob ob Maßnahmen ihren Zweck erfüllen und in welchem Umfang vorgegebene Ziele erreicht werden. Bei der Suche sehen wir uns da zum Beispiel die Conversion Rate an. Weitere wichtige Kennzahlen sind aber auch die Null-Treffer- oder die Ausstiegsquote sowie der Wert eines Such-Visits. Wobei man als Shopbetreiber hier vor dem Problem steht, keine vergleichbaren Zahlen der Mitbewerber zu haben. Das heißt, es ist schwer, aus einer isolierten KPI eine Aussage zur Qualität der Suche zu machen. Am besten ist daher ein systematischer Benchmark mit Mitbewerbern. Da macht es dann Sinn, uns als Experten dazu zu holen, um den Status Quo aus einer breiteren Marktübersicht zu bewerten.

Tudock-Such-Interview-KPI

Klingt alles sehr aufwändig. Reicht Google als Suchfunktion nicht völlig aus?

Nein. Google oder andere Suchmaschinen sind zwar die erste Anlaufstelle für den Kunden und führen ihn in den Online-Shop. Dann kommt jedoch die interne Suche ins Spiel.

Inwiefern?

Der Kunde beginnt jetzt, das Angebot zu entdecken, vielleicht auch gezielt nach anderen Produkten zu suchen, die ihm gerade spontan einfallen. Oder er hat Fragen zum Serviceangebot oder möchte sein Produkt mit anderen vergleichen. All das wird mit einer guten Suchfunktion erleichtert.

Und was zeichnet eine gute Suchfunktion aus?

Die interne Suchfunktion muss den Kunden schon bei der Formulierung der Suchbegriffe über Vorschläge unterstützen. Gerade mobil ist das enorm wichtig. Im nächsten Schritt müssen die Ergebnisse möglichst präzise und trotzdem tolerant zum Beispiel gegenüber Tippfehlern ausgespielt werden. Relevant werden ab dann auch die Darstellung der Suchergebnisse, diverse Sortieroptionen und Facetten zum Filtern. Aus technischer Sicht ist die Performance extrem wichtig. Unnötig lange Anwortzeiten der Suchvorschläge, Suchergebnisse oder nach dem Setzen eines Filters wirken sich negativ auf die Conversion Rate aus.

Warum ist das alles für den Kunden wichtig?

All das hilft ihm, die Suchergebnisse zu erkunden und weiter einzuschränken. So findet er schneller das Produkt, das er haben möchte.
Kunden, die die Suche nutzen, erwarten heute eine hohe Qualität der Suchergebnisse. Wie gut Suche funktionieren kann erlebt jeder online im Alltag über Google und andere Suchmaschinen und Dienste. Shops investieren enorm viel Ressourcen in Marketing, SEO und SEA, da ist es umso wichtiger, aus den gewonnenen Visits zufriedene Kunden und Bestellungen zu generieren.

Du sagtest gerade, es sei besonders mobil wichtig, dass die Suchfunktion den Kunden unterstützt. Kannst du das konkretisieren? Was war für dich persönlich das beste Nutzererlebnis bei einer mobilen Suche?

Als Google Maps mobil die Möglichkeit eingeführt hat, über die Suchvorschläge direkt eine Hausnummer hinzuzufügen, bevor die Suche selbst abgeschickt wird. Das war ein Feature, das leicht umzusetzen war und das für mich als Nutzer einen enormen Mehrwert gebracht hat. Seitdem achte ich noch stärker auf vermeintliche Kleinigkeiten. Das zeigt, dass die Komplexität einer Lösung nichts über den Mehrwert für den Kunden aussagt. Entscheidend ist, ob man ein Kundenbedürfnis überhaupt erkennt und wie man die Suche dann für die Nutzer dahingehend verbessert.

Wie er seine Schwachstellen findet, weiß unser hypothetischer Shopbesitzer nun. Was könnt Ihr von Tudock machen, um diese zu beheben?

Da gibt es unzählige Möglichkeiten. Wichtig ist, erstmal zu bestimmen, wo die Schwächen liegen und welche Maßnahmen für den Shop wie hoch priorisiert werden sollten. Jeder Shop ist da anders und jedes Sortiment hat seine Herausforderungen. Ganz allgemein gilt aber für jeden Shop, eine gute Balance zwischen Suchrelevanz und Geschäftszielen zu finden. Die Suche sollte so angepasst werden, dass sie häufige Suchmuster gut beantwortet.

Kannst Du uns Beispiele dafür geben?

Ein Beispiel sind Artikelnummernsuchen im B2B oder die Suche nach Modellnummern im Elektronikbereich. Diese Suchmuster spielen dort eine große Rolle, sind in einem Fashion Shop aber völlig irrelevant.

Aber wieso sollte ich als Shopbetreiber euch als Experten hinzuziehen? Kann ich das nicht auch intern abbilden?

Ja, das geht. Ich denke, am besten ist es, wenn ein interner Produktmanager über einen längeren Zeitraum von uns mit Wissen und Erfahrung unterstützt wird. Wir sehen, dass jedes Suche-Projekt grundsätzlich sehr ähnliche Herausforderungen mit sich bringt. Sowohl technologisch als auch intern beim Kunden. Wir helfen, Sackgassen zu vermeiden. Die steile Lernkurve beim Thema Suche kann mit unserer Hilfe vom Shopbetreiber viel besser und effizienter bewältigt werden. Und dann ist natürlich auch die Frage, ob intern überhaupt die Kapazitäten vorhanden sind, das Thema abzubilden.

Das heißt, Ihr begleitet Eure Kunden auch noch nach der Umsetzung der Onsite-Search, richtig?

Richtig. In der Regel begleiten wir unsere Kunden über längere Zeiträume, um beim Betrieb und der Weiterentwicklung der Suche zu unterstützen. Dazu zählt dann neben der Optimierung und dem KPI-basierten Reporting auch die konzeptionelle Weiterentwicklung des Produktes über ganz neue Features, etc.

Was bringt mir als Shopbesitzer die Optimierung der internen Suchfunktion?

Je nachdem, auf welchem Qualitätsniveau man bei der Suche startet, kann man den Umsatz pro Visit erheblich verbessern. Faktoren wie Imagegewinn und Kundenzufriedenheit sind nicht oder nur schwer nachweisbar. In der Regel spiegelt sich Zufriedenheit aber auch intern beim Shopbetreiber wider.

Und was genau macht Ihr, um die Suche zu optimieren?

Wir identifizieren Optimierungspotenziale, empfehlen Lösungen dafür und setzen diese um oder unterstützen bei der Umsetzung und dem Testing. Bleiben wir bei dem einfachen Beispiel mit den Artikelnummern: Hier bestimmen wir das Suchvolumen für Artikelnummernsuchen und prüfen die aktuelle Qualität der Ergebnisse. Ist die Artikelnummernsuche noch nicht ideal, finden wir gemeinsam mit dem Kunden Lösungen und testen diese systematisch durch. Anschließend kann die neue Suchkonfiguration live gehen, und die Kunden können besser nach Artikelnummern suchen.

Wenn mir nun also als Shopbetreiber meine aktuelle Suchlösung nicht mehr ausreicht und ich eine neue Suchfunktion in meinen Online-Shop integrieren lassen möchte. Wie geht Ihr das Projekt konkret an?

Wenn die Entscheidung der Suchlösung noch offen ist, definieren wir gemeinsam mit dem Kunden die individuellen Anforderungen des Shops und evaluieren die am besten geeignete Suchlösung. Wichtig dabei ist natürlich auch die strategische Ausrichtung des Shopbetreibers. Steht die Entscheidung für eine Suchlösung fest, testen wir systematisch verschiedene Konfigurationen der Suche. um schnellstmöglich zu einer guten Grundkonfiguration zu kommen. Danach übernehmen oder begleiten wir den Betrieb, also den täglichen Umgang mit der Suche, die Optimierung über Synonyme etc. Je nach Projekt übergeben wir das Thema dann an einen internen Produkt- oder Betriebsmanager oder begleiten den Kunden über Jahre hinweg beim Betrieb und der Weiterentwicklung der Suche.

Welche Themen im Bereich Onsite-Search interessieren dich besonders? Wo denkst du, liegt der Schlüssel zum Erfolg beim Thema Produktsuche?

Aus fachlicher Sicht interessiert mich das Thema Ranking der Suchergebnisse und Kategorieseiten besonders. Das ist ein komplexes Thema mit vielen unterschiedlichen Stakeholdern, das Kreativität erfordert. Das Ranking ist der Faktor, der über die Sichtbarkeit von Produkten entscheidet und das Kaufverhalten mitprägen kann. Beim Thema Ranking wird auch deutlich, was über Erfolg und Misserfolg von Suche-Projekten entscheidet, nämlich Transparenz und Kommunikation. Beim Thema Suche treffen hohe Erwartungen auf hohe Komplexität bei der Umsetzung. Da ist Kommunikation und Wissenstransfer der Schlüssel zum Erfolg.

Welche Trends gibt es beim Thema Suche? Wo siehst du die Zukunft der Produktsuche?

Ich glaube, dass zukünftig dem Sucherlebnis als Ganzem mehr Beachtung geschenkt wird.

Was meinst Du damit?

Gefühlt werden Daten-, Relevanz- und Usabilityprobleme noch getrennt betrachtet. Die Grenzen aber werden immer weiter verschwimmen, je mehr Fortschritte in den einzelnen Bereichen gemacht werden.

Grenzen verschwimmen, ein schöner Ausdruck. Es geht demnach primär um Veränderung.

Genau, das sieht man zum Beispiel auch bei Dauerthemen wie der Personalisierung oder dem Learning to Rank. Um hier über die Buzzwords hinaus zu echten Lösungen zu kommen, haben die meisten Shopbetreiber noch viel Arbeit vor sich. Beim Thema Personalisierung wird neuerdings viel mehr über Datenhoheit, Transparenz und mögliche Vorurteile in Algorithmen diskutiert. Da Lösungen zu finden, finde ich sehr interessant, und ich bin überzeugt, das werden die bestimmenden Themen im Bereich Suche bleiben.

Verstehe. Es geht also darum, eine Gratwanderung zwischen Individualität und technologischer aber auch ethischer Machbarkeit zu schaffen. Vielen dank für diesen spannenden Ausblick und das tolle Interview, Sebastian!

Starten auch Sie mit Ihrer Suche durch.
Jetzt Kontakt aufnehmen!
Michael Wolf von Tudock
Michael Wolf
Geschäftsführer
Kategorien
Archiv

Visualisierung von Suchergebnissen

Ein allgegenwärtiges Problem bei der Optimierung einer Suche ist die fehlende Transparenz darüber, wie die Suchergebnisse eigentlich zustande kommen. Unser Ziel und unsere Motivation ist es, diese Transparenz für unsere Kunden zu schaffen. Das betrifft die allgemeine Qualität der Suchergebnisse und deren Ranking-Faktoren. 

Mangelnde Transparenz auf Seite des Shopbetreibers kann viele Gründe haben: Der Mitarbeiter, der die Suche betreute und vor Jahren das Ranking definiert hat, ist vielleicht nicht mehr im Unternehmen. Es mangelt generell an internen Ressourcen für das Thema Suche oder die Datengrundlage und Technologie haben sich so verändert, dass nicht mehr klar ist, wo die Suche steht. Das Tracking und die Analytics geben vielleicht nicht so viel zum Thema Suche her oder der Suchanbieter bietet nicht genug Einblick in das Zustandekommen der Suchergebnisse. Das alles kann zu Unsicherheit, Verwirrung, Missverständnissen und damit für Frustration sorgen.

Wir haben daher über die Jahre Mittel und Wege gefunden, für mehr Durchblick zum Thema Suche zu sorgen. Unsere aktuelle Lösung lässt sich mit Trackingdaten kombinieren und erlaubt dadurch auf einfache und schnelle Weise Einblicke in das Sucherverhalten auf Suchergebnisebene. Das Ganze ist so Low-Tech, dass es sich leicht auf verschiedene Projekte übertragen lässt und auch in kleineren Zeitbudgets Sinn macht. Die einzige Voraussetzung sind die Suchbegriffe aus dem Analyticstool oder den Suchlogs sowie Zugriff zum Live bzw. Testshop und eine weitere Datenquelle. Das können Klicks oder Businesswerte wie Bestellungen pro Produkt sein.

Um etwas besser verstehen zu können, hilft es ungemein, es bildlich zu betrachten. Daher fokussiert sich das Tool auf die Visualisierung von Suchergebnissen. Visuelle Informationen sind außerdem besser für jedermann zugänglich, das heißt unabhängig vom fachlichen Background lassen sich schnell Zusammenhänge erfassen und Schlüsse ziehen.

Wir wollen unsere Begeisterung für das Thema Suche mit allen Projektbeteiligten teilen, unabhängig von ihrem fachlichen Hintergrund. Und genau dabei hilft uns dieses Tool.

Herausforderungen

Um die Suchergebnisqualität zu beurteilen, genügt es nicht, sich Suchergebnisse im Shop anzuschauen. Das mag für offensichtlich falsche Treffer ausreichen, aber was wenn das Suchergebnis „Waschmaschine“ ausschließlich aus Waschmaschinen besteht? Dann ist es wichtig, dass die Topseller bzw. Neuheiten auf den vorderen Positionen gelistet werden. Um das zu beurteilen, muss man zusätzliche Daten hinzuziehen, die nicht im Shop sichtbar sind – wie das Nutzerverhalten oder den Verkaufsrang eines Produktes. Je nachdem, welche Informationen verfügbar sind, wird die Bewertung anders ausfallen. Hier ein Beispiel:

Im Frontend sichtbare vs. unsichtbare Informationen

Betrachtet man nur den im Shop sichtbaren Teil, würde man das Suchergebnis als gut bewerten. Die Mitarbeiter, die die Kategorie verantworten, kämen vielleicht zu einem anderen Schluss, da sie die Topseller kennen. Aber auch sie wissen nicht, welche Artikel die Kunden in letzter Zeit im Shop geklickt haben. Daher ist es wichtig, all diese Informationen sichtbar zu machen, um zu einer Bewertung des Suchergebnisses zu kommen.

Das Tool

Das Tool besteht aus drei Komponenten: Zuerst fragen wir die Suchergebnisse einer beliebigen Anzahl von Suchbegriffen inklusive der Position der einzelnen Produkte vom Suchserver ab. Das speichern wir als simple Tabelle, die wir dann mit weiteren Daten aggregieren, um die Ergebnisse abschließend zu visualisieren.

Erste Komponente des Tools: Suchergebnisse vom Server abholen

Im Idealfall haben wir direkten Zugriff zum Suchserver und holen uns die Suchergebnisse als XML ab. Darin sind in der Regel schon viele nützliche Zusatzdaten enthalten. Ist ein direkter Zugriff aufgrund der Systemlandschaft, der Sicherheitsvorkehrungen etc. nicht möglich, setzen wir einen einfachen Crawler ein, der die Produkte und deren Position per URL-Aufruf aus dem Frontend beschafft. Im ungünstigsten Fall kann man die Suchergebnisse auch aus einer Preview der Suchlösung per Copy und Paste in das Tool übertragen. Damit ist man aber sehr eingeschränkt und kann die größte Stärke des Tools nicht nutzen: die Möglichkeit, eine große Menge an Suchergebnissen automatisiert abzurufen.

Im zweiten Schritt kann man die gewonnenen Daten jetzt anreichern, zum Beispiel um die Zielseiten der Suche aus Google Analytics. Das sind laut Google „die Seiten, die Besucher gesehen haben, nachdem sie eine Suche auf Ihrer Website ausgeführt haben“.

Anreicherung der Daten: Hier zum Beispiel mit den Zielseiten der Suche aus Google Analytics

Wir können diese Information nutzen, um die Klicks innerhalb des Suchergebnisses abzubilden. Die Artikelnummer ist in der Regel Teil der URL und lässt sich einfach extrahieren. Sie schafft die Verbindung zu unseren Daten aus Schritt 1, als wir die Suchergebnisse abgeholt haben. So können wir unsere erste Visualisierung erstellen:

Visualisierung der Klicks eines Suchergebnisses

Jede Zeile besteht aus einem Suchbegriff und die Spalten entsprechen den Positionen im Suchergebnis. Rot ist in diesem Fall kein Klick und je intensiver das Grün, desto häufiger wurde der Artikel geklickt. Dies lässt sich dann gleich für eine Reihe von Suchbegriffen darstellen:

Visualisierung der Klicks einer größeren Anzahl von Suchergebnissen

So kann man auch bei einer großen Menge von Suchbegriffen schnell erfassen, wo Probleme auftreten beziehungsweise wie gut das aktuelle Ranking der Nachfrage der Kunden entspricht. Darüber hinaus sieht es auch einfach cool aus. 🙂

Noch interessanter ist es, wenn man weitere Daten dazunimmt. Zum Beispiel Rankingfaktoren wie Relevanz-Scores aus der Suchlösung und Business-Scores der Produkte. Das unterscheidet sich je nach eingesetzter Suche und Setup. Angenommen, der Shop setzt Solr als Produktsuche ein und sortiert zuerst nach Solr Score und dann nach Businesswert. Dann könnte das zum Beispiel so aussehen:

Visualisierung der Klicks, Solr Scores und Businesswerte eines Suchergebnisses

Man erkennt durch die Visualisierung schnell, wo das Problem liegt. Im E-Commerce ist es tendenziell so, dass ein Produkt relevant ist oder nicht. Besonders bei generischen Sortimentsanfragen wie „Waschmaschine“. Aufgrund der Produktdaten ist aus Sicht der Suchlösung aber die eine Waschmaschine eventuell relevanter als die andere. Das kann viele Gründe haben: Der Begriff „Waschmaschine“ kommt bei einer Maschine öfter in den Daten vor als bei einer anderen, das Feld, das Waschmaschine enthält, hat einmal mehr und einmal weniger andere Begriffe oder Synonyme spielen mit in den Relevanz-Score. Das betrifft alle Suchlösungen, die irgendwie mit Feldgewichtungen arbeiten, wie Solr, Fredhopper oder FACT-Finder gleichermaßen.

Um ein Ranking zu beurteilen, schauen wir uns verschiedene Rankingfaktoren im Zusammenspiel an und ergänzen Dateninhalte, die wir hervorheben wollen, also zum Beispiel, ob es sich bei dem Produkt um einen Laptop oder Zubehör beziehungsweise eine Laptoptasche handelt:

Visualisierung verschiedener Rankingfaktoren und manuell festgelegter Kriterien wie “Ersatzteil” etc.

Um möglichst viele Positionen zu erfassen, kann man auch eine andere Darstellung wählen, wie zum Beispiel blockweise von links nach rechts und oben nach unten. So kann man in folgender Abbildung 196 Artikel mit jeweils sechs Informationen pro Artikel auf einmal betrachten:

Die blockweise Darstellung erlaubt noch mehr Positionen auf einmal zu betrachten, um Muster zu erkennen

Alles bis hierher dient der Transparenz und der Bewertung des Status Quo. Wo wir aber auch großes Potential sehen, ist die Möglichkeit, relativ einfach und schnell verschiedene Konfigurationen miteinander zu vergleichen:

Visualisierung der Auswirkungen verschiedener Suchkonfigurationen auf ein bestimmtes Suchergebnis

So kann man sich ein Test-Set zusammenstellen und dafür Kriterien zur Bewertung bestimmen. In unserem Beispiel wollen wir sehen, wie viele Artikel im Suchergebnis von „Waschmaschine“ tatsächlich in den Produktdaten als Waschmaschine verortet sind. Zur Beurteilung würde ein reiner Prozentwert ausreichen. Zum Erforschen, Vergleichen und Erklären ist eine Visualisierung aber besser geeignet.

Ausblick

Bis jetzt nutzen wir die Visualisierung hauptsächlich, um uns ein Bild über Ranking und Relevanzprobleme zu machen und die Erkenntnisse dann mit den Shopverantwortlichen zu besprechen. Wir wollen die Visualisierung aber auch stärker in den Betriebsprozess integrieren, beispielsweise beim Monitoring der Top-Suchen. Das wäre dann ein Thema für einen weiteren Beitrag.

Wir freuen uns über Anmerkungen und Kommentare und sind immer an Ideen und Vorschlägen interessiert, wie man die Transparenz beim Thema Onsite Search weiter erhöhen könnte.

Kategorien
Archiv

Grundwissen Ecommerce Onsite Search #3: Ranking, Kampagnen und Facettierung

Das Suchergebnis durch die Konfiguration der internen Produktsuche beeinflussen

Ob ein Kunde die Suchqualität im Shop als gut empfindet, hängt nicht nur vom Gesamtergebnis der gefundenen Produkte ab. Wie bei Google ist vor allem die Reihenfolge der Treffer entscheidend. Während der Kunde mit der Sortierfunktion auf der Suchergebnisseite die Anzeigereihenfolge der Produkte selbst beeinflussen kann (Sortierung nach Neuheit, Bestseller etc.), bestimmt das Ranking die Reihenfolge der Suchergebnisse nach Kriterien, auf die der Kunde keine direkte Einflussmöglichkeit hat. Stattdessen greift hier die Konfiguration der Suche.

Ranking

Jede Suchlösung ermöglicht es, verschiedene Datenfelder unterschiedlich zu gewichten. Die Gewichtung ergibt dann das Ranking – zusammen mit anderen Mechanismen wie der Häufigkeit und Position eines Begriffes innerhalb des Datenfeldes oder Verkaufszahlen und Klicks. Das Ranking der Suchergebnisseite ist die wichtigste Stellschraube innerhalb des Produktes „Suche“. Die Position eines Artikels auf der Suchergebnisseite ist entscheidend, da die Klicks von Zeile zu Zeile sehr stark zurückgehen und nur ein Bruchteil der Besucher auf Suchergebnisseiten blättert bzw. tiefer in die Suchergebnismenge einsteigt.

Wie hoch man ein Datenfeld gewichtet hängt stark von der Datenqualität ab. Hat man eine gute Kategoriestruktur, sollte diese beispielsweise deutlich höher gewichtet werden als ein Feld mit unstrukturierten Produktattributen oder die Produktbeschreibung. Grundsätzlich kann man sagen:

Kategorie > Produktname > strukturierte Attribute (beispielsweise normalisierte Farben, Größen oder sonstige Eigenschaften) > unstrukturierte Attribute (oft als searchable Attributes bezeichnet wie etwa „wasserfest bis 30 Meter“) > Produktbeschreibung (unstrukturiert und oft irreführend wie „passt gut zu Bluse“ etc.)

Jede Suche gibt initial einen Relevanzwert zu jedem einzelnen Produkt des Suchergebnisses zurück. Bei Solr ist das zum Beispiel der Relevanz-Score, bei Fredhopper die Match-Rate und FACT-Finder arbeitet mit einem Ähnlichkeitswert. Grundsätzlich gibt es einige Gemeinsamkeiten, aber auch starke Unterschiede was die Faktoren betrifft, die in die Relevanz einfließen. Hier ein Beispiel:

Produktranking: Fiktives und vereinfachtes Beispiel für die Bestimmung der Relevanz. Oben der Solr-Score im Vergleich zur Match-Rate bei Fredhopper. Darunter der Solr-Score im Vergleich zur Ähnlichkeit bei FACT-Finder.

Weitere Rankingfaktoren

Der Relevanzscore sollte im Ecommerce immer nur ein Teil des Rankings sein. Andere Faktoren wie Klickrate, Anzahl der Verkäufe, Marge, Verfügbarkeit, Retourenquote, Neuheit eines Produktes etc. beeinflussen idealerweise auch das Ranking. Es bringt aber nichts, jeden möglichen Faktor mit ins Ranking zu nehmen, da zu viele Faktoren sich gegenseitig neutralisieren. Man muss sich gezielt auf einige Werte beschränken. Diese Werte sollten mit den Unternehmenszielen und der Zielgruppe des Shops harmonieren.

Es kann sein, dass Suchanbieter wie beispielsweise Fredhopper die Relevanz-Scores normalisieren. Das heißt: Wenn es innerhalb des Suchergebnisses viele gleich relevante Produkte gibt, bietet es sich an, innerhalb der gleichen Relevanz nach den Businesswerten zu ranken. Um beim oberen Beispiel zu bleiben: Die ersten 15 Treffer sind alles rote Shirts von Nike. Aus Kundensicht sind diese alle gleich relevant. Die Suche gibt für alle den Score 350 zurück. Wenn diese nun einen normalisierten Score bekommen, kann innerhalb dieses Scores nach Verfügbarkeit und Verkäufen gerankt werden. Innerhalb der 15 passenden Treffer erscheinen die gut verfügbaren Topseller dann weiter oben.

Bei FACT-Finder fließen solche Werte als Abwertung in die Ähnlichkeit mit ein. Hier ist es aufgrund der vielen Faktoren des FACT-Algorithmus eher unwahrscheinlich, dass mehrere Artikel exakt dieselbe Ähnlichkeit bekommen. Daher macht ein zweistufiges Ranking keinen Sinn. Das heißt, man konfiguriert bei FACT-Finder zum Beispiel eine maximale Abwertung von 2% bei null Verkäufen und keine Abwertung ab 100 verkauften Artikeln. Ein Artikel mit 100 Verkäufen bekommt somit keine Abwertung; ein Artikel, der bisher nicht verkauft wurde, hat eine Abwertung von 2% und dazwischen wird linear skaliert.

Kampagnen

So gut wie alle kommerziellen Suchanbieter bieten eine Kampagnenfunktionalität. Im Umfang unterscheiden diese sich jedoch stark. Fredhopper und FACT-Finder bieten hier beispielsweise sehr viele Möglichkeiten. Kampagnen können an verschiedene Bedingungen geknüpft werden oder zeitgesteuert laufen. Folgende Funktionalitäten werden im Bereich Suche allgemein als Kampagnen bezeichnet:

Weiterleitungen

Für bestimmte Suchbegriffe wird direkt auf eine URL geleitet. Das kann eine Landingpage, eine Serviceseite, der Kundenlogin etc. sein. Manche Suchlösungen, wie zum Beispiel FACT-Finder und SEMKNOX, bieten hier Bedingungen an wie „Suchanfrage enthält ‚Versand'“, so dass nicht jeder Begriff einzeln hinterlegt werden muss. Bei SEMKNOX kann man sogar reguläre Ausdrücke verwenden um Kampagnen auszulösen.

Weiterleitungen sollten regelmäßig automatisiert geprüft werden, da es sein kann, dass die Linkziele nicht mehr aktuell sind. Weiterleitungen können auch eingesetzt werden, wenn es unmöglich ist, ein bestimmtes Suchergebnis zu optimieren oder die After Search Navigation nicht ideal ist – also die verfügbaren Filter auf der Suchergebnisseite nicht ausreichen. Dann können dem Kunden auf einer Landingpage manuell erstellte Filter, Unterkategorien oder Produktberater angeboten werden.

Artikel pushen

Artikel können global im gesamten Shop oder nur für bestimmte Suchergebnisse nach oben gepusht werden. Bei Fredhopper lässt sich sogar eine genaue Position innerhalb des Suchergebnisses angeben. Ein Beispiel: Ab neunter Position des Suchergebnisses immer vier Adidas Artikel platzieren. Das entspricht dann im Shop der dritten Zeile bei vier Artikeln pro Zeile (Darstellung der Suchergebnisse als Gitter).

Kategorien pushen

Ganze Kategorien können global oder für bestimmte Suchergebnisse nach oben verschoben werden. Die meisten Suchlösungen können auch andere Filterausprägungen verarbeiten. Zum Beispiel: alle Produkte in „blau“ oder Produkte mit der Eigenschaft „wasserfest“ nach oben pushen.

Suchergebnisse gezielt umsortieren

Fredhopper bietet beispielsweise auch die Möglichkeit, Suchergebnisse ganz gezielt nach verschiedenen Kriterien umzusortieren. FACT-Finder kann das über eine Suchergebniskampagne auch ähnlich abbilden.

Suchergebnisse filtern

Um Suchergebnisse zu optimieren, ist es oft nötig ganze Kategorien auszuschließen oder umgekehrt nur ausgewählte Kategorien oder Ausprägungen anzuzeigen. Im Gegensatz zur Umsortierung oder dem Pushen einzelner Artikel, verschwinden die Produkte hier aus dem Suchergebnis. Erfahrungsgemäß ist das ein Feature, das oft für die Optimierung von Suchergebnissen nötig ist, und daher von allen Suchanbietern angeboten werden sollte (was aber leider nicht der Fall ist).

Banner ausspielen

Mit Hilfe von Bannern ist es möglich, oberhalb des Suchergebnisses Zusatzinformationen oder Angebote bzw. Aktionen darzustellen. Das kann genutzt werden, um den User zu inspirieren oder ihn auf Sonderangebote passend zum Suchbegriff aufmerksam zu machen. So will man vielleicht eine Versicherung zum Smartphone mitverkaufen oder auf einen Themenshop hinweisen. Banner werden auch eingesetzt, um dem User bei doppeldeutigen Suchbegriffen die Wahl zu lassen. Die Suche nach „Braun“ kann beispielsweise die Treffer der Farbe ausspielen, das Banner weißt jedoch auf den Markenshop des Herstellers „Braun“ hin. Wird nun häufiger mit dem Banner als mit dem Suchergebnis interagiert, sollte man darüber nachdenken, stattdessen die Elektrogeräte von „Braun“ als Suchergebnis auszuspielen. Manche Marken fordern auch ein Banner oder einen Markenshop, damit man sie im Onlineshop anbieten darf.

Kaufberater

Einige Suchlösungen bieten auch die Möglichkeit, Beraterkampagnen einzurichten. Sucht ein Kunde nach einem generischen Begriff wie „Hose“, kann man ihm dann oberhalb des Suchergebnisses einen Produktberater anbieten. Der Kunde hat die Möglichkeit, sich durch ein paar kurze Fragen oder Icons zu klicken, um die Treffermenge schnellstmöglich einzugrenzen. Im Prinzip sind das ausformulierte Fragen, die der Kunde beantwortet, womit im Hintergrund die Suche Filter setzt. Streng genommen handelt es sich hierbei um eine Sonderform der After Search Navigation.

Weitere Kampagnen:

FACT-Finder, Fredhopper, SLI, SEMKNOX und auch andere Suchlösungen bieten insgesamt so viele Möglichkeiten, Kampagnen und Auslöser zu kombinieren, dass hier nicht genügend Platz ist, alle aufzulisten. Grundsätzlich ist eine Kampagne auch nicht auf die Suchergebnisseite beschränkt. Man kann Kampagnen auch nutzen, um auf der Artikeldetailseite Recommendations oder andere Elemente anzuzeigen, Produktlisten zu bestücken oder je nach Suchbegriff oder angezeigtem Artikel unterschiedliche Rankings auszuspielen.

Facettierung (After Search Navigation)

Grundlage für die After Search Navigation („ASN“) ist die Facettierung (Stichwörter „faceting“ oder auch „faceted search“). Aus den Facetten ergeben sich die Filter auf der Suchergebnisseite. Ein Beispiel: Die Suche nach T-Shirt ergibt 500 Treffer. Bei so einer Treffermenge ist es naheliegend, dass der User seine Treffer einschränken möchte. Die Suche gibt daher zum Suchergebnis Facetten zurück, die aus den Produktdaten bestehen. So sind die 500 T-Shirts von verschiedenen Marken, in unterschiedlichen Farben, Größen, Trendthemen und für Damen und Herren erhältlich. Die Suche spielt nun die entsprechenden Facetten inklusive der Anzahl der Produkte aus dem Suchergebnis mit einer der Ausprägungen zurück. Also beispielsweise für das Suchergebnis „Ihre Suche nach ‚T-Shirt‘ ergab 500 Treffer“:

Generierte Facetten für Filterung des Suchergebnisses "T-Shirt" (fiktives Beispiel)

Schon bei diesem einfachen Beispiel wird die Komplexität deutlich: Es gibt Facetten, die hierarchisch als Filter angezeigt werden sollen wie etwa „Kategorie“. Es gibt Artikel, die über mehrere Ausprägungen einer Facette wie etwa die „Größe“ verfügen. Darüber hinaus ist ein Suchergebnis selten zu 100% homogen. Daher bieten die meisten Suchanbieter an, die Filter erst ab einem Mindestanteil von Artikeln (beispielsweise 5%) oder von einer Mindestanzahl von Artikeln (beispielsweise ab zwei Artikeln in der Facette) anzuzeigen.

Bei der Suche nach Adidas werden neben Bekleidung auch Schuhe, Uhren etc. enthalten sein. Hier sollten erstmal nur die relevantesten Filter angezeigt werden. Attribute wie „wasserfest“ (Uhren) oder „Laufsohle“ (Schuhe) sind erst bei dem jeweiligen Sortiment interessant. Die Suche nach „nike shirt rot“ sollte im Idealfall nur aus roten Nike Shirts bestehen. Da macht es keinen Sinn, die Filter „Farbe“, „Marke“ und „Kategorie“ anzuzeigen. Hier interessiert sich der Nutzer eher für die Zielgruppe, Größe und Material und gegebenenfalls für spezielle Facetten wie „Sportart“ oder Ähnliches.

Eine Facette kann aus einem festen Datenfeld oder aus einem Multi-Attributsfeld generiert werden. Es können zum Beispiel auch Abhängigkeiten definiert werden. Zwei Beispiele: „Zeige Unterkategorie erst nach Auswahl der Oberkategorie an“; „Zeige Akkulaufzeit erst nach Auswahl der Kategorie Elektrogeräte an“ etc.

Wichtig bei der Facettierung ist eine möglichst vollständige Normalisierung der Ausprägungen seitens der Produktdaten. Beispiele hierfür sind Farbkacheln oder Größenangaben. Die Größenangaben US, EUR etc. sollten jeweils beide am Produkt hängen und im Größenfilter entweder getrennt (zwei Facetten-Filter „US-Größe“ und „EUR-Größe“ mit jeweiligen Ausprägungen „L“ und „44“) oder vereinheitlicht sein (ein Größenfilter mit Ausprägung „L / 44“). Das mag banal klingen, stellt aber eine große Herausforderung dar!

Wir weisen darauf hin, dass die Beispiele zum Funktionsumfang einzelner Suchanbieter keinen Anspruch auf Vollständigkeit erheben. Das heißt, auch andere Suchanbieter stellen mitunter gleiche oder ähnliche Funktionen bereit. Ein genaueres Porträt dieser Funktionen hätte aber den Umfang dieser Blogserie gesprengt. Über Hinweise auf interessante Funktionen anderer Anbieter freuen wir uns in den Kommentaren.

Kategorien
Archiv

Grundwissen Ecommerce Onsite Search #2: Synonyme

Die Konfiguration der internen Produktsuche mit Synonymen

Nicht nur die eingesetzte Suchlösung und die Produktdaten, sondern auch die Konfiguration der Suche bestimmt die Suchergebnisqualität im Onlineshop. Nach der initialen Einrichtung empfiehlt es sich, die Suchkonfiguration beständig zu optimieren, um Kunden die bestmögliche Suchqualität zu bieten. Diese Nachjustierung der Suche kann durch Veränderungen im Sortiment, aber auch durch Änderungen im Suchverhalten der Kunden notwendig werden. Wichtige Aufgabe beim Betrieb einer Suche ist die Pflege der Synonyme. Sie helfen unter anderem, die Sprache der Kunden und die Bezeichnungen der Produkte im Shop in Einklang zu bringen.

Synonyme

Einwort- und Mehrwortsynonyme

Die meisten Suchlösungen, darunter auch Fredhopper unterstützen Mehrwortsynonyme. Das heißt, man kann ein Synonym „rolli“ ist gleich „pullover mit rollkragen“ anlegen. Eine der Ausnahmen stellt FACT-Finder dar. Hier kann man nur Einwortsynonyme anlegen. In diesem Beispiel wäre „rolli“ ist gleich „rollkragenpullover“ möglich, aber „rolli“ ist gleich „pullover mit rollkragen“ nicht. Hat man bei FACT-Finder zum Beispiel das Problem, dass einige Artikel „Rollkragenpulli“ und andere „Pullover mit Rollkragen“ heißen, muss man auf Workarounds zurückgreifen.

Beidseitige bzw. ungerichtete Synonyme

Jede Suchlösung sollte zumindest beidseitige Synonyme abbilden können. Um ein beidseitiges Synonym handelt es sich beispielsweise bei „notebook“ ist gleich „laptop“. Die beiden Begriffe haben exakt dieselbe Bedeutung aus Shopsicht. Jedes Notebook ist auch ein Laptop und umgekehrt.

Einseitige bzw. gerichtete Synonyme

Um eine Produktsuche optimal zu konfigurieren, benötigt man häufig auch einseitige bzw. gerichtete Synonyme. Gerichtete Synonyme greifen nur in eine Richtung. Ein Beispiel: Ein Synonym von „Couch“ zu „Ecksofa“ bedeutet, dass jedes Ecksofa auch eine Couch ist, aber nicht jede Couch ein Ecksofa. Oder anders ausgedrückt: Wenn ich nach „Couch“ suche, möchte ich auch die Ecksofas sehen. Wenn ich nach „Ecksofa“ suche aber nicht alle Couches.

Gewichtete Synonyme

Mindestens Fredhopper und FACT-Finder bieten die Möglichkeit, Synonyme zu gewichten. Bei Fredhopper geht das über den Operator Ähnlich „~“. Wenn „Shorts ~ Bermudas ~ kurze Hosen“ eingerichtet ist, werden dieselben Treffer für beide Begriffe ausgegeben. Allerdings erscheinen bei „Bermuda“ die Artikel, die explizit in den Daten als „Bermuda“ verortet sind, weiter oben als andere Shorts und kurze Hosen. Es besteht also ein Unterschied zwischen „ähnlich“ und „gleich“ bei den Synonymen, was die Relevanz und damit die Sortierung betrifft.

Bei FACT-Finder ist es möglich, bei jedem Synonym eine Abwertung anzugeben. Ist „gleich“ bedeutet dann Abwertung 0%, eine Gewichtung wie „ähnlich“ setzt man über höhere Abwertungen um, beispielsweise zwischen 1% und 8%. Der Wert 8% ist nur eine Annahme, je nach der eingestellten Bandbreite kann er auch höher oder niedriger liegen. Sobald die Abwertung des Synonyms die Bandbreite übertrifft, ist aus dem Synonym effektiv ein Antonym geworden.

Antonyme

FACT-Finder bietet auch die Möglichkeit, Antonyme anzulegen. In erster Linie sind diese dazu da, unerwünschte Ähnlichkeiten zu vermeiden. Enthält das Suchergebnis von „Bluse“ auch „Blue Jeans“ aufgrund der Ähnlichkeit, die FACT-Finder zwischen „Blue“ und „Bluse“ herstellt, kann man ein Antonym „bluse“ ist ungleich „blue“ anlegen. Das bedeutet, dass die „Blue“-Artikel aus dem Suchergebnis verschwinden. Das Beispiel zeigt aber auch die Kehrseite der Antonyme. Eine Bluse mit der Farbangabe „Blue“ würde ebenfalls aus dem Suchergebnis „Bluse“ entfernt werden.

Auch bei Antonymen arbeitet FACT-Finder nach dem Prinzip der Abwertung. Ein Antonym ist dann eine Abwertung um 100%. Epoq bietet einen ähnlichen Mechanismus über die Exclude-Regel an. Allerdings kann man dort ausschließlich ähnliche Begriffe ausschließen, wie etwa „naturata EXCLUDE natural“. Eine Regel wie „wein EXCLUDE wasser“ hätte keine Auswirkung auf das Suchergebnis.

Bei FACT-Finder lassen sich Antonyme auch beispielsweise von „rock“ zu „schuhe“ anlegen, wenn das Suchergebnis „rock“ Schuhe in der Farbe „sand rock“ enthält. Durch Antonyme bietet FACT-Finder die Möglichkeit, viele Optimierungen schnell umzusetzen. Es besteht aber auch immer die Gefahr, dass an anderer Stelle ein unerwünschter Nulltreffer auftritt oder relevante Suchergebnisse wegfallen.

Vererbung von Synonymen

Einige Suchlösungen vererben Synonyme. Man kann auch von Verkettung bzw. Transitivität sprechen. Abstrakt ausgedrückt bedeutet das: Wenn A=B und B=C, dann auch A=C. Vererbt die Suchlösung Synonyme nicht, muss man eine Regel A=B=C anlegen, um alle drei Begriffe gleichzusetzen. Aus Sicht eines Shopmanagers, der Synonyme pflegt, ist es anwenderfreundlicher, wenn eine Vererbung stattfindet.

Ein Beispiel: Der Shopmanager legt ein Synonym „Sofas“ ist gleich „Couches“ an. Ein Kollege setzt ein gerichtetes Synonym von „Couches“ zu „Ecksofas“, da er gesehen hat, dass für „Couches“ nicht alle Ecksofas im Suchergebnis erscheinen. Hier würde man erwarten, dass die Suchbegriffe „Couches“ und „Sofas“ nun beide auch alle „Ecksofas“ ausspielen, da die erste Regel ja besagt, „Couches“ ist gleich „Sofas“. Findet keine Vererbung statt, sind die Ecksofas aber tatsächlich nur für den Suchbegriff „Couches“ dabei, weil die Suche die erste Regel nicht mit der zweiten Regel verkettet.

Hier unterscheiden sich die Suchanbieter stark: FACT-Finder vererbt sowohl beidseitige als auch einseitige Synonyme. Einzige Einschränkung ist, dass dies nur bis zu einer bestimmten Tiefe geschieht, um Schleifen und Performanceprobleme zu vermeiden. Hier würden sich das Synonym „Sofas“ ist gleich „Couches“ und das gerichtete Synonym von „Couches“ zu „Ecksofas“ wie erwartet auswirken. Sowohl „Sofas“ als auch „Couches“ enthalten alle Ecksofas. Ein weiteres Synonym „Eckcouches“ ist gleich „Ecksofas“ würde ebenfalls alle Suchbegriffe betreffen.

 

Die Abbildung erklärt die volle Vererbung von beidseitigen (=) und gerichteteten Synonyme (>) anhand eines Beispieles.

Fredhopper vererbt Synonyme beispielsweise nicht. Sollte in einer Regel „Couches“ ist gleich „Sofas“, in einer weiteren Regel „Kanapees“ ist gleich „Sofas“ und in einer dritten Regel ein gerichtetes Synonym von „Couches“ zu „Ecksofas“ angelegt sein, würden die Suchergebnisse wie folgt aussehen: „Sofas“ würde neben den „Sofas“ auch alle „Kanapees“ und „Couches“ enthalten. „Couches“ würde alle „Couches“ und „Sofas“ und zusätzlich die „Ecksofas“ enthalten. „Kanapees“ würde wiederum nur die „Kanapees“ und „Sofas“ enthalten. Hier müsste man eine Regel „Sofas = Couches = Kanapees“ anlegen und zusätzlich das gerichtete Synonym „Ecksofas“ sowohl für „Kanapees“, „Sofas“ als auch für „Couches“ einrichten! Fredhopper weist einen daher im Backend darauf hin, wenn ein Begriff bereits in einer anderen Synonymregel enthalten ist. Man kann die Regeln dann prüfen und gegebenenfalls zusammenführen oder ergänzen. Das macht die Konfiguration etwas schwerer und unübersichtlicher, was leicht zu Fehlern bei der Einrichtung von Synonymen führen kann. Andererseits ist man ohne die Vererbung von Synonymen noch etwas flexibler was den Umgang mit einzelnen Begriffen angeht. Man sollte daher zu Beginn eines Projektes mit einer neuen Suchlösung immer klar stellen, wie und ob Synonyme vererbt werden.

Hier das selbe Beispiel ohne Vererbung der Synonyme. Es findet daher keine Verkettung statt.

Im dritten Beitrag dieser Blogserie beschäftigen wir uns mit weiteren Aspekten der Suchkonfiguration: dem Ranking, Kampagnen und der Facettierung.

[Hinweis: Wir haben den Abschnitt über die Synonym-Vererbung bei Fredhopper am 25.09.2017 aktualisiert.]

Kategorien
Archiv

Grundwissen Ecommerce Onsite Search #1: Funktionsweise

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:

Synonyme Query Time: Hier werden im Hintergrund zwei Suchanfragen abgeschickt, die dann jeweils die Artikel mit "sakko" bzw. "jackett" in den Produktdaten finden.
Synonyme Index Time: Hier bekommt jeder Artikel mit "sakko" in den Produktdaten auch "jackett" hinterlegt und umgekehrt. Die Suche nach "sakko" findet daher auch die Jacketts.

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.

 

Ein Beispiel, wie zur Query und zur Index Time Analyzer durchlaufen werden.
Beispielhafter Ablauf einer Kette von Analyzern und wie sie die Query verändern.

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.

Michael Wolf von Tudock

Moin, ich bin Michael.

Sie suchen einen erfahrenen Partner für ihr E-Commerce-Projekt, haben Fragen zu optimaler Suchtechnologie oder wünschen sich professionelle Beratung? Dann sind Sie bei mir genau richtig. Lassen Sie uns jetzt ins Gespräch kommen!

Sie erreichen mich am Besten per E-Mail unter michael.wolf@tudock.de