So funktioniert die Suche

Eine Suchmaschine durchsucht nicht Ihren Katalog. Sie durchsucht eine Kopie Ihres Katalogs, die sie vorher gebaut hat, in einer Form, die ihr gefällt. Fast alles, was bei B2B-Suche schiefgeht, geht in dieser Kopie schief — und deshalb beginnt dieser Artikel dort und nicht am Suchfeld.

Das Szenario

Ein Instandhaltungstechniker hat einen handgeschriebenen Zettel: Sechskantschraube DIN933 M8x40 A2. Er tippt ihn in Ihren Shop. Vier Dinge müssen jetzt zusammenpassen:

1. Jedes dieser Produkte muss im Index sein.
2. Die Maschine muss die Anfrage in Stücke schneiden, die sie treffen kann, und M8x40 muss diesen Schnitt überleben.
3. Sie muss die richtige Schraube über die 380 anderen Schrauben ranken.
4. Der Käufer muss das Ergebnis eingrenzen können — Gewinde, Länge, Werkstoff —, ohne noch etwas zu tippen.

Index, Tokenisierung, Ranking, Facetten. Stimmt eines davon nicht, ruft der Techniker Ihren Innendienst an, und alles, was Sie in den Shop gesteckt haben, hat einen Anruf gekauft.

Der Index ist eine plattgedrückte Kopie des Katalogs

Ihr Katalog ist normalisiert: eine Produktzeile, Attributwerte in ihrer eigenen Struktur, Optionen in einer anderen, Kategorien in einer Verknüpfungstabelle. Diese Form ist richtig fürs Bearbeiten und falsch fürs Suchen. Aus ihr heraus kann niemand „Edelstahl-Verschraubungen über 100 bar, nach Relevanz sortiert, mit Zählern je Gewindegröße, in 40 Millisekunden“ beantworten.

Also baut die Plattform eine zweite, denormalisierte Kopie: den Index. Ein Dokument je Produkt, mit allem bereits aufgelöst: der deutsche Name, der englische Name, der Hersteller ausgeschrieben statt referenziert, die Kategoriepfade, die Optionsbezeichnungen, die numerischen Werte als Zahlen.

Daraus folgen zwei Dinge, und beide überraschen:

• Der Index hängt immer leicht hinterher. Er wird aus Katalogereignissen aktualisiert, nicht live gelesen. Normale Verzögerung: Sekunden; nach einem Massenimport: Minuten. Siehe Häufige Suchprobleme.
• Suchqualität ist Datenqualität. Die Maschine kann nur treffen, was im Dokument steht. Ist pressure_rating bei 300 Produkten leer, macht keine Ranking-Konfiguration diese 300 über den Druck auffindbar. Steht der Werkstoff mal als V4A, mal als 1.4571, mal als Edelstahl an verschiedenen Produkten, zerfällt die Facette in drei Teile, und jeder sieht klein und nutzlos aus.

Das ist der Satz, den Sie aus diesem Artikel mitnehmen sollten: Die Suche ist eine Linse auf Ihren Katalog, und eine Linse kann kein Detail hinzufügen, das nicht da ist. Jede Stunde für die Datenqualität verbessert die Suche mehr als eine Stunde Suchkonfiguration.

Tokenisierung: warum DIN933 M8x40 schwer ist

Bevor die Maschine irgendetwas treffen kann, schneidet sie Text in Tokens. Standardmäßig schneidet sie an Leerzeichen und Satzzeichen. Dieser Standard ist für Fließtext gebaut, und B2B-Käufer tippen keinen Fließtext.

In dieser Tabelle verstecken sich zwei getrennte Probleme.

Codes dürfen nicht zerschreddert werden. 4711-A, zerschnitten in 4711 und a, trifft jeden Artikel, der mit 4711 anfängt, und sortiert sie nach Zufall. Die Abhilfe: der Maschine sagen, welche Zeichen Teil eines Codes sind statt Trenner, und welche Trenner zusätzlich die ganze Zeichenkette behalten sollen. Dann finden 4711-A und 4711 beide den Artikel, und der exakte Treffer gewinnt.

Deutsche Komposita dürfen nicht atomar sein. Schlauchschelle, Edelstahlrohr, Sechskantschraube — das Deutsche klebt Wörter zusammen, und ein Käufer, der Schraube tippt, bekommt nichts, wenn das Produkt nur Sechskantschraube heißt. Suchmaschinen zerlegen Komposita schlecht oder gar nicht, bei jedem Produkt am Markt. Einen Schalter, der Deutsch repariert, gibt es nicht. Was tatsächlich funktioniert, ist unspektakulär: eine Synonymliste aus echten Anfragen, plus die zerlegten Wörter in den eigenen Daten des Produkts. Siehe Synonyme, Stoppwörter und Regeln.

