Einheiten-Normalisierung in der Produktsuche: Warum 5000g ≠ 5kg ein Conversion-Killer ist

Der teuerste Filter ist der, der zwei Drittel des Sortiments ausblendet

Viele Shop-Betreiber fragen sich: Warum zeigt der Filter "ab 5 kg" nur einen Bruchteil der eigentlich passenden Produkte? Weil die Suche auf dem rohen Einheits-String filtert und alles ausblendet, was als "5000 g", "11 lb" oder "5er Pack à 1 kg" gepflegt ist, obwohl es physikalisch passt. Die Lösung ist eine Einheiten-Normalisierung, die alle Angaben auf einen gemeinsamen Zahlenwert im Index bringt. Das folgende Beispiel zeigt, wie teuer diese Lücke im Alltag wird.

Ein Donnerstag um 14:18 Uhr, ein B2B-Großhandel für Tiernahrung mit 12.000 SKUs. Ein Hundetrainer sucht Trockenfutter für seine Hundepension. Er gibt "Trockenfutter Hund" in die Suchleiste und filtert über die Sidebar "Gewicht ab 5 kg". Die Trefferliste schrumpft von 312 Treffern auf 47. Der Trainer scrollt durch, findet drei Marken, klickt auf die erste. Im Warenkorb-Schritt sieht er, dass es noch zwölf weitere Größen derselben Marke gibt, einige davon im 5000-Gramm-Beutel und im 5-Pfund-Sack, die seiner Suche entsprochen hätten. Er hat sie nie gesehen, weil das Sidebar-Filter nur Produkte gezeigt hat, deren Gewichtsangabe als reine kg-Zahl im Index stand. Alles, was als "5000 g" oder "5 lb" oder "10er Pack à 500 g" gepflegt war, ist herausgefallen.

Das ist nicht ein einzelner Bug, das ist der Standardzustand vieler Shop-Suchen. Lieferanten liefern Produktdaten in Dutzenden Einheits-Konventionen, jede Importroutine kippt sie roh in den Index, das Sidebar-Filter rechnet auf einer Spalte und blendet aus, was nicht passt. Aus Sicht des Kunden sieht das aus wie ein dünnes Sortiment. Aus Sicht der Conversion-Rate ist es ein Verlust, der nicht im Logfile auftaucht, weil der Kunde keine null Treffer sieht. Er sieht 47 statt 312 und denkt, mehr habe der Shop nicht.

Dieser Artikel beschreibt, wie Einheiten-Normalisierung in einer modernen Produktsuche funktioniert. Welche acht Einheiten-Klassen ein E-Commerce-Index typisch sauber halten muss. Wie Compound-Strings wie "500ml", "0.5L" oder "½ Liter" zuverlässig geparst werden. Wo die Normalisierung architektonisch hingehört, in die Indexierung oder in die Query-Zeit. Wie der Multi-Country-Kontext die Sache verschärft. Und wo die rein deterministische Normalisierung an Grenzen kommt, an denen die Hybrid LLM Search eine semantische Ergänzung leistet.

Warum Produktdaten in unterschiedlichen Einheiten ankommen

Woher stammen die vielen unterschiedlichen Einheits-Konventionen in Ihren Produktdaten überhaupt?

Bevor wir über die Lösung sprechen, lohnt der Blick auf die Ursache. Produktdaten sind in einer langen Lieferanten-Kette entstanden und passieren typisch fünf bis sieben Übergaben, bevor sie im Shop-Index landen. Hersteller, Importeur, Großhändler, PIM-Pflege, ERP-Schnittstelle, Such-Index. An jeder Übergabe entstehen Konventions-Brüche.

Erstens die Verpackungsangabe. Ein Hersteller in Süddeutschland schreibt "5 kg Sack". Ein französischer Hersteller schreibt "5 kg" ohne Verpackungs-Form. Ein US-Lieferant schreibt "11 lb bag". Ein japanischer Importeur schreibt "5000 g (5 kg)". Alle vier meinen dasselbe Produkt-Gewicht, aber im Index liegen vier verschiedene Strings.

Zweitens die unterschiedlichen Bezugs-Niveaus. Manche Lieferanten geben das Gewicht pro Einzelartikel an ("500 g pro Dose"). Andere geben das Gesamtgewicht des Verkaufs-Gebindes an ("12 Dosen à 500 g = 6 kg"). Wieder andere geben beides als zwei separate Attribute. Die Such-Logik muss zwischen "Gewicht pro Stück" und "Gewicht pro Verkaufs-Einheit" unterscheiden, sonst ist ein Sechs-Kilo-Pack im 500-Gramm-Filter falsch eingeordnet.

Drittens die Sprach-Konventionen. Ein deutscher Datensatz kennt "Liter", "ml", "kg". Ein englischer kennt "L", "ml", "kg". Ein US-Datensatz kennt "fl oz", "lb", "in". Ein französischer kennt "litre" und "kg". Multi-Country-Shops bekommen alle Konventionen gleichzeitig, weil Sortimente aus verschiedenen Quellen zusammenlaufen.

Viertens die Compound-Notation. Lieferanten schreiben Mengen in einer Vielzahl von Schreibweisen, oft sogar innerhalb desselben Katalogs inkonsistent. "500ml" ohne Leerzeichen, "500 ml" mit Leerzeichen, "500ML" in Großbuchstaben, "0,5l" mit Komma, "0.5L" mit Punkt, "1/2 l" als Bruch, "½ Liter" mit Unicode-Bruch, "halbe Liter" als Wort. Alle bezeichnen denselben Wert. Eine simple String-Übernahme in den Index produziert hier acht verschiedene Index-Einträge für denselben physikalischen Wert.

