Similar Search statt Pagination: Was am Ende einer Suche kommt

Seite drei einer Suche, niemand klickt

Viele Shop-Betreiber fragen sich: Was soll am Ende einer Trefferliste kommen, wenn die Pagination die Kunden verliert? Statt weiterer Pagination-Seiten zeigt Similar Search semantisch ähnliche Produkte über Embeddings, genau dort, wo Kunden sonst abspringen. Wie dieser Übergang aussieht, zeigt ein typischer Abend im Shop.

Ein Mittwoch um 20:47 Uhr, ein DACH-Online-Shop für Outdoor-Ausrüstung. Ein Kunde sucht "Regenjacke wasserdicht Herren", die Treffer-Liste zeigt 412 Produkte, der Kunde scrollt durch die ersten zehn, klickt auf zwei, geht zurück zur Trefferliste, scrollt weiter auf Seite zwei, klickt auf "Seite 3", findet dort drei weitere Jacken, kein Treffer überzeugt. Am Ende der dritten Seite zeigt die Suche eine Pagination-Leiste "Seite 1, 2, 3, 4 ... 28". Der Kunde sieht 25 weitere Seiten Pagination, schließt den Tab und sucht bei der Konkurrenz.

Die Pagination-Endpunkte sind eine der unterschätztesten Verlust-Stellen im E-Commerce. Eine Studie zum Scroll-Verhalten in Such-Ergebnissen zeigt, dass auf Seite drei der Treffer-Liste die Click-Through-Rate unter ein Prozent fällt. Auf Seite vier ist sie statistisch ein Rauschen. Was der Standard-Shop in diesem Moment tut, ist mehr unmatched Treffer anzubieten, also Produkte, die der Kunde mit hoher Wahrscheinlichkeit nicht haben will, weil das Ranking-System sie nicht in die Top-20 sortiert hat.

Die Alternative ist Similar Search. Statt am Ende der Liste mehr Pagination anzuzeigen, fragt das System aktiv: welche Produkte sind den bisherigen Treffern semantisch ähnlich, ohne dass die exakten Worte der Anfrage matchen? Die Antwort kommt aus einem Embedding-Modell, das jedes Produkt als Vektor im hochdimensionalen Raum repräsentiert. Zwei Produkte sind ähnlich, wenn ihre Vektoren nah beieinander liegen. Das hat nichts mit Marketing-Regeln zu tun, nichts mit "Kunden kauften auch", nichts mit kuratierten Empfehlungs-Listen. Es ist eine rein mathematische Ähnlichkeits-Berechnung über das gesamte Sortiment.

Dieser Artikel beschreibt, was Similar Search im E-Commerce konkret leistet. Welcher ähnliche produkte algorithmus dahinter steht, wie sich die Mechanik vom klassischen regelbasierten Recommendation-Engine unterscheidet, warum die Embedding-Logik cookieless funktioniert, an welchen Stellen der Customer-Journey die Similar-Search-Widgets greifen und wie ein Data Lake die Trainings-Grundlage für die Embeddings liefert. Am Ende stehen die konkreten Use Cases, die Tradeoffs und die Schritte zur Einführung in einem laufenden Shop.

Pagination ist eine Notlösung, keine Antwort

Warum gibt es Pagination überhaupt?

Die historische Pagination hat einen einfachen Grund. Ein Shop kann nicht alle 412 Treffer einer Anfrage auf einer Seite zeigen, weil die Ladezeit, die Bildschirm-Tiefe und die kognitive Last des Kunden das nicht hergeben. Die Pagination teilt die Treffer in Häppchen, typisch 20 pro Seite, und überlässt dem Kunden die Routing-Entscheidung: weiterscrollen oder aufgeben.

Diese Annahme stammt aus einer Zeit, in der die Treffer-Sortierung deterministisch und vorhersehbar war. Wenn das System nach Verkaufszahlen sortiert, ist auf Seite eins der Bestseller, auf Seite drei der mittelmäßig nachgefragte Artikel, auf Seite zehn der Restposten. Der Kunde lernt diese Logik und scrollt nach Bedarf. Wenn die Treffer-Sortierung aber stochastisch wird, etwa weil mehrere Ranking-Signale wechselnd dominieren, wird die Pagination zur Glücks-Sache. Auf Seite drei kann der perfekte Treffer liegen, weil ein Signal-Mix den Bestseller verdrängt hat. Der Kunde weiß das nicht und gibt vorher auf.

Das Endless-Scroll-Pattern, das in Social Networks erfolgreich ist, scheitert im E-Commerce regelmäßig an der gleichen Wand. Endless Scroll lädt einfach mehr Treffer nach, ohne die zugrundeliegende Frage zu stellen, ob diese Treffer für den Kunden überhaupt sinnvoll sind. Wer auf Seite drei der Treffer-Liste keinen passenden Treffer findet, ist mit Seite vier nicht besser bedient. Im Gegenteil, die Treffer werden im Schnitt schlechter, weil das Ranking sie aus gutem Grund nach hinten sortiert hat.

Die strukturelle Antwort ist nicht, die Pagination zu polieren oder unendlich weiterzuladen. Die strukturelle Antwort ist, am Übergang zwischen "noch hochrelevante Treffer" und "Reste der Trefferliste" das Verhalten zu wechseln. Dort, wo der Kunde sonst aussteigt, muss das System aktiv Ähnlichkeits-Vorschläge unterbreiten, die aus einer anderen Logik kommen als das Such-Ranking selbst. Das ist die Aufgabe der Similar Search.

Was Similar Search ist und was sie nicht ist

Was ist Similar Search eigentlich genau?

