Computed Filters: Wenn 47 Filter-Werte zu 5 sinnvollen Buckets werden

Wenn 47 Filter-Werte mehr abschrecken als helfen

Viele E-Commerce-Verantwortliche fragen sich: Warum springen Kundinnen von den Filtern zurück in die Suchleiste, obwohl die Sidebar jeden Wert sauber auflistet? Weil zu viele parallele Filter-Werte die Entscheidung erschweren statt sie zu erleichtern: Ab etwa zwölf Einzelwerten in einem Filter kippt die Nutzung. Computed Filters lösen das, indem sie aus 47 Roh-Werten fünf sinnvolle Buckets bauen. Das folgende Beispiel zeigt, wie schnell die klassische Filter-Sidebar ihre Kundin verliert.

Ein Donnerstag um 16:42 Uhr, ein DACH-weiter Online-Shop für Unterhaltungselektronik mit 38.000 SKUs. Eine Kundin sucht einen neuen Fernseher fürs Wohnzimmer. Sie klickt sich in die Kategorie "TV & Heimkino", landet auf einer Listing-Seite mit 612 Treffern und öffnet die Sidebar-Filter. Im Filter "Bildschirmgröße" stehen 47 einzelne Werte, von 19 Zoll bis 98 Zoll, jeweils als eigene Checkbox, alphanumerisch sortiert. Im Filter "Preis" stehen 89 unterschiedliche Preispunkte, von 199 Euro bis 8.999 Euro, ebenfalls als Einzelwerte. Im Filter "Marke" stehen 24 Hersteller, sortiert nach Häufigkeit, was an sich okay wäre, aber im Mobile-Drawer reichlich Platz beansprucht. Die Kundin scrollt drei Sekunden durch die Bildschirmgrößen-Liste, schließt den Filter wieder und tippt stattdessen in die Suchleiste "65 zoll fernseher unter 1000 euro". Was im Shop als gut gepflegte Filter-Auswahl gedacht war, hat sie zur Suche zurückgeschickt, weil die Filter-Anzeige sie überfordert hat.

Das ist nicht ein Einzelfall, das ist der Standardzustand vieler Shop-Suchen. Wir haben das verwandte Phänomen am Beispiel der Autocomplete-Vorschläge bereits beschrieben: ab sieben Vorschlägen kippt die Konversionsrate, weil die kognitive Last des Vergleichens den Sucheffekt aufhebt. Bei Filtern ist die Schwelle sogar enger. Ab etwa zwölf parallelen Werten in einem einzigen Filter kippt die Nutzung. Die Kundin hört auf zu filtern und greift zur Suche, oder, im schlechteren Fall, verlässt den Shop ganz.

Die Lösung ist nicht, Filter wegzulassen. Die Lösung ist, dass die Filter-Logik vor der Anzeige aus 47 Roh-Werten 5 sinnvolle Buckets baut, die der Kundin entlang ihrer realen Entscheidungsdimensionen die Auswahl erleichtern. Statt 47 Bildschirmgrößen-Werte sieht sie "bis 32 Zoll", "32 bis 50 Zoll", "50 bis 65 Zoll", "65 bis 75 Zoll", "über 75 Zoll". Statt 89 Preispunkte sieht sie "unter 500 Euro", "500 bis 1.000 Euro", "1.000 bis 2.000 Euro", "2.000 bis 5.000 Euro", "über 5.000 Euro". Die Zahl der Treffer pro Bucket steht daneben, der Bucket ist ein Single-Klick statt ein Scroll durch eine endlose Liste. Diese Aggregations-Schicht heißt Computed Filters.

Dieser Artikel beschreibt, wie Computed Filters in einer modernen Produktsuche funktionieren. Was der Unterschied zur klassischen Facettensuche ist. Wie die Bucket-Grenzen sinnvoll gewählt werden, regelbasiert oder ML-getrieben. Wie Filter-Hierarchie, Multi-Select, Counter und Mobile-Drawer zusammenspielen. Und wo die Hybrid LLM Search die deterministische Bucket-Logik um eine Natural-Language-Schicht ergänzt.

Facettensuche, Filtersuche, Computed Filters: was der Unterschied bedeutet

Facettensuche, Filtersuche, Computed Filters – ist das nicht ohnehin alles dasselbe?

Die Begriffe Facettensuche, Facettennavigation, Filtersuche und Computed Filters werden in der Praxis oft synonym verwendet, sie meinen aber unterschiedliche Konzepte mit unterschiedlichen Implikationen für die Implementierung.

Die klassische Filtersuche bietet dem Kunden eine feste Liste an Filter-Optionen, typisch in der Sidebar. Die Optionen werden vor der Suche definiert und ändern sich pro Suchanfrage nicht. Eine Filtersuche im Möbel-Shop zeigt immer "Material", "Farbe", "Preis", "Stilrichtung", unabhängig davon, ob die Trefferliste 30 oder 3.000 Treffer enthält. Der Filter ist eine UI-Komponente, kein semantischer Index.

Die Facettensuche ist die nächste Evolutionsstufe. Sie nutzt die tatsächlich indexierten Attribute der Treffer-Menge und blendet pro Suchanfrage nur die Filter ein, die in der aktuellen Treffer-Menge tatsächlich Werte haben. Wenn die Trefferliste nur Sofas enthält, zeigt die Facettensuche "Sitzplätze" und "Bezugsstoff" als Facetten, weil diese Attribute auf Sofas anwendbar sind. Sucht der Kunde nach Lampen, verschwinden diese Facetten und an ihre Stelle treten "Leuchtmittel" und "Lichtfarbe". Die Facettensuche ist dynamisch, der Filter folgt der Treffer-Menge.

Computed Filters sind die dritte Stufe. Sie nehmen die Facetten-Werte aus dem Index nicht als Roh-Daten, sondern aggregieren sie über eine Bucketing-Logik zu einer kleineren, sinnvolleren Anzahl an Anzeige-Buckets. Aus 47 Bildschirmgrößen werden 5 Größen-Klassen. Aus 89 Preispunkten werden 5 Preis-Klassen. Aus 24 Marken werden, je nach Sortier-Logik, die fünf Top-Marken plus ein "weitere Marken"-Bucket. Die Computed-Filter-Schicht steht zwischen Index und UI und ist der Punkt, an dem die UX gestaltet wird.