Fünftens die Lieferanten-spezifischen Eigen-Konventionen. Manche Branchen verwenden Begriffe wie "Strebenlänge", "Wirkstoffkonzentration", "Schüttdichte", die ohne Kontext nicht eindeutig in eine SI-Basis-Einheit übersetzbar sind. Ein PIM, das alle Branchen abdeckt, hat hier Hunderte Sonderfälle.

Diese fünf Quellen führen dazu, dass selbst gepflegte Produktdaten im Index in einer Vielfalt an Einheiten-Strings liegen, die ohne Normalisierungs-Schicht für jeden Filter und jede Sortierung problematisch sind. Die Standard-Such-Lösung ignoriert das Problem und verlässt sich darauf, dass die Pflege "sauber" ist. In Wahrheit ist das nie der Fall, und je größer der Katalog, desto mehr Konvention-Brüche bleiben unentdeckt.

Acht Klassen, die jede Produktsuche normalisieren muss

Welche Einheiten-Klassen deckt ein Shop-Index ab, um den Großteil der Filter-Fälle zu erschlagen?

In der Praxis decken acht Datenklassen den größten Teil der Normalisierungs-Arbeit ab. Jede Klasse hat eine SI- oder Quasi-SI-Basis-Einheit, in die alle Einheiten dieser Klasse umgerechnet werden sollten.

Erstens Gewicht. Basis-Einheit: Kilogramm (kg). Umzurechnen aus: g, mg, t, lb, oz, stone, gr (Gran). Ein Produkt mit "5000 g" wird zu "5 kg". Ein Produkt mit "11 lb" wird zu "4,99 kg". Ein Produkt mit "0,5 t" wird zu "500 kg". Die Konversions-Tabelle ist klein und stabil, die Implementierung trivial, sobald die Tokenisierung sitzt.

Zweitens Volumen. Basis-Einheit: Liter (l). Umzurechnen aus: ml, cl, dl, hl, gal (US und UK unterschiedlich), fl oz (US und UK unterschiedlich), pint (US und UK unterschiedlich). Die Gallone ist die operative Falle: ein US-Gallon hat 3,785 Liter, ein UK-Gallon hat 4,546 Liter. Ohne Markt-Kontext ist die Konversion mehrdeutig.

Drittens Länge. Basis-Einheit: Meter (m). Umzurechnen aus: mm, cm, dm, km, in, ft, yd, mi. Im Möbel-, Bau- und Industrie-Sortiment ist die Längen-Normalisierung essentiell, weil Konfigurationen oft auf Millimeter-genaue Angaben angewiesen sind, aber im Suchfilter in Zentimeter oder Meter ausgespielt werden.

Viertens Fläche. Basis-Einheit: Quadratmeter (m²). Umzurechnen aus: cm², dm², km², sq in, sq ft, ar, ha. Im Garten- und Bau-Sortiment sind Quadrat-Einheiten häufig, im Fliesen- und Bodenbelag-Sortiment sogar zentral für die Mengen-Kalkulation.

Fünftens Stückzahl und Pack-Größe. Basis-Einheit: Stück. Umzurechnen aus: Dutzend, Schock (60), Großhundert (120), Gros (144), Paar (2), Set (kontextabhängig), Karton (kontextabhängig). Die kontextabhängigen Einheiten sind die Falle: ein "Karton" kann sechs, zwölf oder vierundzwanzig Stück enthalten, je nach Hersteller-Konvention. Hier muss das PIM die Auflösung mitliefern.

Sechstens Verpackungs-Einheit. Hier wird keine physikalische Einheit normalisiert, sondern eine logistische Struktur. Ein Produkt kann als Einzelpack, als 6er-Pack, als 12er-Tray, als 144er-Palette geliefert werden. Die Such-Logik braucht hier die Trennung zwischen Endkunden-Einheit (was bestellt der Kunde) und Logistik-Einheit (was wird im ERP geführt). Im Index ist beides nötig, der Filter spielt nur die Endkunden-Einheit aus.

Siebtens Energie und Leistung. Basis-Einheiten: Joule (J), Wattstunden (Wh), Watt (W). Umzurechnen aus: kJ, MJ, kcal, kWh, MWh, PS, HP, BTU. Im Elektro-, Solar-, Heizungs-, KFZ- und Lebensmittel-Sortiment sind diese Einheiten zentral. Ein Akkumulator mit "3000 mAh" und "11,1 V" hat eine berechnete Kapazität von 33,3 Wh, was wiederum für die Versand-Regulierung (Lithium-Batterie-Transport) relevant ist. Die Normalisierung muss hier auch berechnete Folge-Größen unterstützen.

Achtens Konzentration und Dichte. Basis-Einheiten: g/l, mol/l, Prozent (Vol oder Gew). Im Chemie-, Pharma-, Lebensmittel- und Reinigungs-Sortiment sind Konzentrationen ein zentrales Filter-Kriterium. "5%" kann Volumen-Prozent oder Gewichts-Prozent oder mol-basiert sein. Eine saubere Normalisierung verlangt hier zusätzlich den Bezugs-Typ als Metadatum, weil der Wert ohne Bezugs-Typ nicht aussagekräftig ist.

Diese acht Klassen decken nach unserer Erfahrung etwa 95 Prozent der Filter-Anwendungsfälle in DACH-E-Commerce ab. Branchen-spezifische Spezial-Einheiten (Industrie-Schaltleistung, medizinische Dosen, Edelmetall-Feinheiten) kommen on top und sollten als eigene Klassen modelliert werden, nicht in den acht Standard-Klassen vermischt.