Similar Search ist eine semantische Ähnlichkeits-Suche zwischen Produkten, die unabhängig von der ursprünglichen Such-Anfrage operiert. Das System nimmt ein oder mehrere Anker-Produkte (etwa die Top-Treffer der laufenden Suche oder das aktuell angeschaute Produkt auf der Produktdetailseite) und sucht im Index nach Produkten, die diesen Anker-Produkten in der Vektor-Repräsentation ähnlich sind. Die Mechanik nutzt typisch eine kombinierte Embedding-Logik aus drei Quellen.

Erstens, Bild-Embeddings. Ein neuronales Bild-Modell wie CLIP oder ein ähnliches Vision-Encoder-Modell wandelt jedes Produkt-Bild in einen Vektor. Zwei Produkte, deren Bilder ähnlich aussehen, haben nah beieinander liegende Vektoren. Eine schwarze Lauf-Jacke mit Reflektor-Streifen findet andere schwarze Lauf-Jacken mit Reflektor-Streifen, unabhängig davon, ob die Hersteller und Produktnamen in der Beschreibung übereinstimmen.

Zweitens, Text-Embeddings. Ein Sprach-Modell wandelt Produktname, Beschreibung, Kategorie und Attribute in einen Text-Vektor. Zwei Produkte mit semantisch ähnlichen Beschreibungen ("wasserdichte Outdoor-Jacke für Bergwanderungen" und "atmungsaktive Hard-Shell für Hochtouren") landen nah beieinander, auch wenn die exakten Wörter unterschiedlich sind. Das ist die Schicht, die Synonyme und semantische Verwandtschaft auflöst.

Drittens, Behavior-Embeddings. Eine Co-Occurrence-Statistik aus den Klick- und Kauf-Mustern der Cohort liefert eine dritte Vektor-Schicht. Zwei Produkte, die in den gleichen Klick-Sessions oder Warenkorb-Kombinationen vorkommen, sind verhaltensbasiert ähnlich, auch wenn sie visuell und textuell unterschiedlich sind. Eine Stirnlampe und ein Karabiner-Haken haben nichts visuell Gemeinsames, aber wenn sie häufig in den gleichen Touren-Sets gekauft werden, sind sie behavior-ähnlich.

Die saubere Architektur kombiniert alle drei Embedding-Schichten zu einem gewichteten Gesamt-Vektor pro Produkt. Die Gewichte werden pro Sortimentstyp konfiguriert. Bei Mode dominiert das Bild-Embedding (visuelle Ähnlichkeit ist die wichtigste Kauf-Signalquelle), bei B2B-Industrie-Bedarf dominiert das Text-Embedding (Spezifikationen und technische Daten sind entscheidend), bei FMCG dominiert das Behavior-Embedding (Co-Kauf-Muster sind aussagekräftiger als Optik).

Was Similar Search nicht ist, ist genauso wichtig. Sie ist kein regelbasiertes Cross-Selling, das per Hand kuratierte Produkt-Sets anzeigt ("zu diesem Schuh empfehlen wir folgende Socken"). Sie ist keine Bestseller-Liste, die einfach die meist-verkauften Artikel anzeigt. Sie ist keine kategorie-basierte Filter-Logik, die Produkte aus der gleichen Sub-Kategorie zeigt. Sie ist eine vektor-basierte Ähnlichkeits-Berechnung, die das gesamte Sortiment im hochdimensionalen Raum vermisst und die nächsten Nachbarn pro Anker-Produkt zurückgibt.

Embeddings, Vektoren und die mathematische Schicht darunter

Was ist ein Embedding überhaupt?

Der Kern jedes Similar-Search-Systems ist die Embedding-Schicht. Ein Embedding ist eine Zahlen-Folge fester Länge, typisch 256 bis 1024 Dimensionen, die ein Objekt im semantischen Raum repräsentiert. Zwei Objekte sind ähnlich, wenn der Abstand zwischen ihren Embeddings klein ist, gemessen über Cosinus-Ähnlichkeit oder euklidischen Abstand.

Die Embedding-Modelle werden auf großen Datenmengen vortrainiert. Bild-Modelle wie CLIP wurden auf Hunderten Millionen Bild-Text-Paaren trainiert und können Produkt-Bilder ohne Shop-spezifische Nachschulung sinnvoll vektorisieren. Text-Modelle wie Sentence-BERT, MPNet oder neuere multilinguale Modelle vektorisieren Produkt-Beschreibungen, sodass deutsche und englische Beschreibungen im gleichen Vektor-Raum landen. Die Modelle laufen bei der Indexierung des Sortiments einmal pro Produkt und liefern den Embedding-Vektor, der dann im Such-Index gespeichert wird.

Die Nearest-Neighbor-Suche auf den Vektoren ist die andere Hälfte der Mechanik. Bei einem Sortiment mit 50.000 Produkten und 768-dimensionalen Embeddings würde eine Brute-Force-Suche (alle Distanzen berechnen, sortieren) pro Anfrage zwanzig Millisekunden brauchen, was an der Grenze des Akzeptablen liegt. Moderne Vektor-Indizes wie HNSW (Hierarchical Navigable Small World) oder IVF (Inverted File Index) reduzieren die Suchzeit auf ein bis zwei Millisekunden, indem sie den Vektor-Raum hierarchisch indizieren und die Suche nur auf die nahegelegenen Cluster beschränken.

In modernen Such-Backends wie Elasticsearch, OpenSearch oder spezialisierten Vektor-Datenbanken sind diese Indizes Standard-Komponenten. Die Ähnlichkeits-Berechnung wird als eigene Query-Form abgesetzt, parallel zur klassischen Keyword-Suche. Im Ergebnis liefert das Backend pro Anker-Produkt eine sortierte Liste von Nachbarn, die im Front-End als Similar-Search-Widget gerendert wird.