Der Unterschied ist nicht akademisch. Eine reine Facettensuche, die ohne Computed-Filter-Schicht alle Roh-Werte aus dem Index in die Sidebar kippt, produziert exakt den Eingangs-Effekt: 47 Checkboxen für Bildschirmgrößen, alphabetisch sortiert, ohne erkennbare Entscheidungs-Logik. Erst die Computed-Filter-Schicht macht die Facettensuche operativ nutzbar. Im weiteren Verlauf dieses Artikels nutzen wir den Begriff Facettensuche als Oberbegriff und Computed Filters als die operative Auspraegung, die in der Praxis funktioniert.

Eine vierte Komponente, die wir hier streifen, ist die Filter-Hierarchie. Manche Filter sind übergeordnet (Kategorie, Hersteller), andere sind nachgeordnet (Bildschirmgröße, Farbe). Computed Filters bedeuten nicht nur, dass jeder einzelne Filter sauber gebucket ist, sondern auch, dass die Hierarchie der Filter in der UI nach Entscheidungs-Relevanz sortiert ist. Ein Filter "Bildschirmdiagonale" gehört in einem TV-Shop weiter oben als ein Filter "Steckverbindung HDMI 2.1", weil die Diagonale die Kauf-Entscheidung stärker prägt.

Range-Filter sinnvoll bucketen: wie viele und wo die Grenzen ziehen

Bei welchen Filtern lohnt sich das Bucketing zuerst?

Range-Filter sind der häufigste Einsatzort für Computed Filters. Preis, Größe, Gewicht, Kapazität, Wattzahl, Bildschirmdiagonale, Akku-Laufzeit. Überall, wo numerische Werte das Sortiment strukturieren, sind Range-Buckets die Standard-UX-Antwort. Drei Fragen sind hier zu klären: wie viele Buckets, wo die Grenzen, und in welcher Reihenfolge.

Die Anzahl der Buckets folgt der gleichen UX-Regel wie die Autocomplete-Vorschläge. Drei bis sieben Buckets sind die operative Grenze. Drei sind zu wenig, weil sie keine sinnvolle Reduktion erzeugen. Sieben sind die Obergrenze, weil ab acht die Scan-Last wieder steigt. Fünf ist in den meisten Fällen die richtige Zahl, weil sie eine gerade Mitte zulässt und gleichzeitig links und rechts genug Spielraum für Edge-Cases lässt.

Die Lage der Bucket-Grenzen ist die anspruchsvollere Frage. Zwei Strategien sind in der Praxis verbreitet. Die erste ist die uniforme Verteilung. Der Wertebereich wird in fünf gleich große Intervalle aufgeteilt. Wenn die Preise im Sortiment von 199 bis 8.999 Euro reichen, sind die Grenzen bei 1.760, 3.320, 4.880 und 6.440 Euro. Das ist mathematisch sauber, aber operativ meist falsch, weil die Treffer-Verteilung im Sortiment nicht uniform ist. Die meisten Produkte liegen unter 1.500 Euro, der erste Bucket enthält am Ende 87 Prozent der Treffer, die anderen vier sind nahezu leer. Der Filter bringt keinen Reduktions-Nutzen.

Die zweite Strategie ist die quantil-basierte Verteilung. Die Bucket-Grenzen werden so gesetzt, dass jeder Bucket etwa gleich viele Treffer enthält. Aus der konkreten Treffer-Verteilung werden die Quantile bei 20, 40, 60 und 80 Prozent berechnet, und das sind die Bucket-Grenzen. Bei unserem Fernseher-Beispiel könnten die Grenzen dann bei 499, 799, 1.299 und 2.499 Euro liegen, weil sich dort die Treffer-Massen sammeln. Jeder Bucket enthält etwa 120 Treffer, der Reduktions-Nutzen ist hoch.

Die quantil-basierte Strategie hat einen Nachteil. Die Grenzen sind nicht intuitiv. "1.299 Euro" als Bucket-Grenze wirkt willkürlich. Die Kundin denkt in runden Schwellen: 500 Euro, 1.000 Euro, 2.000 Euro. Eine reine Quantil-Logik produziert krumme Grenzen, die das Vertrauen in die Filter-Logik untergraben.

Die operative Lösung ist eine Hybrid-Logik. Die Quantile werden berechnet, dann auf die nächste runde Schwelle gerundet. Der Algorithmus probiert die Runden-Schwellen, die in der Nähe des Quantils liegen, und wählt diejenige, die die Treffer-Verteilung am wenigsten verzerrt. Bei einem 20-Prozent-Quantil von 487 Euro wird auf 500 Euro gerundet, was die Verteilung kaum verändert. Bei einem 60-Prozent-Quantil von 1.412 Euro wird auf 1.500 Euro gerundet, weil 1.000 Euro die Treffer-Verteilung zu stark in den ersten Bucket schieben würde.

Die Reihenfolge der Bucket-Anzeige ist die dritte Frage. In Range-Filtern ist die natürliche Reihenfolge die richtige: aufsteigend von "unter X" nach "über Y". Ausnahmen gibt es nur in Spezialfällen, etwa bei Datums-Filtern, wo die Kundin typisch die jüngsten Treffer zuerst sehen will. Bei Preis-, Größen- und Gewichts-Filtern ist die aufsteigende Reihenfolge der Standard.

Eine vierte Komponente, die häufig übersehen wird, ist die Behandlung der Endpunkt-Buckets. "Unter 500 Euro" ist nach unten offen, "über 5.000 Euro" nach oben. Diese offenen Buckets müssen explizit modelliert sein, weil sie typisch die Long-Tail-Treffer enthalten, die ohne offenen Bucket aus dem Filter herausfallen würden. Ein Produkt zu 99 Euro gehört in den "unter 500 Euro"-Bucket, ein Produkt zu 7.999 Euro in den "über 5.000 Euro"-Bucket. Ohne offene Endpunkte muss der Algorithmus die Grenzen so weit setzen, dass alle Treffer abgedeckt sind, was die mittleren Buckets unscharf macht.