Compound-Einheiten parsen: "500ml", "0.5L", "½ Liter"

Wie lassen sich verschachtelte Schreibweisen wie "500ml", "0.5L" oder "½ Liter" zuverlässig auseinandernehmen?

Sobald klar ist, in welche SI-Basis normalisiert wird, kommt die zweite Hürde: das Parsen der Einheits-Strings aus den Lieferanten-Daten. Eine naive Implementation mit einer einzigen Regex bricht früh zusammen, weil die Variationsbreite zu groß ist.

In der Praxis braucht es eine mehrstufige Tokenizing-Pipeline. Im ersten Schritt wird der String normalisiert: Unicode-Brüche (½, ¼, ¾) werden zu Dezimalzahlen, Komma-Dezimaltrennzeichen werden zu Punkten (oder umgekehrt, je nach Locale), Mehrfach-Leerzeichen werden zu einem Leerzeichen, Groß- und Kleinschreibung der Einheits-Suffixe wird vereinheitlicht. Aus "0,5 L" und "½ Liter" und "0.5L" wird intern ein vergleichbares Tokens-Tupel.

Im zweiten Schritt wird der Wert vom Einheits-Suffix getrennt. Hier sind die Sonderfälle: kein Leerzeichen ("500ml" vs "500 ml"), zusammengesetzte Werte ("3 Stück à 500 g"), Bereichs-Angaben ("500 bis 750 g", "5 - 10 kg"), Tropft-Angaben ("ca. 5 kg", "ab 5 kg", "max 5 kg"). Eine saubere Pipeline erkennt Bereiche und Modifikatoren als eigene Tokens und speichert sie als Metadaten zum normalisierten Wert.

Im dritten Schritt wird das Einheits-Suffix gegen ein Lexikon geprüft. Hier ist die Pflege entscheidend. Das Lexikon listet pro Einheit alle bekannten Schreibweisen ("ml", "Milliliter", "Mililiter" als Tippfehler, "mL", "ML") und ordnet sie der SI-Basis zu. Tippfehler und Großbuchstaben-Varianten gehören ins Lexikon, weil sie in der Praxis sonst die Konsistenz brechen.

Im vierten Schritt wird der Wert in die Basis-Einheit umgerechnet. Aus "500 ml" wird "0,5 l". Aus "5000 g" wird "5 kg". Der Original-String bleibt als Display-Wert im Index, der normalisierte Wert kommt als zusätzliches numerisches Feld dazu. Filter und Sortierung arbeiten ausschließlich auf dem numerischen Feld, die Anzeige greift auf den Display-Wert zurück.

Edge-Cases bleiben und müssen explizit behandelt werden. "1/2 Pfund" ist ein deutsches Halbpfund (250 g), nicht ein halbes US-Pound (227 g). "Liter" als ausgeschriebenes Wort und "l" als Einbuchstabe-Suffix müssen beide erkannt werden, dabei darf "l" nicht versehentlich Bestandteil eines anderen Wortes sein (etwa in "5l" am Ende eines Produktnamens, wo "5l" tatsächlich Liter meint, vs "5l" als Tippfehler für "51"). Die kontext-sensitive Erkennung ist hier wichtiger als die Regex-Komplexität.

Tippfehler in Einheits-Strings sind ein eigenes Thema, das wir in unserem Beitrag zu Fehlertoleranz und Tippfehler-Korrektur ausführlich behandelt haben. Die dort beschriebene Levenshtein-basierte Korrektur greift auch für Einheits-Suffixe, wenn das Lexikon entsprechend aufgesetzt ist. "Mililiter" wird zu "Milliliter", "Lieter" wird zu "Liter", ohne dass jeder Tippfehler manuell gepflegt werden muss.

Index-Zeit vs Query-Zeit: wo gehört die Normalisierung hin?

An welcher Stelle der Such-Pipeline gehört die Umrechnung eigentlich hin?

Die Architektur-Frage ist, an welcher Stelle in der Such-Pipeline die Normalisierung passiert. Zwei Hauptstrategien sind möglich, jede mit eigenen Konsequenzen.

Die erste Strategie ist die Normalisierung zur Index-Zeit. Beim Importieren eines Produkts wird der Einheits-String geparst, in die SI-Basis umgerechnet und als zusätzliches numerisches Feld im Index abgelegt. Das Such-Backend arbeitet ausschließlich auf dem normalisierten Feld. Vorteil: die Query-Zeit ist schnell, weil keine Parsing-Arbeit pro Anfrage anfällt. Nachteil: jede Änderung am Parsing-Lexikon erfordert ein Reindexing, was bei großen Katalogen Stunden dauern kann.

Die zweite Strategie ist die Normalisierung zur Query-Zeit. Der Original-String bleibt im Index, das Such-Backend parst pro Anfrage on the fly. Vorteil: Lexikon-Änderungen wirken sofort, ohne Reindexing. Nachteil: jede Anfrage zahlt die Parsing-Latenz, was bei Hochlast-Phasen problematisch wird.

In der Praxis ist die Index-Zeit-Strategie die operativ richtige Wahl, mit einer Ergänzung. Das normalisierte numerische Feld wird beim Import berechnet, der Original-String bleibt für die Anzeige erhalten. Lexikon-Änderungen lösen ein Differential-Reindexing aus, das nur die betroffenen Produkte neu rechnet, nicht den gesamten Katalog. Damit sind sowohl Performance als auch Pflege-Geschwindigkeit handhabbar.

