Personalisierung der E-Commerce-Suche: Integration von Kaufverlauf und Nutzerkohorten

Die Teile 1 bis 5 dieser Serie beschreiben eine gesteuerte Steuerungsebene, die die Absicht klassifiziert, Einschränkungen durchsetzt, Richtlinienkonflikte löst und zur entsprechenden Abrufstrategie weiterleitet, alles bevor der Produktkatalog abgefragt wird. Jeder bisher beschriebene Mechanismus behandelt alle Käufer identisch. Eine Suche nach „Schokolade“ liefert immer das gleiche Ergebnis, egal ob der Käufer Veganer ist, ein Elternteil, der für den Geburtstag eines Kindes einkauft, oder ein Halal-Konsument.

Dieser Beitrag stellt zwei Personalisierungsmechanismen vor, die die gesteuerte Steuerungsebene erweitern, ohne deren Architektur zu verändern. Beide Mechanismen wirken multiplikativ mit der Governance-Ebene aus den Teilen 1 bis 5 zusammen: Richtlinien werden weiterhin angewendet, Einschränkungen werden weiterhin durchgesetzt, Konflikte werden weiterhin gelöst und Personalisierungssignale werden in dieselbe gesteuerte Abfrage integriert, wodurch sichergestellt wird, dass die von Elasticsearch zurückgegebenen Ergebnisse bereits personalisiert sind.

Der erste Mechanismus fördert Produkte, die der einzelne Käufer zuvor gekauft hat. Der zweite Mechanismus aktiviert kohortenspezifische Richtlinien, die auf dem Profil des Käufers basieren. Gemeinsam zeigen sie, dass Personalisierung kein separates System ist, das an die Suche angehängt oder als Nachbearbeitung der Suchergebnisse angewendet wird; sie ist vielmehr eine natürliche Erweiterung der richtlinienbasierten Steuerungsebene.

Einen detaillierten Einblick in die mathematischen Grundlagen der in diesem Beitrag verwendeten Personalisierungstechniken finden Sie unter Personalisierung der Suche in Elasticsearch ohne ML-Nachbearbeitung sowie unter Kohortenorientiertes Ranking in Elasticsearch.

Um in einer Live-Demonstration zu sehen, wie sich der Kaufverlauf nutzen lässt, um die Suchergebnisse für wiederkehrende Kunden zu verbessern, sehen Sie sich das Video an: Nachvollziehbare Personalisierung: Verbesserung der Suche anhand des Kaufverlaufs.

Optimierung des individuellen Kaufverlaufs

Die einfachste Form der Personalisierung ist auch eine der effektivsten: Wenn ein Käufer ein Produkt bereits gekauft hat, sollte es hervorgehoben werden, wenn er nach etwas Ähnlichem sucht. Ein Kunde, der regelmäßig eine bestimmte Marke von Schokoladenkeksen kauft, sollte diese Kekse bei der Suche nach „Keksen“ weiter oben in der Rangliste sehen, nicht, weil ein Modell eine Präferenz vorhergesagt hat, sondern weil es direkte Verhaltenshinweise dafür gibt.

So funktionierts

Wenn eine Suchanfrage eine Benutzerkennung enthält, wie es beispielsweise bei einem Nutzer mit einer offenen Sitzung der Fall wäre, führt die Steuerungsebene zwei Elasticsearch-Abfragen parallel mithilfe eines Thread-Pools aus:

1. Die Perkolator-Abfrage gegen den Richtlinienindex (die gleiche Governance-Abfrage, die in den Teilen 3 und 4 beschrieben wurde).
2. Eine Abfrage zum Kaufverlauf anhand eines user_purchases-Index, die nach term(user_id) auf den bestimmten Nutzer gefiltert wurde und dann die aktuelle Suchzeichenfolge mit den Produkttiteln dieses Nutzers abgleicht.

Diese Prozesse laufen parallel (keiner wartet auf den anderen), sodass die Personalisierungsabfrage keine nennenswerte Latenz in der Governance-Pipeline verursacht.

Die Kaufverlauf-Abfrage verwendet die Textanalyse von Elasticsearch (Stemming, Tokenisierung), um die aktuelle Suchzeichenfolge mit gespeicherten Produkttiteln abzugleichen. Das bedeutet, dass eine Suche nach „Cookies“ durch eine Standard-Textanalyse einen früheren Kauf von „Brownie-Cookies“ findet, ohne dass eine exakte Übereinstimmung der Zeichenketten erforderlich ist.