Range-Buckets setzen voraus, dass die zugrunde liegenden numerischen Werte sauber im Index liegen. Wenn Bildschirmgrößen mal als "65 Zoll", mal als "165 cm Diagonale" und mal als "65''" gepflegt sind, bekommt die Bucketing-Logik nie ein konsistentes Bild. Wir haben die Voraussetzung der sauberen Einheiten-Normalisierung in der Produktsuche im eigenen Beitrag im Detail beschrieben. Die Computed-Filter-Schicht baut auf der Normalisierungs-Schicht auf, beide gehören in eine moderne Such-Infrastruktur als verbundene Layer.

Regelbasierte Buckets vs. ML-getriebene Aggregation

Wie bündelt man Filter wie Marke oder Farbe, wo es keine Zahlengrenzen gibt?

Bei kategorischen Filtern (Marke, Material, Farbe) ist die Bucketing-Frage anders gelagert als bei Range-Filtern. Hier geht es nicht um numerische Grenzen, sondern darum, welche Roh-Werte zusammengefasst werden und welche separat bleiben.

Die regelbasierte Strategie nutzt vordefinierte Mappings. Ein Farb-Filter im Möbel-Shop hat 134 Roh-Farben aus den Hersteller-Daten ("Anthrazit", "Schiefer-Grau", "Steingrau", "Basaltgrau"). Ein Mapping fasst alle Grau-Töne zu einem einzigen Bucket "Grau" zusammen. Das gleiche gilt für "Beige", "Braun", "Weiß", "Schwarz". Aus 134 Roh-Farben werden zwölf Anzeige-Buckets. Die Mapping-Tabelle ist statisch und wird von der Sortiments-Pflege gepflegt.

Die Vorteile sind operative Stabilität und Erklärbarkeit. Die Kundin sieht immer die gleichen zwölf Farb-Buckets, der Shop-Betreiber weiß genau, welche Roh-Farbe in welchem Bucket landet. Die Pflege ist überschaubar, wenn die Roh-Werte-Menge nicht explodiert.

Die Nachteile sind Pflegeaufwand und Skalierungsgrenzen. Bei jedem neuen Lieferanten kommen neue Roh-Farben dazu, die manuell ins Mapping eingepflegt werden müssen. Bei einem Multi-Country-Sortiment mit 80 Lieferanten ist die Mapping-Tabelle nach sechs Monaten so groß, dass die Pflege ein eigener Halbtags-Job ist. Wir haben den verwandten Punkt zur Mehr-Markt-Logik im Beitrag zu Multi-Country Search-Infrastruktur ausführlich behandelt. Im Computed-Filter-Kontext kommt erschwerend dazu, dass die Mapping-Logik pro Markt unterschiedlich sein kann, weil Farb-Begriffe sprachlich verschieden geclustert sind.

Die ML-getriebene Strategie nutzt Clustering-Verfahren auf den Roh-Werten und den dazugehörigen Produkt-Daten. Die 134 Roh-Farben werden vektorisiert (entweder über Farb-Hex-Werte, wenn vorhanden, oder über semantische Embeddings der Farb-Namen), und ein Clustering-Algorithmus findet die natürlichen Gruppen in den Daten. Das Ergebnis ist eine automatische Bucket-Zuordnung, die mit den Daten wächst.

Die Vorteile sind Skalierbarkeit und Anpassungsfähigkeit. Neue Roh-Werte werden automatisch in den passenden Bucket einsortiert, ohne manuelle Pflege. Die Bucket-Struktur passt sich dem realen Sortiment an. Wenn ein neuer Trend Pastell-Töne in den Möbel-Markt bringt, entsteht automatisch ein "Pastell"-Bucket, sobald genug Roh-Werte dafür im Sortiment sind.

Die Nachteile sind Erklärungs-Bedarf und Edge-Cases. Die Kundin sieht eine Bucket-Aufteilung, die sie nicht direkt nachvollziehen kann ("Warum ist 'Champagne' im 'Beige'-Bucket und nicht im 'Gold'-Bucket?"). Der Shop-Betreiber muss in der Lage sein, die Bucket-Logik zu inspizieren und gegebenenfalls zu überstimmen. Eine reine Blackbox-Aggregation ist im operativen Betrieb selten brauchbar.

In der Praxis ist die hybride Variante meist die richtige Wahl. Die Top-Buckets (die häufigsten zehn bis fünfzehn Roh-Werte) werden regelbasiert gemappt, weil sie 80 Prozent der Treffer abdecken und die Pflege überschaubar ist. Die Long-Tail-Werte werden ML-basiert in die nächste passende Bucket einsortiert. Die Pflege bleibt machbar, die Skalierung funktioniert.

Eine wichtige Eigenschaft der Computed-Filter-Aggregation ist, dass sie sich von der Such-Relevanz-Berechnung trennen lässt. Die Bucket-Zuordnung ist eine UI-Aggregation, sie hat keinen Einfluss auf die Reihenfolge der Treffer innerhalb des Buckets. Die Treffer werden weiterhin nach Such-Relevanz und Listing-Score sortiert. Wir haben die mathematische Mechanik der gewichteten Sortierfaktoren im Beitrag zu Textscore vs Smarte Listings im Detail beschrieben. Im Computed-Filter-Kontext gilt: Bucket-Zuordnung ist UI, Innerhalb-Bucket-Sortierung ist Suche, beide Schichten sind operativ getrennt.

Filter-Hierarchie, Sortierung und Multi-Select

Reicht es, jeden einzelnen Filter sauber zu bucketen?

Computed Filters auf einem einzelnen Filter zu bauen reicht nicht. Eine moderne Filter-UI hat typisch acht bis fünfzehn Filter parallel, und die Reihenfolge dieser Filter in der Sidebar ist genauso entscheidend wie die Bucket-Aufteilung im einzelnen Filter.