Eine Sonderform ist die hybride Strategie. Die häufigen Einheits-Klassen (Gewicht, Volumen, Länge) werden index-zeit-normalisiert. Die seltenen oder kontext-sensitiven Klassen (Konzentration, Verpackungs-Einheit mit Hersteller-spezifischer Auflösung) werden query-zeit-normalisiert. Damit wird die Index-Größe begrenzt, ohne dass die Pflege-Latenz auf den seltenen Fällen leidet.

Ein verwandter Punkt zur Architektur-Trennung von indexierten Stamm-Daten und query-zeit-berechneten Personalisierungen findet sich in unserem Beitrag zu Live-ERP-Daten in der Shop-Suche. Die dort beschriebene Trennung zwischen statischen Index-Feldern und dynamischen Query-Berechnungen gilt analog für die Einheiten-Normalisierung. Statisch normalisierbare Werte kommen in den Index. Kunden-spezifische oder kontextabhängige Umrechnungen kommen in die Query-Schicht.

Filter, Sortier-Logik, Aggregations-Bucket

Was gewinnt die Such-Oberfläche konkret, sobald die Einheiten sauber normalisiert im Index liegen?

Sobald die Werte normalisiert im Index liegen, profitiert die UI in drei konkreten Funktionen.

Erstens der Range-Filter. Ein Sidebar-Filter "Gewicht ab 5 kg" wird zum simplen numerischen Range-Query auf dem normalisierten Feld. Alle Produkte, deren normalisierter Gewichts-Wert größer oder gleich 5 ist, kommen in die Trefferliste, unabhängig davon, ob im Display-String "5 kg", "5000 g" oder "11 lb" steht. Das schließt das Eingangs-Beispiel des Hundetrainers: er sieht nicht mehr 47 Treffer, sondern alle 312, weil die Filter-Logik nicht mehr am String hängt, sondern am numerischen Wert.

Zweitens die Sortier-Logik. Eine Sortierung "aufsteigend nach Gewicht" greift auf das normalisierte Feld zurück. Ohne Normalisierung würde eine String-Sortierung "5000 g" alphabetisch vor "5 kg" platzieren, was numerisch falsch ist. Mit Normalisierung kommen die Produkte in der physikalisch sinnvollen Reihenfolge.

Drittens der Aggregations-Bucket. Eine Facette "Gewicht (kg)" mit den Buckets "0 bis 1", "1 bis 5", "5 bis 10", "10+" zählt korrekt, weil jedes Produkt in genau einem Bucket landet. Ohne Normalisierung würde ein "5000 g"-Produkt entweder in keinen Bucket fallen (wenn die Buckets nur kg-Strings prüfen) oder in einen falschen (wenn die Aggregation den numerischen Wert aus dem String parsiert und dabei die Einheit ignoriert).

Die Aggregations-Mechanik hat eine zweite Ebene. Innerhalb eines Buckets sollen Produkte sinnvoll sortiert werden. Ein 5-kg-Sack und ein 6-Kilo-Sack sollen im Bucket "5 bis 10 kg" in der textlichen Such-Relevanz konkurrieren, nicht in der Gewichts-Reihenfolge. Eine saubere Implementation entkoppelt die Bucket-Zuweisung (numerisch) von der Innerhalb-Bucket-Sortierung (Textscore). Wir haben die mathematische Mechanik der gewichteten Sortier-Faktoren in unserem Beitrag zu Textscore vs Smarte Listings im Detail beschrieben.

Eine Folge-Komplikation entsteht bei der Gruppierung von Varianten. Wenn ein Hundefutter in den Größen 1 kg, 2,5 kg, 5 kg, 10 kg und 15 kg angeboten wird, sollen in der Trefferliste typisch nur die Mutter-Karte sichtbar sein, mit der Variante, die zum aktuellen Filter passt, als Default-Auswahl. Die Mechanik der Gruppen-Aggregation auf der normalisierten Einheit ist in unserem Beitrag zu Gruppierungslogik in der Shop-Suche beschrieben. Die Einheiten-Normalisierung ist der Daten-Layer, auf dem die Gruppierung erst sauber operieren kann.

Eine Geschäftsführung aus einem Großhandel für Industrie-Bedarf beschreibt den Effekt einer sauberen Einheiten-Normalisierung in der Suche so:

"Was uns bei BatteryIncluded überzeugt hat, ist die Kombination aus echter Suchqualität und einem unkomplizierten, partnerschaftlichen Onboarding. Die Lösung greift nahtlos und macht unseren Shop für Kund:innen spürbar besser. Wir empfehlen das Team uneingeschränkt weiter."

B&W Bindlach Großhandels GmbH

Die Aussage "spürbar besser" trifft hier den Kern. Aus Kunden-Sicht wirkt eine sauber normalisierte Such-Schicht nicht nach Technik, sondern nach Selbstverständlichkeit. Der Filter "ab 5 kg" findet alle 5-Kilo-Produkte, ohne dass der Kunde sich Gedanken über die Einheit machen muss.

Imperial vs Metric in Multi-Country-Shops

Was passiert mit der Einheiten-Logik, sobald Ihr Shop mehrere Länder gleichzeitig bedient?

Sobald ein Shop in mehreren Ländern operiert, multipliziert sich die Einheiten-Komplexität. Deutsche Kunden filtern in kg, britische Kunden in stone und pounds, US-Kunden in pounds und ounces, australische Kunden überwiegend metrisch, kanadische Kunden gemischt. Die Such-Schicht muss zwei Aufgaben gleichzeitig lösen.

Die erste Aufgabe ist die interne Konsistenz. Im Index sollten alle Werte in einer einzigen Basis-Einheit pro Klasse liegen (typisch metrisch SI), unabhängig vom Markt. Damit ist die Sortier- und Filter-Logik einheitlich, und Cross-Border-Sortimente fallen nicht zwischen den Index-Schemata zusammen.