Berechnung von Boost-Gewichten

Nicht alle früheren Käufe verdienen die gleiche Aufwertung. Das Gewicht berücksichtigt zwei intuitive Faktoren: wie oft der Kunde das Produkt gekauft hat und wie aktuell es ist. Ein Produkt, das letzte Woche 15 Mal gekauft wurde, ist ein viel stärkeres Signal als ein Produkt, das vor sechs Monaten einmal gekauft wurde. Bei der Gewichtung wird die Häufigkeit logarithmisch skaliert (damit ein einzelner Artikel, der besonders häufig gekauft wurde, nicht alle anderen Artikel überlagert) und die Aktualität exponentiell abgewichtet (damit ältere Käufe mit der Zeit auf natürliche Weise an Bedeutung verlieren).

Die mathematischen Details zur Boost-Formel finden Sie unter Personalisierung der Suche in Elasticsearch ohne ML-Nachbearbeitung.

Wie es zu einer Abfrage wird

Die Kaufverlaufs-Boosts werden als oberste Bewertungsschicht in die Abfrage integriert und umfassen die Filter und Boosts der Governance-Richtlinien aus Teil 3 und 4 sowie alle Geschäftssignal-Boosts wie Marge und Beliebtheit (die wir in Teil 7 näher betrachten werden). Das bedeutet, dass ein Produkt, das aufgrund einer Governance-Richtlinie entfernt wurde, nicht aufgrund eines positiven Kaufverlaufs wieder angezeigt wird. Die Governance steuert den Ergebnissatz; die Personalisierung passt die Reihenfolge innerhalb dieses Satzes an. Produkte ohne Kaufverlauf werden nicht benachteiligt. Das durch die Governance festgelegte Ranking bleibt erhalten, allerdings werden Produkte mit relevantem Kaufverlauf – bei sonst gleichen Bedingungen – darüber platziert.

Warum Elasticsearch bei jeder Suche abfragen?

Der Kaufverlauf wird bei jeder Suche aus Elasticsearch abgefragt, anstatt in der Anwendungsebene zwischengespeichert zu werden. Dies ist eine bewusste Designentscheidung. Da die Abfrage die aktuelle Suchzeichenfolge mit den Produkttiteln mithilfe der Textanalyse-Pipeline von Elasticsearch abgleicht, profitiert das System von der gleichen Stemming-, Tokenisierungs- und Sprachverarbeitungsfunktion, die auch der Produktsuche selbst zugrunde liegt. Eine zwischengespeicherte In-Memory-Suche würde entweder eine erneute Implementierung dieser Analyse oder die Akzeptanz einer gröberen Übereinstimmung erfordern.

Um zu verstehen, warum diese Reihenfolge wichtig ist, betrachten wir einen Kunden, der zuvor Orangensaft gekauft hat und nun nach „Orangen“ sucht. Die Kaufverlauf-Abfrage gleicht „Orangensaft“ mit dem Suchbegriff „Orangen“ durch Textanalyse ab und berechnet einen Boost für dieses Produkt. Die Governance-Ebene hat jedoch bereits „Orangen“ auf die Kategorie „Obst und Gemüse“ beschränkt und Orangensaft vollständig herausgefiltert. Der Kaufverlauf-Boost für Orangensaft ist zwar in der Abfrage vorhanden, hat aber keine Auswirkung, da es im gesteuerten Ergebnissatz kein passendes Dokument gibt, auf das er angewendet werden könnte. Dem Kunden werden frische Orangen angezeigt, sortiert nach Relevanz und Personalisierung. Die Governance-Orientierungshilfen greifen.

Die Leistungskosten sind minimal: Der Kaufverlaufsindex ist klein (der Kaufverlauf eines Nutzers umfasst typischerweise Dutzende bis Hunderte von Dokumenten, nicht Millionen), und die Abfrage wird parallel zur Perkolator-Suche ausgeführt, sodass sie den kritischen Pfad nicht verlängert.

Beispielanfrage für „Quellwasser“ ohne Nutzerverlauf

Wenn ein nicht angemeldeter Nutzer oder ein Nutzer, der noch nie „Quellwasser“ gekauft hat, eine Suche durchführt, werden ihm möglicherweise Ergebnisse angezeigt, die in etwa wie folgt aussehen:

Beispielhafte Kaufhistorie eines Nutzers

