SKU
Eine SKU (Stock Keeping Unit / Bestandseinheit) ist ein eindeutiger alphanumerischer Code, den ein Händler einer bestimmten Produktvariante zuweist, um sie durch Bestand, Verkauf und Fulfillment zu verfolgen. Anders als eine UPC oder ein Barcode ist eine SKU intern für das Unternehmen und kann Attribute wie Größe, Farbe oder Lagerort kodieren. Jede verkaufbare Variation eines Produkts erhält eine eigene SKU.
Definition von SKU
Eine SKU (Stock Keeping Unit, deutsch: Bestandseinheit) ist eine eindeutige Kennung, die ein Unternehmen erstellt, um eine bestimmte, verkaufbare Version eines Produkts durch Bestands-, Bestell- und Verkaufssysteme zu verfolgen. Wenn ein Hoodie in drei Farben und vier Größen erhältlich ist, sind das zwölf SKUs, denn jede Kombination muss unabhängig gezählt, bepreist und nachbestellt werden. Eine SKU ist nicht dasselbe wie ein Produktname oder eine Listung – ein Produkt kann viele SKUs haben, eine für jede Variante, die ein Kunde tatsächlich auswählen und kaufen kann. SKUs sind intern für das Unternehmen, das sie erstellt, was sie von UPCs und EANs unterscheidet – standardisierten Codes, die von einer externen Stelle (GS1) vergeben und von jedem Händler geteilt werden, der genau dieses Produkt verkauft. Ein Händler kann daher eine eigene SKU für ein im Großhandel gekauftes Produkt erstellen und dem Barcode des Herstellers einen internen Code hinzufügen, damit seine eigenen Lager- und Berichtssysteme das Produkt konsistent verfolgen können.
Wie SKU-Codes aufgebaut sind
Es gibt keinen universellen Standard für das SKU-Format, was sowohl eine Stärke als auch eine häufige Quelle für Chaos ist. Die meisten Händler erstellen eine kurze alphanumerische Zeichenfolge, die die für Lager- und Berichtszwecke relevanten Attribute kodiert: Kategorie, Produktlinie, Farbe und Größe sind typische Bestandteile. Ein übliches Muster sieht aus wie TSH-CREW-BLK-L für ein schwarzes, großes Rundhals-T-Shirt oder MUG-CER-12OZ für einen Keramikbecher mit 12 oz Fassungsvermögen. Gutes SKU-Design folgt in der Regel einigen Regeln: Halten Sie die Codes einheitlich lang, damit sie leicht visuell erfasst und in einer Tabelle sortiert werden können, vermeiden Sie Leerzeichen und Sonderzeichen, die CSV-Importe oder URL-Slugs stören könnten, und gestalten Sie den Code so lesbar, dass ein Lagermitarbeiter das Produkt allein am Code erkennen kann, ohne nachschlagen zu müssen. Manche Unternehmen verwenden stattdessen fortlaufende numerische SKUs (10001, 10002…), die automatisch von ihrer Plattform generiert werden, und tauschen Lesbarkeit gegen garantierte Eindeutigkeit. Beide Ansätze funktionieren, solange sie konsequent angewendet werden – das Problem ist meist die Inkonsistenz: Eine Produktlinie manuell kodiert, eine andere automatisch generiert, ohne gemeinsame Logik dazwischen.
Ready to Monitor Your AI Visibility?
Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.
Warum die Verfolgung auf SKU-Ebene für den E-Commerce wichtig ist
Die SKU-Granularität macht Bestandsmanagement überhaupt erst möglich. Aggregierte Bestandszahlen auf Produktebene verdecken die Tatsache, dass eine Variante ausverkauft ist, während eine andere überlagert ist – ein Store zeigt vielleicht „T-Shirt: auf Lager" an, während die tatsächlich verkaufte Größe seit zwei Wochen nachbestellt ist. Die Verfolgung auf SKU-Ebene liegt auch Meldebestandsberechnungen zugrunde, da ein T-Shirt in Größe M und eines in Größe XL mit unterschiedlichen Raten verkauft werden und unterschiedliche Nachbestellauslöser benötigen. Über den Bestand hinaus ist die SKU der natürliche Join-Schlüssel für die Margenanalyse: Sobald einer SKU ein Einstandspreis (Stückkosten, Frachtkosten, Verpackung) zugeordnet ist, kann jede einzelne Bestellposition mit den tatsächlichen Kosten verknüpft werden, sodass Umsatz und Rentabilität auf genau derselben Granularitätsebene berichtet werden können, die das Lager für die Bestandsverwaltung verwendet. Ohne SKU-basierte Kostendaten muss die Rentabilitätsberichterstattung auf Durchschnittswerte auf Bestellebene zurückgreifen, die margenstarke und verlustbringende Produkte vermischen und verdecken, welche SKUs tatsächlich beworben werden sollten.
SKU vs. UPC vs. Produkt-ID
| Kennung | Wer vergibt sie | Gültigkeitsbereich | Typische Verwendung |
|---|---|---|---|
| SKU | Der Händler oder die Marke selbst | Intern für ein Unternehmen | Bestand, Nachbestellung, interne Berichte |
| UPC / EAN | GS1 (externe Normungsorganisation) | Global, von allen Verkäufern geteilt | Point-of-Sale-Scanning, Marktplatz-Listungen |
| Produkt-ID / ASIN | Die Plattform (z. B. Amazon, Shopify) | Intern für diese Plattform | Katalogverwaltung innerhalb eines einzelnen Kanals |
| Varianten-ID | Die Datenbank der E-Commerce-Plattform | Intern im Backend des Stores | Technische Referenz, selten kundenseitig sichtbar |
Ein einzelnes physisches Produkt kann alle vier gleichzeitig tragen: eine vom Hersteller vergebene UPC, eine vom Händler vergebene SKU, eine vom Marktplatz vergebene ASIN und eine von der Plattform vergebene Varianten-ID. Multichannel-Händler benötigen in der Regel eine Zuordnungstabelle, die diese abgleicht, sodass ein Verkauf auf Amazon und ein Verkauf über einen Shopify-Store auf dieselbe zugrunde liegende SKU für die Berichterstattung zurückgeführt werden können.
Stay Updated on AI Visibility Trends
Get the latest insights on AI mentions, brand monitoring, and optimization strategies.
SKU-Daten und KI-gesteuerter Handel
Da Einkäufe zunehmend über KI-Assistenten wie ChatGPT Shopping, Perplexity Shopping und Amazons Rufus abgewickelt werden, sind Produktdatenfeeds – die strukturierten Informationen, die diesen Systemen mitteilen, was auf Lager, zu welchem Preis, in welcher Variante ist – auf saubere SKU-Daten in der zugrunde liegenden Ebene angewiesen. Ein KI-Einkaufsassistent, der „das mittlere in Blau" empfiehlt, muss den zugrunde liegenden Feed auflösen können, um eine tatsächliche SKU mit echtem Bestand und Preis zu erhalten, nicht nur eine allgemeine Produktlistung. Unordentliche oder doppelte SKUs sind ein häufiger Grund, warum Produktfeeds über diese Kanäle abgelehnt oder falsch dargestellt werden. Auf der Analyse-Seite arbeiten Tools wie AmICiteds eshop_get_products- und eshop_list_product_costs-Berichte speziell auf SKU-Granularitätsebene, weil genau dort die Rentabilitätsfragen tatsächlich beantwortet werden – „welche Variante dieses Produkts sollte ich weiterhin auf Lager halten" ist eine SKU-Frage, keine Frage auf Produktnamenebene. Die Meldung von Umsatz und Marge pro SKU statt nach Produkttitel ermöglicht es einem Händler zu sehen, dass das schwarze Modell in M mit 40 % Marge verkauft wird, während das neon-grüne in XXL, obwohl es „dasselbe Produkt" ist, kaum die Gewinnschwelle erreicht.
Bewährte Praktiken für das SKU-Management
- Legen Sie eine kanonische SKU pro Variante fest, bevor Sie über mehrere Kanäle listen, und ordnen Sie jede kanalspezifische ID dieser zu
- Halten Sie SKU-Codes kurz, einheitlich lang und frei von Leerzeichen oder Sonderzeichen
- Weisen Sie jeder SKU einen Einstandspreis zu, nicht nur einen Verkaufspreis, damit die Marge automatisch berechnet werden kann
- Vermeiden Sie die Wiederverwendung einer ausgemusterten SKU für ein neues, nicht verwandtes Produkt – die historische Berichterstattung würde beide vermischen
- Führen Sie regelmäßig Prüfungen auf doppelte oder nahezu doppelte SKUs durch (häufige Folge manueller Tabellenbearbeitungen)
- Beziehen Sie die SKU in jeden Export ein – Bestellungen, Retouren und Kostenblätter – damit Datensätze immer wieder zusammengeführt werden können
Häufige SKU-Fehler
Ein häufiges Problem ist die Gleichsetzung von „Produkt" und „SKU" in der Berichterstattung. Das führt zu Bestandszahlen und Margen, die in der Summe gut aussehen, aber eine schlecht laufende Variante unter einer gut laufenden verstecken. Die Lösung besteht darin, sicherzustellen, dass jeder Bericht – Verkäufe, Bestand, Kosten – auf SKU-Ebene erstellt und nur als Anzeigekomfort auf Produktebene zusammengefasst wird, nicht als zugrunde liegende Berechnung. Ein weiteres häufiges Problem ist die SKU-Abweichung über verschiedene Verkaufskanäle hinweg: Ein Händler erstellt ein SKU-Schema in seinem POS-System, ein anderes wird automatisch von seiner E-Commerce-Plattform generiert, und ein drittes Format taucht in einer Marktplatzlistung auf – ohne zuverlässige Möglichkeit, die Gesamtverkäufe einer bestimmten Variante ohne manuellen Abgleich zusammenzuführen. Die Standardlösung ist eine zentral gepflegte Zuordnungstabelle, idealerweise innerhalb der Plattform, die die Berichterstattung durchführt, anstatt sie jedes Mal ad hoc in einer Tabellenkalkulation neu zu erstellen. Ein dritter Fehler ist die Wiederverwendung von SKUs, wenn ein Produkt eingestellt und ersetzt wird – eine neue Rezeptur oder ein neues Design mit der alten SKU verfälscht historische Trenddaten, sodass es aussieht, als hätte dasselbe Produkt plötzlich seine Performance verändert, anstatt eine saubere Vorher-/Nachher-Aufteilung zu zeigen. Schließlich verzichten viele kleinere Händler darauf, jeder SKU einen tatsächlichen Einstandspreis zuzuordnen, und verwenden stattdessen eine pauschale geschätzte Marge für den gesamten Katalog. Das macht die SKU-basierte Rentabilitätsberichterstattung technisch möglich, aber praktisch irreführend, da sie nicht die tatsächliche Spanne zwischen der besten und der schlechtesten Variante aufzeigen kann.