Die Filter-Hierarchie folgt der Entscheidungs-Relevanz pro Sortiment. In einem TV-Shop ist die Bildschirmgröße in fast allen Such-Kontexten relevanter als die HDMI-Version, weil die Größe die Wohnzimmer-Eignung bestimmt und HDMI ein technisches Detail ist, das die meisten Kundinnen nicht aktiv filtern. Die Diagonale gehört also weiter oben in der Sidebar, HDMI weiter unten oder kollabiert.

Die Hierarchie ist nicht statisch über alle Kategorien gleich. In einem Möbel-Shop steht "Material" weit oben, in einem TV-Shop weit unten oder gar nicht. Eine saubere Filter-Logik ist deshalb kategorie-spezifisch konfigurierbar. Pro Kategorie wird die Filter-Reihenfolge entweder manuell gepflegt oder über die historischen Filter-Nutzungs-Daten automatisch ermittelt. Die häufig genutzten Filter wandern nach oben, die selten genutzten nach unten oder in einen "weitere Filter"-Bereich.

Eine zweite Frage ist Single-Select vs Multi-Select pro Filter. Single-Select erlaubt nur einen Bucket pro Filter ("Bildschirmgröße: 50 bis 65 Zoll"). Multi-Select erlaubt mehrere parallele Buckets ("Bildschirmgröße: 50 bis 65 Zoll ODER 65 bis 75 Zoll"). In der Praxis sind Range-Filter typisch Single-Select, weil sich die Buckets nicht überlappen und ein Multi-Select selten Sinn ergibt. Kategorische Filter (Marke, Farbe) sind typisch Multi-Select, weil die Kundin oft mehrere Marken parallel betrachten will.

Die Bool-Logik zwischen Filtern ist AND, innerhalb eines Filters bei Multi-Select OR. Ein Multi-Select auf "Marke: Sony ODER LG" kombiniert mit einem Range-Filter "Preis: 1.000 bis 2.000 Euro" liefert alle Sony- oder LG-Fernseher in der Preisspanne. Diese Logik muss konsistent für alle Filter gelten, sonst entstehen für die Kundin unverständliche Treffer-Mengen.

Die Sortierung der Bucket-Anzeige innerhalb eines Filters folgt zwei Regeln. Range-Buckets sortieren aufsteigend nach Wert. Kategorische Buckets sortieren nach Häufigkeit, also nach Anzahl der Treffer im Bucket. Die Marke mit den meisten Treffern steht oben. Bei Multi-Select ist diese Häufigkeits-Sortierung wichtig, weil die Kundin meist die Top-Marken filtern will, nicht die Long-Tail-Marken.

Eine spezielle Variante sind dependent filters, also Filter, deren Werte vom aktuellen Filter-Zustand abhängen. Wenn die Kundin "Marke: Sony" filtert, ändern sich die verfügbaren Werte für "Modellreihe", weil nur noch Sony-Modellreihen relevant sind. Ohne dependent filters sieht die Kundin "Sony Bravia", "LG OLED", "Samsung QLED" parallel, was zu Null-Treffer-Kombinationen führt. Mit dependent filters bleibt nur "Sony Bravia" sichtbar, sobald "Marke: Sony" aktiv ist.

Die Implementation der dependent filters ist nicht trivial. Jeder Filter-Klick muss die anderen Filter-Optionen neu berechnen, was bei großen Trefferlisten zu Performance-Problemen führt. Hier wird die Cookieless-Eigenschaft der BatteryIncluded-Such-Schicht relevant: die Berechnung der Filter-Optionen passiert im Backend ohne User-Tracking, ohne Profil-Aufbau, ohne Sitzungs-Daten. Die Filter-Antworten kommen aus der aktuellen Treffer-Menge, nicht aus historischen Nutzer-Daten. Das ist nicht nur DSGVO-konform, sondern auch performance-stabil, weil der Berechnungs-Pfad keine externen Profil-Datenquellen abfragen muss.

Eine Geschäftsführung aus einem österreichischen B2C-Shop für Versicherungen mit Direkt-Verkaufs-Komponente beschreibt den Effekt sauberer Computed-Filter-Hierarchie 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

Die Aussage "im Live-Betrieb sauber" trifft hier den Kern. Computed Filters wirken aus Kunden-Sicht nicht nach Algorithmus, sondern nach Selbstverständlichkeit. Die Filter sind dort, wo die Kundin sie erwartet, sie sind so gegliedert, dass jede Auswahl die Trefferliste sinnvoll reduziert, und sie kombinieren sich vorhersehbar.

Filter-Counter, Performance und das Live-Reduktions-Problem

Braucht wirklich jeder Bucket die Trefferzahl in Klammern daneben?

Computed Filters ohne Counter sind nur die halbe Lösung. Der Counter ist die Zahl in Klammern hinter jedem Bucket, die der Kundin zeigt, wie viele Treffer dieser Bucket bei aktivierter Auswahl liefern würde. "Bildschirmgröße: 50 bis 65 Zoll (142)". Ohne Counter weiß die Kundin nicht, ob sich der Klick lohnt. Mit Counter sieht sie sofort, dass dieser Bucket 142 Treffer enthält, der nächste vielleicht nur 28, und kann ihre Auswahl entsprechend treffen.

Die Counter-Anzeige hat eine versteckte Performance-Komponente. Wenn die Counter live aktualisiert werden, muss bei jedem Filter-Klick die Anzahl pro Bucket neu berechnet werden. Bei zehn parallelen Filtern mit je fünf Buckets sind das 50 separate Counter-Berechnungen pro Filter-Klick. Bei einer Trefferliste von 3.000 Produkten und zehn Filtern sind das 150.000 Produkt-Filter-Vergleiche pro Klick.

In der Praxis sind hier zwei Optimierungen üblich. Die erste ist die Bucket-Cache-Schicht. Die Counter pro Bucket werden pro Filter-Kombination gecacht. Sobald eine Kombination einmal berechnet ist, liegt der Counter im Cache und ist beim nächsten Aufruf in unter einer Millisekunde verfügbar. Die Cache-Hit-Rate ist bei typischen Shop-Sessions hoch, weil viele Kundinnen ähnliche Filter-Kombinationen nutzen.

