Wenn Squarespace als potenzielle Zielplattform für Daten und Geschäftsbeziehungen des Quellshops geprüft wird, verbindet die Plattform eine gehostete Website-Struktur mit Commerce-Datensätzen innerhalb derselben Website-Umgebung. Diese Kombination verändert die Bedeutung von Migrationsdaten. Ein Product ist nicht nur eine Katalogzeile: Es gehört zu einer Store Page, besitzt einen bestimmten Product-Typ, kann Varianten und Attribute enthalten und wird über die Inhalts- und Navigationsstruktur der Website dargestellt. Ein Käufer kann je nach Ursprung der Beziehung als Contact, Customer, Abonnent, Spender oder Website-Nutzer auftreten. Eine Order erhält eine Transaktion, wird aber nicht zu der Konfiguration, die künftiges Checkout-, Zahlungs-, Fulfillment- oder Steuerverhalten steuert.
Die zentrale Übersetzungsaufgabe zwischen den Datenmodellen besteht darin, die Beziehungen zu erhalten, durch die jeder Datensatz in Squarespace nutzbar bleibt. Produktdaten müssen mit ihrem Product-Typ, der Store Page, Varianten, Bildern, der URL und dem Bestand verbunden bleiben. Bei Kontaktdaten muss erkennbar bleiben, ob es um Käuferidentität, Mailinglisten-Teilnahme, Spendenaktivität oder Kontozugriff geht. Inhalts- und SEO-Datensätze müssen ihre Zielzuordnung und internen Verweise behalten, statt nur als dekorativer Text rund um den Shop behandelt zu werden.
Commerce-Bedeutung beginnt in Squarespace bei Website und Store Page
Squarespace ist kein losgelöster Katalog neben einer unabhängigen Website. Commerce-Datensätze leben in einer Website, deren Pages-Bereich, Store Pages, Navigation, Inhalts-Collections, Domains und URLs bestimmen, wie Products veröffentlicht und gefunden werden. Jedes Product gehört zu genau einer Store Page; seine Sichtbarkeit hängt zugleich vom Status des Products und vom Zustand der Store Page ab.
Diese Besitzbeziehung ist wichtig, wenn die Quellplattform mehrere Kataloge, Collections, Websites oder Vertriebskanäle verwendet. Ein Product lässt sich erst korrekt übertragen, wenn die Beziehung zur vorgesehenen Store Page im Ziel feststeht. Die Platzierung auf einer Store Page ist nicht nur eine Menüentscheidung, sondern Teil der Sichtbarkeit und URL-Bedeutung eines Products.
| Annahme aus dem Quellshop | Bedeutung der Beziehung in Squarespace | Folge für die Übertragung |
|---|---|---|
| Products existieren unabhängig von der Website | Jedes Product gehört zu einer Store Page innerhalb einer Squarespace-Website | Product-Identität zusammen mit der vorgesehenen Store-Page-Zuordnung erhalten. |
| Kategoriezuordnung stellt die Navigation wieder her | Produktgruppierung, Store-Page-Platzierung, Tags, Categories und Website-Navigation hängen zusammen, sind aber getrennte Strukturen | Klassifizierung getrennt von Menüs und Seitendarstellung übertragen. |
| Ein allgemeiner Product-Typ passt zu jedem Angebot | Squarespace unterscheidet physische Produkte, Dienstleistungen, Geschenkkarten und Downloads | Der Product-Typ bestimmt verfügbare Varianten-, Bestands-, Fulfillment- und Dateibeziehungen. |
| Customer und Mailinglisten-Abonnent sind dasselbe | Contacts können Customers, Abonnenten, Spender und andere Website-Beziehungen darstellen | Erhalten, warum eine Person im Zielsystem existiert, nicht nur ihre E-Mail-Adresse. |
| Importierte Orders stellen den Commerce-Betrieb wieder her | Orders erhalten Historie und aktuellen Transaktionsstatus; künftiges Verhalten wird an anderer Stelle konfiguriert | Transaktionsnachweise von Zahlungs-, Steuer-, Versand- und Benachrichtigungseinstellungen trennen. |
Diese Beziehung zwischen Website und Commerce betrifft auch externe Kennungen. Eine Product-ID aus der Quelle muss gegebenenfalls an dem Squarespace-Product oder der Variante erhalten bleiben, die ein ERP verwendet. Eine Quellseiten-ID kann zur Inhaltsmigration und nicht zum Commerce gehören. Eine CRM-ID eines Customers gehört zu der vom CRM erkannten Contact-Beziehung und nicht zu einer Order, nur weil sie dort zum ersten Mal aufgetaucht ist.
Produkttypen definieren unterschiedliche Datensatzbeziehungen
Squarespace unterstützt physische Products, Service Products, Gift Card Products und Download Products. Diese Typen sind keine rein kosmetischen Bezeichnungen. Sie bestimmen, ob ein Product Varianten haben kann, wie Bestand dargestellt wird, welche Fulfillment-Bedeutung gilt und welche zusätzlichen Datensätze am Verkauf beteiligt sind.
Physische Products können Varianten und versandrelevante Daten enthalten. Auch Service Products können Varianten besitzen, etwa unterschiedliche Dauer oder Leistungsstufen, während sich ihre Fulfillment-Bedeutung von einer physischen Lieferung unterscheidet. Gift Card Products können Varianten für verschiedene Nennwerte verwenden. Download Products verbinden das Product mit einem digitalen Gut und unterstützen Varianten nicht in derselben Weise.
| Angebot im Quellshop | Product-Bedeutung in Squarespace | Zu erhaltende Beziehung |
|---|---|---|
| Physische Ware | Physical Product | Store Page, Varianten, SKU, Preis, gegebenenfalls Gewicht/Abmessungen, Bestand, Bilder, Versandbedeutung und URL. |
| Beratung, Kurs, Erlebnis oder Leistungsstufe | Service Product | Dienstleistungsidentität, Variante für Stufe oder Dauer, Preis, Inhalt und gegebenenfalls separater Verantwortlicher für Terminplanung oder Leistungserbringung. |
| Shop-Guthaben oder digitaler Geschenkgutschein | Gift Card Product | Nennwertvarianten, Beziehung zur Ausstellung der Geschenkkarte, Käufer-/Empfängerkontext und finanzielle Bedeutung. |
| Herunterladbare Datei | Download Product plus DigitalGood-Beziehung | Product-Metadaten, gekaufte Datei, Auslieferungsberechtigung und URL; keine künstlich erzeugten Varianten. |
| Abo- oder wiederkehrendes Angebot | Product plus Abo- und Order-Beziehung | Product-Identität bleibt getrennt von wiederkehrender Abrechnung, Berechtigung und Verlängerungsstatus. |
| Spenden- oder Mitgliedschaftsangebot | Je nach Fall Donation-, Membership- oder verbundener Squarespace-Bereich statt gewöhnlichem Product | Contact-, Transaktions-, Zugriffs- und Inhaltsbeziehungen bleiben beim zuständigen Squarespace-Bereich. |
Eine Quellplattform kann all diese Angebote als Products, SKUs oder individuelle Produkttypen modellieren. Die Übertragung nach Squarespace sollte sich am Zielverhalten orientieren. Eine herunterladbare Kursdatei, eine geplante Beratung und ein versendetes Buch können denselben Titel und Preis haben, aber nicht dieselben Fulfillment- oder Datensatzbeziehungen.
Product-Attribute, Varianten, Bilder und Bestand
Product-Attribute in Squarespace definieren Werte wie Farbe oder Größe, während Product-Varianten kaufbare Kombinationen darstellen. Eine Variante kann eine eigene SKU, einen eigenen Preis, Bestand, Abmessungen und ausgewählte Attributwerte besitzen. Produktbilder gehören zur Bildsammlung des Products und können Varianten zugeordnet sein.
Optionen aus dem Quellshop müssen nach ihrer geschäftlichen Wirkung unterschieden werden. Ein Wert, der SKU, Preis, Bestand, Bild oder Fulfillment-Identität verändert, verhält sich wie eine Variante. Eine Personalisierungsanweisung, optionale Dienstleistung, Bundle-Komponente oder von einer Anwendung erzeugte Konfiguration hat möglicherweise kein direktes Gegenstück als Squarespace-Variante. Werden alle Quelloptionen zu Varianten, kann eine unbeherrschbare Product-Matrix entstehen; werden echte Varianten dagegen zu Text abgeflacht, gehen Bestands- und SKU-Identität verloren.
| Optionsmuster im Quellshop | Verantwortlicher Squarespace-Bereich | Bedeutung, die erhalten bleiben muss |
|---|---|---|
| Größen-/Farbkombination mit SKU und Bestand | Product-Attribute und ProductVariant | Kaufbare Identität, Attributwerte, SKU, Preis, Bestand und Bildbeziehung. |
| Leistungsstufe oder Dauer | Variante eines Service Products | Verkaufbare Leistungsoption und ihre Preis- oder Beschreibungsunterschiede. |
| Nennwert einer Geschenkkarte | Variante eines Gift Card Products | Kaufbarer Geldwert. |
| Download-Format | In der Regel eigene Product-Bedeutung oder Dateibeziehung statt Variante eines Download Products | Korrekte Dateiberechtigung und Product-Identität. |
| Gravur, Freitext oder Datei-Upload durch Käufer | Je nach unterstütztem Verhalten individuelle Eingabe, Formular, Order-Line-Daten oder verbundene Erweiterung | Vom Kunden gelieferter Wert bleibt mit Kauf und Fulfillment-Verantwortung verbunden. |
| Bundle oder Konfigurator | Product-Beziehung, akzeptierte Vereinfachung oder Struktur einer Erweiterung/eines externen Systems | Komponenten, resultierende SKU, Preis, Bestand und Ausgabe in der Order-Line bleiben nachvollziehbar. |
Bestand wird variantenbezogen geführt. Die Squarespace Inventory API stellt ein InventoryItem als Variante eines physischen oder Service Products dar und speichert, ob Bestand verfolgt wird oder unbegrenzt ist, zusammen mit SKU- und Verfügbarkeitsinformationen. Eine Produktmenge aus dem Quellshop muss daher zuerst mit der Variantenstruktur im Ziel abgeglichen werden.
Auch für einen Quellbestand muss entschieden werden, welches System künftig führend ist. Wenn Squarespace den Bestand verwaltet, sollte die Anfangsmenge zu den Product-Varianten im Ziel passen. Bleibt ein Warehouse- oder ERP-System führend, ist die dauerhafte Beziehung ProductVariant → externer Bestandsschlüssel → Bestandssynchronisierung. Eine kopierte Menge ohne diesen Schlüssel ist veraltet, sobald das externe System seine Aktualisierungen wieder aufnimmt.
Store Pages, Categories, Tags, Navigation und Produktfindung
Store Pages verwalten Products, ersetzen aber nicht jede Struktur, über die Produkte im Quellshop gefunden wurden. Categories, Tags, Store-Page-Platzierung, Navigationslinks, Summary Blocks, Suche, Inhaltsseiten und externe Kampagnenlinks können gemeinsam zur Produktfindung beitragen. Eine Quell-Collection kann eine dauerhafte Abteilung, eine temporäre Kampagne, eine Marke, ein Filterergebnis oder eine redaktionelle Seite dargestellt haben. Diese Bedeutungen sollten getrennt bleiben.
| Struktur zur Produktfindung in der Quelle | Bedeutung im Squarespace-Ziel |
|---|---|
| Dauerhafte Katalogabteilung | Product Category oder dauerhafte Store-Page-Gruppierung entsprechend der Zielstruktur. |
| Produktmarke | Tag, Inhaltsbeziehung, Namenskonvention oder externes Product-Informationsfeld, abhängig von der Verwendung der Marke. |
| Saisonale Collection | Category, Tag, kuratierte Seite oder temporäre Navigationsbeziehung statt dauerhaftem Product-Typ. |
| Attribut für Facettenfilter | Variantenattribut, strukturierter Product-Inhalt, Tag oder externer Such-/Filterverantwortlicher; nicht automatisch eine Category. |
| Link in der Hauptnavigation | Website-Navigationsbeziehung zu einer Store Page, Category-Ansicht, Inhaltsseite oder externen URL. |
| SEO-Landingpage | Seite oder Store-Page-Ziel, verbunden mit Products, Inhalt, URL, Metadaten und internen Links. |
Die Products API stellt nicht jede Category-Beziehung einer Store Page auf dieselbe Weise bereit wie Product-Datensätze. Das unterstreicht die Notwendigkeit, Katalogdaten von der Website-Organisation zu unterscheiden. Das Zielmodell sollte festhalten, welche Datensätze die Product-Klassifizierung verwalten und welche Website-Datensätze für die öffentliche Produktfindung verantwortlich sind.
Ein Product kann korrekt migriert und trotzdem praktisch nicht erreichbar sein, wenn es der falschen Store Page zugeordnet, ausgeblendet oder über keinen erreichbaren Navigationspfad zugänglich ist. Das ist ein Beziehungsproblem und kein Beleg dafür, dass Product-Felder fehlen.
Contacts, Customers, Abonnenten, Spender und Kontozugriff
Commerce- und Marketing-Funktionen von Squarespace können verschiedene personenbezogene Bedeutungen erzeugen. Contacts können Customers, Abonnenten, Spender und andere mit der Website verbundene Personen darstellen. Adressbücher und Marketing-Präferenzen gehören zu diesen Beziehungen. Das ältere Profiles-Modell stellte ähnliche Kategorien von Website-Nutzern bereit, während die aktuelle Contacts API heute die umfassendere Contact-Verwaltung übernimmt.
Ein Customer-Konto aus der Quelle kann zusätzlich Passwörter, Kundengruppen, B2B-Rollen, Loyalitätsguthaben, gespeicherte Zahlungsdetails, Mitgliedschaftszugriff, Abo-Status, Steuerbefreiungen oder CRM-Attribute enthalten. Diese Bedeutungen dürfen nicht allein deshalb zu einem Contact-Datensatz abgeflacht werden, weil die Person nur eine E-Mail-Adresse besitzt.
| Identitätsmuster in der Quelle | Entscheidung über die Squarespace-Beziehung |
|---|---|
| Registrierter Käufer | Contact-/Customer-Identität verbunden mit Orders, Adressen und unterstütztem Kontoverhalten. |
| Käufer im Gast-Checkout | Mit der Order verbundene Käuferidentität; dauerhafter Contact nur, wenn die Zielbeziehung dies unterstützt. |
| Newsletter-Abonnent | Contact plus Mailinglisten- und Einwilligungsbeziehung, bei Bedarf getrennt von Kaufhistorie. |
| Spender | Contact plus Spenden-/Transaktionshistorie, nicht automatisch Commerce-Customer. |
| Mitglied oder Teilnehmer an zugriffsbeschränkten Inhalten | Contact/Website-Nutzer plus Mitgliedschafts- oder Zugriffsbeziehung; Passwort und Berechtigung sind keine gewöhnlichen Profilfelder. |
| B2B-Käufer oder Organisation | Contact plus CRM-/externes System für Unternehmen, Rolle, Preise, Steuern oder Freigabestrukturen. |
| Doppelte Quellprofile | Nur zusammenführen, wenn Identitäts-, Einwilligungs-, Adress- und Order-Nachweise dieselbe Person belegen. |
Eine E-Mail-Adresse ist ein starkes Identitätssignal, aber nicht das einzige. Gemeinsame Adressen, geänderte E-Mails, Gast-Orders, doppelte Importe und Organisationskontakte können zu falschen Zusammenführungen führen. Externe CRM-IDs, Customer-IDs aus der Quelle, Adressen und Order-Beziehungen können erforderlich sein, um unterschiedliche Personen und ihre Historie sauber zu erhalten.
Marketing-Einwilligung muss als eigene Beziehung getrennt von der Käuferidentität bestehen bleiben. Ein Customer, der gekauft hat, ist nicht automatisch Mailinglisten-Abonnent, und ein Abonnent muss nie etwas gekauft haben. Wird der Contact erhalten, aber nicht die Beziehung, die seinen Ursprung erklärt, entstehen sowohl betriebliche Unklarheit als auch Probleme bei Einwilligungen.
Orders, Transaktionen, Fulfillment und historischer Kontext
Squarespace Orders können einmalige Käufe und Subscription Orders darstellen. Sie enthalten Order Lines, Customer-Informationen, Rechnungs- und Lieferadressen, Summen, Rabatte, Steuern, Versanddetails, Fulfillment-Status, Zahlungsstatus, Erstattungen und weiteren Transaktionskontext. Transactions stellen die finanziellen Datensätze zu Orders und Spenden bereit.
Eine Order sollte das zum Kaufzeitpunkt erworbene Product oder die Variante erhalten, auch wenn das aktuelle Product später geändert wird. Eine Order Line ist eine Momentaufnahme der Transaktion und keine Live-Referenz, die mit aktuellem Kataloginhalt überschrieben werden sollte. Zahlungs- und Erstattungsstatus beschreiben, was finanziell passiert ist. Fulfillment und Tracking erklären, wie der Kauf abgewickelt wurde. Importierte oder historische Orders definieren keine aktuellen Zahlungsanbieter, Versandregeln, Steuerkonfiguration, E-Mail-Funktionen oder Warehouse-Verbindungen.
| Historischer Datensatz | Bedeutung in Squarespace |
|---|---|
| Order-Nummer aus der Quelle | Nachverfolgbare externe Referenz für Kundenservice und Abstimmung. |
| Product-/Variantenzeile | Gekaufter Titel, SKU, ausgewählte Attribute, Menge, Preis und weitere Momentaufnahme der Zeile. |
| Rechnungs- und Lieferadressen | Historischer Transaktionskontext, keine dauerhafte Kontoadresse, sofern diese nicht separat dem Contact gehört. |
| Rabatt-, Steuer- und Versandzeile | Erklärung der historischen Summe statt aktueller Rabatt- oder Steuerkonfiguration. |
| Zahlungsstatus und Transaction | Finanzhistorie zur Order, keine wiederverwendbaren Zahlungsdaten. |
| Fulfillment und Tracking | Historischer Versand- oder Leistungserbringungskontext, keine Definition aktueller Fulfillment-Methoden. |
| Abo- oder Zahlungsplanstatus | Order- und Transaction-Lebenszyklus, der mit dem System verbunden bleiben muss, das künftige Abbuchungen steuert. |
| Importierte Order aus Drittanbieter-Vertriebskanal | Order-Historie plus externe Kanal-ID und Quellbeziehung. |
Squarespace kann über seine Commerce APIs Orders aus Vertriebskanälen von Drittanbietern importieren. Die importierte Historie sollte dennoch ihre ursprüngliche Quelle und Kennungen erhalten. Das Anlegen einer Squarespace Order macht Marketplace, Zahlungsanbieter oder Fulfillment-System der Quelle nicht rückwirkend als Eigentümer historischer Referenzen bedeutungslos.
Seiten, Blog Posts, Medien, URLs und SEO-Beziehungen
Squarespace-Websites können reguläre Seiten, Store Pages, Blog Posts, Collection-Elemente, Bilder, Dateien, Navigationslinks, Product-URLs, Category-Ansichten, SEO-Felder, Weiterleitungen, Domains und verbundene Dienste enthalten. Zusammen bilden diese Datensätze ein Inhaltsnetz rund um den Commerce-Katalog.
Eine Product-Beschreibung aus der Quelle gehört zum Product. Ein Kaufratgeber kann dagegen eine Seite oder ein Blog Post sein, der auf mehrere Products verweist. Eine Category-Beschreibung kann zu Store-Page- oder Landingpage-Inhalt werden. Eine Kampagnenseite kann Product-Referenzen enthalten, ohne Product-Daten zu besitzen. Medien können in Products und Inhalten gemeinsam verwendet werden; Bildreihenfolge, Zuschnitt, Alt-Text, Bildunterschriften und interne Links besitzen jedoch eine website-spezifische Bedeutung.
| Web-Element aus der Quelle | Verantwortlicher Bereich in Squarespace |
|---|---|
| Product-Titel, Beschreibung, Bilder, URL-Slug und SEO-Daten | Product- und Store-Page-Beziehung. |
| Richtlinien- oder Informationsseite im CMS | Squarespace-Seite mit Inhalt, Medien, Metadaten und Navigationsbeziehung. |
| Blog Post | Blog-Collection-Element mit Veröffentlichungskontext, Categories/Tags, Medien, internen Links und URL. |
| Produktratgeber oder Kampagnen-Landingpage | Seite/Inhalts-Collection plus Product-Referenzen und Navigation. |
| Menüpunkt | Website-Navigationsbeziehung zu Seite, Store Page, Product-Ziel, Anker oder externer URL. |
| Quell-URL | Zielroute plus Weiterleitungsbeziehung, wenn sich der Pfad ändert. |
| Theme-Block oder individueller Code | Website-Darstellung/-Konfiguration, die auf Inhalts- und Commerce-Datensätze verweist, ohne deren Eigentümer zu werden. |
URL-Kontinuität hängt von der Identität des Ziels ab. Eine Weiterleitung sollte den alten Quellpfad mit dem richtigen Product, der richtigen Store Page, Seite, dem Blog Post oder einem anderen passenden Ziel verbinden. Sie darf nicht dazu dienen, Unklarheit darüber zu verdecken, welcher Datensatz die Quellseite ersetzt. Auch interne Links in migrierten Inhalten sollten auf das vorgesehene Ziel verweisen, statt veraltete Quell-URLs zu erhalten.
Extensions, APIs, individuelle Felder und Verantwortung externer Systeme
Die Squarespace Commerce APIs stellen Products, Inventory, Orders, Transactions, Contacts, Discounts, Websites und Webhooks bereit. Verbundene Dienste und Extensions können zusätzlich Reviews, Loyalitätsprogramme, Abonnements, Fulfillment, Buchhaltung, Versand, Marketing, Terminplanung, Spenden, Mitgliedschaften oder andere Daten verwalten. Ein Datensatz aus einer Quellanwendung darf nicht allein deshalb als nativer Squarespace-Datensatz behandelt werden, weil eine Extension im Ziel eine ähnliche Funktion anbietet.
Der richtige Eigentümer richtet sich nach Geschäftszweck und Lebenszyklus. Eine Warehouse-ID eines Products gehört zur ProductVariant-/ERP-Beziehung. Eine CRM-ID eines Contacts gehört zum Contact und CRM. Eine Marketplace-Order-ID gehört zur Order und zum Vertriebskanal. Eine Mitgliedschaftsberechtigung gehört zum Mitgliedschaftssystem und nicht in eine allgemeine Contact-Notiz.
| Individueller oder externer Wert | Eigentum im Ziel |
|---|---|
| ERP-ID für Product oder Variante | Product/ProductVariant plus ERP-Beziehung auf derselben Katalogebene. |
| Externer Bestandsschlüssel | ProductVariant plus Warehouse- oder Bestandssystem. |
| CRM-ID eines Contacts | Contact plus CRM-Beziehung. |
| Marketplace-Order-ID | Order plus Vertriebskanalbeziehung. |
| Review-, Loyalitäts- oder Abo-Datensatz | Extension oder externes System plus Product-, Contact- oder Order-Referenzen. |
| Ausgabe eines Produktkonfigurators | Product/Variante plus von der Extension verwaltete Konfiguration und resultierende Momentaufnahme in der Order Line. |
| Individuelle Checkout-Antwort | Je nach Geschäftszweck Order oder Contact plus Formular/Extension, die Erfassung und Darstellung verwaltet. |
| Nicht unterstützte Quelltabelle | Expliziter übergeordneter Datensatz, dauerhafter Schlüssel, Lebenszyklus und Zieleigentümer, bevor der Wert erhalten wird. |
Diese Grenze verhindert zwei häufige Fehler: jeden Wert in das nächstgelegene Squarespace-Feld zu zwingen oder App-Daten ohne einen Verbraucher im Ziel zu bewahren. Ein individuelles Feld ist nur nützlich, wenn das Zielteam weiß, welcher Datensatz es besitzt, welches System es erkennt und ob es aktuellen Commerce, historischen Kontext, Inhalt oder externe Konfiguration beschreibt.
Repräsentative Beziehungsketten für die Übertragung nach Squarespace
Eine Beziehungskette zeigt, wie ein Quellkonzept auf Commerce-, Contact-, Inhalts- und Datensätze externer Systeme in Squarespace verteilt wird. Sie macht die Verantwortung im Ziel sichtbar und verhindert, dass ein einzelnes importiertes Feld mehrere miteinander unvereinbare Bedeutungen tragen muss. Die Kette sollte auch dann verständlich bleiben, wenn die Quellplattform später nicht mehr verfügbar ist, sodass jedes Product, jeder Contact, jede Order, URL und Extension-Referenz einen klaren übergeordneten Datensatz und einen dauerhaft zuständigen Verbraucher besitzt.
| Quellmuster | Beziehung im Squarespace-Ziel |
|---|---|
| Bekleidungs-Product mit Größen-/Farbbestand | Store Page → Physical Product → Attribute → ProductVariants → Variantenbilder/SKUs → InventoryItems. |
| Beratungspakete | Store Page → Service Product → Varianten für Stufe/Dauer → Inhalt → bei Bedarf externer Termin- oder Leistungserbringungsverantwortlicher. |
| Digitaler Download | Store Page → Download Product → DigitalGood → Order Line → kaufender Contact → Auslieferungsberechtigung. |
| Abonnent, der später kauft | Contact → Mailinglisten-/Einwilligungsbeziehung → Customer-/Order-Historie, ohne anzunehmen, dass beide Beziehungen identisch sind. |
| Importierter Marketplace-Verkauf | Order → Momentaufnahme der Order Line → Transaction-/Fulfillment-Historie → Contact → externe Marketplace-ID. |
| SEO-kritische Product-Collection | Store Page/Category oder kuratierte Seite → Product-Referenzen → Navigation → Ziel-URL → Weiterleitungen von Quellpfaden. |
| Mitgliedschafts- oder Spendendatensatz | Contact → Verantwortlicher für Mitgliedschaft oder Spende → Transaktions-/Zugriffshistorie, getrennt von gewöhnlichen Product- und Customer-Feldern. |
Diese Ketten halten sichtbar, wem Products, Website-Strukturen, Contacts, Orders, Inhalte und externe Systemdaten gehören. Sie zeigen außerdem, wo eine Quellplattform mehrere Bedeutungen in einem Datensatz zusammengeführt haben kann, die Squarespace getrennt darstellt.
Fazit
Die Übertragung des Datenmodells nach Squarespace hängt von der Beziehung zwischen Commerce-Datensätzen und der Website ab, die sie veröffentlicht. Products gehören zu Store Pages und Product-Typen; Varianten besitzen kaufbare Kombinationen und Bestand; Contacts können Customer-, Abonnenten-, Spender- und kontobezogene Bedeutungen tragen; Orders erhalten Transaktionshistorie; Seiten, Blog Posts, URLs und Navigation verwalten die Produkt- und Inhaltsfindung; Extensions und externe Systeme verwalten spezialisiertes Verhalten.
Ein belastbares Zielmodell erhält diese Beziehungen, ohne migrierte Daten mit Website-Darstellung oder künftiger Betriebskonfiguration zu verwechseln. Das Ergebnis ist nicht nur eine gefüllte Squarespace-Website, sondern ein zusammenhängendes System aus Product-, Contact-, Order-, Inhalts- und externen Datensätzen, deren Verantwortlichkeiten weiterhin nachvollziehbar bleiben.
Häufige Fragen
Warum ist die Zuordnung zu einer Store Page für Squarespace Products wichtig?
Jedes Squarespace Product gehört zu genau einer Store Page, und seine Verfügbarkeit hängt sowohl mit der Product-Sichtbarkeit als auch mit dem Zustand der Store Page zusammen. Product-Daten und Store-Page-Zuordnung bilden daher eine gemeinsame Zielbeziehung, auch wenn die Website-Navigation eine eigene Ebene bleibt.
Kann jede Product-Option aus der Quelle zu einer Squarespace-Variante werden?
Nein. Eine Variante ist passend, wenn die Auswahl eine eigene kaufbare Kombination mit SKU, Preis, Bestand, Bild, Abmessungen oder anderer verkaufsrelevanter Bedeutung erzeugt. Personalisierungen, Bundles, Uploads oder anwendungsgesteuerte Optionen können einen anderen Verantwortlichen benötigen.
Sind Squarespace Contacts, Customers und Abonnenten derselbe Datensatztyp?
Sie können dieselbe Person bezeichnen, die Beziehungen sind jedoch unterschiedlich. Kundenhistorie, Mailinglisten-Einwilligung, Spendenaktivität, Adressbücher und Kontozugriff sollten auch dann unterscheidbar bleiben, wenn ein Contact sie verbindet.
Stellt eine migrierte Order das Checkout-Verhalten in Squarespace wieder her?
Nein. Die Order erhält Transaktions-, Order-Line-, Zahlungs-, Erstattungs-, Adress- und Fulfillment-Kontext. Aktuelle Zahlungsanbieter, Steuereinstellungen, Versandmethoden, Benachrichtigungen und angebundenes Fulfillment bleiben separate Konfiguration.
Wie sollte Product-Bestand in Squarespace dargestellt werden?
Bestand sollte der Squarespace ProductVariant folgen, die den verkaufbaren Artikel darstellt. Bleibt ein externes Bestandssystem führend, benötigt die Variante zusätzlich den dauerhaften externen Schlüssel, über den der Bestand nach der initialen Datenübertragung weiter gepflegt wird.
Wo sollten appverwaltete oder individuelle Squarespace-Daten liegen?
Sie sollten beim Product, der ProductVariant, dem Contact, der Order, dem Inhaltsdatensatz, der Extension oder dem externen System verbleiben, das ihren Geschäftszweck besitzt. Allgemeine Notizen ersetzen weder eine definierte übergeordnete Beziehung noch eine dauerhafte Kennung.