Eine Nutzerin namens Carol hingegen hat einen Einkaufsverlauf, die folgende Produkte enthält:

Beispielsuche nach „Quellwasser“ mit dem obigen Kaufverlauf

Wenn Carol nach „Quellwasser“ sucht, werden ihr personalisierte Ergebnisse angezeigt, die ihre bisherigen Käufe widerspiegeln. Ein Blick auf den Kaufverlauf oben zeigt, dass sie das „kohlensäurehaltige Quellwasser“ (die grüne Flasche) etwa 40 Mal gekauft hat, zuletzt vor zwei Tagen. Wenn sie nach „Quellwasser“ sucht, wird dieses Produkt hervorgehoben, da wir wissen, dass sie es mag. Beachten Sie, dass in den nicht personalisierten Ergebnissen stattdessen das Rubicon-Quellwasser an erster Stelle stand.

Kohortenorientierte Richtlinienaktivierung

Der individuelle Kaufverlauf eignet sich gut für wiederkehrende Kunden mit etabliertem Verhalten. Viele Käufer sind jedoch Neukunden, anonym oder verhalten sich anders als sonst. Für diese Kunden bietet die Zugehörigkeit zu einer Kohorte eine andere Art der Personalisierung, die darauf basiert, wer der Kunde ist, und nicht darauf, wie er sich verhalten hat.

Ein veganer Kunde, der nach „Schokolade“ sucht, sollte vegane Schokolade weiter oben in den Suchergebnissen sehen. Ein Halal-bewusster Kunde, der nach „Snacks“ sucht, sollte Halal-zertifizierte Produkte gut sichtbar angezeigt bekommen. Ein gesundheitsbewusster Käufer, der nach „Joghurt“ sucht, sollte probiotische Optionen bevorzugt angezeigt bekommen.

Kohorten als Richtlinien, nicht als Produkt-Tags

Produkte verfügen bereits über ihre normalen Attribute, einschließlich Felder wie dietary_restrictions: ["vegan"] oder dietary_restrictions: ["halal"]. Die Frage ist, wo die Logik liegt, die die Kohorte eines Kunden mit diesen Produktattributen verbindet.

Der naive Ansatz wäre, diese Zuordnung in der Anwendungsebene oder in der Suchvorlage fest zu programmieren: Wenn der Nutzer Veganer ist, wird ein Boost für dietary_restrictions: "vegan" hinzugefügt. Aber es handelt sich hier um dasselbe „Spaghetti-Code“-Chaos auf Anwendungsebene, das in Teil 1 beschrieben wurde, und es verursacht dieselben operativen Reibungsverluste: Das Hinzufügen einer neuen Kohorte oder die Änderung der Definition einer Kohorte erfordert eine Codeänderung.

Die gesteuerte Steuerungsebene behält die Kohortenlogik stattdessen in der Richtlinien-Engine bei. Eine Kohortenrichtlinie verbindet zwei Aspekte miteinander: die Zugehörigkeit eines Kunden zu einer Kohorte (zum Beispiel „vegan“) und ein Produktmerkmal (zum Beispiel dietary_restrictions: “vegan”). Die Richtlinie legt Folgendes fest: Wenn ein Käufer aus der veganen Zielgruppe eine Suche durchführt, sollen Produkte bevorzugt angezeigt werden, bei denen dietary_restrictions den Begriff „vegan“ enthält.

Da die Kohortenlogik in der Richtlinien-Engine und nicht im Anwendungscode enthalten ist, bedeutet das Folgendes:

• Eine neue Kohorte kann durch die Erstellung einer neuen Richtlinie hinzugefügt werden; eine Produkt-Neuindizierung ist nicht erforderlich.
• Kohorten-Richtlinien verwenden die vollständige Regel-Engine: Sie können Filter hinzufügen, Soft-Boosts anwenden, Synonyme erweitern, Abrufstrategien ändern oder jede andere Aktion einer Richtlinie vornehmen.
• Das Kohortenverhalten wird über dieselbe Admin-Benutzeroberfläche verwaltet wie alle anderen Richtlinien: Ein Händler kann Kohortenrichtlinien über den unter Teil 2 beschriebenen Workflow „Erstellen → Testen → Veröffentlichen“ erstellen, testen und veröffentlichen.

Beispiel einer veganen Kohortenrichtlinie

Ein Händler erstellt eine Kohortenrichtlinie mit folgenden Merkmalen:

