Produktdaten im Running-Handel: Schuhtechnologie und Größenlogik im Griff

Zwei Datenaufgaben in einem Schuh: Technologie-Attribute als Vergleichsbasis und ein Größen-/Weitenlauf als Kaufentscheidung – wo FEDAS und die Pools helfen und wo sie aufhören.

Jakob Feinböck, Productbay4. Juli 20267 Min. Lesezeit
☝️Das Wichtigste in Kürze
  • Laufschuhe werden über Technologie-Attribute verglichen – Sprengung, Stack-Höhe, Dämpfung, Gewicht, Pronationsstütze –, doch jede Marke benennt sie anders.
  • Gekauft werden sie über die Passform: jeder Schuh braucht einen Größen- und Weitenlauf auf einem konsistenten Schema, jede Variante mit eigenem EAN/GTIN.
  • FEDAS und Verbund-Pools klassifizieren den Schuh und decken die großen Marken – tragen aber weder die Technologie-Tiefe noch die Größen-Weiten-Matrix.
  • Productbay hält jeden Schuh als Elternartikel mit verknüpften Größen-/Weiten-Varianten und vergleichbaren Technologie-Attributen und normalisiert beides per KI.

Ein Laufschuh wirkt wie ein einfaches Produkt, bis du versuchst, ihn in Daten zu beschreiben. Ein Kunde will wissen, wie hoch die Sprengung ist, ob es ein Neutral- oder Stabilschuh ist, wie schwer er ist und wie viel Dämpfung er trägt – und dann braucht er ihn in genau seiner Größe und Weite. Zwei Datenaufgaben in einem Produkt: ein Satz Technologie-Attribute, die nur zählen, wenn sie markenübergreifend vergleichbar sind, und ein Größen-und-Weiten-Lauf, der nur funktioniert, wenn jede Variante sauber modelliert ist.

Produktdaten für Laufschuhe leben auf zwei Achsen zugleich: Technologie-Attribute als Vergleichsbasis und Größen-Weiten-Varianten als Kaufentscheidung. Das ist eine fokussierte Ecke der breiteren Sport- und Outdoor-Herausforderung und überschneidet sich stark mit der Schuh-Datenlogik – doch Running treibt beide Probleme auf die Spitze.

Warum sind Technologie-Attribute bei Laufschuhen so schwer vergleichbar?

Running ist eine Kategorie, in der Kunden wirklich über Specs einkaufen. Sprengung, Stack-Höhe, Gewicht und Pronationsstütze sind die Attribute, nach denen ein ambitionierter Läufer filtert und vergleicht. Das Problem: keine zwei Marken beschreiben sie gleich:

  • Sprengung (Höhenunterschied Ferse zu Zehen): mal ein sauberer Millimeterwert im Feed, mal im PDF-Datenblatt vergraben, mal nur aus zwei getrennten Stack-Zahlen ableitbar.
  • Dämpfung: die eine Marke bewirbt einen markenrechtlich geschützten Schaumnamen, die nächste gibt eine Stack-Höhe an, die dritte beschreibt das Laufgefühl nur im Fließtext – drei Wege, dasselbe zu sagen.
  • Pronationsstütze: Neutral vs. Stabil vs. Motion Control, uneinheitlich benannt oder ganz weggelassen.
  • Gewicht und Einsatzzweck: das Gewicht variiert je nach Musterschuhgröße, und Begriffe wie „Daily Trainer", „Tempo" oder „Wettkampf" sind Marketingworte, keine strukturierten Felder.

Damit ein Kunde nach Sprengung filtern oder Dämpfung markenübergreifend vergleichen kann, musst du diese Attribute erst aus uneinheitlichen Feeds herauslösen und auf einen gemeinsamen Satz mappen. Dieses Mapping ist die Vergleichsbasis – ohne es lügen die Filter in deinem Shop.

Wie vereinheitlichst du Größen und Weiten über Marken hinweg?

Die zweite Achse ist die Passform, und hier explodiert die SKU-Zahl. Derselbe Fuß landet je nach Marke auf anderen EU-, UK- und US-Nummern, Weiten sind uneinheitlich (oder gar nicht) benannt, und Halbgrößen tauchen in manchen Läufen auf, in anderen nicht. Ein sauberer Running-Katalog muss all das lösen:

