Se Squarespace viene scelto come piattaforma di destinazione, la preparazione deve stabilire come il catalogo commerce si inserirà nel sito più ampio prima che inizi qualsiasi esecuzione di migrazione. Ogni Product appartiene a una Store Page, mentre Products fisici, servizi, gift card e download seguono comportamenti differenti per varianti e inventario. Contacts, Orders, Transactions, Pages, Blog Posts, navigazione, estensioni e design del sito restano inoltre famiglie di record separate.
La preparazione dovrebbe registrare ogni azione necessaria insieme al responsabile, alle evidenze di supporto e a una condizione chiara che definisca quando l’area è pronta. Questo evita di scambiare un export Product completo per una Store Page completa, un Contact per un diritto di abbonamento o membership, oppure dati storici di pagamento per configurazione corrente del processo di acquisto.
Confermare il modello del sito Squarespace e delle Store Pages
Definisci la relazione prevista tra sito web, Store Pages, Products, contenuti, navigazione e sistemi collegati.
| Area di preparazione | Decisione da registrare | Responsabile | Evidenza di preparazione |
|---|---|---|---|
| Struttura del sito | Domini, lingua/locale, valuta, navigazione, Pages, Blog e aree abilitate al commerce | Responsabile del sito | Mappa del sito e dei percorsi |
| Store Pages | Quale Store Page possiede ciascuna famiglia Product | Responsabile commerce | Matrice di assegnazione delle Store Pages |
| Tipi di Product | Gestione di Products fisici, servizi, gift card e download | Responsabile merchandising | Inventario dei tipi Product |
| Modello Customer | Contacts, iscritti, donatori, Customers, account e relazioni CRM esterne | Responsabile Customer | Matrice di classificazione dei Contacts |
| Modello Orders e finanziario | Orders, subscription Orders, Transactions, rimborsi e riferimenti esterni | Operations/finance | Pacchetto di evidenze storiche |
| Modello delle estensioni | Responsabilità di evasione, abbonamenti, membership, booking, imposte, marketing e analisi | Responsabile tecnico | Registro delle dipendenze |
Il modello è pronto quando ogni record commerce o contenuto importante ha un unico responsabile previsto in Squarespace o in un sistema esterno e ogni famiglia Product dispone di una Store Page assegnata.
Preparare accessi, archivi di origine ed evidenze recuperabili
Raccogli:
- accesso amministratore alla piattaforma di origine e le autorizzazioni necessarie sul sito e sulle funzioni commerce di Squarespace;
- export o backup datati per Products, Customers, Orders, contenuti, iscritti e dati personalizzati rilevanti;
- immagini Product, file scaricabili, media delle pagine e archivi dei contenuti di origine;
- inventari di Store Pages, navigazione, domini e URL;
- evidenze relative a estensioni, API, webhook e sistemi esterni;
- identificatori esterni di Product, Contact, Order e transazioni;
- un responsabile delle modifiche sulla piattaforma di origine per Products, Contacts, Orders, contenuti e inventario durante la finestra di migrazione.
| Evidenza | Perché conta | Condizione di preparazione |
|---|---|---|
| Registro degli accessi | Conferma che le aree di origine e destinazione possano essere ispezionate | Le autorizzazioni necessarie sono disponibili |
| Archivio datato della piattaforma di origine | Preserva uno stato di riferimento recuperabile | Gli export si aprono correttamente e riportano una data |
| Archivio media e file | Protegge immagini Product, media delle pagine e download | I file possono essere associati ai record che li possiedono |
| Inventario Store Pages | Evita l’assegnazione dei Products alla pagina commerce sbagliata | Ogni famiglia Product ha una Store Page di destinazione |
| Registro degli ID esterni | Protegge la continuità di CRM, evasione, contabilità o marketplace | Ogni chiave è assegnata all’entità corretta |
| Registro delle modifiche | Rileva aggiornamenti nella piattaforma di origine dopo la data dell’archivio | Record nuovi e modificati hanno responsabile responsabili |
Se un’applicazione o sistema esterno non può fornire un export, registra il limite e il responsabile invece di ometterlo dalla preparazione.
Preparare tipi di Product, varianti, immagini e inventario
Squarespace supporta Products fisici, servizi, gift card e download. Products fisici e di servizio possono utilizzare varianti; i record di inventario si applicano alle varianti fisiche e di servizio e possono essere tracciati o illimitati. I Download Products hanno relazioni con file ma non utilizzano lo stesso modello di varianti.
Prepara esempi rappresentativi per:
- ogni tipo Product utilizzato dal business;
- Products semplici e con più varianti;
- attributi Product come colore, taglia o peso;
- relazioni tra SKU della variante, prezzo, stock e immagini;
- file scaricabili e aspettative di accesso;
- Service Products ed eventuali dipendenze da booking o scheduling esterno;
- storico delle gift card o saldi correnti quando rilevanti;
- bundle, abbonamenti, personalizzazione o comportamenti gestiti da estensioni;
- identificatori ERP, PIM, warehouse, marketplace ed evasione.
| Comportamento di origine | Decisione di preparazione | Evidenza | Condizione di preparazione |
|---|---|---|---|
| Product fisico o di servizio con varianti | Definire responsabilità di Product e varianti | ID record padre/variante, attributi, SKU, prezzo, stock e immagini | Ogni combinazione ha una variante Squarespace prevista |
| Download Product | Definire responsabilità di Product, file e consegna | File di origine, ID Product, regole di accesso ed esempio Order | La relazione con il file ha un responsabile definito |
| Service Product con scheduling | Separare i dati Product dai record di booking o scheduling esterno | Esempi di servizio e appuntamento | L’responsabilità dello scheduling è documentata |
| Gift card o stored value | Definire responsabile storico e corrente | Esempi di codice/saldo e responsabile finance | Il trattamento dello stored value è esplicito |
| Funzionamento Product gestito da estensione | Identificare l’estensione o sistema esterno che continuerà a operare | Evidenze relative a Product e configurazione | I record richiesti compaiono nel registro delle dipendenze |
L’area è pronta quando ogni famiglia Product ha un tipo, una Store Page, un modello di varianti, un trattamento dell’inventario, un responsabile per media/file e una chiave esterna.
Preparare Store Pages, Categories, navigazione e scoperta dei Products
Ogni Product Squarespace appartiene a una Store Page. Le Categories della Store Page e la navigazione sono però strutture separate. La Products API non fornisce le assegnazioni alle Categories della Store Page, quindi le evidenze di origine per raggruppamento Product e scoperta nella vetrina online devono essere preparate direttamente.
Raccogli:
- nomi, identificatori, URL e assegnazioni Product delle Store Pages;
- Product Categories e raggruppamenti di merchandising utilizzati in ogni Store Page;
- navigazione principale, navigazione secondaria, link del footer e landing page;
- filtri, attributi, link interni e collection di campagne;
- percorsi di acquisto di alto valore e URL di origine;
- redirect e decisioni di ritiro.
| Area di scoperta | Responsabile | Evidenza richiesta | Condizione di preparazione |
|---|---|---|---|
| Store Page | Responsabile commerce/sito | Elenco Store Page e assegnazioni Product | Ogni Product ha una Store Page prevista |
| Category o raggruppamento | Responsabile merchandising | Appartenenza dei Products ed esempi di percorsi pubblici | Il significato del gruppo è documentato indipendentemente dalla navigazione |
| Navigazione | Responsabile del sito | Albero menu e link di destinazione | Store Pages, Categories, Pages e link esterni hanno collocazioni previste |
| Contenuto landing | Responsabile editoriale | Contenuto pagina, media, metadati e riferimenti Product | Percorsi di campagne e permanenti hanno responsabili definiti |
| Redirect | Responsabile SEO | Registro URL origine-destinazione | Ogni percorso prioritario ha un esito approvato |
Non presumere che la migrazione dei Products ricrei automaticamente Categories delle Store Pages, posizione nei menu o percorsi degli acquirenti. Queste relazioni richiedono evidenze e responsabile propri.
Preparare Contacts, rubriche indirizzi, iscritti e identità Customer
La Contacts API di Squarespace rappresenta le persone associate al sito, inclusi Customers, iscritti alle mailing list, donatori e altri partecipanti. Contacts può avere rubriche indirizzi e preferenze marketing e il Contact ID corrisponde al Customer ID referenziato dagli Orders.
Prepara:
- Customers registrati, acquirenti senza account, iscritti, donatori e altri Contacts;
- esempi di email duplicate o identità ambigue;
- rubriche indirizzi dei Contacts e indirizzi di spedizione predefiniti;
- preferenze marketing ed evidenze di consenso;
- Customer/Contact IDs utilizzati dagli Orders;
- aspettative relative all’accesso account;
- membership, abbonamenti, loyalty, booking o record CRM posseduti altrove;
- identificatori esterni di Contact e Customer.
| Caso di identità | Responsabile | Evidenza | Condizione di preparazione |
|---|---|---|---|
| Customer con Orders | Operazioni cliente | Contact ID, rubrica indirizzi ed esempi Order | Le relazioni Order usano l’identità Contact prevista |
| Acquirente senza account | Operazioni cliente | Email, Order e istantanee degli indirizzi | Lo storico senza account è documentato senza inventare un account |
| Iscritto o donatore | Responsabile marketing/fundraising | Consenso, lista e contesto dell’attività | L’identità non commerce non viene trattata per impostazione predefinita come Customer retail |
| Partecipante a membership o abbonamento | Responsabile dell’applicazione | Piano, entitlement, rinnovo o record di accesso | La relazione specializzata ha un responsabile che continua a operare |
| Contact CRM esterno | Responsabile integrazione | ID CRM e regole di matching | L’identità cross-system è documentata |
Autenticazione e accesso account devono essere preparati separatamente dall’identità Contact. Un record Contact da solo non riproduce password della piattaforma di origine, entitlement membership o profilo applicativo.
Preparare Orders storici, subscription Orders e Transactions
Seleziona Orders che mettano in evidenza acquisti una tantum e in abbonamento, righe Product e variante, Customer IDs, indirizzi, sconti, imposte, spedizione, evasione, rimborsi e riferimenti esterni. Prepara Transactions separatamente perché i documenti finanziari possono contenere pagamenti, rimborsi, commissioni ed errori gateway collegati a un Order o a una donazione.
| Area storica | Evidenza richiesta | Condizione di preparazione |
|---|---|---|
| Order una tantum | Righe Product/variante, Customer, totali, stato ed evasione | La transazione può essere spiegata a partire dal pacchetto di origine |
| Subscription Order | Contesto dell’abbonamento, storico rinnovi, Products e Customer | La ricorrenza storica è distinta dalla configurazione live dell’abbonamento |
| Pagamento e rimborso | Documento Transaction, tipo di pagamento, rimborso ed esempi di errore | Lo storico finanziario è collegato all’Order corretto |
| Evasione | Spedizione, tracking, quantità evase e ID esterni | Il contesto della consegna passata è comprensibile |
| Order senza account | Email, indirizzo e relazione Order | L’identità senza account resta distinta da un account persistente |
| Order esterno | ID del canale, ERP, contabilità o assistenza | Le chiavi di riconciliazione restano associate all’Order corretto |
Orders e Transactions storici preservano il commerce passato. Processori di pagamento correnti, processo di acquisto, imposte, spedizioni, sconti, fatturazione degli abbonamenti e configurazione dell’evasione restano aree separate di preparazione assegnate ai team responsabili.
Preparare contenuti, Blog Posts, media, domini e URL
Il commerce Squarespace vive comunemente all’interno di un sito orientato ai contenuti. Prepara:
- CMS Pages, Blog Posts, contenuti delle Store Pages, descrizioni Product e landing page;
- autori, date, tag, Categories, media e link interni;
- inventari di immagini, video, file scaricabili e alt text;
- dominio principale, domini secondari, locale, valuta e responsabilità degli strumenti di analisi;
- URL di Product, Store Page, contenuti, Blog Post e campagne;
- metadati, relazioni canoniche, redirect e percorsi ritirati;
- navigazione, footer e link di campagna.
| Area contenuti | Responsabile | Evidenza | Condizione di preparazione |
|---|---|---|---|
| CMS Page | Responsabile editoriale | Contenuto, media, metadati, percorso e contesto di navigazione | Ogni Page ha una destinazione e un percorso previsti |
| Blog Post | Responsabile editoriale | Corpo, autore/data, media, tag/Categories e URL | Storico editoriale e percorso sono documentati |
| Contenuto Product/Store Page | Responsabile commerce | Descrizione, immagini, raggruppamento e responsabilità della pagina | Il contenuto resta associato all’oggetto commerce corretto |
| Dominio e percorso | Responsabile SEO/sito | Registro domini e URL | Ogni percorso prioritario ha una destinazione o decisione di ritiro |
| Dipendenza da template o blocchi | Designer del sito | Inventario di layout, blocchi, form, embed o codice | Il lavoro di presentazione è separato dai contenuti migrati |
Un record di contenuto è pronto quando corpo, media, percorso, responsabile e livello di presentazione previsto sono noti. Copiare soltanto il testo non rappresenta una preparazione completa.
Inventariare estensioni, API, webhook e sistemi esterni
Crea un registro delle dipendenze che includa evasione, abbonamenti, membership, booking, email marketing, CRM, contabilità, imposte, spedizioni, Reviews, loyalty, marketplace, donazioni, analisi e applicazioni personalizzate.
Per ogni dipendenza, registra:
- scopo aziendale;
- Products, Contacts, Orders, Transactions, contenuti o file coinvolti;
- sistema autorevole e ID esterni;
- disponibilità di export o API;
- responsabile della configurazione;
- destinazione che continuerà a operare, sostituzione o decisione di ritiro;
- evidenze di origine necessarie prima di configurare il flusso di lavoro di destinazione.
Il registro è pronto quando ogni campo o record attivo gestito da un’estensione ha responsabile, entità record padre, sistema utilizzatore che continuerà a utilizzarlo, identificatore durevole ed evidenza di origine recuperabile senza dipendere soltanto dalla visualizzazione nella vetrina online.
Selezionare campioni rappresentativi per i test di migrazione
| Campione | Scopo della preparazione |
|---|---|
| Physical Product con varianti | Esporre relazioni tra attributi, SKU, immagini e inventario |
| Service Product | Distinguere dati Product da scheduling o responsabilità di servizi esterni |
| Download Product | Esporre relazioni Product-file e accesso tramite Order |
| Product assegnato a una Store Page prioritaria | Esporre responsabilità di Store Page, Category, navigazione e URL |
| Contact con più indirizzi e Orders | Esporre Contact ID, rubrica indirizzi e relazione Customer |
| Order di abbonamento o rimborsato | Esporre ricorrenza, Transactions, rimborso e totali |
| CMS Page o Blog Post | Esporre responsabilità di contenuto, media, metadati e percorso |
| Record gestito da estensione | Esporre applicazione che continuerà a operare e identificatori esterni |
Per ogni campione, registra ID di origine, URL di origine quando rilevante, tipo Product, Store Page, motivo aziendale, responsabile previsto in Squarespace, esclusioni note, chiavi esterne e responsabile della revisione responsabile.
Completare il gate di preparazione per Squarespace
| Domanda di preparazione | Evidenza richiesta | Condizione di preparazione |
|---|---|---|
| Accessi e archivi di origine sono recuperabili? | Registro degli accessi ed export/backup datati | I record necessari possono essere ispezionati indipendentemente dalla piattaforma live di origine |
| Responsabilità di sito e Store Page è definita? | Matrice sito/Store Page | Ogni famiglia Product e area di contenuto ha un responsabile |
| Tipi Product e varianti sono preparati? | Inventario di tipi Product e varianti | Casi fisici, servizio, gift card e download sono documentati |
| Contacts e Orders sono collegati? | Esempi di relazioni Contact/Order | Identità, indirizzi e transazioni storiche sono comprensibili |
| Transactions ed estensioni sono inventariate? | Evidenze finanziarie e registro delle dipendenze | Rimborsi, pagamenti e record gestiti da applicazioni hanno responsabili definiti |
| Contenuti e URL sono preparati? | Registro contenuti e percorsi | Pages, Blog Posts, Store Pages, media e redirect hanno destinazioni previste |
| Sono stati selezionati campioni rappresentativi? | Registro campioni | Complessità di catalogo, identità, Order, transazioni, contenuti ed estensioni è coperta |
| Gli elementi irrisolti sono sotto controllo? | Registro decisioni | Ogni elemento aperto ha responsabile e scadenza |
Il gate è completo quando nessuna decisione critica relativa a Store Page, tipo Product, variante, Contact, Order, Transaction, contenuto, percorso o estensione dipende da un’ipotesi non documentata.
Conclusione
La preparazione per Squarespace dovrebbe produrre un pacchetto di evidenze che unisca sito web e commerce. I Products devono essere assegnati alla Store Page e al tipo Product corretti, varianti e inventario devono mantenere le proprie relazioni, Contacts devono restare distinti da programmi account specializzati, Orders e Transactions devono preservare il contesto storico e contenuti o percorsi devono avere responsabile chiari.
Quando queste decisioni vengono documentate prima del test di migrazione rappresentativo, il campione può riflettere il sito Squarespace previsto senza confondere i record commerce importati con il design del sito o la configurazione live del processo di acquisto.
Domande frequenti
Che cosa va preparato per primo per Squarespace?
Inizia dalla mappa di responsabilità del sito e delle Store Pages. Definisci quale Store Page possiede ciascuna famiglia Product e quali Pages, Blog Posts, domini, Contacts e sistemi esterni fanno parte della destinazione.
Perché i tipi Product di Squarespace devono essere preparati separatamente?
Products fisici, servizi, gift card e download non condividono relazioni identiche con varianti, inventario, file, evasione o applicazioni. Ogni tipo richiede evidenze rappresentative dalla piattaforma di origine.
Come devono essere preparate le Categories delle Store Pages?
Raccoglile direttamente insieme alle appartenenze Product, ai percorsi e allo scopo di merchandising. Non sono disponibili tramite Products API e non devono essere dedotte dai soli record Product.
Squarespace Contacts e Customers sono identità separate?
Contacts rappresenta persone associate al sito, inclusi Customers, iscritti e donatori. Lo stesso Contact ID può comparire come Customer ID in un Order, ma membership o abbonamenti specializzati possono restare di proprietà di un’altra applicazione.
Perché Orders e Transactions devono essere preparati separatamente?
Gli Orders spiegano articoli acquistati ed evasione, mentre i documenti Transaction spiegano pagamenti, rimborsi, commissioni ed errori gateway. Servono entrambi per conservare un contesto storico completo.
Quando la preparazione per Squarespace è completa?
È completa quando accessi, Store Pages, tipi Product, varianti, inventario, Contacts, Orders, Transactions, contenuti, percorsi, estensioni, campioni e decisioni irrisolte hanno tutti responsabile responsabili ed evidenze recuperabili.