Eine wichtige Designschicht ist die Filter-Kombination. Das System soll nicht stumpf die nächsten Vektor-Nachbarn anzeigen, sondern muss die Geschäfts-Constraints respektieren. Ein Produkt ohne Lager-Bestand sollte nicht im Widget erscheinen, ein Produkt aus dem falschen Land-Markt nicht, ein Produkt der falschen Saison ebenfalls nicht. Die Vektor-Suche wird mit Filter-Bedingungen kombiniert, sodass das Ergebnis nur ähnliche Produkte enthält, die gleichzeitig die Geschäfts-Regeln einhalten. Wir haben die ERP-getriebenen Filter im Beitrag zu ERP-Daten als Ranking-Quelle im Detail beschrieben.

Klassische Recommendation-Engines und ihre strukturelle Grenze

Wie haben Produkt-Empfehlungen vor Embeddings funktioniert?

Bevor Similar Search auf Embedding-Basis möglich war, dominierten regelbasierte Recommendation-Engines die E-Commerce-Landschaft. Die klassischen Mechaniken hatten drei Ausprägungen.

Die Cross-Selling-Liste war kuratiert. Ein Produktmanager definierte pro Produkt oder pro Kategorie eine Liste von ergänzenden Produkten, die im Widget angezeigt wurden. Die Mechanik war einfach zu implementieren und gab dem Marketing die volle Kontrolle, war aber pflege-intensiv. Bei einem Sortiment mit 50.000 Produkten musste das Marketing entweder Hunderttausende manueller Verknüpfungen pflegen oder die Logik auf Kategorie-Ebene halten, was die Treffer-Qualität verwässert.

Die "Kunden kauften auch"-Liste war datengetrieben, aber simpel. Eine SQL-Abfrage zählte, welche Produkte im gleichen Warenkorb wie das Anker-Produkt vorkamen, sortierte nach Häufigkeit und zeigte die Top-Treffer. Die Mechanik war robust für High-Volume-Produkte (Bestseller hatten genug Daten), versagte aber für die Long-Tail. Bei einem Produkt mit weniger als zwanzig Bestellungen ist die Co-Kauf-Statistik Rauschen, und die Widget-Liste wird leer oder sinnlos.

Die Kategorie-basierte Empfehlung war noch einfacher. Das Widget zeigte einfach andere Produkte aus der gleichen Sub-Kategorie, sortiert nach Verkaufszahlen oder Lager-Status. Die Mechanik funktionierte als Fallback, war aber semantisch arm. Bei einem Anker-Produkt "rote Sommer-Regenjacke Damen Größe 38" zeigte das Widget einfach andere Damen-Regenjacken, ohne die rote Farbe, die Sommer-Eigenschaft oder die Größe zu berücksichtigen.

Alle drei klassischen Mechaniken haben einen gemeinsamen blinden Fleck. Sie nutzen kein semantisches Verständnis des Produkts. Sie wissen nicht, dass eine "wasserdichte Outdoor-Jacke" und eine "Hard-Shell für Hochtouren" semantisch eng verwandt sind. Sie wissen nicht, dass ein Karabiner mit 25 Kilo Bruchlast und ein Karabiner mit 25 Kilonewton Bruchlast technisch identisch sind. Sie wissen nicht, dass zwei visuell sehr ähnliche Schuhe von unterschiedlichen Herstellern für die gleichen Anwendungs-Fälle in Frage kommen. Die Embedding-basierte Similar Search löst alle drei Probleme, weil sie auf der semantischen und visuellen Ebene operiert, nicht auf der Hersteller- oder Kategorie-Ebene.

Die vier Stellen, an denen Similar Search greift

Wo im Shop taucht Similar Search konkret auf?

Similar Search ist kein Punkt-Feature, sondern eine Schicht, die an mehreren Stellen der Customer-Journey aktiv wird. Die vier wichtigsten Einsatz-Orte sind End-of-Results, Produktdetailseite, 0-Treffer-Fall und Email-Retargeting.

Erstens, End-of-Results. Am unteren Ende einer Suchergebnis-Liste, dort wo der Kunde sonst Pagination sehen würde, zeigt das System einen Similar-Search-Block. Die Anker-Produkte sind die Top-Treffer der laufenden Suche, das System sucht nach Produkten, die diesen Top-Treffern semantisch ähnlich sind und im aktuellen Treffer-Set noch nicht angezeigt wurden. Der Block ist überschrieben mit "Diese Produkte könnten Sie auch interessieren" oder "Semantisch ähnlich zu Ihren Top-Treffern". Der Kunde, der bisher abspringen würde, bekommt eine kuratiert wirkende Auswahl statt einer langen Reste-Rampe.

Zweitens, Produktdetailseite. Auf der Detail-Seite eines konkreten Produkts zeigt das Widget ähnliche Alternativen aus dem Sortiment. Anker ist das angeschaute Produkt, die Nachbarn sind die semantisch nächsten Produkte im Vektor-Raum, gefiltert auf verfügbare Lager-Bestände und passende Markt-Verfügbarkeit. Im Unterschied zur klassischen "Kunden kauften auch"-Liste zeigt der Similar-Search-Block keine ergänzenden Produkte (Socken zur Lauf-Schuh), sondern echte Alternativen (andere Lauf-Schuhe). Der Kunde, der mit dem aktuellen Produkt nicht hundertprozentig zufrieden ist, sieht direkt die nächstbesten Optionen, ohne zurück zur Trefferliste navigieren zu müssen.