GrößenebeneDas ProblemWas ein sauberer Katalog braucht
GrößenskalenEU / UK / US unterscheiden sich pro Marke für denselben Fußeine Masterskala mit markenspezifischem Mapping
Weitenschmal / normal / weit unterschiedlich benannt oder fehlendein konsistentes Weitenschema über alle Marken
Halbgrößenin manchen Läufen vorhanden, in anderen nichtexplizit modelliert, nicht in ganze Größen verschmolzen
Variantenjede Größe/Weite ist eine verkäufliche Einheit mit eigenem Barcodejede Kombination als verknüpfte Variante mit eigenem EAN/GTIN

Macht man das falsch, driften Bestand, Bestellung und Retouren auseinander. Die Kern-Erkenntnis: jede Größen-und-Weiten-Kombination ist eine eigene Variante mit eigenem EAN/GTIN, aber alle müssen mit einem Elternschuh verknüpft bleiben, damit die Technologie-Attribute geteilt und nicht dupliziert werden.

Wo hören FEDAS und die Pools auf?

FEDAS klassifiziert den Artikel als Laufschuh und gibt dem Sortiment eine gemeinsame Warengruppensprache – echt nützlich für die Struktur. Verbund-Pools (Intersport, Sport 2000) liefern saubere Stammdaten für die großen gelisteten Running-Marken. Aber beide hören weit vor dem auf, was ein Running-Katalog braucht: FEDAS trägt keine Sprengung, keine Stack-Höhe, kein Dämpfungsattribut und keine Größen-Weiten-Matrix, und die Pools decken nur die gelisteten Marken – nicht die kleineren Labels, Eigenmarken oder Zubehör. Die Technologie-Tiefe und die Größenlogik sind genau die Ebene, die dir kein Standard liefert, weshalb die Handarbeit nie verschwindet. Es ist dieselbe Lücke, mit der die ganze Schuh-Kategorie lebt, nur schärfer, weil Läufer über Zahlen vergleichen.

Wie hält Productbay die Laufschuh-Daten sauber?

Productbay ist genau für diese Zwei-Achsen-Aufgabe gebaut – vergleichbare Attribute plus saubere Varianten – mit verknüpften Attributen (linked attributes) als Kern der Größenlogik:

  • Konsolidieren: jeden Markenfeed einmal anbinden – CSV, Excel, Feed-URL, FTP, API – und über SKU oder EAN/GTIN abgleichen, sodass bestehende Schuhe aktualisiert und neue Modelle angelegt werden, jedes als Elternartikel.
  • Passform modellieren: jede Größe und Weite wird eine verknüpfte Variante mit eigenem EAN/GTIN, alle an einen Elternschuh gebunden, sodass die Technologie-Attribute einmal geteilt und nicht pro Größe neu erfasst werden.
  • Technologie anreichern: KI löst Sprengung, Stack, Dämpfung, Gewicht und Stütze aus Titeln und PDF-Datenblättern heraus, mappt Markengrößen auf deine vereinheitlichte Skala und dein Weitenschema, schreibt Beschreibungen und füllt Lücken aus freigeschalteten Quellen – immer mit Review-Queue vor der Veröffentlichung.
  • Ausspielen: Zwei-Wege-Sync mit Shopify und Shopware, ERP-Anbindungen (Xentral, weclapp) und Feed-Exporte für Amazon, OTTO und Kaufland – jeweils mit kanalspezifischen Transformationen.

Der Lohn ist ein Katalog, in dem ein Kunde nach Sprengung filtern, Dämpfung markenübergreifend vergleichen und genau seine Größe und Weite finden kann – weil die Attribute vergleichbar sind und die Varianten verknüpft bleiben. Productbay ist für Fachhändler mit Multi-Lieferanten-, Multi-Kanal-Katalogen gebaut, vom mittelständischen Shop bis zum großen Filialisten.

Häufige Fragen

Lass uns deinen Produktdaten-Prozess ansehen

Sprengung, Stack, Dämpfung, Gewicht – plus jede Größe und Weite auf ein Schema gemappt. Sieh in 30 Minuten, wie Productbay Laufschuh-Technologie in vergleichbare Attribute überführt und Größenvarianten verknüpft hält.

Jetzt starten