La modellazione dei dati in Shopify Plus parte dalla base dati di Shopify e aggiunge significato operativo enterprise intorno a struttura dell’organizzazione, B2B, Markets, più store, integrazioni, autorizzazioni e responsabilità dei flussi di lavoro. Products, varianti, collezioni, Customers, Orders, pagine, Blog Posts, redirect, metafield e app restano centrali. La differenza a livello Plus è che molti di questi record possono avere un significato aziendale maggiore rispetto a una migrazione Shopify di un singolo store.
Questa distinzione è importante perché le piattaforme di origine enterprise memorizzano spesso la logica commerce in strutture che non si traducono direttamente in normali record Shopify. Un’origine Magento o Adobe Commerce può usare gruppi Customer, siti, store, store view, attributi Product, regole di prezzo, shared catalogs, account B2B e dati di proprietà delle estensioni. Una Custom Platform può usare tabelle proprietarie, identificatori ERP, regole checkout personalizzate, autorizzazioni degli acquirenti basate sui ruoli o cataloghi regionali. Shopify Plus può supportare molti risultati enterprise, ma la pianificazione della migrazione deve stabilire se ogni struttura di origine debba diventare dato Shopify, configurazione Shopify Plus, configurazione di app, mappatura diretta dei campi, progettazione dati lato destinazione, lavoro di integrazione o flusso riprogettato.
Shopify Plus usa i dati Shopify con una governance enterprise
Shopify Plus non è una piattaforma dati separata da Shopify. I dati core continuano a seguire i concetti Shopify: i Products contengono varianti, le collezioni raggruppano Products, Customers e Orders conservano storico di acquirenti e transazioni, pagine e Blog Posts supportano i contenuti, i redirect aiutano la continuità del traffico e metafield o metaobject estendono le informazioni strutturate. La pianificazione della migrazione deve quindi preservare il modello Shopify invece di inventare un modello enterprise personalizzato all’interno di Shopify Plus.
Il livello enterprise cambia il modo in cui questo modello viene governato. Un Product può dover supportare più Markets, vetrine multiple, disponibilità B2B, continuità degli SKU ERP, metafield personalizzati o merchandising gestito da app. Un Customer può dover essere distinto da un account Company, un ruolo di acquisto, una location, un termine di pagamento o una struttura commerciale regionale. Una vetrina può essere un unico store che usa Markets oppure uno di più expansion store all’interno di un’organizzazione. Queste decisioni non sono cosmetiche: definiscono come i dati migrati verranno utilizzati dopo il lancio.
| Area dati | Significato core in Shopify | Significato nella migrazione Shopify Plus |
|---|---|---|
| Products e varianti | Struttura del catalogo vendibile. | Logica SKU enterprise, disponibilità B2B, merchandising specifico per mercato, riferimenti ERP e governance dei dati Product. |
| Collezioni | Raggruppamento dei Products per navigazione e merchandising. | Decisioni di segmentazione per regione, brand, canale, B2B e campagne. |
| Customers | Profili degli acquirenti e storico Orders. | Acquirenti D2C, contatti B2B, relazioni Company, ruoli degli acquirenti e responsabilità degli account. |
| Orders | Contesto storico delle transazioni. | Supporto, riconciliazione, revisione Orders B2B, termini di pagamento, evidenze di evasione e valore come riferimento per le integrazioni. |
| Metafield e metaobject | Estensioni strutturate dei dati personalizzati. | Arricchimento Product, modelli di contenuto, identificatori di integrazione, attributi B2B e contesto operativo enterprise. |
| Store e organizzazione | Ambienti amministrativi e della vetrina online. | Più store, governance, autorizzazioni, sicurezza, fatturazione e responsabilità operative. |
La migrazione non dovrebbe appiattire queste differenze in un semplice trasferimento di record. Deve definire il significato di destinazione di ogni struttura critica per l’azienda.
Products, varianti e significato del catalogo enterprise
Products e varianti Shopify restano il primo livello di revisione del catalogo. Products di origine con taglie, colori, unità, bundle, kit, opzioni configurabili, scelte di abbonamento o SKU guidati da ERP devono essere interpretati rispetto alla struttura Product-variante di Shopify. Shopify Plus non elimina la necessità di queste decisioni; aumenta piuttosto la loro importanza perché i dati di catalogo possono dover supportare più brand, Markets, cataloghi B2B, vetrine e sistemi esterni.
Un catalogo D2C semplice può migrare verso Products e varianti con poca interpretazione aggiuntiva. Un catalogo enterprise richiede spesso una classificazione più profonda. Gli attributi di origine possono essere contenuti descrittivi, specifiche ricercabili, opzioni che definiscono varianti, input per filtri, identificatori ERP, indicatori di idoneità B2B, valori specifici per mercato o logica di proprietà di un’app. Trattare tutti gli attributi come normali descrizioni può indebolire merchandising, ricerca e integrazioni.
| Modello di catalogo nella piattaforma di origine | Domanda di pianificazione per Shopify Plus |
|---|---|
| Product configurabile con molti attributi di origine | Quali attributi definiscono varianti Shopify, quali diventano metafield e quali devono restare esterni? |
| Visibilità Product per gruppo Customer | La visibilità deve essere gestita tramite cataloghi B2B, separazione degli store, regola di un’app o progettazione dati separata? |
| Nomi o descrizioni Product regionali | La destinazione deve usare Markets/localizzazione, store separati, flussi di traduzione o ricostruzione dei contenuti? |
| SKU o ID Product ERP | L’identificatore deve essere preservato come SKU, metafield, dato di app o riferimento di integrazione? |
| Bundle, kit, abbonamento o pacchetto configurabile | Deve usare configurazione Shopify o di un’app, una riprogettazione lato destinazione oppure configurazione manuale? |
| Arricchimento Product enterprise | I dati strutturati devono diventare metafield, metaobject, dati di app o configurazione di tema/contenuti? |
La migrazione Product è più solida quando ogni campo di origine ha uno scopo di destinazione chiaro. L’obiettivo non è forzare ogni campo enterprise nella forma Product nativa di Shopify. È preservare le informazioni che devono restare utilizzabili nel modello operativo Shopify Plus.
Collezioni, navigazione e segmentazione della vetrina online
Le collezioni non equivalgono alle Categories di ogni piattaforma di origine. Alcune piattaforme usano le Categories come gerarchia del database, navigazione della vetrina online, pagine di merchandising, pagine di destinazione SEO, gruppi di reportistica o strutture per il controllo degli accessi. Le collezioni Shopify possono supportare il raggruppamento dei Products e il merchandising della vetrina, ma il piano di migrazione deve stabilire se ogni raggruppamento di origine debba diventare una collezione Shopify, una voce di navigazione, una pagina, una destinazione di redirect, un’esperienza specifica per mercato, una regola di catalogo B2B oppure una struttura storica da escludere.
Shopify Plus aggiunge domande sulla segmentazione. Un’azienda può utilizzare store separati per brand o regioni. Un’altra può usare un solo store con Markets e contenuti localizzati. Un’azienda B2B può richiedere disponibilità Product per Company o catalogo anziché affidarsi soltanto a collezioni pubbliche. Queste scelte di destinazione influenzano il modo in cui deve essere rappresentato il significato di Category e collezioni.
| Significato del raggruppamento di origine | Interpretazione più adatta in Shopify Plus |
|---|---|
| Percorso di navigazione pubblico per i Customers | Collezione Shopify, navigazione e revisione della vetrina online. |
| Pagina di destinazione SEO | Decisione tra collezione, pagina, redirect, metadati o ricostruzione dei contenuti. |
| Raggruppamento regionale della vetrina | Pianificazione Markets/localizzazione o expansion store. |
| Raggruppamento con accesso solo B2B | Catalogo B2B, regola di app o progettazione di una vetrina separata. |
| Gruppo interno di reportistica | Metafield, tag, dati di app oppure esclusione dalla vetrina pubblica. |
| Category legacy non più utilizzata | Esclusione deliberata, trattamento archivio o destinazione di redirect. |
La differenza essenziale è il significato. La stessa Category di origine può svolgere più funzioni. La pianificazione Shopify Plus deve preservare le funzioni che servono dopo il lancio, non soltanto i nomi delle Categories.
Le Companies B2B non sono normali Customers
Il B2B è una delle differenze più importanti del modello dati Shopify Plus. In una normale migrazione Shopify, i record Customer rappresentano in genere profili di acquirenti con informazioni di contatto e storico Orders. In Shopify Plus B2B, un acquirente aziendale può dover esistere all’interno di una struttura Company. La Company è l’organizzazione principale; le Company Locations contengono il contesto di acquisto specifico della location, come indirizzi, informazioni fiscali, cataloghi, termini di pagamento e contatti assegnati. Un profilo Customer può essere collegato a una o più Company Locations, quindi identità dell’acquirente e contesto dell’account aziendale non devono essere appiattiti in un singolo tag Customer.
Una piattaforma di origine può rappresentare il B2B in molti modi: gruppi Customer, account aziendali, flussi di preventivo, gerarchie account, cataloghi contrattuali, shared catalogs, acquirenti esenti da imposta, relazioni con rappresentanti commerciali, ID account ERP, autorizzazioni di approvazione o campi personalizzati. Questi elementi non devono essere migrati automaticamente come normali tag o note Customer se questo non corrisponde al significato previsto nella destinazione.
| Struttura B2B di origine | Domanda per la destinazione Shopify Plus |
|---|---|
| Gruppo Customer | È un segmento, un attributo Company, un contesto di prezzo, una regola di catalogo o un’etichetta storica? |
| Account aziendale | Deve diventare una Company Shopify B2B con Company Locations oppure usare un’altra struttura account definita? |
| Ruolo o autorizzazione dell’acquirente | Quale contatto Customer appartiene a quale Company Location e quale ruolo di acquisto deve restare? |
| Prezzi contrattuali | I prezzi sono gestiti da cataloghi B2B, prezzi di un’app o da un sistema esterno? |
| Identificatore account ERP | Deve usare Company ID, Company Location ID, un metafield o un riferimento di proprietà dell’integrazione? |
| Flusso di preventivo o approvazione | Si tratta di configurazione lato Shopify, flusso di app o comportamento di origine non supportato? |
Questa separazione evita un errore importante: considerare i record Customer come migrati mentre viene persa l’architettura commerciale che li rendeva utilizzabili per la vendita B2B.
Markets, localizzazione e strutture multi-store
Le aziende che adottano Shopify Plus migrano spesso da piattaforme con siti, store view, lingue, regioni, brand, domini o cataloghi specifici per mercato. Queste strutture di origine devono essere interpretate rispetto all’architettura Shopify Plus prevista: un unico store con Markets, più store, expansion store, configurazione di localizzazione, cataloghi B2B o una combinazione di questi elementi. La decisione deve essere guidata da governance, proprietà dei dati, catalogo, prezzi, evasione degli ordini, contenuti, vincoli legali e strategia regionale del brand.
Una store view di origine non equivale necessariamente a un Market Shopify. Un dominio regionale può non richiedere uno store Shopify Plus separato. Una versione linguistica può appartenere alla configurazione di traduzione/localizzazione anziché a un albero di contenuti migrato separatamente. Un sito di origine può rappresentare un brand, una geografia, un canale o una vecchia scelta implementativa che non dovrebbe essere copiata meccanicamente.
| Struttura di origine | Possibile interpretazione in Shopify Plus |
|---|---|
| Store view o vista linguistica | Configurazione di localizzazione e traduzione, oppure vetrina separata se la governance lo richiede. |
| Dominio specifico per paese | Market, strategia dei domini, piano di redirect o decisione sugli expansion store. |
| Catalogo regionale | Regole di disponibilità Product, configurazione Markets, catalogo B2B, logica di app o store separato. |
| Sito multi-brand di origine | Expansion store, store separato, collezioni o architettura di contenuti specifica per brand. |
| CMS Pages localizzate | Pagine, Blog Posts, traduzioni, metaobject, redirect o ricostruzione manuale dei contenuti. |
| Prezzi regionali | Prezzi Markets, prezzi cataloghi B2B, configurazione di app o logica di sistema esterno. |
La domanda sul modello dati non riguarda quindi soltanto dove finiscono i record. Riguarda quale struttura operativa di destinazione devono supportare i record migrati.
Metafield, metaobject e governance dei dati personalizzati
Metafield e metaobject sono strumenti importanti nelle migrazioni Shopify Plus, ma non devono diventare un contenitore generico per ogni campo di origine. I metafield estendono risorse Shopify esistenti come Products, Customers, varianti, Orders o altri oggetti. I metaobject creano oggetti strutturati con più campi che possono essere referenziati dai metafield, usati nei temi oppure gestiti come voci di contenuto o dati.
Per Shopify Plus, la pianificazione dei dati personalizzati deve essere più disciplinata perché le piattaforme enterprise di origine contengono spesso grandi quantità di attributi, specifiche, campi personalizzati, ID ERP, indicatori di mercato, etichette B2B, contenuti di merchandising e record di proprietà delle app. Alcuni campi sono utili per contenuti rivolti ai Customers. Alcuni servono alle integrazioni. Alcuni sono storici. Alcuni sono obsoleti. Alcuni richiedono definizioni dei campi, regole sui dati o configurazione del tema. Altri non dovrebbero essere migrati affatto.
| Tipo di dato personalizzato | Possibile percorso di gestione |
|---|---|
| Specifiche Product | Metafield Product, metafield Category, metaobject o dati di app. |
| Blocchi di contenuto ricchi e riutilizzabili | Metaobject, pagine, Blog Posts, sezioni del tema o ricostruzione manuale dei contenuti. |
| Identificatori ERP/CRM/PIM | Metafield, campi di proprietà dell’app, ID esterno nativo o riferimento di integrazione. |
| Contesto account B2B | Configurazione Company e Company Location, metafield Customer o dati di proprietà dell’app. |
| Dati di estensioni della piattaforma di origine | Migrazione tramite applicazione, mappatura dell’integrazione, archivio o riprogettazione quando non esiste una destinazione nativa. |
| Campi storici di reportistica | Esclusione, archivio, metafield o decisione di reportistica esterna. |
Il miglior modello dati Shopify Plus non è quello con il maggior numero di campi personalizzati migrati. È quello in cui ogni campo personalizzato ha un responsabile di destinazione, un funzionamento di visualizzazione, una regola di qualità dei dati e uno scopo aziendale definiti.
Orders, pagamenti, evasione e contesto dei flussi di lavoro
La migrazione degli Orders verso Shopify Plus deve preservare il significato storico senza implicare che ogni flusso di origine venga ricreato. Gli Orders di origine possono includere etichette di pagamento, metodi di spedizione, sconti, contesto fiscale, stati di evasione, spedizioni parziali, rimborsi, preventivi, fatture, riferimenti a ordini di acquisto, ID ERP o dati dei rappresentanti commerciali. Parte di questo contesto può essere leggibile come informazione storica dell’Order. Un’altra parte può appartenere alla configurazione Shopify, a configurazione di app, a integrazioni esterne o a un flusso di destinazione riprogettato.
Questa distinzione è ancora più importante per le aziende che utilizzano Plus perché gli Orders storici possono supportare assistenza Customer, revisione degli account B2B, riordino B2B, riconciliazione finanziaria, corrispondenza ERP e analisi dell’evasione. Tuttavia, lo storico Orders migrato non configura checkout Shopify attivo, processori di pagamento, logica fiscale, instradamento dell’evasione, flussi di purchase order o termini di pagamento B2B.
| Contesto Order di origine | Interpretazione nella migrazione Shopify Plus |
|---|---|
| Riferimento di pagamento | Contesto storico, non configurazione del pagamento attivo. |
| Metodo di evasione | Leggibilità storica più revisione della configurazione di evasione nella destinazione. |
| Rimborso o annullamento | Contesto storico per supporto e riconciliazione. |
| Numero purchase order | Contesto Order B2B, metafield o dato di app, oppure riferimento a sistema esterno. |
| ID Order ERP | ID esterno nativo, metafield, campo di app o riferimento di integrazione. |
| Storico di preventivi o approvazioni | Nota storica, flusso di app, configurazione B2B o comportamento personalizzato non supportato. |
Una migrazione Shopify Plus affidabile deve rendere utile lo storico Orders senza confondere la storia con la configurazione operativa attiva.
App, integrazioni e dati dei sistemi esterni
Le aziende che utilizzano Shopify Plus dipendono spesso da ERP, PIM, OMS, CRM, sistemi di abbonamento, fidelizzazione, recensioni, imposte, spedizioni, frodi, strumenti di analisi, marketplace, personalizzazione e automazione. Alcuni valori di origine sono dati commerce nativi; altri appartengono a tali sistemi e compaiono nella piattaforma di origine solo perché un’estensione o un’integrazione li ha copiati lì.
La decisione di traduzione dei dati deve identificare il sistema di record che continuerà a essere autorevole. Un PIM può restare responsabile dell’arricchimento. Un ERP può continuare a possedere account, SKU, inventario o identificatori Order. Una piattaforma di abbonamenti può essere responsabile di contratti e calendari di fatturazione. Un’app fidelizzazione può possedere saldi e storico dei livelli. Copiare questi dati in Shopify Plus non trasferisce la responsabilità né ricrea il flusso operativo.
| Dipendenza | Domanda sul modello dati |
|---|---|
| ERP | Quali identificatori Product, Customer, Company, Company Location, Order e inventario devono restare stabili? |
| PIM | Quali attributi diventano campi Shopify, metafield o metaobject e quali restano di proprietà del PIM? |
| OMS o sistema di evasione | Quali valori Order ed evasione sono contesto storico e quali restano operativi nel sistema collegato? |
| CRM | Quali campi Customer appartengono a Shopify Plus e quali restano dati relazionali nel CRM? |
| Applicazione di abbonamento | Quali record e identificatori devono essere trasferiti tramite l’applicazione invece di essere rappresentati come normali Orders? |
| Applicazione fidelizzazione o recensioni | Quali saldi, membership, recensioni e chiavi cross-system hanno una destinazione supportata? |
Un valore critico per il business non dovrebbe essere trasferito soltanto perché esiste un campo disponibile. Deve avere un responsabile nominato, un identificatore stabile, una rappresentazione Shopify Plus definita quando necessaria e un utilizzatore che continuerà a consumarlo. Quando queste condizioni mancano, può essere preferibile archiviare il valore, riprogettare il flusso o mantenerlo nel sistema esterno anziché creare un’altra copia non governata.
Conclusione
Le differenze del modello dati Shopify Plus non riguardano soltanto i campi Shopify. Riguardano il significato enterprise associato ai dati Shopify. Products, varianti, collezioni, Customers, Orders, pagine, Blog Posts, redirect, metafield, metaobject, app e strutture a livello di organizzazione devono essere interpretati attraverso B2B, Markets, governance multi-store, integrazioni esterne e responsabilità operative.
Un modello dati Shopify Plus coerente distingue i normali dati Shopify dalle strutture operative a livello Plus. Identifica che cosa deve essere migrato, che cosa deve essere configurato in Shopify Plus, che cosa appartiene ad app o integrazioni, che cosa richiede mappatura diretta o ristrutturazione dei dati e che cosa appartiene all’implementazione di applicazioni o integrazioni. Questa distinzione evita che lo store di destinazione diventi una copia superficiale della piattaforma di origine anziché un ambiente Shopify enterprise realmente utilizzabile.
Domande frequenti
Le differenze del modello dati Shopify Plus sono separate da quelle di Shopify?
Sono correlate, non separate. Shopify Plus utilizza la base dati di Shopify, ma le migrazioni Plus associano normalmente un maggiore significato enterprise agli stessi record attraverso B2B, Markets, più store, dati personalizzati, integrazioni, autorizzazioni e governance dei flussi di lavoro.
I gruppi Customer B2B della piattaforma di origine dovrebbero diventare tag Customer Shopify?
Non automaticamente. Un gruppo Customer di origine può rappresentare prezzi, struttura aziendale, accesso dell’acquirente, stato fiscale, segmentazione o un’etichetta storica. Il significato di destinazione deve essere valutato prima di decidere se appartenga a Companies B2B, cataloghi, segmenti Customer, metafield, app o a una decisione esplicita sui dati di destinazione.
I metafield possono risolvere ogni requisito di dati personalizzati Shopify Plus?
No. I metafield estendono una risorsa Shopify esistente; i metaobject modellano record strutturati riutilizzabili. Nessuno dei due ricrea un flusso applicativo, una relazione ERP, un modello di autorizzazioni B2B o un sistema esterno autorevole. Devono essere usati soltanto quando responsabile e utilizzatore del dato nella destinazione sono definiti.
Come devono essere interpretati i dati multi-store di origine per Shopify Plus?
Devono essere mappati rispetto alla struttura operativa di destinazione prevista. Possono diventare un singolo store Shopify Plus con Markets, più store, expansion store, contenuti localizzati, cataloghi B2B oppure una combinazione di configurazione lato destinazione e ambito della migrazione.
Quali relazioni Shopify Plus richiedono la traduzione più attenta?
Companies B2B e Company Locations, responsabilità per market o store, contesto di cataloghi e prezzi e identificatori dei sistemi esterni richiedono la mappatura relazionale più chiara. Ogni record può esistere in Shopify Plus pur restando associato all’acquirente, location, vetrina, catalogo o sistema di record sbagliato.
Come devono essere preservate le relazioni tra Company e location B2B in Shopify Plus?
Una Company, le sue locations, gli acquirenti assegnati, i cataloghi, i termini di pagamento, il contesto fiscale e gli ID account esterni devono essere trattati come record correlati anziché come tag Customer. La mappatura deve mantenere ogni acquirente collegato alla location di acquisto corretta e preservare gli identificatori richiesti dai sistemi back-office che continueranno a essere utilizzati.