Eine Kundin tippt „marineblaue wasserdichte Kinderjacke“ in den Shop und erhält nur die beiden Produkte, deren Bezeichnung wortwörtlich passt. Ein anderer Kunde kommt über die Kategorieseite und möchte nach Größe, Wärmeleistung und Einsatzzweck eingrenzen, findet dort aber eine lange Filterliste aus den Datenfeldern der Hersteller. Beide Probleme haben dieselbe Ursache: Produktfindung ist kein Suchfeld, das nachträglich an die Oberfläche gehängt wird, sondern das gemeinsame System aus Katalogdaten, Sprache, Ranking und Interaktionsentscheidungen.
Eine gute Findungsarchitektur versucht nicht, perfekt zu erraten, wonach jemand sucht. Sie verarbeitet die Anfrage nachvollziehbar, zeigt Produkte mit vergleichbaren Eigenschaften, macht das Filterergebnis vorhersehbar und bietet in der Sackgasse einen Ausweg. Dieser Leitfaden gestaltet Suche und Filterung gemeinsam mit den Ebenen Produkttaxonomie, Index, Facetten, Ranking, Null-Treffer und Messung. Die Technologieauswahl bleibt dabei an den Katalog und den tatsächlichen Bedarf der Kundschaft gebunden.
1. Klassifizieren Sie Suchanfragen als Nutzeraufgaben, nicht als Stichwörter
Suchanfragen tragen unterschiedliche Absichten: konkreter Produktname oder SKU, Kategorie, Eigenschaft, Anwendungsfall, Kompatibilität, Problemlösung oder Marke. „Laufschuhe“ und „Herren-Laufschuhe Größe 42 mit Pronationsstütze“ verlangen weder dasselbe Ranking noch dieselben Startfilter. Bereinigen und anonymisieren Sie Ihre Suchprotokolle und bilden Sie daraus Gruppen nach hohem Volumen, hohem Umsatz, Null-Treffern und Wiederholungssuchen.
Definieren Sie den Sucherfolg nicht allein als Bestellung nach der Anfrage. Filternutzung, Produktaufrufe, Warenkorblegungen und Wiederholungssuchen sind diagnostische Signale. Ein Klick auf das erste Ergebnis belegt nicht, dass das passende Produkt gefunden wurde. Bewerten Sie Aufgabentests und Verhaltensdaten gemeinsam.
Wenn getrennte Teams Kategorienavigation und Suche verantworten, entstehen Widersprüche. Dieselbe Eigenschaft „wasserdicht“ muss auf der Produktkarte, in den Suchsynonymen, im Filter und auf der Detailseite dieselbe Bedeutung tragen. Wer die Produktfindung verantwortet, muss das kaufmännische Team, den Katalogbetrieb, die Suchtechnik, das Design und die Analytics an denselben Entscheidungstisch bringen.
| Anfragetyp | Beispiel | Systembedarf | Erfolgssignal |
|---|---|---|---|
| Konkretes Produkt | Modell AB-123 | SKU- und Modellzuordnung | Schneller Weg zur richtigen Detailseite |
| Kategorie | Campingzelt | Breite Ergebnisse und passende Facetten | Sinnvolle Eingrenzung |
| Eigenschaft | wasserdichte Jacke | Normalisierung der Eigenschaften | Passende Produkte werden getrennt |
| Kompatibilität | Hülle für Gerät X | Beziehungsdaten | Auswahl eines kompatiblen Produkts |
| Anwendung | Kaffeemühle für Einsteiger | Inhalts- und Produktsignale | Entscheidungshilfe |
2. Bauen Sie Suchqualität auf Produktdaten und Taxonomie auf
Eine Suchmaschine kann fehlende Kataloginformationen nicht erzeugen. Für Produktname, Marke, Kategorie, Farbe, Größe, Kompatibilität und Bestand braucht es ein verbindliches Wörterbuch. Bleiben „marineblau“, „dunkelblau“ und der Herstellercode getrennt, zerfällt die Zuordnung. Der Quellwert bleibt erhalten, während der kundenseitige Wert normalisiert wird.
Der Kategoriebaum soll dem Suchmodell der Kundschaft folgen, nicht der Lagerklassifikation. Zu tiefe Bäume erschweren die Navigation, zu breite Kategorien die Filterung. Ein Produkt kann in mehrere Zusammenhänge gehören. Die Kategorie beantwortet, was das Produkt ist; die Facette beantwortet, über welche Eigenschaft eingegrenzt wird.
Jede Eigenschaft braucht eine Definition, einen Datentyp, zulässige Werte, eine Einheit, eine Pflichtangabe und ein Quellsystem. Lieferantendaten durchlaufen eine Prüfung, und ein unbekannter Wert wird nicht in die falsche Kategorie überführt. Ein Katalog-Dashboard priorisiert fehlende und widersprüchliche Eigenschaften nach ihrer Wirkung auf die Produktfindung.
- Kundenseitige Produkteigenschaften sind im Wörterbuch definiert.
- Gleichbedeutende Werte werden normalisiert, die Quelldaten bleiben erhalten.
- Die Rollen von Kategorie und Filtereigenschaft sind getrennt.
- Einheiten-, Sprach- und Marktumrechnungen folgen ausdrücklichen Regeln.
- Fehlende und widersprüchliche Katalogdaten werden vor der Veröffentlichung geprüft.
- Für jede kritische Eigenschaft sind fachliche Verantwortung und Quellsystem benannt.
3. Gestalten Sie Anfragenanalyse und Ranking als erklärbare Ebenen
Beim Indexieren wird Text in durchsuchbare Begriffe zerlegt. Groß- und Kleinschreibung, sprachspezifische Sonderzeichen sowie Marken- und Modellcodes verlangen jeweils eigenes Verhalten; für eine Beschreibung gilt nicht dieselbe Regel wie für eine SKU. Begrenzen Sie die Tippfehlertoleranz auf die Fehler, die in Ihren Suchprotokollen tatsächlich vorkommen.
Die offizielle Dokumentation von Elasticsearch zur Textanalyse beschreibt den Analyzer als das Regelwerk, das Text beim Indexieren oder beim Suchen verarbeitet. Vorgefertigte Analyzer wie standard, simple, whitespace und keyword zerlegen Text unterschiedlich; findet sich keine passende Komponente, lässt sich aus Zeichenfiltern, Tokenizer und Token-Filtern ein eigener Analyzer zusammenstellen. Die offizielle Referenz empfiehlt außerdem, Analyzer vor dem Produktivbetrieb zu testen.Elastic Documentation — Analyzer reference
Trennen Sie im Ranking Textrelevanz, Bestand, Lieferfähigkeit, Qualität und kaufmännische Regeln. Gesponserte Produkte müssen gekennzeichnet sein und dürfen die Relevanzbasis nicht überlagern. Ein Popularitätsmodell kann neue Produkte ohne Verhaltensdaten nach unten drücken. Jede manuelle Fixierung braucht eine verantwortliche Person, eine Begründung und ein Enddatum.
Prüfen Sie im goldenen Anfrageset das erwartete Produkt, unpassende Treffer und Null-Treffer. Beobachten Sie im Onlinetest Produktaufrufe, Warenkorblegungen, Käufe und Wiederholungssuchen gemeinsam. Halten Sie den Testzeitraum fest, weil Saison, Kampagnen und Bestand das Ergebnis beeinflussen.
| Ebene | Zweck | Risiko | Kontrolle |
|---|---|---|---|
| Textrelevanz | Anfrage und Produkt zusammenführen | Falsche Feldgewichtung | Goldenes Anfrageset |
| Katalogeignung | Bestand und Lieferfähigkeit sichern | Passende Produkte werden unnötig verdrängt | Markt- und Bestandstest |
| Verhalten | Nützliche Ergebnisse lernen | Popularitätsverzerrung | Schutz für neue Produkte |
| Kaufmännische Regel | Kampagnen und Sponsoring steuern | Verlust von Relevanz und Vertrauen | Kennzeichnung, Grenze und Enddatum |
4. Legen Sie die Facettenlogik kategoriespezifisch, vorhersehbar und umkehrbar an
Nicht jede Kategorie braucht dieselben Filter. Bei Schuhen zählen Größe, Weite und Untergrund, bei Fernsehern Bildschirmdiagonale, Panel und Anschlüsse, bei Ersatzteilen die Kompatibilität. Allgemeine Farb- und Preisfilter reichen nicht aus. Bilden Sie Filterbezeichnungen aus der Entscheidungssprache Ihrer Kundschaft statt aus internen Datenspalten und ergänzen Sie unklare Fachbegriffe um eine kurze Erläuterung.
Auswahlen innerhalb einer Gruppe wirken meist als ODER, Auswahlen über Gruppen hinweg als UND: rot oder blau, gleichzeitig in kleiner Größe. Prüfen Sie diese Regel im jeweiligen Kontext. Zeigen Sie die Trefferzahl vorab an, fassen Sie gesetzte Filter zusammen und lassen Sie sie einzeln wie auch gesammelt zurücksetzen. Auf Mobilgeräten darf der Auswahlstand nicht verloren gehen.
Die offizielle Aggregations-Referenz von Elasticsearch erklärt, dass Bucket-Aggregationen Dokumente nach Feldwert, Bereich oder anderen Kriterien gruppieren. Eine Terms-Aggregation kann für jeden eindeutigen Wert dynamisch einen Bucket erzeugen; die Dokumentation hält fest, dass in verteilten Indizes die Anzahl der zurückgegebenen Begriffe und die Shard-Einstellungen eine Fehlerspanne bei den Dokumentzahlen erzeugen können. Behandeln Sie Filterzahlen deshalb nicht als absolute Wahrheit, sondern gleichen Sie sie mit Konfiguration und Katalog ab.Elasticsearch Reference — Terms aggregation
Facetten-URLs müssen teilbar und mit der Zurück-Taste verlässlich sein. Jede Kombination indexierbar zu machen, kann Crawling- und Duplicate-Content-Probleme erzeugen; die SEO-Regeln gehören deshalb gesondert gesteuert. Oberfläche, Analytics und Server müssen denselben Parametervertrag nutzen.
- Die Facetten beruhen auf den Entscheidungen, die in der jeweiligen Kategorie anstehen.
- Die Auswahllogik innerhalb und zwischen Gruppen ist ausdrücklich getestet.
- Trefferzahl, gesetzte Filter und Zurücksetzen sind sichtbar.
- Optionen ohne Treffer werden gesperrt oder erläutert.
- Der mobile Filterstand bleibt beim Schließen des Panels erhalten.
- Regeln für URL, Zurück-Taste, Teilen und SEO-Indexierung sind festgelegt.
5. Hypothetisches Szenario: die Ergebnisse zu „Laufschuhe“ in Ordnung bringen
Dieses Szenario ist hypothetisch und beschreibt kein Ergebnis eines realen Shops. In einem Sportgeschäft liefert die Anfrage „Damen Trailrunning-Schuhe 39“ die breite Kategorie zurück. Der Größenfilter zählt Varianten mit, die nicht auf Lager sind, und „Trail“ steht bei manchen Produkten in der Kategorie, bei anderen nur in der Beschreibung. Die Kundschaft sucht erneut.
Die Eingangsdaten sind Suchprotokolle, die Quote der Wiederholungssuchen, die Feldabdeckung im Katalog, Bestands- und Variantendaten sowie Aufgabentests. Statt zuerst ein neues KI-Rankingmodell einzukaufen, normalisiert das Team Produkttyp, Untergrund, Geschlechterdarstellung und Variantengröße. Die Verfügbarkeit der Variante wird im Index getrennt geführt, und der Anfragenparser ordnet „Trail“ der Einsatzeigenschaft und 39 der Größenfacette zu.
Die Entscheidung hat drei Ebenen: Unvollständige Produkte werden korrigiert, Feldgewichte am goldenen Set getestet und die Facetten für Größe und Untergrund sichtbar gemacht. Passende Produktaufrufe, Null-Treffer, Wiederholungssuchen, Warenkorblegungen und Retouren wegen falscher Variante werden gemeinsam verfolgt. Ein Modell-Upgrade wird erst bewertet, wenn die Daten stabil sind.
6. Verbessern Sie die Suchqualität laufend über Anfrageset, Verhalten und Betrieb
Verknüpfen Sie die Ereignisse Suche, Null-Treffer, Filter, Sortierung, Produktauswahl, Warenkorblegung und Wiederholungssuche über eine Anfrage-ID. Rohe Suchanfragen können sensible Angaben enthalten; legen Sie Regeln für Zugriff, Aufbewahrung, Maskierung und Löschung fest. Werten Sie die Ergebnisse nach Kategorie und Gerät aus.
Die Untersuchung von Baymard zu Produktlisten und Filterung hält fest, dass Filterung, Sortierung und Listengestaltung gemeinsam die Produktfindung stützen und dass das Forschungsprogramm betrachtet, wie Nutzerinnen und Nutzer Listen überfliegen, bewerten, filtern und sortieren. Diese Erkenntnisse liefern eine Ausgangshypothese; den Aufgabentest mit Ihrer eigenen Katalogsprache und Ihrer eigenen Kundschaft ersetzen sie nicht.Baymard Institute — E-Commerce Product Lists & Filtering UX
In den ersten 30 Tagen lassen sich eine Anfragen- und Katalogprüfung, ein Ereigniswörterbuch und ein goldenes Set aus den ersten 50 bis 100 kritischen Anfragen aufbauen. In den folgenden 30 Tagen werden Normalisierung, Synonyme, Rettungswege bei Null-Treffern und Kategoriefacetten pilotiert. Im dritten Monat kommen Ranking-Experimente, ein Performance-Budget und ein wöchentlicher Suchbetrieb dazu. Der genaue Umfang hängt von Katalogumfang und Teamkapazität ab.
Der wöchentliche Betrieb prüft Null-Treffer, Meldungen über schlechte Ergebnisse, Kampagnenbegriffe und abgelaufene Regeln. Änderungen werden versioniert und durchlaufen goldenes Set und Performance-Test. Ein richtiges Ergebnis, das zu spät kommt, ist für die Kundschaft nicht auffindbar.
| Kennzahl | Was sie zeigt | Risiko der Einzelbetrachtung |
|---|---|---|
| Null-Treffer | Lücke in Abdeckung oder Anfragenverständnis | Manche Anfragen dürfen zu Recht leer bleiben |
| Wiederholungssuche | Das erste Ergebnis reicht womöglich nicht | Die Kundschaft grenzt ihre Absicht vielleicht nur ein |
| Produktauswahl | Das Ergebnis hat Interesse geweckt | Kein Beleg für das richtige Produkt oder einen Kauf |
| Warenkorblegung | Signal für kaufmännische Passung | Bestands- und Preiseffekte mischen sich ein |
| Latenz | Antwortkosten des Systems | Die gefühlte Geschwindigkeit hängt vom Gerät ab |
7. Grenzen und Fehlermodi: Eine klügere Suchmaschine rettet keine schlechten Daten
Semantische oder vektorbasierte Suche kann bei Anfragen in natürlicher Sprache helfen; harte Einschränkungen wie Bestand, Preis, Größe und Kompatibilität verlangen jedoch weiterhin strukturierte Daten und Geschäftsregeln. Generative Antworten können falsche Produkteigenschaften oder nicht vorhandene Optionen erfinden. Kein neues Verfahren sollte die Basissuche ohne goldenes Anfrageset, sicheren Fallback und Prüfungen auf Produktgenauigkeit ersetzen.
Häufige Fehler sind: das Suchfeld allein dem Technikteam überlassen, den Klick als Erfolg werten, allen Kategorien dieselben Filter geben, Produktvarianten falsch modellieren, Popularität vor Relevanz stellen, manuelle Regeln unbefristet laufen lassen und die Null-Treffer-Seite zur Sackgasse machen. Bei Null-Treffern lassen sich Schreibvorschlag, Kategorie, passende Inhalte oder ein Weg zum Support anbieten; unpassende Produkte zu zeigen, kann das Vertrauen beschädigen.
Verhaltensdaten spiegeln die bisherige Darstellung wider: Ein weit unten platziertes Produkt wirkt schlecht, weil es wenige Klicks bekommt. Experimente müssen Position, Saison, Bestand und Preis berücksichtigen. Keine Technologie garantiert ein bestimmtes Geschäftsergebnis. Ein tragfähiges System steuert Katalogqualität, erklärbare Regeln und Nutzerforschung gemeinsam.
Fazit
Reduzieren Sie die Produktfindung nicht auf ein Suchfeld, ein Filterpanel oder ein neues Algorithmusprojekt. Verbinden Sie die Nutzeraufgabe mit einem Produktwörterbuch, verarbeiten Sie Freitext und exakte Eigenschaften getrennt, legen Sie das Facettenverhalten eindeutig fest und belegen Sie die Qualität mit einem Anfrageset am echten Verhalten. Belastbare Daten sind die grundlegende Funktion der Produktfindung.
Häufig gestellte Fragen
Quellen
- Elastic Documentation — Analyzer reference
Verhalten vorgefertigter und eigener Textanalyzer
- Elasticsearch Reference — Terms aggregation
Facettenähnliche Bucket-Erzeugung und Grenzen verteilter Dokumentzahlen
- Baymard Institute — E-Commerce Product Lists & Filtering UX
Eigenständige Usability-Forschung zu Produktlisten, Filterung und Sortierung
Bauen Sie ein System, in dem Kundinnen und Kunden das richtige Produkt wirklich finden
Wir prüfen Ihre Katalogdaten, Ihre kritischen Suchanfragen, Ihre Filterlogik und Ihren Messplan gemeinsam und leiten daraus die vorrangige Sucharchitektur ab.
Meine Produktfindungs-Architektur bewerten lassen


