Metadaten, benutzerdefinierte Felder und Erweiterungen sind die Bereiche eines E-Commerce-Shops, in denen geschäftliche Bedeutung häufig über das Standardmodell für Produkte, Kunden, Bestellungen, Kategorien oder Inhalte hinausgeht. Sie können einfache Referenzinformationen enthalten, aber auch Storefront-Darstellung, Filterung, Preisberechtigung, Kundenrechte, Fulfillment-Abläufe, Steuerlogik, Personalisierung, Integrationen, Reporting oder Automatisierung steuern.
Diese Datenebene unterscheidet sich technisch von gewöhnlichen Datensatzfeldern. Für Produkttitel, SKU oder Kunden-E-Mail gibt es auf einer anderen Plattform meist ein klares Ziel. Für ein individuelles Kompatibilitätsfeld, ein Wholesale-Freigabekennzeichen, eine Regel für Produkt-Badges, eine ERP-ID, einen App-gesteuerten Abonnementwert oder eine Plugin-spezifische Optionstabelle gilt das nicht unbedingt. Derselbe Wert kann leicht zu speichern, schwer zu interpretieren und riskant zu erhalten sein, wenn die Zielplattform nicht dasselbe Datenmodell oder dieselbe Erweiterungsarchitektur verwendet.
Eine technische Prüfung sollte daher fragen: Was ist das Feld? Wo liegt es? Welches System besitzt es? Welche Funktion hängt davon ab? Kann die Zielplattform es in derselben Weise nutzen? Dass ein Feld vorhanden ist, reicht nicht. Es muss weiterhin das Ergebnis unterstützen, für das es geschaffen wurde.
Was Metadaten und benutzerdefinierte Felder in einem E-Commerce-Shop darstellen
Metadaten und benutzerdefinierte Felder erweitern das Standarddatenmodell. Sie erlauben, Informationen zu speichern, für die die Plattform kein Standardfeld bietet, oder bestehenden Datensätzen und Datenkategorien zusätzlichen Kontext zu geben.
Typische Beispiele sind:
- Produktspezifikationen außerhalb nativer Produktfelder;
- Produkt-Badges, Labels, Kompatibilitätshinweise, Pflege-, Größen-, Garantie- oder Compliance-Informationen;
- benutzerdefinierte Kategoriefelder für Landingpage-Inhalte, Merchandising-Blöcke, SEO-Texte oder Menülogik;
- Kundenfelder für Wholesale-Freigabe, VAT-Status, Loyalty-Stufe, Mitgliedschaft, Account-Typ oder Vertriebsverantwortung;
- Bestellmetadaten für Lieferhinweise, Fulfillment-Routing, Abonnements, Retouren, Rechnungen, Betrugsprüfung oder Reporting;
- individuelle Optionswerte aus Produktkonfiguratoren, Personalisierungs-Apps, Buchungssystemen oder konfigurierbaren Produktabläufen;
- externe Kennungen für ERP, CRM, PIM, POS, Marketplace, Fulfillment, Versand, Automatisierung, Analytics oder Reporting.
Manche Metadaten sind nur beschreibend, andere steuern Shop-Funktionen. Diese Trennung ist zentral: Beschreibende Metadaten müssen vor allem zugänglich bleiben. Verhaltenssteuernde Metadaten müssen weiterhin von Storefront-Templates, Admin-Oberflächen, Apps, Regeln, Workflows und verbundenen Systemen verstanden werden.
Typische Metadatenstrukturen in Shop-Daten
Metadaten können an viele Datenkategorien und Datensatzstrukturen gebunden sein. Ihre technische Form hängt davon ab, was das Feld beschreibt und wie die Plattform individuelle Daten speichert.
| Datenbereich | Typische Metadaten | Betroffene Funktion |
|---|---|---|
| Produkte und Varianten | Spezifikationen, Badges, Kompatibilität, Material, Pflege, Quell-IDs, Downloads, Produktkonfigurator-Werte | Produktseiten, Filter, Merchandising, Feeds, Integrationen, Fulfillment und Support |
| Kategorien und Kollektionen | Hero-Text, Menülabels, Aktionsblöcke, SEO-Inhalte, Landingpage-Regeln, Sortierung, Anzeigeoptionen | Navigation, Kollektionsseiten, Merchandising, SEO und Theme-Ausgabe |
| Kunden | Kundentyp, Freigabe, Steuer-/VAT-Status, Loyalty-Stufe, B2B-Rolle, Unternehmens-ID, Vertriebsmitarbeiter, Segmentierungswerte | Account-Zugriff, Preise, Aktionen, Personalisierung, Segmentierung, Steuern und CRM |
| Bestellungen | Lieferhinweise, Quellkanal, Betrugskennzeichen, Fulfillment-Anweisungen, Subscription-IDs, externe Order-IDs, Geschenknachrichten | Fulfillment, Service, Retouren, Buchhaltung, Versand, Reporting und Folgesysteme |
| Inhaltsobjekte | Artikelattribute, CMS-Block-Einstellungen, Formularwerte, Seitenbeziehungen, Lokalisierungsfelder | Ausgabe, Navigation, Suche, Lokalisierung und Kampagnenverwaltung |
| Integrationsdatensätze | ERP-/Marketplace-IDs, Feed-Kennungen, Lagercodes, Automatisierungsflags | Synchronisierung, Abstimmung, Reporting, Fulfillment und systemübergreifendes Matching |
Metadaten sind nicht immer für Käufer sichtbar. Besonders risikoreich können unsichtbare operative Kennungen sein, weil externe Systeme sie benötigen, um Datensätze nach dem Plattformwechsel wiederzuerkennen.
Informative gegenüber verhaltenssteuernden Metadaten
Eine nützliche technische Trennung ist die Frage, ob ein Feld nur Kontext speichert oder tatsächlich etwas steuert.
| Metadatentyp | Funktion | Typisches Risiko |
|---|---|---|
| Informative Metadaten | Details für Referenz, Administration, Support oder Inhaltsvollständigkeit | Geringeres Risiko, wenn Informationen für Mitarbeiter oder an benötigter Stelle zugänglich bleiben |
| Darstellungsmetadaten | Steuern Inhalte in Storefront, E-Mails, Labels, Tabs, Badges oder Inhaltsbereichen | Risiko steigt, wenn Theme oder Inhaltsmodell das Feld nicht lesen kann |
| Such- und Filtermetadaten | Steuern Filter, Facetten, Suchranking, Produktsuche oder Kollektionsregeln | Risiko steigt bei unterschiedlichen Feldtypen oder Indexierungsregeln |
| Berechtigungsmetadaten | Steuern Zugriff, Preissichtbarkeit, Rabatte, Steuerstatus, B2B-Rechte oder Freigabe | Risiko steigt bei unterschiedlichen Rollen-, Segment- oder Kundengruppenmodellen |
| Operative Metadaten | Unterstützen Fulfillment, Lagersteuerung, Rechnungen, Retouren, Abonnements, Betrugsprüfung oder Support | Risiko steigt, wenn Teams oder Folgesysteme exakte Werte benötigen |
| Integrationsmetadaten | Verbinden Datensätze mit ERP, CRM, PIM, POS, Marketplace, Analytics, Versand oder Automatisierung | Risiko bei geänderten, fehlenden, doppelten oder falsch zugeordneten Kennungen |
Diese Trennung verhindert den Fehler, alle benutzerdefinierten Felder gleich zu behandeln. Ein internes Notizfeld benötigt nicht dieselbe Prüfung wie ein Feld, das Wholesale-Preise oder ERP-Synchronisierung steuert.
Wie Plattformen individuelle Daten unterschiedlich speichern
Plattformen lösen Anforderungen an individuelle Daten unterschiedlich. Einige verwenden native Custom Fields, andere Metafields oder Attribute. Weitere speichern Zusatzdaten in Plugin-Tabellen, App-eigenen Datensätzen, JSON-Strukturen, benutzerdefinierten Datenbankspalten oder Theme-Konfiguration.
| Plattformmodell | Typische Form individueller Daten | Technische Konsequenz |
|---|---|---|
| SaaS mit Metafield-System | Namespace/Key/Value, typisierte Custom Fields, App-eigene Felder, Theme-lesbare Werte | Speicherung kann einfach sein, aber Sichtbarkeit, Datentyp, App-Eigentum und Theme-Zugriff müssen geprüft werden |
| Attributreiches Modell | Attributsets, Gruppen, scoped Werte, Optionslisten, Entity-Attribute-Value-Strukturen | Filterung und Admin-Struktur sind möglich, Mapping hängt aber von Attributtyp und Scope ab |
| Open Source / Plugin-intensiv | Plugin-Tabellen, Custom Post Meta, Moduldaten, serialisierte Werte, Custom Columns, Erweiterungskonfiguration | Werte können außerhalb des Standardexports liegen und erweiterungsspezifische Interpretation brauchen |
| Enterprise / Composable | Custom Objects, Custom Resources, API-Erweiterungen, PIM-Felder, Middleware-IDs | Datenquelle und Eigentümerschaft sind ebenso wichtig wie Feldtransfer |
| Marketplace-verbundene Shops | Marketplace-IDs, kanalspezifische Felder, Feed-Attribute, Listing- und Compliance-Metadaten | Werte können kanalspezifisch sein und gehören nicht ausschließlich der Shop-Plattform |
| Headless / individueller Storefront | CMS-Felder, API-Attribute, Frontend-Konfiguration, eigene Schemas, App-Inhalte | Storefront-Funktion kann von API-Verträgen und Frontend-Code statt nur Plattformdatensätzen abhängen |
Ein Feld namens material, customer_type oder external_id kann deshalb je nach Speicherort etwas anderes bedeuten. Es kann natives Attribut, Metafield, App-Einstellung, ERP-Kennung, Plugin-Feld oder reiner Theme-Wert sein. Der Feldname allein erklärt seine Rolle nicht.
Datentyp, Geltungsbereich und Eigentümerschaft sind entscheidend
Individuelle Daten bestehen nicht nur aus Name und Wert. Mehrere Eigenschaften bestimmen, ob ein Feld nach einem Plattformwechsel nützlich bleibt.
| Eigenschaft | Warum sie wichtig ist |
|---|---|
| Datentyp | Text, Zahl, Datum, Boolean, URL, Datei, Liste, JSON, Referenz und Rich Text verhalten sich in Formularen, Filtern, APIs und Themes unterschiedlich |
| Geltungsbereich | Ein Wert kann global, pro Store View, Sprache, Markt, Kanal, Kundengruppe oder Website gelten |
| Datensatzbezug | Dasselbe Feld kann zu Produkt, Variante, Kategorie, Kunde, Bestellung, Unternehmen, Inhaltsobjekt oder Integration gehören |
| Eigentümerschaft | Native Plattform, Theme, App, Plugin, Modul, eigener Code oder externes System bestimmen, wer lesen und schreiben kann |
| Sichtbarkeit | Admin-only, Storefront-, API-, Feed-, Suchindex-sichtbar oder im Standardexport verborgen |
| Kardinalität | Einzelwert, mehrere Werte, geordnete Listen, wiederholbare Blöcke, Referenzen und verschachtelte Objekte benötigen unterschiedliche Zielstrukturen |
| Validierungsregeln | Pflichtwerte, erlaubte Optionen, Formatierung und Abhängigkeiten beeinflussen Import und Verwaltung |
| Lebenszyklus | Manche Felder sind historische Snapshots, andere müssen nach Launch editierbar, synchronisiert oder neu berechnet bleiben |
Ein Textfeld kann zwar als Text übertragen werden. Benötigt die Zielplattform es jedoch als typisierte Referenz, filterbare Option oder App-lesbare Konfiguration, erhält ein einfacher Transfer die Geschäftsfunktionsweise nicht.
Daten im Eigentum von Erweiterungen und Apps
Apps, Plugins, Module und Erweiterungen schaffen häufig eine eigene Datenebene, etwa für Produktkonfiguratoren, Abonnements, Loyalty, Reviews, erweiterte Suche, B2B-Preise, Produktlabels, Bundles, Empfehlungen, Formulare, Marketplace-Feeds, Termine, Downloads oder Lieferregeln.
Diese Daten können schwer zu übertragen sein, weil sie von der eigenen Struktur der Erweiterung abhängen:
- benutzerdefinierte Datenbanktabellen;
- App-spezifische IDs;
- Konfigurationsdatensätze;
- serialisierte oder JSON-Einstellungen;
- Theme-Snippets oder Blöcke;
- Frontend-Skripte;
- API-Beziehungen;
- geplante Jobs oder Automatisierungsregeln;
- anbieterbezogene Datensätze außerhalb der E-Commerce-Plattform.
Ein Datensatz kann außerhalb der ursprünglichen Erweiterung bedeutungslos sein. Eine Produktkonfigurator-Konfiguration kann Optionsgruppen, bedingte Logik, Preisaufschläge, Kundendateien und Auswahlen enthalten, die nur die ursprüngliche App versteht. Ein Subscription-Datensatz kann Abrechnungszyklus, Kundenfreigabe, Payment-Token-Beziehung, Retry-Status, Kündigungsstatus und Anbieterkennungen enthalten und lässt sich nicht wie gewöhnliche Bestelldaten behandeln.
Die technische Frage ist daher nicht nur, ob erweiterungseigene Daten existieren, sondern ob die Zielplattform ein natives Äquivalent, eine Ersatz-App, ein Custom-Object-Modell oder einen Konfigurationspfad nach der Migration bietet, der die beabsichtigte Funktion erhält.
Typische Bereiche, in denen individuelle Daten Shop-Funktionen beeinflussen
Individuelle Daten werden häufig erst sichtbar, wenn sich die Funktion ändert.
| Funktionsbereich | Möglicher Einfluss von Metadaten oder Erweiterungsdaten |
|---|---|
| Produktseiten | Spezifikationen, Tabs, Badges, Kompatibilität, Downloads, Konfiguratoroptionen, variantenspezifische Hinweise |
| Suche und Filter | filterbare Attribute, Tags, Metafields, Taxonomiewerte, indexierte Custom Fields, Suchkonfiguration |
| Preise und Aktionen | Kundentyp, Mengenstufe, Wholesale-Flag, Berechtigungsfeld, Produktlabel-Regeln, erweiterungsgesteuerte Rabattbedingungen |
| Kundenkonten | B2B-Rollen, Freigaben, Loyalty-Stufen, VAT-Status, Mitgliedschaften, Unternehmensbeziehungen, Zugriffsrechte |
| Checkout und Fulfillment | Lieferhinweise, Versandbeschränkungen, Abholregeln, Abonnementwerte, Bestell-Custom-Fields, Routing-IDs |
| Integrationen | ERP-/CRM-IDs, Feed-Kennungen, Lagercodes, Marketplace-Listing-IDs, Middleware-Referenzen |
| Reporting und Analytics | Attribution-Felder, Kanal-IDs, Vertriebsfelder, Custom Status, operative Kategorien |
| Lokalisierung und Multi-Store | Locale-spezifische Werte, Store-View-Overrides, marktspezifische Inhalte, kanalspezifische Sichtbarkeit |
Deshalb sollten Metadaten anhand von Anwendungsfällen geprüft werden. Ein Wert kann im Admin korrekt erscheinen und dennoch nutzlos sein, wenn Filter ihn nicht indexieren, der Storefront ihn nicht ausgibt, Preislogik ihn nicht liest oder ein externes System ihn nicht mehr erkennt.
Transformation statt nur Transfer
Bei metadatenreichen Projekten ist häufig eine Transformation statt einfacher Feldübertragung nötig. Dabei wird der Quellwert so umgeformt, dass die Zielplattform ihn korrekt nutzen kann.
Beispiele:
- Produktattribute in Metafields oder typisierte Custom Fields umwandeln;
- Tags in Kundensegmente, Gruppen oder Zugriffsregeln überführen;
- Plugin-spezifische Optionsstrukturen in native Optionen, Custom Fields oder ein Ersatz-App-Modell überführen;
- ein Quellfeld auf mehrere Zielfelder aufteilen;
- mehrere Quellwerte in einer normalisierten Zielstruktur zusammenführen;
- Textwerte in Optionslisten umwandeln, damit sie filterbar sind;
- serialisierte oder JSON-Werte in lesbare Feldgruppen überführen;
- externe IDs erhalten, während sich das umgebende Datenmodell ändert;
- veraltete Erweiterungswerte ausschließen, die auf der Zielseite keinen Zweck mehr haben.
Die richtige Entscheidung hängt von der künftigen Rolle des Feldes ab. Für reine historische Referenz kann Transfer ausreichen. Muss das Feld Storefront, Administration, Suche, Filter, Berechtigung, Automatisierung oder Synchronisierung steuern, muss die Zielrepräsentation an diesem Ergebnis ausgerichtet werden.
Auf welche plattformspezifischen Unterschiede zu achten ist
Typisierte Felder gegenüber freien Textfeldern
Einige Plattformen erzwingen starke Datentypen, andere speichern individuelle Werte als freien Text. Starke Typisierung verbessert Validierung, Filterung und API-Nutzung, kann aber Bereinigung oder Normalisierung von Quellwerten verlangen.
Produkt- gegenüber Variantenfeldern
Ein individuelles Feld kann auf einer Plattform zum Stammprodukt und auf einer anderen zu jeder Variante gehören. Steuert es größen-, farb- oder SKU-spezifische Funktion, kann produktbezogene Zuordnung zu breit sein.
Attributsets gegenüber globalen Custom Fields
Attributreiche Plattformen organisieren Felder in Sets oder Gruppen, andere verwenden global definierte Metafields oder Custom Fields. Das beeinflusst Admin-Nutzbarkeit und Pflege nach Launch.
App-eigene gegenüber händlereigenen Feldern
Einige Felder werden von Apps erzeugt und kontrolliert. Sie dürfen möglicherweise nicht sicher außerhalb der App bearbeitet werden; eine Ersatz-App kann eine andere Struktur nutzen.
Store View, Markt und Sprache als Scope
Ein Wert kann sich je Sprache, Website, Markt oder Kanal unterscheiden. Hat die Zielplattform ein anderes Scope-Modell, muss der Wert eventuell dupliziert, zusammengeführt oder neu gestaltet werden.
Suchindexierte gegenüber nicht indexierten Feldern
Ein Feld kann existieren, ohne für Suche oder Filter verfügbar zu sein. Unterstützt es Produktsuche, sind Such- und Filterkonfiguration ebenso wichtig wie der Feldwert.
Metadaten vor einem Plattformwechsel prüfen
Ein brauchbares Metadateninventar erfasst mehr als Feldnamen. Es dokumentiert Geschäftszweck und technische Abhängigkeit.
| Prüffrage | Warum sie wichtig ist |
|---|---|
| Welcher Datensatz oder welche Datenkategorie besitzt das Feld? | Produkt-, Varianten-, Kategorie-, Kunden-, Bestell-, Inhalts- oder Systemzuordnung beeinflusst Mapping |
| Welchen Datentyp hat der Wert? | Text, Zahl, Datum, Boolean, Liste, Datei, Referenz, JSON oder Rich Text brauchen unterschiedliche Behandlung |
| Ist das Feld informativ oder verhaltenssteuernd? | Verhaltenssteuernde Felder benötigen tiefere Validierung |
| Wo ist das Feld sichtbar? | Admin, Storefront, API, Feed, Suche, Report oder externes System bestimmen den Testumfang |
| Wer aktualisiert es? | Händler, Apps, Integrationen, Middleware, Mitarbeiter oder Jobs können Editierbarkeit benötigen |
| Welche Funktion hängt davon ab? | Filter, Preise, Segmentierung, Checkout, Fulfillment, Reporting oder Integrationen können betroffen sein |
| Gibt es auf der Zielplattform ein Äquivalent? | Natives Feld, Metafield, Attribut, App-Modell, Custom Object oder kein Äquivalent bestimmen die Komplexität |
| Ist Transformation erforderlich? | Transfer, Konvertierung, Normalisierung, Aufteilung, Zusammenführung oder Ausschluss sind unterschiedliche Anforderungen |
Das Inventar sollte wichtige Beispiele statt nur Feldsummen enthalten. Ein Produkt mit komplexen Optionen, ein Kunde mit Freigabelogik, eine Kategorie mit individueller Landingpage und eine Bestellung mit operativen Metadaten können mehr zeigen als eine lange Liste einfacher Felder.
Auswirkungen auf die Migration bei Metadaten und Erweiterungen
Das Risiko entsteht meist aus Bedeutung, Eigentümerschaft und Funktion.
Wichtige Konsequenzen sind:
- Feldnamen reichen möglicherweise nicht zur Bestimmung des Geschäftszwecks;
- einige Felder liegen außerhalb von Standardexporten;
- App-eigene Daten sind ohne Original-App oder kompatiblen Ersatz möglicherweise nicht nutzbar;
- die Zielplattform kann einen Wert speichern, ohne ihn für Themes, Filter, APIs, Feeds oder Reports verfügbar zu machen;
- externe IDs müssen am richtigen Datensatz erhalten bleiben;
- verhaltenssteuernde Felder benötigen Validierung durch Storefront- und Workflow-Ergebnisse;
- individuelle Werte können Transformation, Normalisierung, Filterung oder Neuzuordnung erfordern.
Die Behandlung sollte dem konkreten Feldproblem entsprechen. Eine erweiterte Feldzuordnung kann passen, wenn Quellfelder anderen kompatiblen Zielfeldern zugeordnet werden müssen. Selektive Filterung kann passen, wenn nur bestimmte Datensätze mit Custom Fields übertragen werden sollen. Erweiterungseigene Daten, Custom-Platform-Funktionen, eigene Logik und nicht standardisierte Strukturen benötigen eine angepasste Interpretation, wenn gewöhnliche Feldübertragung ihre Bedeutung nicht erhält.
Was nach der Übertragung von Metadaten validiert werden sollte
Validierung muss prüfen, ob Metadaten im Kontext weiterhin funktionieren.
Priorität haben:
- Produkte mit individuellen Spezifikationen, Badges, Kompatibilität, Downloads oder Produktkonfigurator-Funktion;
- Varianten mit SKU-spezifischen Werten;
- Kategorien/Kollektionen mit Landingpage- oder Merchandising-Feldern;
- Kunden mit Freigabe-, Loyalty-, B2B-, VAT-, Rollen- oder Segmentierungswerten;
- Bestellungen mit Fulfillment-, Rechnungs-, Subscription-, Retouren- oder Support-Metadaten;
- Datensätze mit ERP-, CRM-, PIM-, POS-, Marketplace-, Versand-, Automatisierungs- oder Reporting-Bezug;
- jedes Feld, das von einer Quellstruktur in eine neue Zielrepräsentation transformiert wurde.
Nützliche Prüffragen:
- Erscheint das Feld an der richtigen Admin-Stelle?
- Zeigt oder verbirgt der Storefront den Wert korrekt?
- Lesen Suche, Filter, Preislogik, Segmentierung oder Automatisierung den Wert weiterhin?
- Erkennen verbundene Systeme die migrierte Kennung?
- Können Mitarbeiter das Feld nach Launch pflegen?
- Bewahrt die neue Struktur bei transformierten Feldern die beabsichtigte Funktion?
Validierung sollte repräsentative Komplexität priorisieren. Eine einfache Textnotiz ist weniger kritisch als ein Feld, das Berechtigung, Preise, Produktsuche, Fulfillment oder Integrationskontinuität steuert.
Fazit
Metadaten, benutzerdefinierte Felder und Erweiterungen enthalten häufig die geschäftsspezifischste Logik eines Shops. Sie wirken wie kleine Zusatzwerte, können aber bestimmen, wie Produkte erscheinen, wer welche Berechtigung erhält, welche Preise gelten, wie Bestellungen operativ verarbeitet werden und wie externe Systeme Datensätze erkennen.
Die sicherste technische Prüfung trennt informative von verhaltenssteuernden Feldern, identifiziert den Eigentümer jedes Werts und bestimmt, ob die Zielplattform dieselbe Bedeutung über native Felder, Attribute, Metafields, Custom Objects, Apps oder individuelle Behandlung bewahren kann. Eine Migration sollte nicht nur daran gemessen werden, ob ein Custom Field nach dem Transfer existiert. Entscheidend ist, ob es weiterhin Storefront-, Admin-, operative und Integrationsfunktionen unterstützt.
Wenn Metadaten für Preise, Sichtbarkeit, Filterung, Segmentierung, Fulfillment oder angebundene Systeme entscheidend sind, sollte die Zielrepräsentation vor der Ausführung geprüft werden. Hängt das gewünschte Ergebnis von Transformation, erweiterungsspezifischer Behandlung oder eigener Logik ab, braucht die Zuordnung, angepasste Behandlung, Implementierungsgrenze und Abnahme einen qualifizierten Verantwortlichen.
Häufige Fragen
Sind Metadaten dasselbe wie ein benutzerdefiniertes Feld?
Nicht immer. Ein benutzerdefiniertes Feld ist meist ein definiertes Zusatzfeld an Produkt, Kunde, Bestellung, Kategorie oder Inhaltsobjekt. Metadaten sind breiter und umfassen auch App-Werte, Plugin-Daten, Kennungen, Konfiguration und andere ergänzende Informationen.
Warum kann ein benutzerdefiniertes Feld migrieren und trotzdem nicht mehr funktionieren?
Weil Speicherung nicht dasselbe ist wie Funktion. Das Feld kann auf der Zielplattform existieren, aber vom Theme, Suchindex, Filtersystem, einer Preisregel, App, einem Workflow, einer API oder einem externen System nicht mehr gelesen werden.
Welche benutzerdefinierten Felder brauchen besonders viel Aufmerksamkeit?
Felder, die echte Funktion steuern: Preise, Sichtbarkeit, Berechtigung, Filterung, Segmentierung, Fulfillment, Steuern, Abonnements, Produktkonfiguratoren, Marketplace-Listings oder externe Systemkennungen.
Benötigen metadatenreiche Shops immer eine individuelle Migrationslösung?
Nein. Manche Metadaten lassen sich über unterstütztes Feld-Mapping oder Konfiguration abbilden, wenn die Zielstruktur klar ist. Individuelle Behandlung wird wichtiger bei erweiterungseigenen Daten, Custom-Platform-Funktionen, eigener Logik, Transformation, nicht standardisierten Strukturen oder Zielverhalten, das gewöhnlicher Feldtransfer nicht erhalten kann.