Drittens, 0-Treffer-Fall. Wenn die ursprüngliche Such-Anfrage null Treffer liefert, ist Similar Search die rettende Schicht. Das System klassifiziert die Anfrage, bildet einen semantischen Vektor aus der Anfrage selbst (nicht aus einem Anker-Produkt) und sucht die semantisch nächsten Produkte im Sortiment. Statt der frustrierenden "Keine Treffer gefunden"-Seite sieht der Kunde "Direkt passende Treffer haben wir nicht, aber das könnte Sie auch interessieren" und eine Liste semantisch nahegelegener Produkte. Wir haben die Fehlertoleranz und das Verhalten bei Tipp-Fehlern und unklaren Anfragen im Beitrag zur Fehlertoleranz in der Shop-Suche ausführlich beschrieben. Die Similar Search im 0-Treffer-Fall ist der semantische Rettungs-Anker, der auch dort greift, wo die klassische Fehlertoleranz an ihre Grenze stößt.

Viertens, Email-Retargeting und post-Sale-Empfehlungen. Nach dem Kauf eines Produkts kann das System per Email passende Ähnlichkeits-Empfehlungen ausspielen, die auf dem gekauften Produkt als Anker basieren. Im Unterschied zu klassischem User-basiertem Retargeting (das User-Profile braucht und Cookies setzt) operiert die Similar-Search-basierte Retargeting-Mechanik rein produkt-zu-produkt. Sie braucht keine User-spezifischen Embeddings, sondern nur die Produkt-Embeddings des gekauften Artikels und die Sortiments-Embeddings. Das macht sie cookieless und DSGVO-konforme KI, weil keine personenbezogenen Profile aufgebaut werden müssen.

Eine fünfte Anwendungs-Stelle, die in der Praxis oft unterschätzt wird, ist die Such-Autocomplete-Schicht. Wenn der Kunde eine Anfrage tippt und das Autocomplete-Panel die wahrscheinlichsten Vervollständigungen vorschlägt, kann eine parallele Similar-Search-Spalte die semantisch nächsten Produkte zur bisherigen Eingabe zeigen, noch bevor der Kunde die Enter-Taste drückt. Diese Mechanik haben wir im Beitrag zu Autocomplete-Vorschlägen und Conversion erläutert. Im Similar-Search-Kontext ist sie die nullte Empfehlungs-Stelle, die noch vor der eigentlichen Such-Ausführung greift.

Eine Geschäftsführung aus einem österreichischen Direkt-Versicherer beschreibt den Effekt der Similar-Search-Schicht so:

"BatteryIncluded hat uns als kompetenter Sparringspartner geholfen, das Beste aus Volt zu machen, das uns als Lösung für unseren Direktversicherer überzeugt hat. Die Zusammenarbeit war produktiv, die Lösung greift im Live-Betrieb sauber und der Effekt auf unsere Kennzahlen ist messbar."

ÖBV Versicherung

Im Versicherungs-Kontext ist die Similar-Search-Logik besonders wertvoll, weil Produkte (Tarif-Optionen, Bausteine, Zusatz-Versicherungen) selten direkt verglichen werden und der Kunde oft nicht weiß, welche Alternativen für seinen Use Case in Frage kommen. Eine semantische Ähnlichkeits-Suche zwischen Tarifen liefert dem Kunden die nächstbesten Optionen, ohne dass er die Branchen-Sprache der Versicherung beherrschen muss.

Cookieless Recommendations: warum Produkt-zu-Produkt-Embeddings ohne User-Profile auskommen

Wie kann eine Empfehlung ohne Cookies und User-Profile funktionieren?

Eine strukturelle Eigenschaft der Embedding-basierten Similar Search ist, dass sie ohne User-spezifische Daten funktioniert. Das ist gegenüber klassischen personalisierten Recommendation-Engines ein fundamentaler Unterschied.

Klassisches personalisiertes Recommending baut pro User ein Profil. Das Profil enthält angeschaute Produkte, gekaufte Produkte, Kategorie-Präferenzen, Browsing-Zeiten, oft auch Cross-Site-Tracking-Signale. Das Profil wird dann mit anderen User-Profilen verglichen, um Cohorts zu bilden ("User wie du kauften auch"). Die Mechanik setzt Cookies, oft Third-Party-Cookies, und ist im DSGVO-Raum mit erheblichen Compliance-Anforderungen verbunden. Cookie-Banner, Opt-In-Logik, Auftragsverarbeitungs-Verträge mit US-basierten Plattform-Anbietern, regelmäßige Datenschutz-Folgenabschätzungen.

Similar Search auf Produkt-Embedding-Basis hat diese Probleme nicht. Die Embeddings beschreiben Produkte, nicht User. Die Ähnlichkeits-Berechnung läuft zwischen Produkt-Vektoren, nicht zwischen User-Vektoren. Der einzige Eingabe-Datenpunkt aus der laufenden Session ist das aktuell angeschaute Produkt oder die laufende Such-Anfrage, beides sind nicht-personenbezogene Daten. Das System weiß nicht, wer der Kunde ist, und es muss das auch nicht wissen, um die nächstbesten ähnlichen Produkte vorzuschlagen.

Diese Architektur ist vollständig cookieless. Sie braucht keinen Cookie-Banner für die Recommendation-Schicht, keine Opt-In-Logik, keinen Tracking-Pixel. Sie ist DSGVO-konforme KI per Bauart, nicht durch nachgelagerte Compliance-Maßnahmen. Der Shop-Betreiber spart sich die regelmäßige Datenschutz-Folgenabschätzung für die Recommendation-Schicht, weil sie strukturell keine personenbezogenen Daten verarbeitet.

Die Behavior-Embedding-Schicht, die wir oben erwähnt haben, ist die einzige Stelle, an der historische Klick- und Kauf-Muster eingehen. Diese Muster werden auf Cohort-Ebene aggregiert, nicht auf User-Ebene. Das System merkt sich, dass "Stirnlampe X und Karabiner Y oft in der gleichen Session vorkommen" auf Sortiments-Ebene, nicht auf User-Ebene. Die einzelnen Sessions werden nach der Aggregation verworfen, die Cohort-Statistik ist nicht rückführbar auf einzelne User. Damit bleibt auch die Behavior-Schicht in der DSGVO-konformen Zone.