• Kohorten: ["vegan"].
• Matchkriterien: Entspricht jeder Abfrage (oder einer bestimmten Produktkategorie).

Aktion: Soft-Boost auf dietary_restrictions: "vegan" mit einem Boost-Gewicht von 2.

So funktioniert die Kohortenaktivierung

Jedes Richtliniendokument hat ein cohorts-Feld. Bei allgemeinen Richtlinien, die für alle Käufer unabhängig von der Kohorte gelten, kann dieses Feld leer gelassen werden; diesen wird intern von der Steuerungsebene der Wert "_all" zugewiesen. Kohortenspezifische Richtlinien speichern die Namen ihrer Zielkohorte, wie zum Beispiel ["vegan", "kosher", “sweet_tooth”].

Wenn eine Suchanfrage ein Nutzerprofil enthält, erstellt die Steuerungsebene einen einfachen terms-Filter für die Perkolator-Abfrage:

Dieser einzelne Filter umfasst alle allgemeinen Richtlinien sowie die kohortenspezifischen Richtlinien des Nutzers. Der _all-Sentinel ermöglicht einen übersichtlichen Einbeziehungsfilter: Es sind keine must_not- oder exists-Abfragen erforderlich, um den Fall zu behandeln, in dem eine Richtlinie keine Kohortenbeschränkung enthält.

Der Perkolator wertet dann wie gewohnt die Richtlinienübereinstimmungen aus. Der einzige Unterschied besteht darin, dass die Auswahl an Richtlinien auf diejenigen beschränkt wurde, die für die Zielgruppe dieses Käufers relevant sind. Alle nachfolgenden Schritte (kaskadierende Transformationen, Konfliktlösung auf Feldebene, Nachverfolgung verwendeter Phrasen) funktionieren genauso wie der in den Teilen 3 und 4 beschriebene nicht personalisierte Ablauf.

Ergebnisse für nicht-vegane (standardmäßige) Nutzer bei der Suche nach „Schokolade“

Wenn ein nicht-veganer Nutzer nach Schokolade sucht, wird kein veganer Kohorten-Boost auf seine Ergebnisse angewendet. Oft tauchten in den Top-Treffern nicht-vegane Schokoladen wie folgt auf:

Ergebnisse der veganen Kohortenrichtlinie bei der Suche nach „Schokolade“

Wenn ein Käufer aus der veganen Kohorte nach „Schokolade“ sucht, wird diese Richtlinie in die Liste der in Frage kommenden Ergebnisse aufgenommen. Die Übereinstimmung ist gegeben, und die Steuerungsebene gewährt vegan-zertifizierten Schokoladenprodukten einen Soft-Boost. Der Boost wirkt sich multiplikativ aus: Vegane Schokoladen erhalten eine höhere Bewertung, doch nicht-vegane Schokoladen werden nicht vollständig ausgeschlossen, da der oben genannte Filter als Soft-Boost festgelegt ist, den wir in Teil 3 dieser Serie ausführlich beschrieben haben.

Wenn der Käufer jedoch ausdrücklich nach „Hershey-Milchschokolade“ sucht, greift der Vegan-Boost zwar weiterhin, wird jedoch möglicherweise durch die stärkere Textrelevanz der Hershey-Milchschokoladenprodukte überlagert.

Ein Käufer außerhalb der veganen Zielgruppe, der nach der gleichen Abfrage sucht, sieht die Richtlinie für die „vegane Zielgruppe“ nie; sie ist nicht in seiner Auswahl enthalten. Die Governance-Ebene ist identisch, nur der aktive Richtliniensatz unterscheidet sich.

Kohorten mit Kaufhistorie

Ein veganer Kunde mit umfangreichem Kaufverlauf erhält sowohl eine speziell auf seine Kohorte zugeschnittene Richtlinienaktivierung als auch Kaufverlauf-Boosts. Bei neuen oder anonymen Kunden ermöglicht bereits die implizite Zugehörigkeit zu einer Kohorte eine aussagekräftige Personalisierung, ohne dass Verhaltensdaten erforderlich sind (wenn ein anonymer Nutzer beispielsweise ausschließlich nach veganen Produkten gesucht hat, stufen wir ihn als Mitglied der veganen Kohorte ein). Ein Kunde, der sich bei der Kontoeröffnung als Halal-bewusst identifiziert, erhält bei seiner ersten Suche sofort auf Halal zugeschnittene Ergebnisse.