Die zweite Aufgabe ist die Markt-spezifische Darstellung. Der UK-User sieht im Sidebar-Filter "Weight (lb)" und gibt seinen Filter-Range in pounds ein. Die Query-Schicht rechnet pound zu kg um, bevor sie auf das Index-Feld zugreift. Im Ergebnis sieht der UK-User die Produkte, die zu seinem pound-Range passen, mit pound-Anzeige im Treffer. Der DE-User sieht dasselbe Produkt mit kg-Anzeige.

Diese Trennung zwischen Index-Einheit (metrisch SI) und Display-Einheit (Markt-spezifisch) ist die saubere Architektur. Sie verhindert, dass für jeden Markt eine eigene Index-Variante gebaut werden muss, und sie hält die operative Pflege auf einem Set an normalisierten Daten zentral. Die Markt-Wahl ist eine Query-Parameter-Frage, keine Index-Frage.

Eine Toleranz-Frage entsteht beim Range-Filter. Wenn ein UK-User "10 lb" filtert, ist die metrische Entsprechung 4,536 kg. Ein deutsches 5-kg-Produkt liegt knapp darüber. Soll es im Filter "10 lb" auftauchen, weil der UK-User mit 4,536 kg vermutlich auch 5 kg im Sinn hatte? Oder soll es strikt ausgeblendet werden, weil 5 kg eben nicht 10 lb sind? In der Praxis arbeiten viele Shops mit einer Toleranz-Band-Logik: 5 Prozent Schwellwert um den Filter-Range, innerhalb dessen Treffer als "praktisch passend" eingeordnet werden. Das fängt die Konvertierungs-Rundungen ohne harte Filter-Brüche.

Die Multi-Country-Sortiments-Logik hängt eng mit der Pricing-, Versand- und Steuer-Architektur zusammen. Wir haben den verwandten Punkt zur Multi-Country-Such-Architektur in unserem Beitrag zu Multi-Country Search-Infrastruktur ausführlich behandelt. Im Einheiten-Kontext gilt die dort beschriebene Trennung zwischen marktneutralem Index und marktspezifischer Query-Schicht. Die Konvertierungs-Tabellen sind klein und stabil, der operative Gewinn ist groß.

Verpackungs-Einheit als eigene Logik-Ebene

Warum lassen sich Verpackungs-Einheiten wie 6er-Pack oder 24er-Tray nicht wie physikalische Größen behandeln?

Eine Sonderstellung haben Verpackungs-Einheiten. Hier wird keine physikalische Konversion gemacht, sondern eine kommerzielle Bündel-Struktur abgebildet. Ein Produkt kann gleichzeitig als Einzel-Dose, als 6er-Pack, als 24er-Tray und als 144er-Karton-Palette angeboten werden. Die Such-Logik muss die richtige Verpackungs-Einheit pro Suchkontext zeigen.

Drei Architektur-Entscheidungen sind nötig.

Erstens die Granularitäts-Frage. Werden alle Verpackungs-Varianten als eigene SKUs im Index geführt? Oder gibt es eine Master-SKU mit Varianten-Auflösung im Frontend? Die SKU-Variante bietet maximale Filter-Granularität, bläht den Index aber stark auf. Die Master-Variante hält den Index kompakt, verlangt aber eine separate Logik für die Varianten-Anzeige im Treffer.

Zweitens die Standard-Auswahl. Welche Verpackungs-Einheit wird beim ersten Treffer ausgespielt? In der Praxis bewährt sich die "kunden-typische" Variante als Default, mit Klick-Wechsel zu anderen Varianten in der Treffer-Karte. Für B2C-Shops ist das oft die kleinste Verpackungs-Einheit (Einzel-Dose), für B2B-Shops oft eine mittlere (6er-Pack oder 24er-Tray).

Drittens die Filter-Logik. Ein Filter "Verpackungs-Einheit: 24er-Tray" zeigt alle Produkte, die in einem 24er-Tray verfügbar sind, auch wenn sie als Einzel-Dose oder 6er-Pack ebenfalls bestellbar wären. Die Boolean-Logik ist hier ein "OR über Varianten", nicht ein "AND auf der Master-SKU".

Die Mechanik der Verpackungs-Einheit hängt mit der Lagerbestand-Sync aus dem ERP zusammen. Ein 24er-Tray mit 0 Stück Bestand ist nicht bestellbar, auch wenn 100 Einzel-Dosen am Lager sind. Die Lager-Aggregations-Logik muss pro Verpackungs-Einheit separat funktionieren. Wir haben die ERP-Sync-Pattern in unserem Beitrag zu Live-ERP-Daten in der Shop-Suche im Detail beschrieben. Im Verpackungs-Kontext gilt zusätzlich die Pack-Auflösung pro SKU-Variante.

Wo die Normalisierung an Grenzen kommt: die Hybrid-LLM-Ergänzung

Wo stößt die rein deterministische Einheiten-Normalisierung an ihre Grenzen?

Deterministische Einheiten-Normalisierung deckt einen großen Teil der Filter-Anwendungsfälle ab, sie hat aber natürliche Grenzen. Drei Anfrage-Typen führen klassische Normalisierung an die Wand.

Erstens umgangssprachliche Mengen-Angaben. "Eine Handvoll Nüsse", "wenige Gramm", "ein bisschen Mehl", "viel Wasser". Diese Anfragen sind semantisch eindeutig (sie meinen jeweils eine ungefähre Menge), aber sie haben keine SI-Entsprechung. Eine reine Normalisierungs-Logik kann sie nicht zuordnen.