Die zweite ist die Approximation für Long-Tail-Buckets. Buckets, die weniger als ein Prozent der Treffer enthalten, müssen nicht exakt gezählt werden, weil die Counter-Anzeige bei "(3)" oder "(7)" für die Kundin keinen Unterschied macht. Die Approximation liefert eine Schwellen-Aussage ("unter 10 Treffer") und spart Berechnungs-Aufwand.

Eine dritte Frage ist, ob die Counter live oder vorberechnet sein sollen. Live-Counter sind exakt, aber teuer. Vorberechnete Counter sind günstig, aber bei dynamischen Bestands- oder Preis-Änderungen veraltet. Die operativ richtige Wahl hängt vom Sortiments-Typ ab. Bei stabilen Sortimenten reicht eine nächtliche Vorberechnung. Bei dynamischen Sortimenten mit Live-Bestand und Live-Preisen ist eine Live-Berechnung mit aggressivem Caching die saubere Lösung.

Die Verbindung zur Live-Bestand-Logik ist eng. Wenn ein Bucket Treffer enthält, deren Bestand auf null gefallen ist, sollte der Counter diese Treffer nicht mehr mitzählen. Sonst klickt die Kundin auf "65 Zoll (142)" und sieht in der Trefferliste nur 138 Produkte, weil vier mittlerweile ausverkauft sind. Wir haben die Mechanik der Live-Bestand-Sync im Beitrag zu Live-ERP-Daten in der Shop-Suche im Detail beschrieben. Im Computed-Filter-Kontext ist die Bestand-Sync der Punkt, an dem die Counter ihre Vertrauenswürdigkeit gewinnen oder verlieren.

Eine spezielle Variante des Counter-Problems ist die Null-Bucket-Anzeige. Soll ein Bucket mit null Treffern angezeigt werden? Die meisten Shops verstecken Null-Buckets, was die UI bereinigt, aber den Effekt hat, dass die Kundin die Vollständigkeit der Filter-Optionen nicht mehr sieht. Eine bessere Lösung ist, Null-Buckets ausgegraut anzuzeigen, mit dem Counter "(0)". Damit weiß die Kundin, dass dieser Bucket strukturell existiert, in der aktuellen Treffer-Menge aber leer ist, und sie kann ihre Filter-Kombination anpassen.

Eine Geschäftsführung aus einem deutschen Großhandel für Werkzeug und Industriebedarf beschreibt die operative Wirkung der Counter-Stabilität so:

"Die Suche ist bei uns ein entscheidender Faktor für Conversion. BatteryIncluded liefert die Qualität und die Geschwindigkeit, die ein professioneller Großhandel braucht, und das Team versteht unser Geschäft."

G. Wurm GmbH & Co. KG

Die Aussage "Geschwindigkeit" verweist hier direkt auf die Counter-Performance. Eine Filter-UI, die bei jedem Klick eine halbe Sekunde wartet, bevor die neuen Counter erscheinen, ist im operativen Betrieb unbrauchbar.

Mobile-First: Filter-Drawer, Inline-Filter und Dynamische Anzeige

Muss die Filter-UX auf dem Smartphone anders gedacht werden als am Desktop?

Über 60 Prozent der E-Commerce-Sessions im DACH-Raum laufen mobil. Die Filter-UX muss auf mobilen Geräten genauso funktionieren wie auf Desktop, und sie hat dort eigene Constraints.

Auf Desktop ist die Standard-Filter-UX die Sidebar links neben der Trefferliste. Alle Filter sind ständig sichtbar, die Kundin sieht direkt, welche Optionen verfügbar sind, und klickt ohne Modal-Sprung. Auf Mobile ist das nicht praktikabel, weil der Bildschirm zu schmal ist. Hier sind zwei Pattern-Varianten verbreitet.

Die erste ist der Filter-Drawer. Ein Button "Filter" am oberen oder unteren Rand der Trefferliste öffnet eine modale Schublade von rechts oder unten, die alle Filter enthält. Die Kundin klickt sich durch die Filter, schließt den Drawer und sieht die gefilterte Trefferliste. Vorteil: alle Filter sind in einem strukturierten Bereich verfügbar, die Trefferliste bleibt sauber. Nachteil: die Filter-Auswahl ist ein eigener UX-Schritt, der den Flow unterbricht.

Die zweite ist der Inline-Filter. Die wichtigsten zwei bis drei Filter werden als horizontale Chip-Reihe direkt über der Trefferliste angezeigt, die restlichen Filter sind in einem "weitere Filter"-Drawer versteckt. Die Kundin sieht die Top-Filter direkt, kann sie mit einem Klick aktivieren, und greift nur bei Bedarf zum Drawer. Vorteil: die häufigen Filter sind im Flow erreichbar. Nachteil: die Auswahl der "wichtigsten" Filter muss korrekt sein, sonst landen die falschen Filter im Inline-Bereich.

In der Praxis hat sich eine Hybrid-Variante als optimal erwiesen. Die Top-Filter sind inline (typisch zwei bis drei Range-Filter, weil sie direkt im Bucket-Klick die Reduktion liefern). Der "weitere Filter"-Drawer öffnet sich für die restlichen Filter. Innerhalb des Drawers sind die Filter nach Entscheidungs-Relevanz sortiert. Die Kundin hat den schnellen Pfad für die häufigen Filter und den vollen Zugriff auf die seltenen.

Die dynamische Filter-Anzeige ist ein verwandter Punkt. Die Frage ist, welche Filter überhaupt angezeigt werden, abhängig vom aktuellen Suchkontext. Wir haben den Punkt eingangs in der Abgrenzung Facettensuche vs Filtersuche bereits gestreift. Im Mobile-Kontext kommt eine zweite Logik dazu. Filter, die im aktuellen Kontext nur einen einzigen Bucket-Wert haben (alle Treffer sind "Marke: Sony", weil die Kundin schon im Sony-Shop ist), sollten nicht angezeigt werden, weil sie keine Reduktion liefern. Filter, die im aktuellen Kontext mehr als einen Bucket haben, aber dessen Bucket-Verteilung extrem ungleichmäßig ist (99 Prozent in einem Bucket, 1 Prozent in einem zweiten), sind im Mobile-Bereich oft auch nicht hilfreich. Hier wird die Filter-Anzeige zu einer aktiven Kuratierungs-Frage, nicht zu einer reinen Abbildung der Index-Werte.

