Bei der Bewertung von ShopWired als mögliche Zielplattform zeigt das Datenmodell, wie Quelldaten, Beziehungen und geschäftliche Bedeutung in der Zielumgebung abgebildet werden müssen.
Wenn ShopWired als Zielplattform betrachtet wird, besteht die Aufgabe nicht nur darin, Products, Customers, Orders, Categories, Reviews, Coupons und CMS-Datensätze in einen neuen Administrationsbereich zu übertragen. ShopWired besitzt eine eigene Handelsstruktur für Products, Categories, Marken, Variationen, Auswahlmöglichkeiten, Extras, Bestand, Customer-Identität, B2B-Funktionen, Checkout-Konfiguration, Umsatz- und Verkaufssteuer, Versandregeln, Apps, API-Verhalten und die Theme-gesteuerte Storefront. Eine belastbare Migration muss Source-Daten in diese Struktur übersetzen, ohne die geschäftliche Bedeutung der Datensätze zu verlieren.
Die zentrale Frage lautet: Wenn ein Source-Datensatz in ShopWired ankommt, bleibt verständlich, was er bedeutet, und kann der Shop ihn weiterhin richtig verwenden? Eine Product-Option, die zuvor nur als einzelnes Label geführt wurde, kann in ShopWired eine Variation, Auswahlmöglichkeit, ein Extra, Bundle, Personalisierungsfeld oder eine von einer App bereitgestellte Funktion darstellen. Ein Customer-Segment kann als Customer-Datensatz, Newsletter-Abonnent, B2B-Customer, Preisgruppe oder Custom Field enden. Eine historische Order kann für Servicezwecke vollständig lesbar sein, ohne dadurch Checkout, Versand, Zahlung, Umsatzsteuer, Sales Tax oder B2B-Verhalten für zukünftige Transaktionen zu konfigurieren.
Die Datenbedeutung in ShopWired wird klarer, wenn Datensatzübertragung und operative Rekonstruktion getrennt betrachtet werden. Jeder Wert sollte nach der kommerziellen oder operativen Funktion eingeordnet werden, die er weiterhin erfüllen muss: Katalognavigation ermöglichen, kaufbare Kombinationen steuern, Customer-Historie erhalten, B2B-Konten unterstützen, historische Orders erklären, Suchsichtbarkeit bewahren, externe Systeme verbinden oder die laufende Merchandising-Arbeit unterstützen.
Prioritäten bei der Datenübertragung nach ShopWired
Die Planung des ShopWired-Datenmodells sollte mit den Bereichen beginnen, in denen sich geschäftliche Bedeutung am stärksten verändern kann: Product-Konfiguration, Customer-Identität, B2B-Verhalten, Order-Interpretation, Auffindbarkeit in der Storefront und Abhängigkeiten von externen Systemen. Diese Bereiche entscheiden darüber, ob der migrierte Shop nur befüllt oder tatsächlich nutzbar ist.
| Bereich im Quellshop | Interpretation in ShopWired | Planungsfrage für die Migration |
|---|---|---|
| Product-Varianten und Optionen | Variationen, Auswahlmöglichkeiten, Extras, Bundles, Text-/Dateieingaben oder App-Verhalten | Beeinflusst die Source-Option SKU, Preis, Bestand, Versand, Steuer oder nur die Darstellung? |
| Category- und Markenstruktur | Product-Auffindbarkeit, Navigation, Filterung, SEO und Merchandising | Können Customers priorisierte Products weiterhin über die erwarteten Wege finden? |
| Customer-Datensätze | E-Mail-basierte Customer-Identität, Kontostatus, Order-Historie, Notizen, Custom Fields und B2B-Trennung | Behalten doppelte, Gast-, B2B- und registrierte Customer-Datensätze die richtige Bedeutung? |
| Customer-Gruppen und B2B-Konten | B2B-Sichtbarkeit, Preise, Kontoverhalten und operative Regeln | Welche Regeln sind Daten, welche ShopWired-Konfiguration und welche benötigen eine gesonderte Prüfung? |
| Historische Orders | Customer-Historie, Zahlungs- und Versandbezeichnungen, Steuerwerte, Order-Notizen, Auftragsabwicklung-Kontext und externe Referenzen | Bleiben historische Orders nach der Migration für Service und Berichtswesen nutzbar? |
| Inhalte und SEO-Assets | Seiten, Landingpages, Blog Posts, Menüs, Redirects, Metadaten und Theme-gesteuerte Darstellung | Welche Inhalte beeinflussen Suche, Vertrauen, Conversion oder B2B-Onboarding? |
| Apps und Integrationen | Externe Datenverantwortung, API-/Webhook-Verhalten, Bestandsfeeds, Buchhaltung, Auftragsabwicklung, E-Mail, Marktplätze oder CRM-Prozesse | Welche angebundenen Systeme müssen neu konfiguriert, zugeordnet, aufgebaut oder ausgeschlossen werden? |
Diese Sicht verhindert einen typischen Fehler: ähnliche Feldnamen als ausreichenden Nachweis für gleiche Bedeutung zu behandeln. Feldähnlichkeit garantiert keine operative Gleichwertigkeit. In ShopWired hängt Bedeutung davon ab, wie ein Datensatz an Product-Auswahl, Customer-Erkennung, B2B-Verkauf, Checkout, Auftragsabwicklung, Steuerberechnung und Storefront-Darstellung beteiligt ist. Eine belastbare Verantwortung-Map verbindet deshalb jeden Wert mit seinem übergeordneten Product, der Variation, dem Customer, B2B-Konto, Angebot, der Order, dem Content-Datensatz, der App oder dem externen System, bevor ein Feld-Mapping festgelegt wird.
Products, Categories, Marken und Auffindbarkeit
ShopWired Products sind mit Categories, Marken, Variationen, Auswahlmöglichkeiten, Extras, Bestand, Preisen, Bildern, Suchbegriffen, Filtern, URLs und Merchandising-Beziehungen verbunden. Quellplattformen können dieselben Sachverhalte in Products, Collections, Tags, Attributen, Herstellern, Page-Builder-Blöcken oder App-Datensätzen speichern. Im Ziel sollte jede Bedeutung der ShopWired-Struktur zugeordnet werden, die sie tatsächlich besitzt.
Categories bilden eine hierarchische Product-Organisation, Marken die Hersteller- oder Markenidentität. Product-Filter können strukturierte Vergleichswerte sichtbar machen. Product-Suchbegriffe verbessern die Auffindbarkeit, ohne selbst sichtbare Categories zu werden. Ein Theme kann diese Datensätze darstellen, ist aber nicht deren maßgeblicher Eigentümer.
| Source-Katalogkonzept | Eigentümer in ShopWired | Konsequenz der Übertragung |
|---|---|---|
| Abteilung oder dauerhafte Hierarchie | Category und Parent-Child-Struktur | Product-Zugehörigkeit und dauerhaftes Navigationsziel erhalten. |
| Hersteller oder Marke | Markenbeziehung | Markenidentität von generischer Category oder Spezifikation trennen. |
| Technisches Attribut zur Eingrenzung | Product-Filter oder strukturiertes Feld | Vergleichswert erhalten, ohne künstliche Varianten zu erzeugen. |
| Interner Suchsynonym-Begriff | Product-Suchbegriff | Auffindbarkeit verbessern, ohne den Begriff als Kataloginhalt auszugeben. |
| Kampagnen-Collection | Category, Landingpage, Angebot oder kuratierte Darstellungsbeziehung | Dem kommerziellen Zweck statt dem Source-Label folgen. |
| Hauptbild und Galerie | Product-/Variations-Medienbeziehung | Bildrolle und variationsspezifische Medien erhalten, wenn sich die kaufbare Kombination ändert. |
Product-Identität bleibt nur dann kommerziell nutzbar, wenn Teams erkennen können, was verkauft wird, wo es erscheint, welcher Marke oder Category es zugeordnet ist, wie es gefunden wird und welcher Bestands- und Preisdatensatz die kaufbare Einheit steuert.
Variationen, Auswahlmöglichkeiten, Extras und Bedeutung der Product-Konfiguration
ShopWired unterscheidet Variationen, Auswahlmöglichkeiten, Extras, Freitext, Datei-Uploads, Bundles, Vorbestellungen, Abonnements und weitere Product-Verhaltensweisen. Quellplattformen nennen all diese Strukturen häufig „Optionen“, obwohl ihre Beziehungen verschieden sind.
Eine Variation bildet eine kaufbare Kombination und kann SKU, Preis, Bestand, Bild, Gewicht, GTIN, MPN und umsatzsteuerrelevante Bedeutung tragen. Eine Auswahlmöglichkeit oder ein Extra kann eine optionale Wahl bzw. einen Aufpreis ergänzen, ohne dieselbe bestandsführende Identität zu schaffen. Text- und Dateieingaben erhalten von Customers gelieferte Informationen. Ein Bundle verbindet ein Angebot mit anderen Product-Datensätzen. Vorbestellungen und Abonnements erzeugen Zeit- und Transaktionsbeziehungen, die über statische Product-Felder hinausgehen.
| Source-Verhalten | Eigentümer in ShopWired | Zu erhaltende Bedeutung |
|---|---|---|
| Größen-/Farbkombination mit eigener SKU oder eigenem Bestand | Variation | Kaufbare Identität, Preis, Bestand, Bild, Gewicht und externe Kennungen auf Kombinationsebene |
| Optionales Upgrade oder Geschenkverpackung | Auswahlmöglichkeit oder Extra | Optionale Auswahl und Preiswirkung ohne falsche Variantenbestände |
| Gravurtext | Product-Freitextfeld und Snapshot in der Order-Zeile | Customer-Eingabe mit Bezug zur gekauften Position |
| Customer-Grafik oder Dokument | Datei-Upload-Beziehung und Snapshot in der Order-Zeile | Eigentum, Sicherheit und Sichtbarkeit für die Auftragsabwicklung |
| Kit oder Multipack | Bundle oder Product-zu-Product-Beziehung | Komponentenidentität, Menge, Bestandsverantwortung und historische Order-Bedeutung |
| Vorbestellbares oder abonnierbares Product | Product plus zeitliche/Order-Beziehung | Release-, Abrechnungs-, Verlängerungs- oder Kontokontext, der nicht allein in Product-Feldern steckt |
| Bedingter Konfigurator | App-eigene Logik | Source-Auswahl und resultierende Order-Daten von der erzeugenden App trennen |
Diese Unterscheidung verhindert zwei gegensätzliche Fehler: beschreibende oder optionale Daten als Varianten aufzublähen und bestandsführende Kombinationen zu statischem Text zu reduzieren. Externe Kennungen müssen auf der Product- oder Variationsebene verbleiben, die Lager-, Buchhaltungs-, Feed- und Marktplatzsysteme tatsächlich erkennen.
Customer-, Konto- und Marketingdaten
ShopWired trennt Customer-Profile, Newsletter-Abonnenten, B2B-Customers, Bonuspunkte, Empfehlungsbeziehungen, Customer-Quellen und von Apps erzeugte Customer-Daten. E-Mail ist ein wichtiger Identitätsschlüssel; doppelte E-Mail-Adressen, Guest Orders, Legacy-Konten und B2B-Beziehungen können eine direkte Eins-zu-eins-Zuordnung jedoch unsicher machen.
Ein Customer-Datensatz kann Kontaktdaten, Adressen, Kontostatus, Order-Historie, Notizen und Custom Fields besitzen. Newsletter-Status beschreibt eine Kommunikationsbeziehung und ersetzt keine Customer-Identität. B2B-Status ergänzt Preis- und Zugriffslogik. Bonuspunkte bilden ein Customer-bezogenes Ledger. App-Tags oder CRM-Kennungen können im Eigentum externer Systeme bleiben.
| Source-Identitätsmuster | Beziehungsentscheidung in ShopWired |
|---|---|
| Registrierter Retail-Käufer | Customer-Profil mit Adressen und historischen Orders verknüpfen |
| Gastkäufer | Order-bezogene Identität und Adressen erhalten, ohne ein dauerhaftes Konto zu erfinden |
| Reiner Newsletter-Kontakt | Subscriber-Beziehung getrennt von einem Käuferkonto halten, sofern die Datensätze nicht tatsächlich dieselbe Person repräsentieren |
| Genehmigter B2B-Käufer | B2B-Customer plus Preis-, Sichtbarkeits-, Steuer- und Kontobeziehungen, die der Freigabe Bedeutung geben |
| Doppelte Source-Konten | Nur zusammenführen, wenn Identität, Einwilligung, Adressen und Order-Eigentum die Entscheidung stützen |
| Bonus- oder Empfehlungsstand | Customer-bezogener Programmdatensatz statt generischer Customer-Notiz |
| CRM- oder Marketing-ID | Externe Systemkennung mit dokumentierter Customer-/B2B-Customer-Beziehung |
Customer-Bereinigung darf daher nicht nur nach Namensähnlichkeit erfolgen. Die Zuordnung muss Order-Historie, Einwilligung, B2B-Status, externe Kennungen und zukünftiges Kontoverhalten schützen.
B2B-, Trade-, Angebots- und Preisdaten
Zu ShopWired B2B-Strukturen gehören B2B-Customers, nur für B2B sichtbare Categories und Products, B2B-Preise, Preisstaffeln, individuelle Preise, globale Rabatte, Angebote und damit verbundenes Kontoverhalten. Dabei handelt es sich um verbundene Datensätze, nicht um Attribute einer einzigen Customer-Zeile.
Die Käuferidentität gehört zum Customer bzw. B2B-Customer. Die kommerzielle Regel kann einer Preisstaffel, einem Product-spezifischen B2B-Preis, einer individuellen Ausnahme, einem globalen Rabatt, einer Sichtbarkeitsbeziehung oder einem Angebot gehören. Historische Angebote und Orders bewahren verhandelte Ergebnisse; die aktuelle B2B-Konfiguration definiert das zukünftige Kaufverhalten.
| B2B-Source-Element | Eigentümer in ShopWired | Bedeutung der Beziehung |
|---|---|---|
| Genehmigtes Geschäftskonto | B2B-Customer | Käuferidentität und genehmigter B2B-Status |
| Großhandelsstufe | B2B-Preisstaffel oder globaler Rabatt | Gemeinsame kommerzielle Behandlung einer Klasse von B2B-Customers |
| Vertragspreis | Individueller B2B-Customer-Preis oder andere Product-Customer-Beziehung | Kontospezifische Ausnahme auf der richtigen Product- oder Variationsebene |
| Nur für B2B sichtbares Sortiment | Product-/Category-Sichtbarkeitsbeziehung | Welche genehmigten Käufer das Product finden und kaufen können |
| Angebot | Angebotsdatensatz mit Customer, Products, Preisen, Notizen, Status und ggf. späterer Order | Verhandelter kommerzieller Snapshot statt gewöhnlicher Warenkorb |
| Bestellbedingungen | Customer-/Angebots-/Order-Kontext plus Ziel-Zahlungskonfiguration | Historische Bedingungen und Referenzwerte getrennt vom Live-Checkout |
| Umsatzsteuerstatus | B2B-Customer- und Steuerbeziehung | Käufernachweis und kommerzielle Behandlung nicht auf ein Label reduzieren |
Eine Source-Customer-Group allein reicht daher nicht aus. Ihre Datenmodellbedeutung besteht im Netzwerk aus Preisen, Products, Sichtbarkeitsregeln, Angebotsverlauf, Bedingungen und Steuerbehandlung, das mit dieser Gruppe verbunden ist.
Orders, Order-Status, Angebote und Transaktionskontext
Eine ShopWired Order dokumentiert, was in einer Transaktion passiert ist. Zu ihren Beziehungen können Customer- oder Gastidentität, Product- und Variationspositionen, Auswahlmöglichkeiten, Extras, Personalisierungsdaten, Preise, Gutscheine, Versand, Zahlungsbezeichnungen, Umsatz- oder Verkaufssteuer, Status, Notizen, Erstattungen, Retouren, Abonnements, Angebote und Referenzen externer Systeme gehören.
Historische Order-Werte sind Snapshots. Sie sollten nicht anhand aktueller Product-Preise oder Steuereinstellungen neu berechnet werden. Eine Zahlungs- oder Versandbezeichnung erklärt die vergangene Order, konfiguriert jedoch weder das Ziel-Freigabekriteriumway noch die Versandzone. Ein Order-Custom-Field gehört zur Transaktion, sofern derselbe Wert nicht bewusst zu dauerhaftem Customer- oder Product-Datum erhoben wird.
| Order-Beziehung | Zu erhaltende historische Bedeutung |
|---|---|
| Customer- oder Gastzuordnung | Wer die Order aufgegeben hat und welche Adressen verwendet wurden |
| Product-/Variationsposition | Gekaufte Identität, SKU, ausgewählte Choices oder Extras, Menge und Positionsbeschreibung |
| Customer-Text/-Datei | Anweisung für die Auftragsabwicklung an der gekauften Position oder Order |
| Preis, Rabatt, Gutschein, Steuer und Summe | Finanz-Snapshot zum Kaufzeitpunkt |
| Zahlungs- und Versandbezeichnung | Methodenkontext für Service und Abstimmung ohne Annahme einer Live-Konfiguration |
| Status, Erstattung, Retoure und Zeitverlauf | Lifecycle-Nachweis und Änderungen an der ursprünglichen Transaktion |
| Angebots- oder Abonnementreferenz | Beziehung zum kommerziellen Prozess vor oder nach der Order |
| Externe ID | Abstimmungsschlüssel für ERP, Buchhaltung, Auftragsabwicklung, Marktplatz oder CRM |
Orders bleiben nutzbar, wenn Mitarbeiter die Transaktion weiterhin interpretieren können, selbst wenn sich aktueller Katalog, Theme, App-Stack oder Checkout-Konfiguration geändert haben.
Checkout-, Versand-, Zahlungs-, Umsatzsteuer- und Sales-Tax-Daten
ShopWired trennt historische Transaktionsdaten von der Konfiguration, die zukünftige Orders erzeugt. Alte Orders können Versandbezeichnungen, Gebühren, Zahlungslabels, Steuerwerte, Befreiungen und Custom-Checkout-Antworten enthalten. Der aktuelle ShopWired-Checkout, Versandzonen und -tarife, Abholmethoden, Payment Freigabekriteriumways, Umsatzsteuerzonen, individuelle Steuersätze, B2B-Regeln und Checkout-Apps sind eigenständige Konfigurationsdatensätze.
| Historischer Quellwert | Dateneigentümer | Separate Zielbeziehung |
|---|---|---|
| Zahlungsart und Transaktionsreferenz | Order | Payment-Freigabekriteriumway- und Zugangsdatenkonfiguration für zukünftige Transaktionen |
| Versandart und -gebühr | Order | Versandzone, Tarif, Einschränkung, Abholung und Carrier-Konfiguration |
| Umsatz- oder Verkaufssteuerbetrag | Finanz-Snapshot der Order | Aktuelle Steuerzonen, Sätze, Befreiungen und Berechnungseinstellungen |
| Nachweis einer Customer-Steuerbefreiung | Customer/B2B-Customer oder externer Compliance-Datensatz | Zielregel, die die Behandlung auf zukünftige Orders anwendet |
| Antwort auf Checkout-Frage | Order- oder Customer-Feld je nach Zweck | Definition und Sichtbarkeitsregel des Checkout-Felds |
| Offline-Bedingungen oder Bestellreferenz | B2B-Customer, Angebot oder Order | Aktuelle Zahlungsbedingungen und Freigabekonfiguration |
| Ausgabe einer Checkout-App | App-eigene Order-Daten | Ziel-App-Konfiguration und unterstützte Datenbeziehung |
Diese Trennung hält historische Daten und zukünftige Konfiguration in ihren richtigen Rollen: migrierte Datensätze erklären vergangene Transaktionen; Konfigurationsdatensätze bestimmen, wie ShopWired neue Orders erzeugt. Beide sind verbunden, aber keines ersetzt das andere. Dasselbe gilt für Customer-Befreiungen und B2B-Bedingungen: Die historische Order bewahrt, was geschah, während die Customer- oder B2B-Beziehung erklärt, warum eine ähnliche Behandlung künftig gelten kann.
Inhalte, SEO, Menüs und Theme-abhängige Daten
ShopWired-Inhalte können Website-Seiten, Landingpages, Blog Posts, Product- und Category-Metadaten, 301-Redirects, Menüs und Linklisten, Unternehmensinformationen, Bilder, Dateien, Featured Products, Product-Q&A und weitere Storefront-Datensätze umfassen. Themes stellen diese Datensätze dar, werden aber nicht zu ihrem maßgeblichen Eigentümer.
Ein Source-Page-Builder-Block kann Text, Bilder, Product-Referenzen, Formulare und App-Widgets in einem visuellen Objekt kombinieren. Im Zielmodell sollten dauerhafte Inhalte von Darstellungs-Konfiguration und dynamischen Commerce-Referenzen getrennt werden.
| Source-Asset | Eigentümer in ShopWired | Konsequenz der Übertragung |
|---|---|---|
| Richtlinien-, Service- oder B2B-Informationsseite | Website-Seite | Body, Metadaten, Links, Medien und dauerhafte URL-Bedeutung erhalten. |
| Kampagnen- oder redaktionelle Landingpage | Landingpage plus Product-/Content-Referenzen | Wiederverwendbaren Inhalt von Theme-spezifischem Layout trennen. |
| Blog-Eintrag | Blog Post | Titel, Body, Medien, ggf. Datum/Autor, Metadaten und interne Links erhalten. |
| Product- oder Category-SEO-Daten | Product/Category plus SEO-Felder | Kanonische Entitätsidentität von Redirects und Menüplatzierung trennen. |
| Menüeintrag | Menü-/Linklistenbeziehung | Öffentliche Navigation kann auf Product, Category, Seite, Blog Post, externe URL oder Kampagne verweisen. |
| Redirect | 301-Redirect-Beziehung | Bedeutung der Source-Zielroute erhalten, ohne alte URL als Seiteninhalt zu behandeln. |
| Theme-Sektion oder Widget | Theme-/App-Darstellung | Darstellung getrennt von den Content- oder Product-Daten neu aufbauen, die sie rendert. |
Content-Eigentum ist für B2B- und Retail-Erlebnisse relevant. Eine B2B-Onboarding-Seite, Product-Spezifikationsbibliothek, Richtlinienseite oder hochwertige Landingpage kann geschäftliche Bedeutung tragen, auch wenn das visuelle Design ersetzt wird.
Apps, API, Webhooks und Daten externer Systeme
ShopWired stellt Apps, API-Zugangsdaten und Webhooks bereit; das Ökosystem umfasst Verbindungen zu Buchhaltung, Auftragsabwicklung, Bestand, Marktplätzen, Marketing, Steuern, Suche, Abonnements und B2B. Source-App-Daten werden nicht automatisch zu nativen ShopWired-Daten, nur weil eine Ziel-App denselben Zweck erfüllt.
Das Zielmodell sollte für jeden operativen Wert das maßgebliche System bestimmen. Product- und Variations-IDs können von einem ERP erkannt werden. Customer-IDs können einem CRM gehören. Order- und Versandreferenzen können in Auftragsabwicklung oder Buchhaltung geführt werden. Marketing-Einwilligung kann einem Marketing-System gehören. Ein Webhook ist Konfiguration; die externe Kennung in seiner Payload ist Dateninhalt.
| Abhängigkeit | Maßgebliche Beziehung |
|---|---|
| ERP-/Buchhaltungs-Product-ID | Product oder Variation, die vom externen System erkannt wird |
| Schlüssel eines Bestandsfeeds | Bestandsführendes Product/Variation plus System, das verfügbaren Bestand besitzt |
| Auftragsabwicklung-Referenz | Order-, Versand- oder Paketbeziehung, die Carrier oder Lager erkennt |
| CRM-Customer-/Unternehmens-ID | Customer- oder B2B-Customer-Beziehung auf der richtigen Kontoebene |
| Marktplatz-Listing-ID | Product-/Variations-/Channel-Beziehung, nicht generische Product-Beschreibung |
| Marketing-Einwilligung und Tags | Subscriber/Customer plus externes Marketing-System, das den Status besitzt |
| App-Custom-Field | App-eigener Wert mit explizitem Parent Product, Customer, Order oder Angebot |
| API-Zugangsdaten oder Webhook-Subscription | Sichere Zielkonfiguration statt Publication- oder Customer-Daten |
API-Paginierung, Authentifizierung und Fehlerbehandlung beeinflussen den Austausch von Datensätzen zwischen Systemen, ändern aber nicht, wem die zugrunde liegenden Daten gehören. Die Verantwortung-Map sollte daher stabil bleiben, auch wenn die Integration neu gebaut wird.
Eigentumsgrenzen für Custom- und externe Daten
Custom- und externe ShopWired-Daten sollten nach Verantwortung-Grenzen organisiert werden, nicht über pauschale Eskalationslabels. Die Kernentscheidung lautet, ob ein Wert zu einer nativen ShopWired-Entität, einer ShopWired-App, der Darstellungs-Konfiguration oder einem externen System gehört.
| Datensignal | Zieleigentümer | Erforderliche Beziehungsdefinition |
|---|---|---|
| Product-Spezifikation für Filter | Product-/Filterstruktur | Attributname, Wert, Product-Zugehörigkeit und Darstellungsrolle in der Storefront |
| Variationsbezogene Warehouse-ID | Variation plus ERP/Lager | Kaufbare Kombination und externer Datensatz, der sie erkennt |
| Vertragsreferenz eines B2B-Customers | B2B-Customer plus CRM/Buchhaltung | Organisation, Kontakt, kommerzielles Konto und externer Systemschlüssel |
| Custom Field nur für Angebote | Angebot | Verhandlungs- oder Freigabekontext, ohne daraus dauerhaftes Customer-Attribut zu machen |
| Von App erzeugter Abonnement- oder Bundle-Datensatz | App plus Product/Order | Parent Product, Abrechnungs- oder Komponentenbeziehungen und historische Transaktionsreferenzen |
| Theme-Einstellung, die Products auswählt | Theme-Darstellung | Product-Referenzen bleiben im Katalog maßgeblich; Einstellung steuert nur die Darstellung |
| Nicht unterstützte Custom-Source-Tabelle | Definierte Parent-Entität oder externes System | Geschäftszweck, Parent-Key, Lifecycle und Zieleigentümer müssen explizit sein |
Dieses Modell verhindert zwei Fehler: jeden Quellwert in das nächstgelegene native Feld zu zwingen und Custom-Daten zu bewahren, ohne ihre Parent-Beziehung zu verstehen. Ein Wert ist nur nutzbar, wenn Teams wissen, welcher Datensatz ihn besitzt, welches System ihn erkennt und ob er Historie, aktuellen Handel oder Darstellung beschreibt. Verantwortung sollte auch über Exporte und Integrationen hinweg stabil bleiben. Wird ein Custom-Wert in mehreren Systemen dupliziert, sollten eine maßgebliche Datenquelle und ein dauerhafter Abstimmungsschlüssel festgelegt werden, damit spätere Aktualisierungen keine widersprüchlichen Versionen desselben kommerziellen Sachverhalts erzeugen.
Fazit
Die Planung des ShopWired-Datenmodells sollte auf Bedeutung statt auf Feldgleichheit ausgerichtet sein. Die wichtigsten Unterschiede treten meist bei Product-Konfiguration, B2B- und Trade-Verhalten, Customer-Identität, Order-Historie, Checkout-Kontext, Content- und SEO-Assets, Apps, API-Prozessen, externen IDs und Custom Fields auf. Jeder Bereich muss nach seinem fortbestehenden Geschäftszweck interpretiert werden, nicht nur danach, ob ein Datensatz importiert werden kann.
Ein belastbares ShopWired-Zielmodell ordnet jeden Quellwert einem Product, einer Variation, einem Customer, einer B2B-Beziehung, einem Angebot, einer Order, einem Content-Datensatz, einer App, einer Darstellungsebene oder einem externen System zu. Diese Verantwortung-Map erhält die kommerzielle Bedeutung, ohne historische Daten mit zukünftiger Konfiguration zu verwechseln.
Häufige Fragen
Warum müssen ShopWired-Product-Optionen bei einer Migration gesondert geprüft werden?
Weil Source-Product-Optionen in ShopWired unterschiedliche Funktionen darstellen können. Manche werden Variationen mit SKU, Preis, Bestand, Bild, Gewicht oder Steuerbedeutung. Andere gehören zu Auswahlmöglichkeiten, Extras, Personalisierungsfeldern, Bundles oder App-eigenen Strukturen.
Werden Customer-Datensätze in ShopWired nur anhand des Namens abgeglichen?
Nein. Customer-Identität ist stark an die E-Mail-Adresse gebunden. Doppelte E-Mails, Guest Orders, registrierte Konten, B2B-Konten und Customer-Custom-Fields müssen sorgfältig geprüft werden, damit Order-Historie und Kontobedeutung nutzbar bleiben.
Konfigurieren migrierte Orders den Checkout in ShopWired?
Nein. Migrierte Orders können historische Zahlungs-, Versand-, Rabatt-, Steuer- und Auftragsabwicklung-Kontexte erhalten, soweit unterstützt. Der Live-Checkout hängt weiterhin von ShopWired-Zahlungs-, Versand-, Steuer-, Customer-Group-, B2B- und App-Konfiguration ab.
Können B2B-Preise und B2B-Regeln wie normale Customer-Daten migriert werden?
Nicht immer. B2B-Konten, Preisstaffeln, individuelle Preise, Angebotsbeziehungen, Product-Sichtbarkeit, Kontobedingungen und Steuerbehandlung sind verbundene kommerzielle Datensätze und keine gewöhnlichen Felder eines Customer-Profils.
Wann brauchen ShopWired-Custom-Daten einen eigenen Eigentümer?
Wenn ein Wert zu einer App, einem externen System, einer Custom-Source-Tabelle, einer Darstellungsebene oder einer Beziehung gehört, die nicht sinnvoll in einem gewöhnlichen Product-, Customer-, Angebots-, Order- oder Content-Datensatz liegt.
Wie sollten B2B- und Trade-Regeln in ShopWired übertragen werden?
Trennen Sie die zugrunde liegende Käuferidentität und Product-Daten von der Regel, die Preis, Sichtbarkeit, Steuerbehandlung, Angebot oder Checkout-Verhalten verändert. Bewahren Sie die Datensätze mit dauerhafter Bedeutung und dokumentieren Sie anschließend, welche Zielkonfiguration oder welches angebundene System die kommerzielle Regel durchsetzt.