Zweitens qualitative Größen-Adjektive. "Kompakt", "groß", "klein", "handlich", "tragbar", "stationär". Im Industrie- und Konsumgüter-Sortiment sind diese Adjektive Verkaufs-Argumente, aber sie korrelieren nur unscharf mit einer numerischen Einheit. "Kompakter Akku-Schrauber" kann bei einem Hersteller 1,2 kg und bei einem anderen 2,5 kg bedeuten.

Drittens kombinatorische Anfragen mit impliziter Einheits-Logik. "Trockenfutter für große Hunde mit Allergien", "Schrauben für Bauholz Außen", "Hundeleine für Welpen". Die richtigen Treffer hängen von Einheits-Werten (Gewicht, Länge, Größe), Material-Eigenschaften und semantischen Kategorien ab. Eine reine Filter-Logik auf normalisierten Zahlen reicht nicht.

In all diesen Fällen ergänzt die Hybrid LLM Search die deterministische Normalisierung um eine semantische Schicht. Das LLM interpretiert die Anfrage, mappt umgangssprachliche Begriffe auf semantische Buckets (große Hunde = etwa 25 bis 45 kg Lebendgewicht = entsprechende Futtersorte), kombiniert das mit den Filter-Werten und gibt eine erweiterte Treffer-Liste zurück. Die deterministische Schicht macht die exakten Range-Filter, die semantische Schicht macht die unscharfen Interpretationen.

Wichtig ist die Reihenfolge. Die deterministische Normalisierung ist die Basis. Ohne saubere Einheiten-Werte im Index bringt auch die semantische Schicht nichts, weil sie auf falsche oder leere Filter-Werte verweisen müsste. Die Hybrid LLM Search ist die Ergänzung, nicht der Ersatz, und sie funktioniert am besten auf einem sauber normalisierten Daten-Layer.

Die strukturelle Eigenschaft, dass die LLM-Schicht keine personenbezogenen Daten benötigt, macht die Hybrid LLM Search cookieless und DSGVO-konform. Das semantische Mapping arbeitet auf Produkt-Daten und auf der aktuellen Anfrage, nicht auf User-Profilen. Die Einheiten-Normalisierung selbst ist sowieso eine reine Daten-Layer-Operation ohne User-Bezug, also DSGVO-neutral. Made in Germany als Hosting-Standort komplettiert das Argument im DACH-Markt.

DSGVO und Datenfluss: warum die Normalisierung neutral bleibt

Ist die Einheiten-Normalisierung datenschutzrechtlich überhaupt ein Problem?

Anders als bei Personalisierung oder ERP-Sync ist die Einheiten-Normalisierung datenschutzrechtlich unkritisch. Sie operiert ausschließlich auf produktbezogenen Stamm-Daten, die typisch öffentlich sind (Hersteller-Angaben aus dem Katalog) und keine Personenbeziehung haben. Die Pflege des Normalisierungs-Lexikons ist eine interne Operation des Such-Anbieters, ohne Datenfluss zu Kunden-Profilen.

Diese Neutralität ist ein operativer Vorteil. Compliance-Audits, Datenschutz-Prüfungen und IT-Sicherheits-Bewertungen können die Such-Schicht ohne Bedenken passieren lassen, solange die Daten-Flüsse aus dem ERP und PIM sauber strukturiert sind. Die Einheiten-Normalisierung selbst löst keine zusätzlichen Compliance-Auflagen aus.

Eine zweite operative Eigenschaft kommt dazu. Die Normalisierungs-Logik ist plattform-übergreifend wiederverwendbar. Dieselben acht Klassen, dieselben Konversions-Tabellen, dieselben Compound-Parsing-Regeln funktionieren in einer Shopware-, Magento- oder WooCommerce-Installation. Die entkoppelte Infrastruktur der BatteryIncluded-Such-Schicht macht diese Wiederverwendung explizit. Die Normalisierung passiert in der Such-Schicht, nicht im jeweiligen Shop-Backend, und ist damit unabhängig von der konkreten Shop-Implementation.

Wir haben den verwandten Punkt zur DSGVO-konformen KI-Architektur in unserem Beitrag zu Search-Merchandising im Backend erläutert. Im Einheiten-Kontext gilt: die Normalisierung ist eine reine Produktdaten-Operation, ohne User-Tracking, ohne Profil-Aufbau, ohne Daten-Speicherung über Sitzungen hinweg. Das ist nicht ein Sonderfall, sondern die strukturelle Standard-Eigenschaft einer Such-Infrastruktur, die produktdaten-zentriert konzipiert ist.

Was Sie diese Woche tun können

Wie führen Sie die Einheiten-Normalisierung diese Woche pragmatisch ein, ohne gleich das ganze System umzubauen?

Wenn Sie heute eine Standard-Shop-Suche mit Filter-Brüchen an Einheiten-Grenzen betreiben, ist die folgende Reihenfolge der pragmatische Einstieg.

Schritt eins ist die Bestandsaufnahme. Erheben Sie aus Ihrem PIM oder Index, wie viele unterschiedliche Einheits-Strings für die Top-10-Kategorien Ihres Sortiments im Datenbestand sind. Eine Stichprobe von 500 SKUs pro Kategorie reicht, um ein Gefühl für die Variations-Breite zu bekommen. Wenn Sie pro Kategorie mehr als zehn unterschiedliche Schreibweisen für dieselbe physikalische Größe finden, ist Normalisierungs-Bedarf akut.

Schritt zwei ist die Filter-Analyse. Welche Sidebar-Filter sind in den Top-10-Kategorien aktiv? Welche davon greifen auf Einheiten-Werte zurück? Wie groß ist die Treffer-Reduktion durch den Filter? Wenn ein Gewichts-Filter die Trefferliste um über 70 Prozent reduziert, ist die Wahrscheinlichkeit hoch, dass viele Treffer durch Einheits-Inkonsistenz herausfallen, nicht durch tatsächliche Nicht-Passung.