Die Performance ist auf Mobile besonders sensibel. Filter-Klicks dürfen keine harten Page-Reloads auslösen, die UI muss reaktiv aktualisieren. Hier hilft die Kombination aus Counter-Cache, AJAX-Updates und sauberer Loading-State-Anzeige. Die Kundin sieht beim Filter-Klick sofort einen Loading-Indicator, die Trefferliste aktualisiert in unter einer Sekunde, der Counter-Cache liefert die neuen Zahlen ohne sichtbare Latenz.

Cookieless Cohort-Lernen und Hybrid-LLM-Filter-Mapping

Lassen sich Filter datenbasiert optimieren, ohne einzelne Nutzer zu tracken?

Eine Schicht, die die deterministische Computed-Filter-Logik ergänzt, ist das Cohort-basierte Lernen aus aggregiertem Such- und Filter-Verhalten. Wir verwenden den Begriff bewusst in Abgrenzung zum klassischen User-Tracking. Die BatteryIncluded-Such-Schicht baut keine User-Profile, sie speichert keine personenbezogenen Sitzungs-Daten, sie ist vollständig cookieless. Was sie macht, ist die Aggregation von Such- und Filter-Mustern auf der Ebene des Sortiments, nicht der Person.

Konkret bedeutet das: die Such-Schicht beobachtet, welche Filter-Kombinationen in welchen Kategorien wie oft genutzt werden, welche Filter-Buckets wie oft zu einem Klick auf einen Treffer führen, welche Filter-Sequenzen typisch zu einem Kauf führen. Daraus entstehen aggregierte Muster auf Sortiments-Ebene, die der Computed-Filter-Logik als Optimierungs-Signal dienen. Welche Bucket-Grenzen erzeugen die höchste Click-Through-Rate? Welche Filter-Hierarchie produziert die wenigsten Filter-Abbrüche? Welche Buckets sind im Vergleich zu ihrer Treffer-Anzahl ungewöhnlich häufig oder ungewöhnlich selten geklickt?

Diese Cohort-Auswertung ist DSGVO-neutral, weil sie auf Sortiments-Ebene und nicht auf Personen-Ebene operiert. Sie liefert dem Shop-Betreiber Optimierungs-Hinweise, ohne dass er Cookies, Tracking-Pixel oder Sitzungs-Profile braucht. Die strukturelle Eigenschaft macht das System DSGVO-konform, ohne dass der Betreiber Compliance-Aufwand betreiben muss.

Eine zweite Ergänzung ist das Natural-Language-Mapping in den Computed-Filter-Layer. Die Kundin tippt nicht "Bildschirmgröße: 50 bis 65 Zoll" in die Suchleiste, sondern "fernseher fürs wohnzimmer" oder "großer fernseher unter 1000 euro". Die Hybrid LLM Search interpretiert diese natürliche Anfrage, mappt die impliziten Filter-Werte ("groß" = etwa über 55 Zoll, "Wohnzimmer" = typisch 50 bis 75 Zoll) auf die Computed-Filter-Buckets und liefert die passenden Treffer.

Die Mechanik funktioniert in beide Richtungen. Die Kundin kann mit natürlicher Sprache filtern, ohne die Filter-UI zu nutzen. Und die Filter-UI zeigt nach einer Natural-Language-Anfrage die aktiven Filter als sichtbare Chips an, sodass die Kundin sieht, welche Buckets das System gesetzt hat und sie bei Bedarf anpassen kann. Aus "fernseher fürs wohnzimmer" werden die aktiven Chips "Kategorie: TV", "Bildschirmgröße: 50 bis 75 Zoll". Die Kundin kann den Chip "50 bis 75 Zoll" anklicken, einen anderen Bucket wählen, und die Trefferliste reagiert sofort.

Die Reihenfolge ist hier wichtig. Die Computed-Filter-Schicht ist die Basis. Die Natural-Language-Schicht ist die Ergänzung, die die Kundin auf die deterministischen Buckets zugreifen lässt, ohne die Filter-UI nutzen zu müssen. Beide Schichten operieren auf demselben Index, demselben Bucket-System, derselben Treffer-Logik. Es gibt keine getrennten Wege, die zu unterschiedlichen Trefferlisten führen können.

Diese Architektur ist die Auspraegung der entkoppelten Infrastruktur, die wir als BatteryIncluded propagieren. Die Such-Schicht ist eigenständig, sie operiert unabhängig vom Shop-Backend, sie liefert die Filter- und Such-Logik als zentralen Layer. Die Computed Filters sind ein Beispiel dafür: eine UI-Verbesserung, die im Shop-Backend allein nie sauber lösbar wäre, weil sie auf eine spezialisierte Bucketing-, Cache- und Aggregations-Schicht angewiesen ist, die in keinem Standard-Shop-System out of the box mitgeliefert wird. Made in Germany als Hosting-Standort komplettiert das DACH-Vertrauens-Argument.

Was Sie diese Woche tun können

Wo fange ich an, wenn meine Filter-Sidebar heute noch Roh-Werte auflistet?

Wenn Sie heute eine klassische Filter-Sidebar mit langen Roh-Wert-Listen betreiben, ist die folgende Reihenfolge der pragmatische Einstieg.

Schritt eins ist die Filter-Inventur. Erheben Sie aus Ihrer Listing-Seite, wie viele Roh-Werte pro Filter in den Top-10-Kategorien Ihres Sortiments aktuell angezeigt werden. Wenn Sie pro Filter mehr als zehn Roh-Werte finden, ist Bucketing-Bedarf akut. Wenn Sie pro Filter mehr als 20 finden, ist die Filter-UI vermutlich der größte Conversion-Killer in Ihrer Listing-Seite.

