Zum Hauptinhalt
Intelliger
E-Commerce Produkterkennung

Ein agentenlesbares Produktdatenschema mit gültigen und ungültigen Beispielen

Ein praktisches agentenlesbares Produktdatenschema für Produkte, Varianten, Angebote, Nachweise und Kompatibilität mit Validierungsregeln und fehlerhaften Vorrichtungen.

Katalogingenieur, der einen physischen Laufschuh mit strukturierten Produktdaten auf einem Laptop abgleicht
Intelliger•
Rezensiert 11. August 2026 · 13 Minuten gelesen

Ein agentenlesbares Produktschema muss das Produktkonzept, die käufliche Variante, das Händlerangebot und die volatile Verfügbarkeit voneinander trennen. Es benötigt typisierte Attribute, stabile Identifikatoren, explizite Einheiten, Herkunft und Kompatibilitätsnachweise. Ein einziger Block von Marketingkopien mit einem Preis reicht nicht aus. Das folgende Schema ist ein praktisches internes Modell, kein neuer öffentlicher Standard und enthält Vorrichtungen, die ein Validator ablehnen sollte.

Dieser Artikel richtet sich an Commerce-Dateningenieure, die Retrieval- oder Shopping-Agent-Pipelines erstellen. Das Ergebnis ist eine versionierte Schemagrenze, die Sie aus Feeds, APIs und strukturierten Daten abbilden können, ohne dass das Modell erraten kann, welche SKU tatsächlich gekauft werden kann.

Verwenden Sie es als Speiche neben dem E-Commerce Produkt Discovery Guide und die Large Catalog Retrieval Architektur.

Produkt, Variante und Angebot separat definieren

Ein Produkt beschreibt ein kommerzielles Konzept, wie z. B. ein Trailschuhmodell. Eine Variante beschreibt eine kaufbare Konfiguration, wie z. B. Größe 43 in blau. Ein Angebot beschreibt die Bedingungen eines Händlers für diese Variante auf einem Markt. Bestands- und Lieferbeobachtungen beschreiben den sich ändernden Zustand dieses Angebots.

Product
  -> Variant
      -> Offer
          -> Inventory observation
          -> Delivery promise

Diese Unterscheidung ist kompatibel mit etablierten Commerce-Daten. Schema.org trennt Product und Offer, mit Eigenschaften für SKU, GTIN, Preis, Währung und Verfügbarkeit. Schema.org Produkt und Schema.org Angebot Es sind nützliche Austauschformate, aber eine Agentenlaufzeit erfordert normalerweise strengere Feldanforderungen und Herkunft als das Vokabular allein.

Ein typisiertes internes Schema

Das folgende TypeScript ist ein illustrativer interner Vertrag:

type DecimalString = `${number}`;
type IsoDateTime = string;
type EvidenceRef = {
  source: 'merchant_api' | 'manufacturer' | 'certifier';
  uri: string;
  digest: `sha256:${string}`;
  observedAt: IsoDateTime;
};

type Product = {
  schemaVersion: '2026-08-11';
  productId: `product:${string}`;
  title: string;
  brand: string;
  description: string;
  taxonomy: string[];
  identifiers: { gtin?: string; mpn?: string };
  attributes: Record<string, AttributeValue>;
  evidence: EvidenceRef[];
};

type AttributeValue =
  | { type: 'text'; value: string }
  | { type: 'boolean'; value: boolean }
  | { type: 'number'; value: DecimalString; unit: string }
  | { type: 'enum'; value: string; vocabulary: string };

type Variant = {
  variantId: `variant:${string}`;
  productId: Product['productId'];
  sku: string;
  optionValues: Record<string, string>;
  attributes: Record<string, AttributeValue>;
  compatibility: CompatibilityClaim[];
};

type CompatibilityClaim = {
  targetId: string;
  relation: 'compatible_with' | 'replaces' | 'requires';
  status: 'verified' | 'merchant_asserted' | 'unknown';
  evidence?: EvidenceRef;
};

type Offer = {
  offerId: `offer:${string}`;
  merchantId: `merchant:${string}`;
  variantId: Variant['variantId'];
  market: string;
  currency: string;
  listPrice: DecimalString;
  validFrom: IsoDateTime;
  validUntil?: IsoDateTime;
  purchaseUrl: string;
};

Binäre Gleitkommapunkte können Gleichheits- und Rundungsfehler einführen Einheiten sollten aus einem kontrollierten Vokabular stammen, nicht aus freiem Text wie about 2kg.

Ein gültiges maschinenlesbares Beispiel