Wie sich Personalisierungsebenen zusammensetzen

Die Verschachtelungsreihenfolge der function_score-Ebenen ist entscheidend. Vom Innersten zum Äußersten:

1. Basisabfrage: Das Schlüsselwort oder die semantische Übereinstimmung mit benannten Abfragen (fulltext_match, title_phrase_match).
2. Ebene der Governance-Richtlinie: Feste Filter als bool.filter-Klauseln, Soft-Boosts als function_score-Funktionen (Teile 3 und 4).
3. Business-Signal-Steigerungen: Margen- und Popularitätssteigerung (die wir in Teil 7 erkunden werden).
4. Kaufverlauf-Boosts: Die äußerste function_score-Ebene.

Diese Reihenfolge stellt sicher, dass die Governance die Ergebnisliste (was angezeigt wird) steuert, geschäftliche Signale das Ranking innerhalb dieser Liste anpassen (was aus Sicht des Händlers zuerst angezeigt wird) und den Kaufverlauf das Ranking auf der Grundlage des individuellen Verhaltens weiter anpasst (was aus Sicht des Käufers zuerst angezeigt wird). Jede Ebene überlagert die vorherige auf multiplikative Weise, sodass sich die Effekte verstärken, anstatt sich zu widersprechen.

Was das operativ bedeutet

Durch die Personalisierung über die geregelte Steuerungsebene bleiben alle in Teil 1 und 2 beschriebenen betrieblichen Eigenschaften erhalten:

• Änderungen ohne Bereitstellung. Kohorten-Richtlinien werden über die Admin-Benutzeroberfläche erstellt, getestet und aktiviert. Das Hinzufügen einer neuen Ernährungkohorte oder das Anpassen einer Gewichtung erfordert weder Codeänderungen noch die Beteiligung der Entwicklungsabteilung.
• Prüfbarkeit. Jede Kohortenrichtlinie ist ein eigenständiges, versioniertes Dokument. Wenn ein Händler fragt: „Warum ist das Ranking für vegane Produkte für diesen Nutzer höher?“, ist die Antwort eine spezifische Richtlinie mit einer spezifischen Priorität, die im Fehlerbehebungs-Panel zusammen mit allen anderen Richtlinien angezeigt wird, die für diese Abfrage ausgelöst wurden.
• Konfliktlösung. Die Richtlinien für Kohorten unterliegen der gleichen Konfliktlösung pro Feld, die in Teil 3 beschrieben wurde. Wenn die Kategorie-Boost-Funktion einer Kohortenrichtlinie mit der Kategorie-Überschreibung einer Kampagnenrichtlinie in Konflikt gerät, wird der Konflikt deterministisch durch denselben Prioritäts- und Strategie-Framework gelöst; eine Sonderbehandlung ist nicht erforderlich.
• Messbarkeit. Da Kohorten-Richtlinien eigenständig und einzeln aktivierbar sind, lassen sich ihre Auswirkungen auf die Konversions-, Klick- und Warenkorb-Raten ebenso wie bei jeder anderen Richtlinie im System unabhängig voneinander messen.

Wie geht es weiter in dieser Serie?

Im nächsten Beitrag wird eine weitere Dimension der gesteuerten Kontrollebene untersucht: wie Margen und Popularitätssteigerungen pro Anfrage durch Richtlinien angepasst werden können, wodurch die ökonomische Optimierung zu einer Governance-Entscheidung und nicht zu einer statischen Konfiguration wird.

Siehe Teil 7: Abfragegesteuerte wirtschaftliche Optimierung: Margen- und Popularitätssteigerung pro Abfrage

Setzen Sie die reglementierte E-Commerce-Suche in die Praxis um

Die in diesem Beitrag beschriebenen Personalisierungsmuster (Boosting des individuellen Kaufverlaufs und kohortenbasierte Richtlinienaktivierung) wurden von Elastic Services Engineering als Teil unseres wiederholbaren E-Commerce-Suchbeschleunigers konzipiert und entwickelt. Beide Mechanismen sind in die in der gesamten Reihe beschriebene verwaltete Steuerungsebenen-Architektur integriert. Wenden Sie sich an Elastic Professional Services.

Nehmen Sie an der Diskussion teil

Haben Sie Fragen zur Suchsteuerung, zu Abrufstrategien oder zur Sucharchitektur im E-Commerce? Nehmen Sie an der Diskussion der Elastic-Community teil.