Schritt zwei ist die Filter-Nutzungs-Analyse. Welche Filter werden in Ihren Top-Kategorien tatsächlich geklickt, welche nicht? Welche Filter-Kombinationen führen zu Käufen, welche zum Abbruch? Aus dieser Analyse kommt die Filter-Hierarchie, die in Ihrer Sidebar abgebildet sein sollte. Die häufig geklickten Filter gehören oben, die selten geklickten nach unten oder in den "weitere Filter"-Bereich.

Schritt drei ist die Bucket-Definition für die Top-Range-Filter. Wählen Sie die zwei bis drei Range-Filter mit der höchsten Nutzung (typisch Preis und eine kategorie-spezifische Größe) und definieren Sie fünf Buckets pro Filter. Nutzen Sie die quantil-basierte Logik mit Runden-Korrektur, sodass die Bucket-Grenzen sowohl die Treffer-Verteilung treffen als auch intuitiv lesbar sind.

Schritt vier ist die Bucket-Definition für die Top-Kategorischen Filter. Wählen Sie die Filter mit den meisten Roh-Werten (typisch Marke, Farbe, Material) und definieren Sie regelbasierte Mappings, die die Top-Buckets sauber abbilden. Die Long-Tail-Werte können vorerst in einen "weitere Werte"-Bucket gesammelt werden, bis Sie die ML-getriebene Aggregation einführen.

Schritt fünf ist die Mobile-Anpassung. Setzen Sie für Ihre wichtigsten Listing-Seiten den Filter-Drawer um, mit zwei bis drei inline Top-Filtern und einem "weitere Filter"-Drawer für die restlichen. Messen Sie die Filter-Nutzung auf Mobile vor und nach der Umstellung, der Effekt ist typisch im zweistelligen Prozentbereich für die Filter-Nutzungs-Rate.

Schritt sechs ist die Counter-Pflege. Stellen Sie sicher, dass Ihre Counter live aktualisieren und die Live-Bestand-Sync berücksichtigen. Ein Counter, der zwischen Filter-Klick und Trefferliste abweicht, ist ein Vertrauens-Bruch, der die Filter-Nutzung dauerhaft reduziert.

Diese sechs Schritte sind in jedem Fall sinnvoll, unabhängig davon, ob Sie später auf eine spezialisierte Such-Infrastruktur wechseln oder Ihre vorhandene Lösung optimieren. Was sie nicht ersetzen können, ist die operative Reife einer Such-Plattform, die die Computed-Filter-Logik standardisiert mitbringt, die Bucket-Definitionen pro Kategorie konfigurierbar macht, die Mobile-Drawer-Logik out of the box bedient und die Cohort-Auswertung zur kontinuierlichen Optimierung bereitstellt.

Häufige Fragen (FAQ)

Was ist Facettensuche im E-Commerce?

Facettensuche bezeichnet eine dynamische Filter-UI, die pro Suchanfrage nur die Filter-Werte aus den tatsächlichen Index-Attributen der aktuellen Treffer-Menge anzeigt. Im Gegensatz zur klassischen Filtersuche, die eine feste Liste an Optionen ausspielt, passt sich die Facettensuche dem Sortiments-Kontext an. Sucht die Kundin Sofas, sieht sie Facetten wie "Sitzplätze" und "Bezugsstoff". Sucht sie Lampen, sieht sie "Leuchtmittel" und "Lichtfarbe". Die operative Auspraegung der Facettensuche, die in der Praxis funktioniert, sind Computed Filters, die die Roh-Werte aus dem Index zu sinnvollen Anzeige-Buckets aggregieren, statt sie ungefiltert anzuzeigen.

Was ist der Unterschied zwischen Facettensuche und Filtersuche?

Filtersuche bietet eine feste Liste an Filter-Optionen, die vor der Suche definiert werden und sich pro Suchanfrage nicht ändern. Facettensuche nutzt die tatsächlich indexierten Attribute der Treffer-Menge und blendet nur die Filter ein, die in der aktuellen Treffer-Menge Werte haben. Die Facettensuche ist dynamisch, der Filter folgt der Treffer-Menge. Computed Filters sind die nächste Evolutionsstufe, sie aggregieren die Facetten-Werte zu sinnvollen Anzeige-Buckets, statt sie als Roh-Liste auszuspielen. Aus 47 Bildschirmgrößen-Werten werden fünf Größen-Klassen, aus 89 Preispunkten fünf Preis-Klassen.

Welche 4 Filtertypen gibt es in der Produktsuche?

Vier Filter-Typen decken den größten Teil der E-Commerce-Filter-Anwendungsfälle ab. Range-Filter operieren auf numerischen Werten und liefern Bucket-Grenzen wie "unter 500 Euro" oder "50 bis 65 Zoll". Kategorische Filter operieren auf diskreten Werten wie Marke, Farbe oder Material und werden typisch als Checkbox-Liste angezeigt. Boolean-Filter operieren auf Ja-Nein-Eigenschaften wie "verfügbar" oder "Sale" und werden als Toggle angezeigt. Hierarchische Filter operieren auf Baum-Strukturen wie Kategorie oder Modell-Reihe und werden als geschachtelte Auswahl angezeigt. Computed Filters sind keine fünfte Klasse, sondern eine Aggregations-Schicht, die auf allen vier Typen aufsetzen kann.

Wie funktioniert ein dynamischer Filter?

Ein dynamischer Filter berechnet seine Anzeige-Optionen aus der aktuellen Treffer-Menge, nicht aus einer statischen Liste. Bei jedem Filter-Klick wird die Treffer-Menge neu bestimmt, und die verbleibenden Filter-Optionen werden neu berechnet. Wenn die Kundin "Marke: Sony" auswählt, ändern sich die Optionen für "Modellreihe", weil nur noch Sony-Modellreihen relevant sind. Die Counter pro Bucket aktualisieren live, sodass die Kundin immer sieht, wie viele Treffer ein Klick liefern würde. Die Performance-Voraussetzung für dynamische Filter ist eine schnelle Aggregations-Schicht im Such-Backend, typisch mit Bucket-Cache und Counter-Approximation für Long-Tail-Werte.