Das ist gegenüber tracking-basierten Personalisierungslösungen ein struktureller Vorteil im DACH-Markt. Made in Germany als Hosting-Standort komplettiert das Vertrauens-Argument, das im Versicherungs-, Finanz- und B2B-Sektor besonders wichtig ist.

Data Lake als Foundation: was indiziert wird

Welche Daten stecken hinter den Embeddings?

Die Embedding-Schicht braucht eine Daten-Foundation. Diese Foundation heißt im Kontext der Such-Infrastruktur Data Lake, weil sie alle relevanten Datenquellen in einer einheitlichen Schicht versammelt, ohne dass die Quell-Systeme verändert werden müssen.

Die typischen Daten-Quellen sind erstens das Produkt-Katalog-System (PIM oder direkt aus der Shop-Datenbank), zweitens das ERP-System mit Lager-, Preis- und Verfügbarkeits-Daten, drittens das Bild-Repository mit den Produkt-Bildern in mehreren Auflösungen, viertens die Klick- und Kauf-Logs der Shop-Sitzung, fünftens die Content-Schicht aus CMS oder PIM mit redaktionellen Texten zu Produkten und Kategorien.

Der Data Lake nimmt diese Quellen in eine einheitliche Indexierungs-Pipeline auf, die pro Produkt einen kombinierten Embedding-Vektor berechnet. Die Pipeline läuft typisch in zwei Modi: Live-Updates per Webhook für Änderungen am Sortiment (Neuaufnahme, Preis-Änderung, Lager-Update), plus periodischer Voll-Sync für Konsistenz-Sicherung. Bei einem Sortiment mit 50.000 Produkten und 768-dimensionalen Embeddings hat der Index eine Größenordnung von wenigen hundert Megabyte, was operativ unkritisch ist.

Die Klick- und Kauf-Logs sind die anspruchsvollste Daten-Quelle, weil sie hohes Volumen haben und kontinuierlich anfallen. Eine saubere Architektur trennt die Roh-Logs (per Session, zeitlich befristet aufgehoben) von den aggregierten Co-Occurrence-Matrizen (langfristig, aber DSGVO-konform aggregiert). Die Behavior-Embeddings werden aus den Aggregaten berechnet, nicht aus den Roh-Logs. Damit bleibt die DSGVO-Konformität gewahrt, auch wenn die Behavior-Komponente kontinuierlich an die aktuelle Nachfrage angepasst wird.

Die Content-Schicht aus dem CMS ist die unterschätzteste Daten-Quelle. Wenn ein Produkt eine redaktionell gepflegte Beschreibung hat (technische Spezifikationen, Anwendungs-Fälle, Pflege-Hinweise), liefert diese Beschreibung dem Text-Embedding deutlich mehr Signal als der reine Hersteller-Text. Die Text-Embeddings werden präziser, die Ähnlichkeits-Berechnung trifft besser. Wir haben die Rolle redaktioneller Inhalte in der Such-Schicht im Beitrag zur Unified Search erläutert, in der Similar Search ist sie der Differenzial-Hebel für die Text-Embedding-Qualität.

Die Variants-Logik ist eine spezielle Herausforderung. Ein Produkt in zehn Farben und fünf Größen liegt typisch als fünfzig separate Produkt-Dokumente im Shop-System vor, hat aber semantisch nur eine gemeinsame Identität. Die Similar-Search-Schicht muss entscheiden, ob sie auf der Variants-Ebene oder auf der Master-Produkt-Ebene rechnet. Wir empfehlen, die Embeddings auf der Master-Ebene zu berechnen und die Variants-Filterung erst nach der Nachbar-Suche anzuwenden. Die Mechanik haben wir im Beitrag zur Gruppierungslogik in der Shop-Suche im Detail beschrieben.

Cold-Start: was passiert mit neuen Produkten

Was passiert mit brandneuen Produkten ohne Verkaufs-Historie?

Eine offene Frage bei jeder embedding-basierten Empfehlungs-Schicht ist das Cold-Start-Problem. Ein neues Produkt im Sortiment hat noch keine Verkaufs-Historie, keine Klick-Daten, keine Co-Kauf-Muster. Die Behavior-Embedding-Komponente liefert für dieses Produkt keinen sinnvollen Signal-Beitrag.

Die Lösung ist die mehrschichtige Embedding-Kombination. Während die Behavior-Komponente bei neuen Produkten schweigt, liefern Bild-Embedding und Text-Embedding sofort sinnvolle Signale, weil sie ausschließlich auf Produkt-eigenen Daten (Bild und Beschreibung) basieren. Die Gewichts-Verteilung für neue Produkte schiebt sich automatisch in Richtung Bild und Text, sobald die Behavior-Komponente fehlt. Der Cold-Start ist damit nicht ein Komplett-Aussetzer, sondern eine Phase reduzierter Signal-Qualität.

Sobald das neue Produkt nach einigen Tagen erste Klicks und Käufe gesammelt hat, beginnt die Behavior-Komponente ihren Beitrag zu liefern. Die Gewichtungs-Verschiebung passiert kontinuierlich, ohne dass eine separate Cold-Start-Logik manuell ausgeschaltet werden muss. Das System lernt das neue Produkt schrittweise in seinen Behavior-Kontext ein.

Eine alternative Mechanik für besonders strategische Neueinführungen ist der Editorial Boost. Wenn das Marketing weiß, dass ein neues Produkt thematisch zu einer Bestseller-Kategorie gehört, kann es einen manuellen Boost-Faktor setzen, der das neue Produkt in der Ähnlichkeits-Liste der Bestseller hochgewichtet. Der Boost-Faktor wirkt zeitlich befristet (typisch zwei bis vier Wochen), damit die Behavior-Schicht in dieser Zeit echte Signale sammeln kann. Danach wird der Boost zurückgefahren und das Produkt findet seinen natürlichen Platz im Embedding-Raum.