{
  "schemaVersion": "2026-08-11",
  "product": {
    "productId": "product:acme:trail-shoe-8",
    "title": "Trail Shoe 8",
    "brand": "Acme",
    "description": "Water-resistant trail shoe with a replaceable insole.",
    "taxonomy": ["footwear", "trail_running"],
    "identifiers": { "mpn": "TS8" },
    "attributes": {
      "weight": { "type": "number", "value": "0.31", "unit": "kg" },
      "water_resistant": { "type": "boolean", "value": true }
    },
    "evidence": [
      {
        "source": "manufacturer",
        "uri": "https://manufacturer.example/products/ts8/spec",
        "digest": "sha256:4af2c8...",
        "observedAt": "2026-08-11T08:00:00Z"
      }
    ]
  },
  "variant": {
    "variantId": "variant:acme:trail-shoe-8:blue:43",
    "productId": "product:acme:trail-shoe-8",
    "sku": "TS8-BLU-43",
    "optionValues": { "color": "blue", "size_eu": "43" },
    "attributes": {},
    "compatibility": []
  },
  "offer": {
    "offerId": "offer:merchant-7:TS8-BLU-43:DE",
    "merchantId": "merchant:merchant-7",
    "variantId": "variant:acme:trail-shoe-8:blue:43",
    "market": "DE",
    "currency": "EUR",
    "listPrice": "129.90",
    "validFrom": "2026-08-11T00:00:00Z",
    "validUntil": "2026-08-18T00:00:00Z",
    "purchaseUrl": "https://merchant.example/de/products/ts8?variant=blue-43"
  }
}

Das Beispiel ist agentenlesbar, weil sich Identitäten sauber verbinden, Werte getippt werden, der Preis Währung und Gültigkeit hat und sachliche Behauptungen Herkunft haben. Es behauptet nicht, dass der Artikel derzeit auf Lager ist. Das erfordert eine Live-Beobachtung.

Ungültiges Beispiel: Produkt und Angebot sind zusammengebrochen

{
  "id": "trail-shoe",
  "name": "Best Trail Shoe",
  "details": "Blue or red, sizes 39 to 46, usually in stock",
  "price": 129.9,
  "compatible": true
}

Ein Validator sollte diesen Datensatz ablehnen, weil:

  • id ist nicht namespaced oder stabil genug, um sich systemübergreifend zu verbinden.
  • Variantenauswahl ist in Prosa eingebettet.
  • Der Preis hat keine Währung, keinen Markt, keinen Händler oder keine Gültigkeit.
  • Binary Floating Point wird für Geld verwendet.
  • "in der Regel auf Lager" ist weder eine aktuelle Tatsache noch eine Zeitstempel Beobachtung.
  • Kompatibilität hat kein Ziel, Beziehung oder Beweise.
  • "Best" ist Werbesprache, kein Produktattribut.

Ungültiges Beispiel: Kennungen widersprechen einander

{
  "productId": "product:acme:trail-shoe-8",
  "variant": {
    "variantId": "variant:acme:trail-shoe-8:red:42",
    "productId": "product:acme:trail-shoe-9",
    "sku": "TS8-BLU-43",
    "optionValues": { "color": "red", "size_eu": "42" }
  },
  "offer": {
    "offerId": "offer:merchant-7:TS8-BLU-43:DE",
    "variantId": "variant:acme:trail-shoe-8:blue:43",
    "currency": "EUR",
    "listPrice": "129.90"
  }
}

Jedes Feld ist syntaktisch plausibel, was diese Befestigung nützlicher macht. Die Variante zeigt auf Produkt 9, seine SKU und Optionen sind nicht einverstanden, und das Angebot verweist auf eine andere Variante. Die Schemavalidierung allein kann die Referenzfehler verfehlen.

Validierungsregeln, die für Agenten von Bedeutung sind

Implementieren Sie mindestens vier Validierungsschichten.

Formvalidierung

Fehlende erforderliche Felder, zusätzliche unbekannte Felder, fehlerhafte Daten, ungültige URLs und nicht unterstützte Schemaversionen werden abgelehnt.

Referenzvalidierung

Stellen Sie sicher, dass jede Variante auf ein bestehendes Produkt und jedes Angebot auf eine bestehende Variante verweist. merchantId + market + offerId und stabile Wiederverwendungsregeln für SKUs.

Semantische Validierung