Schritt drei ist die Stichproben-Validierung. Wählen Sie fünf Filter-Kombinationen aus den Top-Kategorien (etwa "Gewicht ab 5 kg" in der Hundefutter-Kategorie) und prüfen Sie manuell, wie viele Treffer im Filter zu sehen sind, wie viele im Sortiment tatsächlich passen würden. Die Differenz ist die Conversion-Lücke, die durch die fehlende Normalisierung entsteht.

Schritt vier ist die Lexikon-Vorbereitung. Definieren Sie pro Einheits-Klasse die Basis-Einheit und die wichtigsten Eingangs-Einheiten mit ihren Konversions-Faktoren. Für die acht Standard-Klassen genügt eine kompakte Tabelle. Für branchen-spezifische Sonder-Einheiten müssen Sie das Lexikon erweitern, typisch in Zusammenarbeit mit Ihren Lieferanten oder Produktdaten-Verantwortlichen.

Schritt fünf ist die Pilot-Implementation. Wählen Sie eine Kategorie mit hoher Filter-Aktivität und implementieren Sie die Normalisierung dort prototypisch. Messen Sie zwei Wochen lang die Filter-Trefferzahl, die Click-Through-Rate und die Conversion-Rate gegen die alte Logik. Wenn der Pilot positive Ergebnisse zeigt, rollen Sie die Normalisierung auf die anderen Kategorien aus.

Schritt sechs ist die Multi-Country-Erweiterung, falls Sie in mehreren Märkten operieren. Definieren Sie pro Markt die Display-Einheit (kg vs lb, l vs gal) und implementieren Sie die Query-Schicht-Umrechnung, ohne den Index zu duplizieren. Setzen Sie eine 5-Prozent-Toleranz-Band auf die Range-Filter, damit Konvertierungs-Rundungen keine harten Brüche erzeugen.

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 Normalisierungs-Pipeline standardisiert mitbringt, Lexika für die häufigen Branchen vorkonfiguriert hat und die Multi-Country-Logik out of the box unterstützt.

Häufige Fragen (FAQ)

Was bedeutet Einheiten-Normalisierung in der Produktsuche?

Einheiten-Normalisierung bedeutet, alle physikalischen Mengen-Angaben in einem Produkt-Katalog auf eine einheitliche Basis-Einheit pro Klasse umzurechnen und im Index als zusätzliches numerisches Feld abzulegen. Aus "5000 g", "11 lb" und "0,5 t" wird intern ein normalisierter kg-Wert. Filter, Sortierung und Aggregations-Buckets arbeiten auf dem numerischen Feld, die Anzeige greift auf den Original-String zurück. Damit greift ein Filter "ab 5 kg" auf alle Produkte mit kg-Wert größer oder gleich 5, unabhängig vom Display-String. Die Konsequenz ist eine vollständige Trefferliste statt einer durch String-Inkonsistenz verzerrten.

Welche Einheiten-Klassen muss ein E-Commerce-Index abdecken?

Acht Klassen decken nach unserer Erfahrung etwa 95 Prozent der Filter-Anwendungsfälle im DACH-E-Commerce ab. Gewicht (Basis: kg), Volumen (Basis: l), Länge (Basis: m), Fläche (Basis: m²), Stückzahl und Pack-Größe (Basis: Stück), Verpackungs-Einheit (logistische Struktur statt physikalische Einheit), Energie und Leistung (Basis: J, Wh, W), Konzentration und Dichte (Basis: g/l, mol/l, Prozent). Branchen-spezifische Spezial-Einheiten wie Industrie-Schaltleistung, medizinische Dosen oder Edelmetall-Feinheiten kommen on top und sollten als eigene Klassen modelliert werden, nicht in den acht Standard-Klassen vermischt.

Wie funktioniert das Parsen von Compound-Strings wie "500ml" oder "½ Liter"?

Eine mehrstufige Tokenizing-Pipeline normalisiert zunächst den String (Unicode-Brüche zu Dezimalzahlen, Dezimaltrennzeichen vereinheitlicht, Mehrfach-Leerzeichen zu einem). Im zweiten Schritt wird der Wert vom Einheits-Suffix getrennt, mit Erkennung von Bereichen ("5 bis 10 kg"), Modifikatoren ("ca.", "ab", "max") und Zusatz-Mengen ("3 Stück à 500 g"). Im dritten Schritt wird das Einheits-Suffix gegen ein Lexikon geprüft, das alle bekannten Schreibweisen und Tippfehler-Varianten der jeweiligen Einheit enthält. Im vierten Schritt wird der Wert in die SI-Basis-Einheit umgerechnet. Der Original-String bleibt im Index als Display-Wert, der normalisierte Wert kommt als numerisches Feld dazu.

Soll die Normalisierung zur Index-Zeit oder zur Query-Zeit passieren?

Index-Zeit ist die operativ richtige Standard-Wahl. Beim Importieren eines Produkts wird der Einheits-String geparst, in die SI-Basis umgerechnet und als zusätzliches numerisches Feld im Index abgelegt. Die Query-Zeit ist schnell, weil keine Parsing-Arbeit pro Anfrage anfällt. Lexikon-Änderungen lösen ein Differential-Reindexing aus, das nur die betroffenen Produkte neu rechnet, nicht den gesamten Katalog. Eine hybride Strategie ist möglich: häufige Klassen index-zeit-normalisieren, seltene oder kontext-sensitive Klassen query-zeit-normalisieren. Damit wird die Index-Größe begrenzt, ohne die Pflege-Latenz auf den seltenen Fällen zu opfern.