Ranking: was „bester Treffer“ heißt

Wenn 40 Dokumente treffen, muss etwas die Reihenfolge entscheiden. Echte Maschinen kombinieren mehrere Signale:

Die Reihenfolge dieser Signale ist eine Grundsatzentscheidung, keine technische. Ein B2C-Shop rankt nach Kaufwahrscheinlichkeit. Ein technischer Großhandel rankt nach Identität zuerst: Sieht die Anfrage wie ein Code aus und trifft ein Code, ist dieser Artikel Ergebnis eins, und nichts überholt ihn. Alles andere ist verhandelbar.

Facetten kommen aus filterbaren Attributen

Eine Facette ist ein Filter mit Zählern — Werkstoff: V4A (212). Die Storefront erfindet sie nicht. Die Maschine kann nur über Felder aggregieren, die beim Bau des Index als Facettenfelder deklariert wurden, und die kommen direkt aus Attributen, die Sie im Katalog als filterbar markiert haben.

Das ist die ganze Kette, und sie ist es wert, auswendig gekonnt zu werden, denn sie erklärt die meisten „warum fehlt dieser Filter“-Tickets:

Attribut existiert → Attribut ist filterbar → Attribut steht als Facettenfeld im Index → die Storefront kann es rendern → der Käufer sieht es

Numerische Facetten sind dieselbe Kette mit einem Zusatzschritt: Ein Maßattribut speichert Wert und Einheit, und der Index speichert den Wert umgerechnet in die Standardeinheit, damit ein Bereichsfilter 100–250 bar Gleiches mit Gleichem vergleicht. Deshalb nimmt 10 in einem nackten Zahlenfeld plus das Wort „bar“ irgendwo anders dieses Attribut still und für immer aus der Suche.

Suche gilt je Kanal und je Locale

Ein Index bedient nicht alle.

• Je Locale. Ein deutsches und ein englisches Dokument tokenisieren verschieden, enthalten verschiedenen Text und brauchen verschiedene Synonyme. Ein Käufer, der auf der englischen Storefront hexagon bolt sucht, darf nicht gegen deutsche Beschreibungen gerankt werden.
• Je Kanal. Ein Kanal ist ein eigener Zuschnitt des Katalogs. Ein Punchout-Katalog für einen Großkunden enthält dessen verhandeltes Sortiment und sonst nichts. Würde die Suche den Kanal ignorieren, fände dieser Käufer Artikel, die er nicht kaufen darf — und riefe dann an, um zu fragen, warum er sie nicht bestellen kann.

Kundenspezifische Sortimente gehen einen Schritt weiter: derselbe Kanal, gefiltert je Organisation. Die Plattform erzwingt das zur Anfragezeit, indem sie den Filter an den Such-Berechtigungsschlüssel bindet, den die Storefront ausgestellt bekommt — ein Käufer kann ihn nicht durch Ändern der URL entfernen.

So funktioniert das in der Revenue Cloud

• Die Maschine ist Typesense, selbst betrieben auf der eigenen Infrastruktur der Plattform. Nichts an Ihrem Katalog verlässt sie — der Grund, warum ein SaaS-Suchanbieter unter der DSGVO keine Option war.
• Der Index ist je App definiert. Die Products-App deklariert, welche Felder im Suchdokument existieren, welche durchsuchbar sind, welche Facetten und welche sortierbar. Sie konfigurieren Verhalten; Sie pflegen keine Leitungen.
• Aktualisierungen kommen als Ereignisse. Eine Produktänderung wird als Ereignis veröffentlicht und als Einzeldokument-Update angewandt. Einen nächtlichen Neuaufbau gibt es im Normalbetrieb nicht.
• Schemaänderungen bauen einen neuen Index und schwenken um. Ein neues Facettenfeld heißt: Der Index wird neben dem laufenden neu gebaut und atomar umgeschaltet, es gibt kein Fenster, in dem die Suche nichts zurückgibt.
• Der Suchdienst ist sichtbar unter App Studio › Services › Suche, mit seinen Collections und ihren Dokumentzahlen. Auf diesem Bildschirm bestätigen Sie, dass der Index existiert und befüllt ist, bevor Sie irgendetwas anderes untersuchen.

Weiter

• Wie B2B-Käufer tatsächlich suchen: die Anfragemuster, die das alles überleben muss.
• Den Index konfigurieren: welche Attribute durchsuchbar sind, mit welchem Gewicht.