Die Editorial-Boost-Schicht ist ein Beispiel für die hybride Architektur, die wir in der gesamten Such- und Recommendation-Infrastruktur verfolgen. Die KI-Mechanik trifft die Hauptentscheidung, die menschliche Redaktion behält die Vetorecht bei strategischen Fällen. Das macht das System einerseits skalierbar (50.000 Produkte werden nicht einzeln gepflegt), andererseits steuerbar (strategische Produkte können gezielt forciert werden, ohne dass die Gesamt-Logik kompromittiert wird).

Performance, Skalierung und ein Wort zur Latenz

Bremst Similar Search die Ladezeit der Seite aus?

Die Performance-Frage ist bei jeder Recommendation-Schicht relevant, weil die Widgets auf jeder PDP, am Ende jeder Suchergebnis-Liste und in jedem 0-Treffer-Fall geladen werden. Wenn die Latenz dieser Berechnung über 50 Millisekunden steigt, leidet die wahrgenommene Performance der gesamten Seite.

Die saubere Architektur hält die Embedding-Berechnung im Index (offline, einmal bei der Indexierung) und die Nachbar-Suche im Live-Pfad (online, pro Anfrage). Die Online-Komponente nutzt einen vorberechneten Vektor-Index (HNSW oder IVF), der die Nachbar-Suche in ein bis zwei Millisekunden erledigt. Die Filter-Anwendung (Lager, Land, Saison) läuft parallel und addiert zwei bis drei Millisekunden. Die gesamte Similar-Search-Antwort liegt damit unter zehn Millisekunden, was für die Front-End-Wahrnehmung praktisch unsichtbar ist.

Bei großen Sortimenten (über 500.000 Produkte) wird die Index-Struktur entscheidend. HNSW-Indizes skalieren gut bis in den siebenstelligen Bereich, IVF-Indizes mit Quantisierung skalieren bis in den hundert-Millionen-Bereich. Die Wahl der Index-Struktur wird pro Sortiments-Größenordnung getroffen. Im DACH-E-Commerce-Standard mit 10.000 bis 200.000 Produkten ist HNSW die Default-Wahl mit komfortablen Latenz-Reserven.

Eine Cache-Schicht für die häufigsten Anker-Produkte (PDP der Bestseller, Top-Treffer der häufigsten Suchen) reduziert die Last weiter. Da die Embeddings bei einer Indexierung berechnet werden und sich nur bei Sortiments-Änderungen verschieben, ist die Cache-Invalidation einfach. Die Nachbar-Listen sind über Stunden hinweg stabil.

Eine Geschäftsführung aus einem etablierten deutschen Premium-Wein-Versand mit modernem Empfehlungs-Setup beschreibt den Effekt der entkoppelten Architektur so:

"Was uns besonders überzeugt hat, ist die Geschwindigkeit, mit der wir BatteryIncluded an unsere Bestandssysteme angebunden bekommen haben. Die Integration in den bestehenden Tech-Stack lief reibungslos und das Ergebnis ist messbar besser als das, was wir vorher hatten."

Silkes Weinkeller / Burda

Im Wein-Versand sind die Ähnlichkeits-Empfehlungen besonders heikel, weil ein Wein-Kunde sich von einer ähnlichen Empfehlung Geschmacks-Verwandtschaft erwartet, nicht Preis-Verwandtschaft oder Etiketten-Ähnlichkeit. Die Embedding-Schicht kombiniert hier Bild-Embedding (Etikett), Text-Embedding (Geschmacks-Notiz), Behavior-Embedding (Co-Kauf der Cohort) und liefert eine Ähnlichkeits-Liste, die den Geschmacks-Kontext besser trifft als jede klassische Sortiments-Logik.

Was Sie diese Woche tun können

Womit fangen Sie in dieser Woche an?

Wenn Sie heute am Ende Ihrer Suchergebnis-Liste eine Standard-Pagination zeigen und auf der Produktdetailseite eine regelbasierte "Kunden kauften auch"-Liste, ist der pragmatische Einstieg in fünf Schritten.

Schritt eins ist die Pagination-Endpunkt-Analyse. Werten Sie aus Ihrem Webanalytics aus, welcher Anteil Ihrer Such-Sessions auf Seite zwei und Seite drei der Treffer-Liste landet, und welcher Anteil dort abspringt. Die Drop-Off-Rate auf Seite drei ist der quantitative Beleg, dass Pagination das Verhalten nicht optimal bedient. Im typischen DACH-E-Commerce liegt die Drop-Off-Rate auf Seite drei bei über 60 Prozent.

Schritt zwei ist die Sortiments-Embedding-Analyse. Vor der produktiven Einführung lohnt sich ein Pilot, in dem Sie für eine repräsentative Sortimentsstichprobe (etwa 500 Produkte aus drei Kategorien) Embeddings berechnen lassen und die Nachbar-Listen visuell inspizieren. Die Inspektion zeigt sehr schnell, ob die Bild-Embeddings, Text-Embeddings und Behavior-Embeddings die richtigen Gewichte für Ihr Sortiment haben. Bei Mode dominiert oft das Bild-Embedding, bei B2B-Industrie oft das Text-Embedding.

Schritt drei ist die Stelle-Priorisierung. Beginnen Sie mit dem End-of-Results-Widget, weil dort der größte Sofort-Effekt sichtbar ist (Pagination-Abspringer werden gefangen). Erweitern Sie dann auf die Produktdetailseite und schließlich auf den 0-Treffer-Fall. Die Email-Retargeting-Stelle ist eine spätere Erweiterung, weil sie das Marketing-Operations-Team einbindet und nicht nur die Shop-Front.