Wie geht eine Multi-Country-Suche mit Imperial vs Metric um?

Die saubere Architektur trennt zwischen Index-Einheit (metrisch SI, einheitlich für alle Märkte) und Display-Einheit (markt-spezifisch). Im Index liegen alle Werte in kg, l, m. Die Query-Schicht rechnet die Filter-Eingabe des Users in die Index-Einheit um. Ein UK-User mit "10 lb" sieht im Treffer trotzdem pound-Anzeige, der DE-User dasselbe Produkt mit kg-Anzeige. Eine 5-Prozent-Toleranz-Band auf den Range-Filter fängt Konvertierungs-Rundungen ab und verhindert harte Filter-Brüche. Die Markt-Wahl ist eine Query-Parameter-Frage, keine Index-Frage, und braucht keine duplizierten Index-Strukturen.

Wie verhindert die Normalisierung Conversion-Verluste durch fehlende Treffer?

Ohne Normalisierung filtert die Such-Logik auf einer einzigen Spalte mit einer einzigen Einheits-Konvention. Produkte, deren Einheits-String nicht zur Konvention passt, fallen aus dem Filter. Aus Kunden-Sicht wirkt das wie ein dünnes Sortiment, ohne dass null Treffer erscheinen. Der Kunde sieht eine reduzierte Liste und denkt, mehr habe der Shop nicht. Mit Normalisierung greift der Filter auf den numerischen Wert und liefert alle Treffer, die physikalisch passen, unabhängig vom Display-String. Die Conversion-Lücke schließt sich, weil keine Treffer mehr durch Schreibweise verloren gehen.

Was passiert mit Verpackungs-Einheiten und Pack-Größen?

Verpackungs-Einheiten sind keine physikalische, sondern eine logistische Struktur. Ein Produkt kann gleichzeitig als Einzelpack, 6er-Pack, 24er-Tray und 144er-Karton-Palette angeboten werden. Die Architektur-Entscheidung ist, ob jede Variante als eigene SKU im Index geführt wird (maximale Filter-Granularität, größerer Index) oder ob eine Master-SKU mit Varianten-Auflösung im Frontend genutzt wird (kompakter Index, separate Display-Logik). Die Standard-Auswahl pro Treffer ist typisch die kunden-typische Variante (B2C: kleinste Einheit, B2B: mittlere Einheit). Filter "Verpackungs-Einheit: 24er-Tray" wirken als OR über Varianten, nicht als AND auf der Master-SKU. Der Lager-Bestand muss pro Verpackungs-Einheit separat geführt werden, weil ein leerer 24er-Tray nicht aus den 100 verfügbaren Einzel-Dosen kompensiert werden kann.

Welche Anfragen erfordern eine semantische Ergänzung über die Hybrid LLM Search?

Drei Anfrage-Typen liegen außerhalb des deterministischen Normalisierungs-Bereichs. Erstens umgangssprachliche Mengen-Angaben wie "eine Handvoll", "wenige Gramm", "ein bisschen". Zweitens qualitative Größen-Adjektive wie "kompakt", "groß", "handlich". Drittens kombinatorische Anfragen mit impliziter Einheits-Logik wie "Trockenfutter für große Hunde", die Gewicht, Material und semantische Kategorien kombinieren. Hier ergänzt die Hybrid LLM Search die deterministische Schicht um ein semantisches Mapping. Wichtig ist die Reihenfolge: die deterministische Normalisierung ist die Basis, die LLM-Schicht ist die Ergänzung. Ohne saubere Einheiten-Werte im Index bringt auch die semantische Schicht nichts, weil sie auf leere oder falsche Filter-Werte verweisen müsste.

Bereit für eine Produktsuche, die Einheiten richtig versteht?

Saubere Einheiten-Normalisierung in der Produktsuche ist kein kosmetisches Detail, sondern eine strukturelle Entscheidung über die Konsistenz Ihrer Filter, Sortierungen und Aggregationen. Wer hier sauber baut, gewinnt Conversion-Rate über das gesamte Sortiment, weil keine Treffer mehr durch Schreibweisen-Inkonsistenz verloren gehen. Volt Search® von BatteryIncluded ist als entkoppelte Infrastruktur konzipiert, die die acht Einheiten-Klassen out of the box normalisiert, Compound-Strings über eine konfigurierbare Pipeline parst, Multi-Country-Märkte mit getrennten Display-Einheiten und einheitlichem Index bedient und die Verpackungs-Einheiten-Logik mit der ERP-Lagerbestand-Sync verbindet. Hybrid LLM Search ergänzt die semantische Schicht für unscharfe Anfragen wie "kompakt", "handlich" oder "für große Hunde". Cookieless, DSGVO-konforme KI, Made in Germany, ohne dass Sie eigene Parser bauen oder pro Markt ein eigenes Index-Schema betreiben müssen.

Zu Ihrer kostenlosen Demo und erleben Sie live an Ihren eigenen Produktdaten, wie Volt Search® die Einheiten-Normalisierung als gleichwertigen Index-Layer behandelt, wie das Compound-Parsing "500ml" und "0,5 L" und "½ Liter" zuverlässig auf denselben Wert mappt, wie die Multi-Country-Schicht Imperial- und Metric-Filter ohne Index-Duplizierung bedient und wie die Verpackungs-Einheiten-Logik in Treffer-Karten und Filtern sauber konsolidiert wird. Ohne eigene Parser, ohne pflege-intensive Tippfehler-Listen, ohne lange Setup-Phase.