Mit A/B-Tests die interne Suche optimieren

Im E-commerce spielt die interne Suchfunktion mittlerweile eine extrem wichtige Rolle. Conversionrates in Sessions mit Suche liegen oft um ein Vielfaches höher als in Sessions ohne Suche (laut SDL im Schnitt um 270% höher).

Über die Gründe kann man nur spekulieren. Nahe liegend scheint, dass wir durch die großen Anlaufstellen im Netz – vor allem Google, YouTube und Amazon – gelernt haben, dass eine Suche oft schneller zum gewünschten Ziel führt, als eine noch so gute Navigation. Zumindest wenn die Suche gut funktioniert.

Screenshot einer Heatmap von beck-shop.de

Heatmap aus econda. Rot eingefärbt sind die Bereiche, die häufig geklickt werden. Deutlich sichtbar ist, dass die Suche sehr viel häufiger verwendet wird als die Navigation.

Trotzdem wird die Suchoptimierung von vielen Sitebetreibern sträflich vernachlässigt. Das ist nicht verwunderlich, weil es sich um ein technisch und konzeptionell anspruchsvolles Thema handelt, das oft unterschätzt wird. Meist beschränkt sich die Optimierung auf Design und Anordnung der Suchelemente (z.B. Aufbau der Suchergebnisse, Bildergröße, Button-Labels, etc.). Aber das Kernstück – der Algorithmus, der die Relevanz bestimmt – ist schwerer zu testen. Und weil das so ist, wird die Optimierung der Suchalgorithmen oft durch die Beobachtung von Einzelfällen gesteuert. Was wiederum dazu führt, dass man zwar diese vereinzelten Problemfälle löst, sich aber die Suchqualität insgesamt verschlechtern kann. Die Frage ist also: Wie können wir die Effekte von Änderungen am Suchalgorithmus quantitativ über Tests nachweisen? Darum drehen sich die folgenden Gedanken und Prozessvorschläge:

1. Aufsetzen der Such-Konfigurationen

Die Voraussetzung für quantitative A/B-Tests am Suchalgorithmus ist, dass man unterschiedliche Suchkonfigurationen parallel anlegen kann. Diese Konfigurationen heißen bei uns Suchtemplates. Das sollte auf vielen gängigen Suchplattformen möglich sein (zumindest bei unserer Solr-Instanz, bei SDL und auch bei der Google Search Appliance). In diesen einzelnen Such-Templates konfigurieren wir, wie sich die Suche im Original und der Variante verhalten soll: Das kann unter. Matchingmethoden beinhalten, unterschiedliche Boostingwerte, Personalisierung, etc.

Wir arbeiten aktuell mit drei Suchtemplates:

Live-Template enthält die Konfiguration, die aktuell live ist.

Test-Template enthält die Konfiguration für die Variante, die im Rahmen von A/B-Tests getestet werden soll.

Experimente-Template enthält die Konfiguration, um Änderungen am Algorithmus explorativ ausprobieren und qualitativ einschätzen zu können (dazu später mehr).

Aufstellung der Such-Templates

Welche Rolle die Templates dann genau für die Umsetzung des A/B-Tests spielen wird unter 4. genauer erklärt.

2. Zielgerichtetes Experimentieren

Noch ein paar Sätze zum Thema „explorative Experimente“: Damit meine ich natürlich nicht, dass man einfach wild am Algorithmus herumspielt, um zu sehen, was passiert. Es geht vielmehr darum, dass man sehr konkrete Problemstellungen hat, für die man die passenden Lösungen finden muss. Wir explorieren als mit einem klaren Ziel vor Augen.