Schritt vier ist die Editorial-Boost-Logik. Definieren Sie, welche strategischen Produkte einen manuellen Boost-Faktor bekommen können, und welche Boost-Faktoren Sie maximal zulassen. Eine saubere Boost-Logik begrenzt das Marketing auf etwa 10 Prozent des Sortiments mit zeitlich befristeten Boosts, damit die Embedding-Schicht ihre natürliche Logik behält.

Schritt fünf ist die Performance-Messung. Etablieren Sie ein wöchentliches Monitoring der Similar-Search-Widgets: Click-Through-Rate auf den Widget-Treffern, Conversion-Rate der Click-Throughs, Drop-Off-Rate vor dem Widget. Diese drei Metriken zeigen, ob die Embedding-Gewichte richtig kalibriert sind. Wenn die Click-Through-Rate sinkt, ist meist die Gewichts-Verteilung zwischen den Embedding-Schichten zu kalibrieren.

Diese fünf Schritte sind in jedem Fall sinnvoll, unabhängig davon, ob Sie auf eine spezialisierte Recommendation-Infrastruktur wechseln oder eine vorhandene Lösung umstellen. Was sie nicht ersetzen können, ist die operative Reife einer Plattform, die die Embedding-Berechnung, die Vektor-Indexierung, die Filter-Kombination, die Editorial-Boost-Schicht und die DSGVO-konforme Behavior-Aggregation out of the box mitbringt.

Häufige Fragen (FAQ)

Was ist ein ähnliche produkte algorithmus im E-Commerce?

Ein ähnliche produkte algorithmus berechnet die semantische Ähnlichkeit zwischen Produkten über Embeddings. Jedes Produkt wird durch einen Vektor in einem hochdimensionalen Raum repräsentiert, der aus Bild-Embeddings, Text-Embeddings und Behavior-Embeddings kombiniert ist. Zwei Produkte gelten als ähnlich, wenn der Abstand zwischen ihren Vektoren klein ist, gemessen über Cosinus-Ähnlichkeit oder euklidischen Abstand. Anders als regelbasierte Cross-Selling-Mechaniken nutzt der Algorithmus kein manuell kuratiertes Mapping, sondern berechnet die Nachbarschaft im Vektor-Raum automatisch über das gesamte Sortiment. Die Mechanik findet auch dann ähnliche Produkte, wenn die exakten Wörter der Beschreibung oder die Kategorie-Zuordnung unterschiedlich sind.

Was ist der Unterschied zwischen Similar Search und einer klassischen Recommendation-Engine?

Eine klassische Recommendation-Engine arbeitet regelbasiert oder mit einfacher Co-Occurrence-Statistik. Sie nutzt kuratierte Produkt-Verknüpfungen, "Kunden kauften auch"-Listen oder kategorie-basierte Filter. Die Mechanik versagt bei Long-Tail-Produkten ohne ausreichende Verkaufs-Historie und liefert keine semantischen Ähnlichkeits-Treffer, sondern nur statistische Co-Vorkommen. Similar Search auf Embedding-Basis berechnet die semantische und visuelle Nähe zwischen Produkten über vortrainierte Embedding-Modelle. Sie findet auch dann sinnvolle Empfehlungen, wenn das Anker-Produkt eine niedrige Verkaufs-Frequenz hat, weil die Embeddings auf produkt-eigenen Daten (Bild und Beschreibung) basieren und nicht ausschließlich auf historischen Klick-Mustern.

Welche Embedding-Quellen werden für Similar Search kombiniert?

Eine saubere Similar-Search-Architektur kombiniert drei Embedding-Quellen. Bild-Embeddings aus einem Vision-Encoder-Modell wie CLIP repräsentieren die visuelle Ähnlichkeit zwischen Produkten. Text-Embeddings aus einem multilingualen Sprach-Modell wie Sentence-BERT oder MPNet repräsentieren die semantische Ähnlichkeit der Produkt-Beschreibungen und Attribute. Behavior-Embeddings aus den aggregierten Klick- und Kauf-Mustern der Cohort repräsentieren die verhaltensbasierte Co-Vorkommen. Die drei Quellen werden zu einem gewichteten Gesamt-Vektor kombiniert, die Gewichte werden pro Sortimentstyp konfiguriert. Bei Mode dominiert typisch das Bild-Embedding, bei B2B-Industrie das Text-Embedding, bei FMCG das Behavior-Embedding.

Ist Similar Search cookieless und DSGVO-konform?

Ja, eine sauber gebaute Similar Search auf Produkt-Embedding-Basis ist vollständig cookieless und DSGVO-konforme KI. Die Ähnlichkeits-Berechnung läuft zwischen Produkt-Vektoren, nicht zwischen User-Vektoren. Der einzige Eingabe-Datenpunkt aus der laufenden Session ist das aktuell angeschaute Produkt oder die laufende Such-Anfrage, beides sind nicht-personenbezogene Daten. Die Behavior-Embedding-Schicht aggregiert historische Klick- und Kauf-Muster auf Cohort-Ebene, nicht auf User-Ebene, sodass keine personenbezogenen Profile aufgebaut werden. Das System braucht keinen Cookie-Banner für die Recommendation-Schicht, keine Opt-In-Logik und keine Tracking-Pixel. Im DACH-Markt mit Made in Germany als Hosting-Standort ist das ein struktureller Vorteil gegenüber tracking-basierten Personalisierungslösungen.

An welchen Stellen der Customer-Journey wirkt Similar Search?

