Direkte Antwort
Produkttext beschreibt. Produkt-Fit qualifiziert.
Text kann Nutzen, Thema und Stimmung vermitteln. Produkt-Fit beantwortet dagegen eine prüfbare Frage: Erfüllt genau dieses Produkt die notwendigen Bedingungen dieses Kundenkontexts – und welche Unsicherheit bleibt?
Ein Sprachmodell kann aus einer Beschreibung plausible Eigenschaften ableiten. Plausibel ist im Handel aber nicht automatisch wahr. Sobald Edition, Kompatibilität, Zielgruppe, Voraussetzungen oder Sicherheit relevant werden, braucht die Aussage ein explizites Datenmodell und eine nachvollziehbare Quelle.
Der Decision Core
Vier Bausteine machen aus Text eine prüfbare Entscheidung.
Was ist am Produkt selbst wahr?
Spielzeit, Sprache, Plattform, Dauer, FormatWie hängt es mit anderem zusammen?
Edition von, benötigt, kompatibel mit, passt zuWann gilt eine Aussage – und wann nicht?
Voraussetzung, Ausschluss, Bereich, PrioritätWas ist nicht belastbar bekannt?
fehlend, widersprüchlich, veraltet, ungeprüftErst das Zusammenspiel erlaubt eine begründbare Aufnahme, einen Ausschluss oder eine sichere Rückfrage.
| Baustein | Beantwortet | Typischer Fehler ohne Struktur |
|---|---|---|
| Attribut | „Wie viele?“, „Wie lange?“, „Welche Sprache?“ | Freitextwerte sind uneinheitlich oder beziehen sich auf eine andere Variante. |
| Relation | „Wozu gehört es?“, „Was braucht es?“, „Was passt dazu?“ | Gemeinsame Begriffe werden fälschlich als Kompatibilität interpretiert. |
| Regel | „Unter welcher Bedingung gilt der Fit?“ | Eine allgemeine Eigenschaft wird für jeden Kontext als geeignet ausgegeben. |
| Unknown | „Was wissen wir nicht sicher?“ | Eine Lücke wird mit wahrscheinlich klingendem Text gefüllt. |
Ein Produktname reicht nicht
„Erweiterung“ ist noch keine vollständige Kaufentscheidung.
Die Beschreibung kann großartige neue Szenarien versprechen. Für den Kunden sind jedoch andere Fragen kaufentscheidend:
- Ist es eine abhängige Erweiterung oder eigenständig spielbar?
- Welches konkrete Grundspiel und welche Edition werden benötigt?
- Stimmen Sprache, Region und Release-Version überein?
- Ist das notwendige Grundspiel beim Händler aktuell verfügbar?
- Erweitert das Produkt Spielerzahl, Spielzeit oder nur Inhalt?
Diese Antworten gehören nicht als lose Sätze in eine Textwand. Dafür braucht es stabile Produktidentitäten und gerichtete Relationen wie requires_base_game, standalone_expansion, edition_of oder compatible_with. Für öffentliche Standards können passende schema.org-Relationen genutzt werden; fachliche Details bleiben als klar dokumentierte Shelfkind-Typen erhalten.
Unknown schlägt erfunden: Ist die Editionsbindung nicht geklärt, wird die Relation nicht automatisch gesetzt. Das Produkt bleibt für diese Frage ungeklärt, bis Quelle und Match geprüft sind.
Datenqualität als Vereinbarung
Ein Datenfeld wird erst mit seinem Einsatzkontext operational.
Ein Decision Data Contract beginnt nicht beim Schema, sondern bei der Verbraucherentscheidung. Für eine kritische Aussage werden mindestens folgende Punkte festgelegt:
Use Case
Welche Kundenfrage oder welcher Prozess hängt von der Information ab?
Erwartung
Welches Format, welche Semantik, Aktualität und Toleranz werden benötigt?
Verantwortung
Welche Quelle und welcher Owner dürfen den Wert ändern oder freigeben?
Fehlerweg
Führt eine Verletzung zu Block, Quarantäne, Warnung oder dokumentierter Ausnahme?
Diese Sicht folgt dem Data-Contracts-Prinzip, Datenqualität als Produzenten-Konsumenten-Vereinbarung zu behandeln. Shelfkind überträgt es auf Decision Data: Eine Spezifikation ohne Quelle, Prüfung, Verantwortlichkeit und Reaktion ist noch kein kontrollierter Produktdatenprozess.
Pragmatische Umsetzung
Schreibe nicht zuerst mehr. Modelliere zuerst das Entscheidende.
- Eine wirtschaftlich relevante Kundenfrage und einen begrenzten Katalogausschnitt wählen.
- Notwendige Attribute, Relationen, Regeln und Unknown-Zustände definieren.
- Produkte eindeutig mit SKU, GTIN/EAN, Edition, Sprache und fachlicher ID matchen.
- Quellen, Rechte, Freshness, Confidence und Reviewer je Aussage dokumentieren.
- Die Daten kontrolliert veröffentlichen und dieselbe Frage erneut testen.
- Erst danach Text ergänzen, wenn er ein belegtes Informationsbedürfnis besser erklärt.
Kurz beantwortet
Häufige Fragen
Sind Produktbeschreibungen damit unwichtig?
Nein. Produktbeschreibungen bleiben wichtig für Verständnis, Marke und menschliche Beratung. Dennoch dürfen sie nicht mit strukturiertem, verifiziertem Produkt-Fit verwechselt werden.
Kann ein LLM Relationen automatisch vorschlagen?
Ja, als Kandidat. Kritische Relationen wie Abhängigkeit, Kompatibilität oder Eignung brauchen anschließend Produktmatch, Quelle, Confidence, Rechte und fachliche Freigabe.
Muss jedes Unknown öffentlich sichtbar sein?
Nicht zwingend als technischer Status auf der Produktseite. Der ausspielende Prozess muss aber wissen, dass die Aussage fehlt, damit er nicht still eine positive Behauptung erzeugt.
Decision-Ready Foundation
Baue einen Katalog, der Beziehungen kennt – nicht nur Beschreibungen.
Wir definieren Identitäten, Entscheidungsfelder, Relationslogik und Qualitätsregeln für einen vereinbarten Katalogausschnitt.
Foundation ansehenMethodische Grundlage: Relation-Based Context aus dem „5 Cs“-Framework und Fitness-for-use/Data-Contract-Prinzipien nach Sanderson, Freeman und Schmidt (2026). Shelfkinds konkrete Relationstypen und Quality Gates sind eine eigene Operationalisierung und werden pro Decision Pack fachlich geprüft.