Bewährt hat sich dabei ein Ansatz, den wir mit foryouandyourcustomers entwickelt haben. Dabei haben wir die Suchanfragen aus den letzten 6 Monaten analysiert und versucht Muster zu identifizieren. Für diese Suchmuster haben wir 5-10 konkrete Suchanfragen ausgewählt und erhalten damit ein repräsentatives Suchanfrage-Set, mit dem wir den Großteil der Suchanfragen und damit des Suchverhaltens abbilden. Dieses Set wird anschließend qualitativ bewertet – wie gut sind also die Ergebnisse für jede konkrete Suchanfrage aus dem repräsentativen Set. Abschließend ergänzen wir das Set noch durch die 50 Top-Suchanfragen und erhalten so eine Liste mit ca. 100 Suchbegriffen.

Dieses Set wird in jeder Iteration der Suchoptimierung für eine qualitative Einschätzung zurate gezogen. Haben wir also bei der initialen Bewertung des Sets herausgefunden, dass die Qualität bei einem bestimmten Suchmuster nicht sehr gut ist, überlegen wir uns mit welchen Änderungen am Algorithmus wir darauf antworten können. Funktioniert beispielsweise unsere ISBN-Suche super, wenn die Nutzer einfach die ISBN eingeben und eher schlecht wenn sie davor noch den Begriff „ISBN“ eingeben, dann bietet sich an den Begriff „ISBN“ in die Stoppwortliste aufzunehmen – dazu ist freilich kein A/B-Test nötig, soll aber auch nur zeigen, wie man sich den Problemen nähert. Nach jedem Umlauf bekommen wir also einen Vergleich, in welchen Mustern, bei welchen repräsentativen Begriffen, sich die subjektive Qualität verbessert und verschlechtert hat.

Wichtig dabei: Die durchgeführten Änderungen müssen natürlich dokumentiert werden, um auch nachvollziehen zu können, welche Änderungen zu welchen Ergebnissen geführt haben.

Ist das Ergebnis zufriedenstellend wird die Konfiguration des Experimente-Templates auf das Test-Template übertragen.

3. Definition von KPIs für die Suchqualität

Einer der entscheidenden Punkte ist die richtige Auswahl der KPIs für die Messung der Suchqualität. Hier kann man sich natürlich nur annähern. Bewährt haben sich folgende Metriken:

  • Anteil der Search Refinements, also der direkten Folgesuchen als Hinweis darauf, dass die Qualität der Suchanfragen zunächst nicht gut war.
  • Anteil der Search Exits, also der Ausstiege nach der Suche als sehr deutlicher Hinweis darauf, dass die Suchergebnisse nicht gut waren. Allerdings ist der Wert mit Vorsicht zu genießen. Wir haben beispielsweise sehr konkrete Hinweise darauf, dass viele Nutzer die Suche zur reinen Recherche verwenden. Ähnlich wie bei Absprungraten und Ausstiegsraten bietet sich hier die Bewertung mit mehr als nur einer Metrik an.
  • Klicks auf Suchergebnisse, mit der Prämisse, dass Nutzer nur dann auf Suchergebnisse klicken, wenn die Suchergebnisse zu ihren Erwartungen passen.
  • Wer in Google Analytics die Suchergebnisseiten als Produktlisten trackt, bekommt hier wunderbare Auswertungsmöglichkeiten über Klick- und Conversionsraten. Hier könnte beispielsweise die Klickrate in den Suchergebnissen als KPI herangezogen werden.

Screenshot für Produktlistenleistung der internen Suche

Zusätzlich könnten natürlich weitere Datenquellen hinzugezogen werden, wie beispielsweise ein Click-Tracking wie es von ClickTale angeboten wird oder eine Ergänzung um qualitative Daten durch Nutzerumfragen, die man mit „minimalinvasiven“ Tools wie Qualaroo durchführt.

4. Aufsetzen des A/B-Tests

Wie bekommen wir es jetzt hin, dass die Nutzer auch die beiden Alogrithmusvarianten zu sehen bekommen?