Similar Search greift an mehreren Stellen. Am Ende einer Suchergebnis-Liste ersetzt sie die Standard-Pagination durch einen Block semantisch ähnlicher Produkte zu den Top-Treffern. Auf der Produktdetailseite zeigt sie als Widget die nächstbesten Alternativen zum angeschauten Produkt. Im 0-Treffer-Fall liefert sie semantisch passende Produkte, wenn die ursprüngliche Anfrage keine exakten Treffer hat. Im Email-Retargeting nach dem Kauf liefert sie passende Anschluss-Produkte auf Basis des gekauften Anker-Produkts. Eine zusätzliche Anwendungs-Stelle ist die Such-Autocomplete-Schicht, die parallel zur Vervollständigungs-Vorschlag eine Spalte mit semantisch nahegelegenen Produkten zeigt, noch bevor der Kunde die Suche absetzt.

Wie wird das Cold-Start-Problem bei neuen Produkten gelöst?

Das Cold-Start-Problem tritt auf, wenn ein neues Produkt noch keine Verkaufs-Historie und keine Co-Kauf-Muster hat. Die Behavior-Embedding-Komponente kann für dieses Produkt keinen Signal-Beitrag liefern. Die Lösung ist die mehrschichtige Embedding-Kombination. Bild-Embedding und Text-Embedding funktionieren sofort, weil sie ausschließlich auf produkt-eigenen Daten basieren. Die Gewichts-Verteilung verschiebt sich automatisch in Richtung Bild und Text, sobald die Behavior-Komponente fehlt. Sobald das Produkt nach einigen Tagen erste Klicks und Käufe gesammelt hat, beginnt die Behavior-Komponente ihren Beitrag zu liefern. Für strategische Neueinführungen kann zusätzlich ein zeitlich befristeter Editorial Boost gesetzt werden, der das neue Produkt in der Ähnlichkeits-Liste der Bestseller hochgewichtet.

Wie schnell ist Similar Search bei einer Live-Anfrage?

Eine saubere Architektur trennt die Embedding-Berechnung (offline, bei der Indexierung) von der Nachbar-Suche (online, pro Anfrage). Die Online-Komponente nutzt einen vorberechneten Vektor-Index, typisch HNSW (Hierarchical Navigable Small World) oder IVF (Inverted File Index), der die Nachbar-Suche in ein bis zwei Millisekunden erledigt. Die Filter-Anwendung für Lager-Bestand, Land-Markt und Saison addiert zwei bis drei Millisekunden. Die gesamte Similar-Search-Antwort liegt damit unter zehn Millisekunden. Bei großen Sortimenten über 500.000 Produkte werden Index-Strukturen mit Quantisierung eingesetzt, die bis in den hundert-Millionen-Produkt-Bereich skalieren. Im DACH-E-Commerce-Standard von 10.000 bis 200.000 Produkten ist HNSW die Default-Wahl mit komfortablen Latenz-Reserven.

Wie verhält sich Similar Search zu Volt Search®?

Volt Search® ist die Such-Schicht der BatteryIncluded-Infrastruktur und liefert die Treffer-Liste zu einer eingegebenen Suchanfrage. Similar Search im Rahmen der AI Recommendations greift am Ende dieser Trefferliste, auf der Produktdetailseite, im 0-Treffer-Fall und im Post-Sale-Retargeting. Beide Schichten arbeiten auf der gleichen Daten-Foundation (Data Lake mit Produkt-Daten, Content-Daten, ERP-Daten und aggregierten Behavior-Daten) und nutzen die gleichen Embeddings. Die Trennung in Such-Schicht und Recommendation-Schicht erlaubt eine modulare Einführung. Shops, die heute eine andere Suche im Einsatz haben, können AI Recommendations als isolierten Recommendation-Layer integrieren, ohne die Such-Schicht zu wechseln. Umgekehrt können Shops mit Volt Search® die AI Recommendations als Ergänzung aktivieren, ohne separate Embeddings zu pflegen.

Bereit für Produkt-Empfehlungen, die semantisch greifen und ohne User-Profile auskommen?

Similar Search statt Pagination ist eine strukturelle Entscheidung über das Verhalten am Ende einer Suche, auf der Produktdetailseite und im 0-Treffer-Fall. Wer den Pagination-Endpunkt durch eine semantische Ähnlichkeits-Liste ersetzt, wer die Produktdetailseite um echte Alternativ-Vorschläge erweitert und wer den 0-Treffer-Fall in einen semantischen Rettungs-Anker verwandelt, gewinnt Click-Through-Rate auf den Empfehlungs-Widgets, Self-Service-Rate bei unklaren Anfragen und Conversion-Rate über das gesamte Sortiment. AI Recommendations von BatteryIncluded ist als entkoppelte Infrastruktur konzipiert, die die Embedding-Berechnung, die Vektor-Indexierung, die Filter-Kombination und die Editorial-Boost-Logik out of the box mitbringt. Die Bild-, Text- und Behavior-Embeddings werden im Data Lake kombiniert und pro Sortimentstyp gewichtet, ohne dass Sie eigene Embedding-Modelle trainieren oder pflegen müssen. Cookieless, DSGVO-konforme KI, Made in Germany, ohne dass Sie User-Profile aufbauen, Tracking-Pixel setzen oder Cookie-Banner um die Empfehlungs-Schicht erweitern müssen.

AI Recommendations live sehen und erleben Sie an Ihren eigenen Produkt-, Content- und Behavior-Daten, wie der Embedding-basierte ähnliche produkte algorithmus die Pagination am Ende der Suche durch semantische Empfehlungen ersetzt, wie das Similar-Search-Widget auf der Produktdetailseite echte Alternativen statt regelbasierter Cross-Sells liefert, wie der 0-Treffer-Fall in einen semantischen Rettungs-Anker verwandelt wird und wie die Cookieless-Architektur Ihre Compliance-Last auf der Empfehlungs-Schicht auf null reduziert. Ohne eigene Embedding-Pipelines, ohne Vektor-Index-Pflege, ohne separates Behavior-Aggregations-System.