Bestätigen Sie, dass Einheiten- und Attributtypen dem Kategorievokabular entsprechen. Schuhgröße ist keine Freiformlänge. Spannung sollte eine vereinbarte Einheit verwenden. GTINs benötigen, falls vorhanden, gültige Längen und Prüfziffern. Google Merchant Center benötigt ebenfalls stabile Artikel-IDs und bildet Variantengruppen, GTIN, Preis, Währung und Verfügbarkeit zu definierten Feldern ab. Google unterstützt Produkt-Strukturierte-Daten-Attribute einen praktischen Interoperabilitätsbezug enthält.

Frischevalidierung

Überprüfung validUntil und observedAtVerwandeln Sie ein abgelaufenes Angebot nicht stillschweigend in ein aktives. unknown und den autoritativen Zustand abrufen.

function validateBundle(bundle: Bundle, now: Date): Issue[] {
  const issues: Issue[] = [];
  if (bundle.variant.productId !== bundle.product.productId)
    issues.push({ code: 'VARIANT_PRODUCT_MISMATCH' });
  if (bundle.offer.variantId !== bundle.variant.variantId)
    issues.push({ code: 'OFFER_VARIANT_MISMATCH' });
  if (
    bundle.offer.validUntil &&
    Date.parse(bundle.offer.validUntil) <= now.getTime()
  )
    issues.push({ code: 'OFFER_EXPIRED' });
  if (!isDecimal(bundle.offer.listPrice))
    issues.push({ code: 'PRICE_FORMAT_INVALID' });
  return issues;
}

Entwickeln Sie das Schema, ohne alte Fakten zu ändern

Die Entwicklung von Schemata wird gefährlich, wenn ein neuer Mapper die Bedeutung von Datensätzen bereits im Index ändert. Behandeln Sie das normalisierte Bündel als ein unveränderliches Ereignis. Speichern Sie seine Schemaversion, die Mapperversion und den Quellverdau zusammen. Eine Korrektur erzeugt eine neue Bündelrevision; sie schreibt die Beweise hinter dem alten nicht um.

type CatalogRevision = {
  bundleId: `bundle:${string}`;
  revision: number;
  schemaVersion: '2026-08-11';
  mapperVersion: `mapper:${string}`;
  sourceDigest: `sha256:${string}`;
  supersedes?: `${CatalogRevision['bundleId']}@${number}`;
  indexedAt: IsoDateTime;
};

Angenommen, ein Händler schickt weight: "310" ohne Einheit. Mapper 4 nimmt Gramm an, während Mapper 5 das Feld ablehnt. Wenn dieselbe Quelle unter Mapper 5 erneut verarbeitet wird, darf der indexierte Wert nicht stillschweigend in ein abwesendes Attribut umgewandelt werden.

Fügen Sie einen Migrationstest für jede Schema- oder Mapperänderung hinzu:

  1. Führen Sie den alten Fixture Corpus durch beide Mapper-Versionen.
  2. Diff die normierte Ausgabe Feld für Feld.
  3. Klassifizieren Sie jede Differenz als beabsichtigt, verboten oder Überprüfung erforderlich.
  4. Führen Sie Ranking- und Kompatibilitätstests mit beiden Revisionen erneut durch.
  5. Erfordern Sie eine Entscheidung des Betreibers für geänderte Kennungen, Geld, Einheiten oder Kompatibilität.

Dies fängt einen Fehler, den JSON Schema nicht kann: Ein Datensatz kann gültig bleiben, während sich seine kommerzielle Bedeutung ändert. Halten Sie Leser zumindest für das Migrationsfenster rückwärtskompatibel. Lehnen Sie eine zukünftige Schemaversion ab, die Sie nicht verstehen, anstatt zu erraten, wie Sie sie herunterkonvertieren können.

Halten Sie Entdeckung Fakten abgesehen von Live-Zustand

Indextitel, Beschreibungen, stabile Attribute, Evidenzverdauungen und Kompatibilitätsbeziehungen: Abrufen von Preisen, Inventar, Werbeaktionen und Lieferschätzungen von maßgeblichen Händlersystemen in der Nähe der Transaktion.

Die Produktdaten-Anleitung von Google erfordert Preis und Verfügbarkeit, um der Zielseite und dem Checkout zu entsprechen, und empfiehlt häufige Updates, wenn sich diese Werte ändern. Google Merchant Produktdatenspezifikation ist eher für Auflistungen als für eine autonome Ausführung konzipiert, aber seine Dismatch-Regeln zeigen, warum ein veralteter Handelsstaat nicht als harmlose Metadaten behandelt werden kann.