Die Voraussetzung dafür ist, dass wir zwei unterschiedliche Such-Seiten aufbauen, auf denen die beiden unterschiedlichen Suchkonfigurationen (unser Suchtemplates) zum Einsatz kommen. Das A/B-Test-Tool (in unserem Falle Optimizely) übernimmt die Aufteilung des Traffics auf die beiden Varianten und teilweise auch das Tracking der Ergebnisse. Unser Setup sieht konkret so aus:

Schematische Darstellung des A/B-Test Setups

Schematische Darstellung des A/B-Test Setups zur Optimierung der Suche

Wir richten also ein einfaches Redirect-Experiment ein, d.h. dass die Original-Suchseite und die Variante der Suchseite auf zwei unterschiedlichen URLs zu finden sind. Das Original könnte bsp. unter http://www.beispiel.de/search.php?q=test zu finden sein und die Variante unter http://www.beispiel.de/search_b.php?q=test. Jetzt kommt der entscheidende Punkt: search.php verwendet die aktuellen Live-Einstellungen der Suche (Suchtemplate „Live“) und search_b.php verwendet die Test-Einstellungen der Suche (Suchtemplate „Test“). Dementsprechend bekommen die Nutzer die auf search.php landen andere Ergebnisse als die Nutzer, die vom Test-Tool auf search_b.php geleitet werden.

Dann heißt es warten, bis wir signifikante Ergebnisse bekommen.

5. Konsequenzen aus den Ergebnissen

Die Test münden in drei unterschiedliche Szenarien:

In Szenario 1 sehen wir, dass die Testversion besser funktioniert als das Original (Sektkorken knallen!). In dem Fall werden die Einstellungen des Test-Templates auf das Live-Template übertragen, so dass 100% der Nutzer in den Genuss der besseren Suche kommen. Nach diesem Schritt sind alle drei Template (Live, Test, Experiment) wieder auf demselben Stand.

Such-Template Migration bei positiven Test-Ergebnissen

In Szenario 2 funktioniert die Variante schlechter als das Original. In dem Fall werden die Einstellungen des Live-Templates auf das Test- und das Experiment-Template zurück übertragen. Damit sind alle Templates wieder auf demselben Stand.

Such-Template Migration bei negativen Test-Ergebnissen

In Szenario 3 gibt es keine statistisch signifikanten Ergebnisse. Wir verfahren mit den Templates wie in Szenario 2.

… und dann beginnt der Prozess wieder von vorne!

Noch ein letzter wichtiger Punkt zum Abschluss: Für die Dauer der Tests sind Arbeiten an allen Templates nicht möglich. Nur so ist sichergestellt, dass die Templates nach der Migration wieder alle auf demselben Stand sind.

 

Damit haben wir bislang gute Erfolge erzielt. Wie testet ihr die Qualität der Suche? Wird das überhaupt getestet? Seht ihr in dem vorgeschlagenen Prozess noch Schwächen? Feedback in jeder Form ist willkommen, solange es konstruktiv ist.

  • OCP

    Hi Franz, nice post. Have you ever weighed CrazyEgg up against any other tools on the market? Let’s say for example with Decibel Insight, Hotjar, ClickTale? If so, how have you found the level of usability on each?

    • Hi Owain,
      thanks for your feedback.
      We haven’t worked with CrazyEgg yet. The heatmap you see is actually generated by our web analytics tool econda. From what I have learnt from several sales meetings (alas!) ClickTale provides a really comprehensive suite that also offers form tracking and mouse movement recording and what not. So CrazyEgg might be a more economic investment if you’re only interested in clicktracking. But I haven’t worked with either tool on a regular basis.

  • OCP

    Interesting to know, each have their own benefits and we used most of these tools before we launched our own tool – Decibel Insight, as we noticed that there was a clear gap in the market for more comprehensive behavioural analytics. If you do find yourself with some time to test our tool (through a free trial for a number of weeks) on one of your sites; it would be great to hear your feedback as to how your experience was. If interested, please drop me an email and we can pass across the code for you. We will leave it completely in your hands thereafter if you wanted to look at paying for a more comprehensive account.

  • Top!