Quando VTEX viene valutata come piattaforma di destinazione, la pianificazione del modello dati dovrebbe partire da una domanda di rappresentazione: quali record della sorgente diventeranno strutture e-commerce realmente utilizzabili in VTEX e quali, invece, appartengono a un altro dominio VTEX, all’implementazione dello storefront, a un’integrazione o a un sistema esterno? VTEX è un ambiente e-commerce modulare, quindi il significato dei dati è distribuito tra Catalog, SKUs, specifications, pricing, promotions, checkout, Orders, Logistics, seller, contesto marketplace, Master Data, search, implementazione storefront e sistemi esterni.
Questo rende VTEX diversa dalle piattaforme in cui Products, Customers, Orders, pagine e URL possono essere esaminati principalmente come record isolati. Un’opzione Product della sorgente può diventare uno SKU, una specification, una scelta nello storefront, un custom field oppure un requisito da ricostruire. Un campo Customer della sorgente può essere una normale informazione di profilo, un dato Master Data, un’informazione B2B, un’identità gestita dal CRM o metadata di integrazione. Un Order della sorgente può conservare valore per l’assistenza, ma non configura automaticamente checkout, pagamenti, evasione, marketplace o Logistics in VTEX.
Il perimetro di migrazione VTEX più solido non è quello che trasferisce più dati. È quello che conserva il significato utile dei record separando chiaramente dati migrati, configurazione VTEX, implementazione frontend, responsabilità delle integrazioni, mappatura strutturata o gestione dedicata nel target, nonché requisiti che richiedono una ristrutturazione specifica.
Il significato dei dati VTEX è distribuito tra più servizi e-commerce
I dati VTEX devono essere interpretati in base al dominio della piattaforma che li possiederà dopo la migrazione. I dati del Catalog possono influenzare visualizzazione Products, ricerca, pricing, promotions, disponibilità SKU, Logistics e funzionamento marketplace. Lo storico Orders può essere importante per assistenza e reportistica, mentre l’elaborazione degli ordini attivi dipende da checkout, pagamenti, evasione, Logistics e configurazione operativa. I dati Customers possono apparire semplici all’inizio, ma Master Data, segmentazione, contesto B2B, identificativi CRM o moduli personalizzati introducono decisioni separate.
Questo modello distribuito cambia il modo in cui va esaminata la migrazione. Un campo che nella sorgente sembrava un comune attributo Product può diventare una specification in VTEX. Una variante sorgente può richiedere struttura a livello SKU. Un prezzo specifico per canale può appartenere a regole o tabelle di pricing anziché al record Product. Un riferimento a un seller marketplace potrebbe non essere normale dato di catalogo. Una pagina contenuto può richiedere implementazione nello storefront o pianificazione di redirect anziché una migrazione diretta uno-a-uno.
| Record o funzione nella sorgente | Domanda di interpretazione in VTEX | Implicazione per la migrazione |
|---|---|---|
| Opzione o variante Product | Definisce uno SKU vendibile, una Product specification o una scelta dello storefront? | La relazione Product-SKU-specification deve essere esplicita nel perimetro. |
| Attributo o custom field | Serve a filtraggio, dettaglio Product, operations, integrazione o processo Customer? | La mappatura dipende dall’uso aziendale, non soltanto dalla somiglianza dei nomi dei campi. |
| Prezzo o promotion di canale | È un prezzo base, una price table, una condizione del canale di vendita, un coupon o una regola promotion attiva? | Il comportamento commerciale va separato dallo storico dei prezzi. |
| Campo Customer aggiuntivo | È dato di profilo, Master Data, contesto B2B, metadata CRM o informazione posseduta da un’integrazione? | Alcuni valori possono richiedere mappatura o filtering delimitati, una ristrutturazione specifica oppure gestione tramite sistema esterno. |
| Stato Order o nota di evasione | È contesto storico utile all’assistenza oppure comportamento OMS/Logistics attivo? | La migrazione Orders non deve essere trattata come configurazione dei processi di destinazione. |
VTEX richiede quindi una mappatura guidata dal significato. Ogni area dati deve avere uno scopo futuro e un responsabile dichiarati; questa responsabilità determina se un campo appartiene ai record migrati, alla configurazione VTEX, all’implementazione dello storefront, ai dati d’integrazione, a un modello di destinazione ristrutturato oppure a un’esclusione intenzionale.
La rappresentazione del Catalog parte dalle relazioni tra Category, Brand, Product, SKU e specification
Il Catalog VTEX non è una tabella Product piatta. La struttura di base collega Categories, Brands, Products, SKUs e specifications. Un Product rappresenta la definizione commerciale generale, mentre ciascuno SKU rappresenta la variante o unità fisica acquistabile e gestibile a stock. I gruppi di specifications collegati alle Categories definiscono quali proprietà Product e SKU si applicano e possono essere ereditati lungo i livelli delle Categories.
| Struttura sorgente | Interpretazione VTEX | Conseguenza sulla relazione |
|---|---|---|
| Parent Product con varianti figlie | Product con uno o più SKUs | Identità vendibile, immagini, inventario e righe Order appartengono al livello SKU quando appropriato. |
| Attributo Product | Product specification | Conservare il significato di campo e valore collegato alla Category invece di copiare semplice testo libero. |
| Attributo di variante, per esempio taglia o voltaggio | SKU specification | Mantenerlo associato allo SKU che rappresenta la variazione fisica. |
| Brand o produttore | Relazione Brand | Non appiattire il valore quando navigazione o scoperta dipendono dall’entità Brand. |
| Albero Categories | Classificazione Catalog | Il posizionamento nelle Categories determina ereditarietà delle specifications e organizzazione dei Products. |
| Insieme di immagini Product | Relazione media dello SKU | VTEX collega disponibilità vendibile e immagini agli SKUs attivi. |
| Bundle, kit o assembly configurabile | Kit, attachment, assembly option, service o logica esterna | Stabilire quale struttura VTEX possiede realmente la relazione tra componenti e pricing. |
Una migrazione può conservare tutti i nomi Product della sorgente e produrre comunque un Catalog VTEX debole se SKUs, specifications, immagini, Categories e Brands non descrivono più lo stesso articolo vendibile.
Specifications, attachments e assembly options conservano significati diversi
Le specifications VTEX sono proprietà strutturate associate alle Categories e applicate a Products o SKUs. Possono supportare navigazione, confronto, selezione, integrazioni o visualizzazione. La loro funzione è quindi importante quanto il valore. Un campo “colore” usato per il filtraggio non equivale automaticamente a una nota colore in testo libero; una taglia che distingue gli SKUs non è la stessa cosa di una specifica dimensionale del Product.
VTEX separa inoltre le specifications dalle strutture di personalizzazione Product opzionali. Gli attachments possono raccogliere informazioni legate a uno SKU. Le assembly options possono rappresentare combinazioni più complesse, quantità, articoli aggiuntivi, costi e relazioni di inventario. I kit raggruppano SKUs venduti insieme, mentre servizi aggiuntivi a pagamento possono essere rappresentati attraverso relazioni di service dello SKU. Questi concetti non dovrebbero essere compressi in un’unica colonna generica “option”.
| Significato nella sorgente | Concetto di destinazione VTEX | Distinzione principale |
|---|---|---|
| Caratteristica descrittiva | Product specification | Descrive il Product generico. |
| Caratteristica che definisce una variante | SKU specification | Distingue l’unità vendibile. |
| Informazione fornita dal cliente | Attachment | Aggiunge informazioni a uno SKU senza creare necessariamente un altro SKU. |
| Componente o combinazione configurabile | Assembly option | Rappresenta articoli aggiuntivi, quantità, costi o relazioni di inventario. |
| Gruppo di unità vendibili | Kit | Conserva una composizione di SKUs venduti insieme. |
| Servizio aggiuntivo a pagamento associato all’articolo | Relazione service dello SKU | Mantiene il servizio separato dall’identità dello SKU base. |
Il modello di destinazione deve preservare la struttura che determina identità Product, scelta del cliente, inventario e interpretazione delle righe Order, non limitarsi a conservare etichette e valori.
Pricing, Promotions, trade policy e offerte costituiscono livelli commerciali distinti
Un export della sorgente può collocare prezzo, prezzo promozionale, canale, marketplace e valori di disponibilità accanto al record Product. VTEX separa questi significati tra Catalog, Pricing, Promotions, trade policy, Logistics, inventario e offerte seller. Lo stesso SKU può quindi partecipare a contesti commerciali differenti senza diventare più Products.
| Record commerciale | Significato in VTEX | Conseguenza sulla responsabilità |
|---|---|---|
| Prezzo base o di listino | Relazione Pricing per uno SKU | Il prezzo non è un attributo Product permanente. |
| Risultato promotion o coupon | Adeguamento commerciale governato da regole | L’evidenza storica dello sconto negli Orders è separata dalle regole promotion attive. |
| Trade policy | Contesto del canale di vendita | Determina dove Products o SKUs sono disponibili e può collegare condizioni commerciali. |
| Inventario e Logistics | Disponibilità e promessa di evasione | Stock e significato della consegna sono gestiti fuori dal record descrittivo del Catalog. |
| Offerta seller | Offerta commerciale di un seller per un articolo del Catalog | Identità marketplace e proprietà seller restano distinte dalla definizione Product. |
| Assortimento specifico per canale | Disponibilità Product per trade policy o seller | Conservare la relazione invece di duplicare il Product. |
Questo modello a livelli è particolarmente importante quando lo Store sorgente utilizza cataloghi regionali, listini B2B, offerte marketplace o pricing governato da ERP. La migrazione deve conservare gli identificativi che collegano lo SKU ai record di prezzo, canale, seller, inventario e Logistics.
Customers, record B2B e Master Data richiedono identità esplicite
I dati collegati ai Customers in VTEX possono comprendere profili degli acquirenti, indirizzi, strutture organizzative B2B, identificativi CRM, consensi, moduli personalizzati e documenti Master Data. Master Data è un database nativo key-document progettato per archiviare, ricercare, ampliare e personalizzare dati; un record personalizzato può quindi rappresentare un oggetto operativo autonomo anziché un semplice campo Customer aggiuntivo.
| Record sorgente | Possibile responsabile in VTEX | Domanda sull’identità |
|---|---|---|
| Profilo acquirente | Customer o dati profilo | Quale email, documento o chiave esterna identifica la persona? |
| Indirizzo | Record indirizzo collegato al Customer | È dato account riutilizzabile, snapshot di un Order o entrambi? |
| Azienda, organizzazione, ruolo buyer o cost center | Dominio B2B o modello dati personalizzato | Quali relazioni controllano accesso, approvazione, Catalog o contesto di prezzo? |
| Valore loyalty, CRM o qualifica | Master Data o CRM esterno | Quale sistema lo aggiorna e quale chiave lo collega al Customer? |
| Invio di un modulo personalizzato | Documento Master Data | È un attributo Customer, un record di processo o un’entità indipendente? |
| Consenso marketing | Relazione Customer o sistema marketing | Conservare finalità, timestamp, origine e significato legale quando richiesto. |
Una gestione rigorosa dell’identità impedisce che persone, aziende, indirizzi e record di processo non correlati vengano appiattiti in un unico profilo. Il modello di migrazione deve definire chiavi durevoli e cardinalità delle relazioni prima di scegliere i campi di destinazione.
Gli Orders conservano lo storico e-commerce attraverso domini operativi distinti
Uno storico Order VTEX può collegare identità Customer, seller, trade policy, righe SKU, prezzi, promotions, imposte, evidenza dei pagamenti, dati di spedizione, evasione, stato e riferimenti esterni. Queste relazioni spiegano la transazione passata. Non rendono la configurazione corrente di Checkout, Payments, OMS, Logistics, inventario, carrier o warehouse parte del record Order.
| Valore collegato all’Order | Significato storico | Dominio attivo separato |
|---|---|---|
| Riga SKU e seller | Che cosa è stato acquistato e da chi | Catalog corrente e offerte seller possono cambiare in seguito. |
| Prezzo e sconto | Snapshot commerciale | Regole Pricing e Promotions attive sono separate. |
| Riferimento transazione pagamento | Evidenza dell’elaborazione del pagamento | Configurazione live di gateway e antifrode è separata. |
| Metodo di spedizione, SLA e indirizzo | Promessa storica di consegna | Logistics, docks, warehouses, carrier e pickup point sono separati. |
| Stato e dati di evasione | Stato OMS passato | I nuovi Orders possono seguire un flusso operativo differente. |
| ID Order esterno | Tracciabilità tra sistemi | Conservarlo quando ERP, marketplace, assistenza clienti o reportistica lo utilizzano ancora. |
Il confine rilevante è il modello di relazione: quali valori storici rimangono associati all’Order e quali domini live possiedono il comportamento futuro.
Catalog marketplace, seller e offerte richiedono responsabilità separate
VTEX può operare come marketplace, come seller o come parte di una rete marketplace collegata. I dati marketplace comprendono quindi più di Products e Orders: possono includere identità seller, SKU seller, corrispondenze di Catalog, offerte, prezzi, inventario, commissioni, responsabilità di evasione, mappatura Product e Category e riferimenti a inserzioni esterne.
| Livello marketplace | Significato | Relazione da conservare |
|---|---|---|
| Product e SKU canonici | Identità condivisa del Catalog | Le offerte seller devono riferirsi all’articolo Catalog previsto. |
| Seller | Responsabile commerciale e operativo | Mantenere l’identità seller distinta da Brand, supplier o manufacturer. |
| Offerta | Prezzo, inventario e contesto di evasione specifici del seller | Non fondere tutte le offerte nella definizione Product. |
| Mappatura Catalog | Relazione tra strutture Product/Category esterne e VTEX | Conservare la chiave di mappatura se il connettore continua a operare. |
| Origine Order marketplace | Storico del canale e del seller | Conservare quando assistenza, settlement o reportistica ne dipendono. |
| Riferimento commissione o settlement | Contesto finanziario marketplace | Mantenerlo nel sistema responsabile del settlement invece di forzarlo nei normali campi Order. |
Una migrazione verso VTEX deve stabilire se ciascun record marketplace della sorgente diventa una relazione Catalog VTEX, un’offerta seller, un record del connettore esterno, un attributo storico Order o un oggetto conservato nel sistema esterno.
Storefront, CMS Pages, Blog Posts, Search e URL vanno separati dal trasferimento dei dati core
L’implementazione storefront VTEX può includere frontend headless, componenti CMS, comportamento di ricerca, merchandising, redirect e continuità SEO. Un Product può essere migrato in VTEX mentre l’esperienza storefront rimane incompleta. Una CMS Page può conservare valore editoriale senza avere una corrispondenza uno-a-uno con l’implementazione storefront di destinazione. I Blog Posts possono essere importanti per il traffico organico, ma il modo in cui vengono gestiti dipende dal perimetro e dalla configurazione della piattaforma.
Nella pianificazione del modello dati, record contenuto e URL devono essere valutati in base al ruolo aziendale, non soltanto al tipo di record. Un URL Category della sorgente può rappresentare un percorso Catalog, una landing page di ricerca, una pagina merchandising o una risorsa SEO. Una pagina contenuto può essere policy, guida all’acquisto, landing page di campagna o layout personalizzato. Una regola di ricerca può essere nativa della piattaforma, posseduta da un’app o specifica dell’implementazione.
| Risorsa sorgente | Domanda di pianificazione per VTEX |
|---|---|
| URL Product | Deve reindirizzare, restare equivalente o essere ricostruito attraverso il routing dello storefront? |
| Pagina Category o collection | È organizzazione del Catalog, navigazione, esperienza di ricerca, contenuto SEO o merchandising? |
| CMS Page | Deve essere migrata come contenuto, ricreata nello storefront, reindirizzata o dismessa? |
| Blog Post | Rientra nel perimetro di migrazione, nel perimetro SEO, nella strategia contenuti o in una decisione CMS separata? |
| Logica search/filter | Dipende da specifications, configurazione search, comportamento app o implementazione personalizzata? |
Questa separazione evita di considerare completi i record Catalog mentre restano irrisolte relazioni rivolte al cliente per scoperta, contenuti e URL.
Sistemi esterni e dati personalizzati determinano il vero confine della migrazione
Le migrazioni VTEX coinvolgono spesso ERP, CRM, PIM, OMS, WMS, middleware marketplace, provider di pagamento, sistemi loyalty, fiscali, analytics, strumenti di assistenza clienti e applicazioni storefront personalizzate. Questi sistemi possono possedere identificativi Product, prezzi, inventario, attributi Customers, riferimenti Orders, dati seller, informazioni di evasione o record personalizzati.
Il perimetro deve identificare la responsabilità dei sistemi. Se un ERP sovrascriverà un valore della sorgente, quel valore conta soltanto se serve come stato iniziale, riferimento storico o chiave di riconciliazione. Se un ID esterno deve continuare a collegare Orders, Customers o Products tra sistemi, conservarlo può essere essenziale. Se un record personalizzato supporta un processo che VTEX non rappresenta nativamente come dato e-commerce standard, può essere necessario una mappatura o una ristrutturazione dedicata.
| Tipo di dato esterno o personalizzato | Decisione di perimetro |
|---|---|
| ID Product o Order ERP | Conservare se necessario per riconciliazione o sincronizzazione. |
| Set di attributi PIM | Mappare soltanto i valori necessari a Catalog, specifications o search VTEX. |
| Identificativo Customer CRM | Conservare se i processi di assistenza clienti o marketing ne dipendono. |
| Riferimento WMS o evasione | Stabilire se appartiene allo storico, alla configurazione dell’integrazione o a una gestione personalizzata. |
| Dati app o middleware | Verificare il comportamento di migrazione supportato prima di presumere che possano essere trasferiti. |
Mappatura o filtering delimitati possono essere utili quando il requisito riguarda operazioni supportate di filtro, mappatura o configurazione. Una mappatura o una ristrutturazione specifica va invece considerata quando sono coinvolti dati non supportati, record personalizzati, trasformazioni bespoke, gestione di una piattaforma di origine personalizzata o adeguamenti della logica di migrazione oltre le funzionalità supportate.
I confini di responsabilità definiscono il perimetro della migrazione VTEX
Il perimetro VTEX è determinato da responsabilità e relazioni, non dal volume dei record. Un catalogo piccolo può essere strutturalmente complesso quando dipende da ereditarietà delle specifications, assembly options, più trade policy, seller, documenti Master Data o identificativi esterni. Un catalogo grande può essere relativamente lineare quando Products, SKUs, Categories, Brands e specifications seguono un modello coerente.
| Pattern sorgente | Domanda centrale | Conseguenza sul perimetro |
|---|---|---|
| Product con più varianti acquistabili | Quale oggetto sorgente diventa lo SKU VTEX? | Conservare parent Product, identità SKU, specifications, immagini e riferimenti inventario. |
| Assortimento regionale o B2B | Quale relazione tra trade policy, prezzo e accesso si applica? | Mantenere il contesto commerciale distinto dall’identità Product. |
| Tabelle Customers o di processo personalizzate | Il record è profilo, documento Master Data, entità B2B o oggetto di sistema esterno? | Modellare entità e relazione durevole invece di aggiungere campi Customer arbitrari. |
| Catalog marketplace | VTEX è marketplace, seller o entrambi? | Separare record Catalog canonici da offerte seller e chiavi di mappatura. |
| Contenuto storefront headless o personalizzato | Quale CMS, app o repository possiede il contenuto? | Non trattare l’implementazione storefront come normale dato Catalog. |
| Integrazione ERP/PIM/WMS/OMS | Quale sistema è autorevole per ciascun valore? | Conservare ID tra sistemi e regole di responsabilità senza duplicare modelli esterni. |
Questo confine mantiene coerente il modello VTEX tra domini Catalog, commerciali, Customers, marketplace, contenuti e operations.
Conclusione
VTEX distribuisce il significato e-commerce tra domini collegati. Categories, Brands, Products, SKUs e specifications formano il Catalog; Pricing, Promotions, trade policy, inventario, Logistics e offerte seller aggiungono contesto commerciale; record Customers e B2B possono estendersi in Master Data; Orders conservano relazioni storiche attraverso Checkout, Payments, OMS ed evasione; contenuti storefront e sistemi esterni mantengono responsabilità proprie.
Il modello di migrazione deve quindi preservare chiavi e relazioni invece di appiattire ogni valore in Products, Customers o Orders. Una responsabilità chiara tra i domini VTEX permette a un Product di restare trovabile, a uno SKU di restare vendibile, a un Order di restare comprensibile, a un’offerta seller di restare attribuibile e a un’integrazione esterna di continuare a riferirsi al record corretto.
Domande frequenti
Perché gli SKUs sono così importanti in una migrazione verso VTEX?
Gli SKUs spesso controllano varianti vendibili, prezzo, inventario, disponibilità, Logistics e scelte nello storefront. Se le opzioni Product della sorgente non vengono rappresentate in strutture SKU e specification utilizzabili in VTEX, i Products possono essere migrati senza soddisfare le esigenze commerciali o operative.
Tutti gli attributi sorgente diventano specifications VTEX?
No. Gli attributi della sorgente devono essere valutati in base alla funzione. Alcuni appartengono alle specifications, alcuni definiscono gli SKUs, altri appartengono a contenuti o integrazioni e altri ancora dovrebbero essere esclusi perché non supportano più il funzionamento previsto nel target.
Promotions e regole di prezzo della sorgente possono essere migrate come campi Product?
In genere no. Promotions, coupon, price table, condizioni per canale e logica di pricing esterna vanno esaminati separatamente dai prezzi Product di base. Alcuni valori possono essere migrati come riferimenti, mentre il comportamento commerciale attivo può richiedere configurazione VTEX o lavoro di integrazione.
Gli Orders storici equivalgono alla configurazione OMS di VTEX?
No. Gli Orders storici conservano, dove supportato, il contesto degli acquisti passati. L’elaborazione dei nuovi Orders dipende dalla configurazione corrente di Checkout, Payments, OMS, Logistics, inventario e seller.
Quando i dati VTEX richiedono un modello di entità separato?
Quando un record sorgente non può diventare record Catalog, Customer, Master Data, Order, CMS, seller o di sistema esterno senza perdere identità o relazioni. Prima di assegnare i singoli campi, occorre definire responsabile dell’entità, chiave e collegamenti.
In che modo trade policy e relazioni SKU influenzano la migrazione verso VTEX?
Il Product fornisce il significato descrittivo condiviso, mentre gli SKUs rappresentano le varianti vendibili e le trade policy possono cambiare assortimento, prezzo, Logistics o contesto commerciale. La mappatura deve preservare queste relazioni affinché un record non venga considerato completo solo perché esiste il contenitore Product.