Squarespace combina la struttura di un sito web gestito e i record commerce all’interno dello stesso ambiente. Questa combinazione cambia il significato dei dati durante la migrazione. Un Product non esiste soltanto come riga di catalogo: appartiene a una Store Page, ha un tipo di Product specifico, può contenere varianti e attributi e viene presentato attraverso la struttura dei contenuti e della navigazione del sito. Un acquirente può comparire come Contact, Customer, iscritto, donatore o utente del sito in base alla relazione che ha generato il record. Un Order conserva una transazione, ma non diventa la configurazione che governa i futuri processi di acquisto, pagamenti, evasione o imposte.
Il compito centrale della migrazione è preservare le relazioni che rendono utile ogni record in Squarespace. I dati Product devono restare collegati al relativo tipo di Product, alla Store Page, alle varianti, alle immagini, all’URL e all’inventario. I dati Contact devono mantenere la distinzione tra identità dell’acquirente, partecipazione alla mailing list, attività di donazione e accesso all’account. I record di contenuto e SEO devono conservare la propria destinazione e i riferimenti interni invece di essere trattati come testo decorativo attorno allo store.
Il significato commerce in Squarespace parte dal sito e dalla Store Page
Squarespace non è un catalogo separato collocato accanto a un sito indipendente. I record commerce vivono all’interno di un sito in cui pannello Pages, Store Pages, navigazione, raccolte di contenuti, domini e URL determinano come i Products vengono pubblicati e trovati. Ogni Product appartiene a una sola Store Page, mentre la sua visibilità dipende sia dallo stato del Product sia dallo stato della Store Page.
Questa regola di proprietà è importante quando la piattaforma di origine utilizza più cataloghi, collection, siti o canali di vendita. Un Product non può essere rappresentato correttamente finché non viene definita la relazione con la Store Page di destinazione. La collocazione nella Store Page non è soltanto una scelta di menu: partecipa alla visibilità del Product e al significato del suo URL.
| Ipotesi dello store di origine | Significato della relazione in Squarespace | Conseguenza per la migrazione |
|---|---|---|
| I Products esistono indipendentemente dal sito | Ogni Product appartiene a una Store Page all’interno di un sito Squarespace | Preservare l’identità del Product insieme alla Store Page a cui deve appartenere. |
| L’assegnazione Category ricrea la navigazione | Raggruppamento dei Products, collocazione nelle Store Pages, tag, Categories e navigazione del sito sono collegati ma distinti | Migrare la classificazione separatamente da menu e presentazione delle pagine. |
| Un solo tipo generico di Product è sufficiente per ogni offerta | Squarespace distingue Products fisici, servizi, gift card e download | Il tipo di Product determina quali relazioni con varianti, inventario, evasione e file sono disponibili. |
| Customer equivale a iscritto alla mailing list | Contacts può rappresentare Customers, iscritti, donatori e altre relazioni con il sito | Preservare il motivo per cui la persona esiste nella destinazione, non soltanto l’indirizzo email. |
| Gli Orders importati ricreano le operazioni commerce | Gli Orders conservano storico e stato della transazione; il funzionamento futuro resta configurato altrove | Tenere separate le evidenze della transazione dalle impostazioni di pagamento, imposte, spedizione e notifiche. |
Questa relazione tra sito e commerce riguarda anche gli identificatori esterni. Un ID Product di origine può dover restare associato al Product o alla variante Squarespace utilizzata da un ERP. Un ID pagina di origine può appartenere alla migrazione dei contenuti invece che al commerce. Un ID CRM del Customer appartiene alla relazione Contact riconosciuta dal CRM, non a un Order solo perché la prima occorrenza è stata generata durante il processo di acquisto.
I tipi di Product definiscono relazioni diverse
Squarespace supporta Products fisici, servizi, gift card e download. Questi tipi non sono etichette decorative. Determinano se un Product può avere varianti, come viene rappresentato l’inventario, quale significato assume l’evasione e quali record aggiuntivi partecipano alla vendita.
I Products fisici possono includere varianti e dati relativi alla spedizione. Anche i Service Products possono avere varianti, ad esempio per durata o livello, mentre il loro significato di evasione differisce dalla consegna fisica. I Gift Card Products possono usare varianti per i diversi importi. I Download Products collegano il Product a un bene digitale e non supportano le varianti nello stesso modo.
| Offerta nella piattaforma di origine | Significato del Product in Squarespace | Relazione da preservare |
|---|---|---|
| Merce fisica | Physical Product | Store Page, varianti, SKU, prezzo, peso/dimensioni quando rilevanti, inventario, immagini, significato della spedizione e URL. |
| Consulenza, corso, esperienza o livello di servizio | Service Product | Identità del servizio, variante relativa a livello o durata, prezzo, contenuto ed eventuale responsabile separato per pianificazione o erogazione. |
| Credito store o gift certificate digitale | Gift Card Product | Varianti per importo, relazione di emissione della gift card, contesto di acquirente/destinatario e significato finanziario. |
| File scaricabile | Download Product più relazione DigitalGood | Metadati Product, file acquistato, diritto alla consegna e URL, senza inventare un insieme di varianti. |
| Abbonamento o offerta ricorrente | Product più relazioni di abbonamento e Order | L’identità Product resta distinta da fatturazione ricorrente, diritto di accesso e stato dei rinnovi. |
| Donazione o offerta membership | Area donation, membership o altra funzione Squarespace collegata, invece di un normale Product quando applicabile | Relazioni Contact, transazione, accesso e contenuti restano assegnate alla funzione Squarespace corretta. |
Una piattaforma di origine può modellare tutte queste offerte come Products, SKU o tipi Product personalizzati. La rappresentazione in Squarespace deve seguire il funzionamento della destinazione. Un file di corso scaricabile, una consulenza programmata e un libro spedito possono avere titolo e prezzo, ma non condividono le stesse relazioni di evasione o gli stessi record.
Attributi Product, varianti, immagini e inventario
Gli attributi Product di Squarespace definiscono valori come colore o taglia, mentre le varianti rappresentano combinazioni acquistabili. Una variante può avere SKU univoco, prezzo, quantità disponibile, dimensioni e valori degli attributi selezionati. Le immagini Product appartengono alla raccolta immagini del Product e possono essere associate alle varianti.
Le opzioni della piattaforma di origine devono essere distinte in base al loro effetto commerciale. Un valore che modifica SKU, prezzo, stock, immagine o identità di evasione è simile a una variante. Un’istruzione di personalizzazione, un servizio opzionale, un componente bundle o una configurazione generata da un’app potrebbe non avere un equivalente diretto come variante Squarespace. Trasformare ogni scelta di origine in una variante può creare una matrice Product ingestibile; appiattire vere varianti in semplice testo elimina invece identità di SKU e inventario.
| Modello di opzione nella piattaforma di origine | Responsabile in Squarespace | Significato da mantenere |
|---|---|---|
| Combinazione taglia/colore con SKU e stock | Attributi Product e ProductVariant | Identità acquistabile, valori degli attributi, SKU, prezzo, inventario e relazione con l’immagine. |
| Livello o durata di un servizio | Variante di Service Product | Scelta di servizio vendibile e relative differenze di prezzo o descrizione. |
| Importo di una gift card | Variante di Gift Card Product | Importo monetario acquistabile. |
| Formato di download | In genere significato Product separato o relazione con il file, non variante di un Download Product | Diritto corretto al file e identità Product. |
| Incisione, testo libero o upload del cliente | Input personalizzato, dati della riga Order o estensione collegata in base al comportamento supportato | Il valore fornito dal cliente resta collegato all’acquisto e al responsabile dell’evasione. |
| Bundle o configuratore | Relazione Product, semplificazione accettata oppure struttura di estensione/sistema esterno | Componenti, SKU risultante, prezzo, inventario e output della riga Order restano comprensibili. |
L’inventario è basato sulle varianti. Nell’Inventory API di Squarespace, un InventoryItem rappresenta una variante di un Product fisico o di servizio e registra se lo stock è tracciato o illimitato, insieme a SKU e informazioni sulla disponibilità. Questo significa che una quantità gestita a livello Product nella piattaforma di origine deve prima essere riconciliata con la struttura delle varianti nella destinazione.
Anche un valore di stock della piattaforma di origine richiede una decisione sul sistema autorevole. Se Squarespace gestisce l’inventario, la quantità iniziale deve essere allineata alle varianti Product di destinazione. Se resta autorevole un warehouse o ERP, la relazione durevole è ProductVariant → chiave esterna dello stock → sincronizzazione dell’inventario. Una quantità copiata senza quell’identificatore diventa obsoleta non appena il sistema esterno riprende gli aggiornamenti.
Store Pages, Categories, tag, navigazione e scoperta
Le Store Pages sono proprietarie dei Products, ma non sostituiscono tutte le strutture di scoperta della piattaforma di origine. Categories, tag, collocazione nelle Store Pages, link di navigazione, summary block, ricerca, pagine di contenuto e link di campagne esterne possono tutti aiutare i visitatori a trovare i Products. Una collection di origine può aver rappresentato un reparto permanente, una campagna temporanea, un brand, il risultato di un filtro o una pagina editoriale. Questi significati devono rimanere distinti.
| Struttura di scoperta nella piattaforma di origine | Significato nella destinazione Squarespace |
|---|---|
| Reparto permanente del catalogo | Product Category o raggruppamento stabile della Store Page in base alla struttura di destinazione. |
| Brand Product | Tag, relazione con contenuti, convenzione di denominazione o campo informativo esterno del Product, in base all’uso del brand. |
| Collection stagionale | Category, tag, pagina curata o relazione di navigazione temporanea, non necessariamente un tipo Product permanente. |
| Attributo usato per filtro a faccette | Attributo di variante, contenuto Product strutturato, tag oppure responsabile esterno di ricerca/filtro, non automaticamente una Category. |
| Link di navigazione principale | Relazione di navigazione del sito che punta a Store Page, vista Category, pagina di contenuto o URL esterno. |
| Landing page SEO | Pagina o destinazione Store Page collegata a Products, contenuti, URL, metadati e link interni. |
La Products API non espone ogni relazione Category delle Store Pages nello stesso modo in cui espone i record Product. Questo rafforza la necessità di distinguere i dati di catalogo dall’organizzazione del sito. Il modello di destinazione deve identificare quali record possiedono la classificazione Product e quali record del sito possiedono la scoperta pubblica.
Un Product può essere migrato correttamente e risultare di fatto non disponibile se appartiene alla Store Page sbagliata, è nascosto o non dispone di un percorso di navigazione raggiungibile. Questo è un problema di relazione, non una prova che manchino i campi del Product.
Contacts, Customers, iscritti, donatori e accesso all’account
Le funzioni commerce e marketing di Squarespace possono creare diversi significati legati alle persone. Contacts può rappresentare Customers, iscritti, donatori e altre persone associate al sito. Rubriche indirizzi e preferenze marketing appartengono a queste relazioni. Il precedente modello Profiles esponeva categorie simili di utenti del sito, mentre l’attuale Contacts API è il responsabile moderno per la gestione più ampia dei Contacts.
Un account Customer di origine può contenere anche password, gruppi cliente, ruoli B2B, saldi loyalty, dettagli di pagamento salvati, accessi membership, stato dell’abbonamento, esenzioni fiscali o attributi CRM. Questi significati non devono essere appiattiti in un unico record Contact soltanto perché la persona possiede un solo indirizzo email.
| Modello di identità nella piattaforma di origine | Decisione sulla relazione in Squarespace |
|---|---|
| Acquirente commerce registrato | Identità Contact/Customer collegata a Orders, indirizzi e comportamento account supportato. |
| Acquirente senza account | Identità dell’acquirente collegata all’Order, con un Contact durevole solo quando la relazione di destinazione lo supporta. |
| Iscritto alla newsletter | Contact più relazione con mailing list e consenso, mantenuta distinta dallo storico acquisti quando appropriato. |
| Donatore | Contact più storico di donazioni/transazioni, non automaticamente un Customer commerce. |
| Membro o partecipante a contenuti con accesso limitato | Contact/utente del sito più relazione membership o accesso; password e diritto di accesso non sono normali campi profilo. |
| Acquirente B2B o organizzazione | Contact più proprietà CRM/sistema esterno per azienda, ruolo, prezzi, imposte o strutture di approvazione. |
| Profili duplicati nella piattaforma di origine | Consolidati solo quando identità, consenso, indirizzi ed evidenze degli Orders indicano che si tratta della stessa persona. |
L’email può essere un forte segnale di identità, ma non l’unico. Indirizzi condivisi, email modificate, Orders senza account, importazioni duplicate e contatti aziendali possono generare fusioni errate. ID CRM esterni, ID Customer della piattaforma di origine, indirizzi e relazioni con Orders possono essere necessari per preservare persone e storico distinti.
Il consenso marketing deve rimanere una relazione separata dall’identità di acquirente. Un Customer che ha effettuato un acquisto non diventa automaticamente iscritto a una mailing list e un iscritto può non aver mai acquistato. Preservare il Contact senza preservare la relazione che spiega perché esiste può creare confusione operativa e problemi relativi al consenso.
Orders, transazioni, evasione e contesto storico
Gli Orders Squarespace possono rappresentare acquisti una tantum e Orders di abbonamento. Contengono righe di ordine, informazioni Customer, indirizzi di fatturazione e spedizione, totali, sconti, imposte, dettagli di spedizione, stato di evasione, stato del pagamento, rimborsi e altro contesto della transazione. Le Transactions forniscono i record finanziari associati a Orders e donazioni.
L’Order deve conservare il Product o la variante acquistata al momento della transazione, anche se il Product corrente viene successivamente modificato. Una riga Order è un’istantanea della transazione, non un riferimento live da sovrascrivere con il contenuto attuale del catalogo. Stato di pagamento e rimborso descrivono ciò che è avvenuto finanziariamente. Evasione e tracking spiegano come è stato gestito l’acquisto. Orders importati o storici non definiscono processori di pagamento correnti, regole di spedizione, configurazione fiscale, comportamento delle email o connessioni al warehouse.
| Record storico | Significato in Squarespace |
|---|---|
| Numero Order della piattaforma di origine | Riferimento esterno tracciabile per assistenza clienti e riconciliazione. |
| Riga Product/variante | Titolo acquistato, SKU, attributi selezionati, quantità, prezzo e altri dati dell’istantanea della riga. |
| Indirizzi di fatturazione e spedizione | Contesto storico della transazione, non indirizzo permanente dell’account a meno che non sia posseduto separatamente dal Contact. |
| Riga di sconto, imposta e spedizione | Spiegazione del totale storico, non configurazione corrente di sconti o imposte. |
| Stato del pagamento e Transaction | Storico finanziario collegato all’Order, non credenziali di pagamento riutilizzabili. |
| Evasione e tracking | Contesto storico della spedizione o dell’erogazione del servizio, non definizione dei metodi correnti di evasione. |
| Stato di abbonamento o payment plan | Ciclo di vita di Order e Transaction che deve restare collegato al sistema che controlla gli addebiti futuri. |
| Order importato da un canale di terze parti | Storico Order più identificatore del canale esterno e relazione con la fonte. |
Squarespace può importare Orders da canali di vendita di terze parti tramite le Commerce APIs, ma lo storico importato deve comunque preservare fonte e identificatori originali. Creare un Order Squarespace non fa scomparire marketplace, provider di pagamento o sistema di evasione di origine come responsabile storico dei riferimenti correlati.
Relazioni tra pagine, Blog Posts, media, URL e SEO
I siti Squarespace possono contenere pagine normali, Store Pages, Blog Posts, elementi di raccolte, immagini, file, link di navigazione, URL Product, viste Category, campi SEO, redirect, domini e servizi collegati. Questi record formano un grafo di contenuti attorno al catalogo commerce.
Una descrizione Product di origine appartiene al Product. Una guida all’acquisto può appartenere a una pagina o a un Blog Post collegato a più Products. La descrizione di una Category può diventare contenuto di una Store Page o landing page. Una pagina campagna può contenere riferimenti a Products senza possedere i dati Product. I media possono essere condivisi tra Products e contenuti, ma ordine delle immagini, ritaglio, alt text, didascalie e link interni hanno significati specifici per il sito.
| Risorsa web di origine | Responsabile in Squarespace |
|---|---|
| Titolo Product, descrizione, immagini, slug URL e dati SEO | Relazione tra Product e Store Page. |
| CMS Page informativa o policy | Pagina Squarespace con contenuto, media, metadati e relazione di navigazione. |
| Blog Post | Elemento della raccolta blog con contesto di pubblicazione, Categories/tag, media, link interni e URL. |
| Guida Product o landing page campagna | Pagina/raccolta di contenuti più riferimenti Product e navigazione. |
| Voce di menu | Relazione di navigazione del sito che punta a pagina, Store Page, destinazione Product, anchor o URL esterno. |
| URL di origine | Percorso di destinazione più relazione di redirect quando il path cambia. |
| Blocco del tema o codice personalizzato | Presentazione/configurazione del sito che fa riferimento a record di contenuto e commerce senza diventarne responsabile. |
La continuità degli URL dipende dall’identità della destinazione. Un redirect deve collegare il vecchio percorso di origine al Product, Store Page, pagina, Blog Post o altra destinazione corretta. Non deve essere utilizzato per nascondere l’incertezza su quale record abbia sostituito la pagina di origine. Anche i link interni nei contenuti migrati devono puntare alla destinazione prevista invece di conservare URL obsoleti della piattaforma di origine.
Estensioni, API, campi personalizzati e proprietà dei sistemi esterni
Le Commerce APIs di Squarespace espongono Products, Inventory, Orders, Transactions, Contacts, Discounts, Websites e webhook. Servizi ed estensioni collegati possono inoltre essere proprietari di Reviews, loyalty, abbonamenti, evasione, contabilità, spedizione, marketing, scheduling, donazioni, membership o altri dati. Un record di un’applicazione di origine non deve essere trattato come dato nativo di Squarespace soltanto perché un’estensione di destinazione offre una funzione simile.
Il responsabile corretto dipende dallo scopo aziendale e dal ciclo di vita. Un ID Product del warehouse appartiene alla relazione tra ProductVariant ed ERP. Un ID CRM del Contact appartiene al Contact e al CRM. Un ID Order del marketplace appartiene all’Order e al canale. Un diritto membership appartiene al sistema membership, non a una nota generica nel Contact.
| Valore personalizzato o esterno | Proprietà nella destinazione |
|---|---|
| ID ERP di Product o variante | Product/ProductVariant più relazione ERP allo stesso livello di granularità del catalogo. |
| Chiave esterna dell’inventario | ProductVariant più warehouse o sistema di inventario. |
| ID CRM del Contact | Contact più relazione CRM. |
| ID Order del marketplace | Order più relazione con il canale di vendita. |
| Record Review, loyalty o abbonamento | Estensione o sistema esterno più riferimenti a Product, Contact o Order. |
| Output di un configuratore Product | Product/variante più configurazione gestita dall’estensione e istantanea risultante nella riga Order. |
| Risposta personalizzata raccolta durante il processo di acquisto | Order o Contact in base allo scopo aziendale, più form/estensione che gestisce raccolta e visualizzazione. |
| Tabella di origine non supportata | Record padre esplicito, chiave durevole, ciclo di vita e responsabile nella destinazione prima di conservare il valore. |
Questo confine evita due errori comuni: forzare ogni valore nel campo Squarespace più vicino e conservare dati di app senza un sistema utilizzatore nella destinazione. Un campo personalizzato è utile solo quando il team di destinazione sa quale record lo possiede, quale sistema lo riconosce e se descrive commerce corrente, contesto storico, contenuto o configurazione esterna.
Catene rappresentative di trasformazione verso Squarespace
Una catena di relazioni mostra come un singolo concetto della piattaforma di origine venga suddiviso tra record commerce, Contact, contenuti e sistemi esterni in Squarespace. Rende visibile il responsabile nella destinazione e impedisce che un unico campo importato porti significati incompatibili. La catena deve restare comprensibile anche dopo che la piattaforma di origine non è più disponibile, così ogni Product, Contact, Order, URL e riferimento di estensione mantiene un record padre chiaro e un sistema utilizzatore che continua a utilizzarlo.
| Modello di origine | Relazione nella destinazione Squarespace |
|---|---|
| Product di abbigliamento con stock per taglia/colore | Store Page → Physical Product → attributi → ProductVariants → immagini/SKU delle varianti → InventoryItems. |
| Pacchetti di consulenza | Store Page → Service Product → varianti di livello/durata → contenuto → responsabile esterno di scheduling o delivery quando necessario. |
| Download digitale | Store Page → Download Product → DigitalGood → riga Order → Contact acquirente → diritto alla consegna. |
| Iscritto che in seguito acquista | Contact → relazione mailing list/consenso → storico Customer/Order, senza presumere che le due relazioni siano identiche. |
| Vendita importata da marketplace | Order → istantanea delle righe → storico Transaction/evasione → Contact → ID marketplace esterno. |
| Collection Product sensibile alla SEO | Store Page/Category o pagina curata → riferimenti Product → navigazione → URL di destinazione → redirect dai percorsi di origine. |
| Record membership o donazione | Contact → responsabile membership o donation → storico transazioni/accessi, separato dai normali campi Product e Customer. |
Queste catene mantengono visibili proprietà di Product, sito, Contact, Order, contenuti e sistemi esterni. Mostrano anche dove una piattaforma di origine può aver combinato in un solo record significati che Squarespace rappresenta separatamente.
Conclusione
La trasformazione del modello dati verso Squarespace dipende dalla relazione tra i record commerce e il sito che li pubblica. I Products appartengono a Store Pages e tipi Product; le varianti possiedono combinazioni vendibili e inventario; Contacts può esprimere significati relativi a Customer, iscritto, donatore e account; Orders conservano lo storico delle transazioni; pagine, Blog Posts, URL e navigazione possiedono la scoperta dei contenuti; estensioni e sistemi esterni possiedono comportamenti specializzati.
Un buon modello di destinazione preserva queste relazioni senza confondere i dati migrati con la presentazione del sito o con la futura configurazione operativa. Il risultato non è soltanto un sito Squarespace popolato, ma un insieme coerente di record Product, Contact, Order, contenuti e sistemi esterni la cui proprietà resta comprensibile.
Domande frequenti
Perché la proprietà della Store Page è importante per i Products Squarespace?
Ogni Product Squarespace appartiene a una Store Page e la disponibilità del Product è collegata sia alla sua visibilità sia allo stato della Store Page. I dati Product e la collocazione nella Store Page formano quindi un’unica relazione di destinazione, anche se la navigazione del sito rimane un livello separato.
Ogni opzione Product della piattaforma di origine può diventare una variante Squarespace?
No. Una variante è appropriata quando la scelta crea una combinazione acquistabile distinta con SKU, prezzo, inventario, immagine, dimensioni o altro significato vendibile. Personalizzazione, bundle, upload o scelte controllate da applicazioni possono richiedere un altro responsabile.
Squarespace Contacts, Customers e iscritti sono lo stesso tipo di record?
Possono riferirsi alla stessa persona, ma le relazioni sono diverse. Storico Customer, consenso alla mailing list, attività di donazione, rubriche indirizzi e accesso all’account devono restare distinguibili anche quando un singolo Contact le collega.
Un Order migrato ricrea il funzionamento del processo di acquisto Squarespace?
No. L’Order conserva contesto di transazione, righe, pagamento, rimborso, indirizzi ed evasione. Processori di pagamento correnti, impostazioni fiscali, metodi di spedizione, notifiche e comportamento dell’evasione collegata rimangono configurazioni separate.
Come deve essere rappresentato l’inventario Product in Squarespace?
L’inventario dovrebbe seguire il ProductVariant Squarespace che rappresenta l’articolo effettivamente vendibile. Se resta autorevole un sistema di inventario esterno, la variante necessita anche della chiave esterna durevole utilizzata per mantenere lo stock dopo il trasferimento iniziale dei dati.
Dove devono risiedere i dati Squarespace gestiti da app o personalizzati?
Devono restare associati al Product, ProductVariant, Contact, Order, record di contenuto, estensione o sistema esterno che ne possiede lo scopo aziendale. Note generiche non sostituiscono una relazione record padre definita e un identificatore durevole.