Wie viele Filter-Buckets sind sinnvoll pro Filter?

Drei bis sieben Buckets pro Filter sind die operative Grenze. Drei sind meist zu wenig, weil sie keine sinnvolle Reduktion liefern. Sieben sind die Obergrenze, weil ab acht die Scan-Last der Kundin wieder steigt. Fünf ist in den meisten Fällen die richtige Zahl, weil sie eine gerade Mitte zulässt und genug Spielraum für Edge-Cases lässt. Bei kategorischen Filtern mit vielen Long-Tail-Werten ist eine Hybrid-Logik üblich: die Top-fünf-Buckets werden explizit angezeigt, die restlichen werden in einem "weitere Werte"-Bucket gesammelt oder ausgeblendet, je nachdem wie häufig die Long-Tail-Werte tatsächlich geklickt werden.

Wie wählt man die Grenzen für Range-Filter sinnvoll?

Die operativ richtige Strategie ist eine quantil-basierte Verteilung mit Rundungs-Korrektur. Aus der konkreten Treffer-Verteilung werden die Quantile bei 20, 40, 60 und 80 Prozent berechnet, sodass jeder Bucket etwa gleich viele Treffer enthält. Die Quantile werden anschließend auf die nächste runde Schwelle gerundet (500 Euro, 1.000 Euro, 1.500 Euro statt 487 Euro, 1.020 Euro, 1.487 Euro), sodass die Bucket-Grenzen intuitiv lesbar sind. Eine reine uniforme Verteilung über den Wertebereich produziert in der Praxis fast immer unausgewogene Buckets, weil die Treffer-Verteilung im Sortiment selten uniform ist. Die Endpunkt-Buckets sollten offen modelliert sein ("unter X", "über Y"), damit Long-Tail-Werte nicht aus dem Filter herausfallen.

Was sind Computed Filters und wie unterscheiden sie sich von normalen Filtern?

Computed Filters sind eine Aggregations-Schicht zwischen Index und UI, die die Roh-Werte aus dem Such-Index zu sinnvollen Anzeige-Buckets bündelt. Ein normaler Filter würde alle 47 Bildschirmgrößen-Werte aus dem Index als 47 Checkboxen anzeigen. Ein Computed Filter aggregiert sie regelbasiert oder ML-getrieben zu fünf Größen-Klassen ("bis 32 Zoll", "32 bis 50 Zoll", "50 bis 65 Zoll", "65 bis 75 Zoll", "über 75 Zoll"). Die Computed-Filter-Schicht ist konfigurierbar pro Kategorie, sie kann Range-Filter quantil-basiert bucketen und kategorische Filter über Mappings oder Clustering zusammenfassen. Die UI wird damit übersichtlich, die Kundin trifft Entscheidungen entlang ihrer realen Dimensionen, nicht entlang der zufälligen Roh-Wert-Vielfalt aus den Lieferanten-Daten.

Funktionieren Computed Filters auch im Mobile-Bereich?

Computed Filters sind im Mobile-Bereich besonders wichtig, weil der Bildschirm zu schmal für lange Roh-Wert-Listen ist. Die Standard-Mobile-UX ist ein Filter-Drawer, der über einen Button "Filter" geöffnet wird, plus zwei bis drei inline Top-Filter direkt über der Trefferliste. Die Top-Filter sind typisch Range-Filter mit Computed Buckets (Preis, Größe), die direkt im Bucket-Klick die größte Reduktion liefern. Die restlichen Filter sind im Drawer organisiert, sortiert nach Entscheidungs-Relevanz. Die Performance muss reaktiv sein, Filter-Klicks dürfen keine harten Page-Reloads auslösen, die UI aktualisiert über AJAX, die Counter kommen aus dem Bucket-Cache. Ohne Computed Filters ist die Mobile-Filter-UX in der Praxis nicht brauchbar, mit Computed Filters wird sie zur natürlichen Reduktions-Schicht zwischen Suche und Treffer.

Bereit für Filter, die aus 47 Werten 5 sinnvolle Buckets machen?

Saubere Computed Filters in der Produktsuche sind kein kosmetisches UI-Detail, sondern eine strukturelle Entscheidung über die Reduktions-Logik Ihrer Listing-Seiten. Wer hier sauber baut, gewinnt Filter-Nutzungs-Rate, Click-Through-Rate auf den Treffern und Conversion-Rate über das gesamte Sortiment, weil die Kundin nicht mehr durch 47 Roh-Werte scrollt, sondern fünf sinnvolle Buckets in unter zwei Sekunden überblickt. Volt Search® von BatteryIncluded ist als entkoppelte Infrastruktur konzipiert, die die Computed-Filter-Schicht out of the box mitbringt, Range-Filter quantil-basiert mit Runden-Korrektur bucketet, kategorische Filter über regelbasierte Mappings und ML-Clustering aggregiert, Filter-Hierarchien pro Kategorie konfigurierbar macht und die Mobile-Drawer-Logik mit inline Top-Filtern und Counter-Cache standardisiert bedient. Hybrid LLM Search ergänzt die Natural-Language-Schicht für Anfragen wie "fernseher fürs wohnzimmer unter 1000 euro" und mappt sie auf die deterministischen Buckets. Cookieless, DSGVO-konforme KI, Made in Germany, ohne dass Sie eigene Bucketing-Algorithmen bauen, pro Kategorie eigene Filter-Logiken pflegen oder die Mobile-UX aus Standard-Komponenten zusammensetzen müssen.

Zu Ihrer kostenlosen Demo und erleben Sie live an Ihren eigenen Produktdaten, wie Volt Search® aus 47 Bildschirmgrößen-Werten fünf sinnvolle Buckets baut, wie die quantil-basierte Bucket-Logik die Treffer-Verteilung sauber trifft und gleichzeitig runde Grenzen produziert, wie die Filter-Hierarchie pro Kategorie konfiguriert und die Mobile-Drawer-UX mit inline Top-Filtern und Counter-Cache reaktiv reagiert. Ohne eigene Bucketing-Algorithmen, ohne pflege-intensive Mapping-Tabellen, ohne lange Setup-Phase.