Für das Laufzeitmuster lesen Live-Preis, Inventar und Lieferung für EinkaufsagentenFür Auffindbarkeitsprobleme siehe Warum Shops für Shopping Agents unsichtbar werden.

Reproduzierbare Einrichtung

Erstellen Sie ein Verzeichnis mit genauen Eingaben und erwarteten Grundcodes:

fixtures/product-schema/
  valid-basic.json
  invalid-missing-currency.json
  invalid-product-reference.json
  invalid-expired-offer.json
  invalid-unknown-unit.json
  invalid-compatibility-without-target.json
  invalid-price-number.json
  invalid-duplicate-offer-id.json

Führen Sie jede durch Form- und Graphenvalidierung.

{
  "fixture": "invalid-product-reference.json",
  "valid": false,
  "codes": ["OFFER_VARIANT_MISMATCH", "VARIANT_PRODUCT_MISMATCH"]
}

Dann fügen Sie Mutationstests hinzu: Ändern Sie einen Identifikator, eine Währung, eine Einheit, einen Zeitstempel oder einen Beweisverdau in einer gültigen Vorrichtung. Eine nützliche Suite beweist, dass der Validator die Mutation aus dem erwarteten Grund ablehnt, nicht nur, dass ein Fehler aufgetreten ist.

Sicherheits- und Missbrauchsfälle

Behandeln Sie jeden vom Händler kontrollierten String als nicht vertrauenswürdige Daten. Produktbeschreibungen können Anweisungen enthalten, die auf das Modell abzielen. Legen Sie niemals Katalogtext in eine Systemnachrichtenrolle oder erlauben Sie ihm, die Toolrichtlinie zu ändern.

Weitere Fehlerfälle sind doppelte SKUs bei Händlern, eine GTIN, die für einen überarbeiteten Artikel wiederverwendet wird, ein Angebot, das den Preis ohne neue Beobachtungszeit ändert, inkompatible Einheitenkonvertierungen, versteckte Produktklassifizierungen für Erwachsene oder eingeschränkte Produkte und Beweis-URIs, deren Inhalt sich ändert, während die URL stabil bleibt.

Aktuelle Intelliger-Grenze

Der kanonische Commerce Graph, das Händler-Connector-Framework, das Produktschema-Mapping und die Agent Search Console sind Zielzustandskomponenten in Intelligers Agentic-Commerce-Blueprint vom August 2026.

Die aktuelle Entwicklervorschau von OATI umfasst Vertrauensobjekte, kanonische Signatur, deterministische Commerce-Einschränkungen, Quittungen, Middleware- und Konformitätsvektoren. Sein Commerce-Profil und seine Sandbox zeigen signierte Preis- und Budgetkontrollen für eine bezahlte API-Transaktion, nicht einen Produktions-Katalog-Einnahmeservice.

Entdecken Sie die beabsichtigte Commerce-Richtung in Agentic Commerce Architektur von Intelliger und die aktuelle offene Vertrauensschicht in der OATI-Dokumentation.

Checkliste der Durchführung

  • Geben Sie Produkten, Varianten, Angeboten und Händlern separate stabile IDs.
  • Geben Sie Attribute ein und normalisieren Sie Einheiten mit kontrolliertem Vokabular.
  • Stellen Sie Geld als Dezimalzeichenfolgen oder Ganzzahlen mit geringer Einheit dar.
  • Bindung des Preises an Währung, Markt, Händler und Gültigkeit.
  • Provenienz und Verdauung für Folgeaussagen aufzeichnen.
  • Modellkompatibilität als Beziehung zu einem Ziel und Status.
  • Erzwingen Sie referenzielle Integrität über JSON Schema hinaus.
  • Lehnen Sie abgelaufene Angebote ab, anstatt sie stillschweigend zu verlängern.
  • Halten Sie den volatilen Zustand aus dem deskriptiven Suchindex heraus.
  • Behandeln Sie Kataloginhalte als nicht vertrauenswürdige Eingabe zum Modell.
  • Veröffentlichen Sie gültige, ungültige und Mutationsvorrichtungen mit Grundcodes.

Überprüfungshinweis: Ein Spezialist für Handelsdatenmodelle sollte die Kategorievokabulare, die Regeln für die Wiederverwendung von Identifikatoren, regulierte Attribute und marktspezifische Preisanforderungen vor der Veröffentlichung oder Produktion überprüfen.

Herunterladen oder Kopieren der Fixture-Struktur oben, dann verwenden Sie die AI-Suche nach E-Commerce-Implementierungsleitfaden Um die Schemavalidierung vor der Katalogindexierung zu platzieren.