Nel valutare VTEX come possibile piattaforma di destinazione, è utile partire dalla sua natura di piattaforma e-commerce cloud pensata per operazioni enterprise, estensibilità, più modelli di business e servizi commerciali collegati tra loro. La sua architettura comprende Catalog, Pricing, Promotions, Checkout, Orders, Logistics, Payments, Search, Master Data, funzionalità marketplace, funzioni B2B, sviluppo storefront e infrastruttura applicativa. Un’implementazione VTEX può operare come negozio con vendita diretta al consumatore, ambiente multi-brand, marketplace, seller collegato a marketplace esterni, canale B2B oppure combinare più di questi modelli.
Questa ampiezza distingue VTEX in modo sostanziale dalle piattaforme in cui il commercio è concentrato in un unico database di catalogo e in un solo storefront. La disponibilità di un Product può dipendere dall’attivazione dello SKU, dall’inventario, dal prezzo, dalla trade policy, dal rapporto con il seller, dalla logistica e dalla configurazione dello storefront. Un Product può esistere nel Catalog ma restare non disponibile perché uno di questi livelli collegati è incompleto. Un’offerta marketplace può comparire sotto un Product pur essendo di proprietà di un altro seller. Uno storefront headless può presentare i dati e-commerce di VTEX senza condividere lo stesso livello di implementazione dell’ambiente amministrativo.
Una migrazione verso VTEX, quindi, non consiste soltanto nel trasferire Products, Customers e Orders. Richiede di ricostruire relazioni commerciali distribuite tra servizi modulari. L’account di destinazione deve esprimere quali articoli esistono, quali SKU sono vendibili, chi li fornisce, dove si trova l’inventario, quali prezzi si applicano, quali canali possono venderli, come il checkout determina l’evasione e quale storefront o applicazione utilizza i dati risultanti.
VTEX come architettura e-commerce cloud
VTEX offre una piattaforma cloud gestita anziché un pacchetto applicativo ospitato e gestito autonomamente. I servizi principali, l’infrastruttura della piattaforma e le API e-commerce operano nell’ambiente VTEX, mentre aziende e partner di implementazione configurano le regole di business, integrano sistemi esterni, costruiscono gli storefront ed estendono le funzionalità attraverso i modelli applicativi e API supportati.
La piattaforma è volutamente modulare. I record del Catalog non determinano da soli l’esperienza del cliente. Pricing, promotions, inventario, logistica, seller, trade policy, checkout, ricerca e rendering dello storefront contribuiscono ciascuno a una parte distinta del risultato finale. Questa modularità supporta la scala enterprise e più modelli operativi, ma aumenta anche la dipendenza dalla correttezza delle relazioni tra i diversi servizi.
| Livello VTEX | Funzione principale | Implicazione per la migrazione |
|---|---|---|
| Catalog | Categories, brand, Products, SKUs, specifications, immagini, attachments, servizi, kit e collections | I concetti del catalogo sorgente devono essere rappresentati nella gerarchia Product-SKU di VTEX e nel modello di specifications collegato alle Categories. |
| Pricing e Promotions | Valori commerciali e regole promozionali | Il record di un Product non determina tutti i prezzi di vendita o gli esiti delle promotions. |
| Logistics | Inventario, docks, warehouses, shipping policies ed evasione | La disponibilità dello SKU dipende da configurazioni operative esterne al record Product. |
| Sellers e Marketplace | Proprietà delle offerte e relazioni marketplace | Il gestore del marketplace può possedere il Catalog mentre un altro seller possiede prezzo, inventario e condizioni di evasione. |
| Checkout e Orders | Orchestrazione della transazione e gestione dello storico Orders | Il comportamento degli acquisti attivi dipende dalla configurazione corrente e dalle integrazioni, non soltanto dallo storico Orders migrato. |
| Storefront e applicazioni | Esperienza rivolta al cliente ed estensioni | I dati e-commerce possono essere presentati attraverso diverse architetture storefront e applicazioni personalizzate. |
La documentazione generale di VTEX pone l’accento su infrastruttura cloud, sicurezza, privacy dei dati, componibilità, estensibilità, architettura dello store ed esperienza per gli sviluppatori. Questi aspetti non sono marginali: determinano come viene governato l’ambiente di destinazione e quali team sono responsabili dei diversi livelli del progetto di migrazione.
Architettura del Catalog: Categories, Products e SKUs
Il Catalog di VTEX parte da Categories e brand, quindi definisce Products e SKUs. Un Product rappresenta la definizione commerciale generale di un articolo, mentre uno SKU è la variante specifica acquistabile, associata allo stock e selezionata dal cliente. Ogni Product appartiene a una Category e a un brand, e ogni Product deve avere almeno uno SKU.
Anche le specifications hanno un ruolo strutturale. VTEX associa gruppi di specifications alle Categories e tali gruppi possono essere ereditati dai livelli inferiori della gerarchia. Le product specifications descrivono caratteristiche a livello Product, mentre le SKU specifications distinguono le varianti acquistabili. Per questo gli attributi della piattaforma sorgente non possono essere mappati in modo affidabile senza stabilire se classificano il Product, definiscono uno SKU, supportano il filtraggio oppure hanno una funzione puramente descrittiva.
| Concetto nella piattaforma sorgente | Possibile destinazione in VTEX | Domanda interpretativa principale |
|---|---|---|
| Parent Product | Product | Il parent sorgente rappresenta un articolo generale oppure è soltanto un contenitore di raggruppamento? |
| Variante | SKU | Ogni variante sorgente corrisponde a un’unità acquistabile e gestita separatamente a stock? |
| Attributo | Product specification o SKU specification | Il valore descrive il Product nel suo complesso oppure distingue uno SKU acquistabile? |
| Opzione o personalizzazione | Attachment, assembly option, service o struttura SKU | La scelta modifica identità di inventario, prezzo, quantità o informazioni fornite dal cliente? |
| Bundle | Kit o struttura collegata all’assembly | I componenti sono fissi, opzionali, gestiti a inventario o prezzati separatamente? |
| Collection | Collection o struttura merchandising dello storefront | Il raggruppamento è tassonomico, promozionale, stagionale o solo di presentazione? |
In VTEX non basta creare i record Product e SKU. Categories, brand, gruppi di specifications, specifications, immagini, attivazione SKU, prezzo, inventario e disponibilità per canale devono lavorare insieme prima che un articolo sia realmente vendibile. Questo spiega perché un semplice confronto del numero di record può sovrastimare la completezza della migrazione. L’unità significativa è una relazione commerciale attiva, non una riga Product isolata.
Attachments, assembly options, services e kit estendono ulteriormente il modello Product. Gli attachments possono raccogliere informazioni opzionali associate a uno SKU. Le assembly options supportano combinazioni più complesse, quantità, articoli aggiuntivi, costi e relazioni di inventario. I services possono rappresentare servizi aggiuntivi a pagamento, come confezioni regalo o garanzie. I kit raggruppano SKUs venduti insieme. Ciascuna struttura ha un significato operativo diverso e non dovrebbe essere appiattita in un unico campo generico per le opzioni.
Trade policy, account e contesto dei canali
VTEX utilizza le trade policy per definire il contesto commerciale tra canali. Una trade policy può influenzare la disponibilità dei Products e altre condizioni di vendita per un determinato canale o una specifica operazione. Gli account enterprise possono inoltre contenere più store, brand, paesi, business unit o storefront con cataloghi sovrapposti ma comportamenti non identici.
Questo modello sensibile al canale è importante durante la migrazione perché le piattaforme sorgente spesso codificano differenze di mercato o di canale in forme meno esplicite. Una piattaforma può utilizzare siti separati, listini, gruppi Customers, warehouse, sottodomini o custom fields per rappresentare ciò che VTEX esprime tramite trade policy e configurazione dell’account. Il progetto di destinazione deve stabilire se tali differenze sorgente debbano restare separate, essere consolidate oppure diventare configurazioni specifiche per canale.
Un Product attivo in una trade policy potrebbe non essere destinato a un’altra. Anche prezzi, logistica, seller, promotions e comportamento del checkout possono variare in base al contesto commerciale. Migrare un unico record Product globale senza conservare queste differenze può causare esposizione eccessiva, assortimento mancante o comportamenti commerciali errati.
Sellers, marketplace e proprietà delle offerte
VTEX supporta sia il modello marketplace sia il modello seller. Un account VTEX può agire come marketplace che riceve offerte da seller esterni, oppure come seller il cui catalogo e le cui offerte vengono distribuiti a marketplace esterni. L’integrazione del Catalog può quindi coinvolgere molto più della proprietà del Product.
Nel contesto marketplace, il marketplace può possedere la presentazione condivisa del Product mentre i seller possiedono le offerte, inclusi prezzo, inventario, condizioni di evasione e identificativi specifici del seller. Le corrispondenze tra Products e Categories possono collegare tassonomie di catalogo differenti tra relazioni marketplace. Lo stesso Product può avere più offerte seller, ciascuna con la propria disponibilità commerciale.
| Elemento marketplace | Significato operativo | Implicazione per la migrazione |
|---|---|---|
| Product | Identità condivisa del catalogo e informazioni di merchandising | Le inserzioni duplicate nella sorgente possono dover essere consolidate attorno a una sola identità Product di destinazione. |
| SKU | Variante Product acquistabile | Le offerte dei seller devono puntare allo SKU corretto invece di creare articoli scollegati. |
| Seller | Organizzazione responsabile di un’offerta | Identità, autorizzazioni e responsabilità operative del seller non sono normali dati Customer. |
| Offerta | Contesto specifico del seller per prezzo, inventario ed evasione | I record delle offerte non possono essere ridotti ai soli prezzi Product. |
| Corrispondenza | Relazione tra Categories o Products esterni e VTEX | La traduzione di tassonomie e identificativi deve restare governata. |
| Flusso Orders | Orchestrazione delle transazioni marketplace-seller | Lo storico Orders e il routing marketplace attivo appartengono a livelli distinti. |
Questo modello operativo distingue nettamente VTEX da una piattaforma gestita da un unico venditore. Una migrazione che ignora le relazioni tra seller e offerte può conservare Products visibili ma perdere la struttura di responsabilità che consente al marketplace di funzionare.
Pricing, inventario, Logistics e vendibilità
VTEX separa l’identità di base del Catalog dai servizi che rendono commercialmente disponibile uno SKU. I prezzi vengono gestiti attraverso strutture di pricing. L’inventario è associato alla logistica e alle sedi di evasione. Shipping policies, docks, warehouses, carrier e condizioni di consegna influenzano la capacità del checkout di determinare un’opzione di evasione valida. Le promotions possono modificare gli esiti commerciali indipendentemente dal prezzo base.
Il risultato è una definizione stratificata della vendibilità. Uno SKU può esistere, avere immagini e specifications, ma restare non disponibile perché non dispone di un prezzo valido, inventario, una trade policy applicabile, un’offerta seller o un percorso di evasione. Al contrario, lo stesso SKU può essere vendibile con prezzi o condizioni logistiche diverse a seconda del canale.
Le piattaforme sorgente spesso comprimono questi livelli in un numero inferiore di campi. Una tabella Product può contenere sia stock sia prezzo. Un’estensione warehouse può conservare i dettagli delle sedi. Un modulo di shipping può calcolare la consegna in modo indipendente. VTEX richiede che questi concetti vengano collocati nei servizi che ne hanno la responsabilità. La migrazione deve quindi preservare la relazione tra identità dell’articolo ed esecuzione commerciale.
Customers, Master Data, Checkout e Orders
L’identità Customer in VTEX può coinvolgere record account, indirizzi, profili, informazioni organizzative, consensi, custom fields e dati archiviati tramite Master Data o sistemi Customer collegati. Le implementazioni B2B possono aggiungere organizzazioni, cost center, ruoli, autorizzazioni, contesti di prezzo e processi di approvazione. Queste strutture non equivalgono a un semplice elenco di utenti registrati.
Il Checkout orchestra il processo di acquisto attivo tra articoli, seller, prezzi, inventario, logistica, pagamenti, promotions e contesto Customer. Gli Orders registrano il risultato delle transazioni concluse e ne supportano l’elaborazione operativa. Lo storico Orders può conservare informazioni preziose per assistenza clienti e reportistica, ma non stabilisce il comportamento del checkout attivo nell’account di destinazione.
Questa distinzione è importante perché una migrazione può trasferire correttamente nomi Customers, indirizzi e totali Orders lasciando però incomplete autorizzazioni organizzative, dati profilo personalizzati, configurazione dei pagamenti, logistica, routing marketplace o integrazioni checkout. La modularità di VTEX rende espliciti questi confini.
Modelli storefront, VTEX IO e componibilità
VTEX supporta diversi approcci allo storefront e alle applicazioni. VTEX IO offre un ambiente cloud per sviluppo e applicazioni, mentre Store Framework e altre opzioni storefront possono utilizzare i servizi e-commerce di VTEX. Le implementazioni headless possono impiegare frontend personalizzati che interagiscono con le API e i servizi della piattaforma.
Uno storefront, quindi, non è semplicemente un tema collegato ai Products migrati. È un livello di implementazione che determina navigazione, presentazione dei Products, ricerca, contenuti, esperienza account, analytics e integrazione con il checkout. Temi, template, widget e script della piattaforma sorgente non diventano automaticamente componenti storefront VTEX.
Componibilità ed estensibilità permettono ai team di aggiungere applicazioni e integrazioni senza modificare il core di un’applicazione self-hosted. Questa flessibilità architetturale distribuisce però la responsabilità tra configurazione della piattaforma, applicazioni, sistemi esterni e codice frontend. Una panoramica della migrazione deve quindi riconoscere che la preparazione dello storefront e la preparazione dei dati sono collegate, ma restano due ambiti distinti.
Integrazioni e responsabilità dei sistemi enterprise
VTEX opera spesso insieme a ERP, PIM, OMS, WMS, CRM, marketplace, sistemi fiscali, pagamenti, ricerca e analytics. La documentazione del Catalog descrive esplicitamente flussi di integrazione con sistemi back-office per creare e aggiornare i dati del Catalog. In molte implementazioni VTEX non è l’unico sistema autorevole per Products, prezzi, inventario, Customers o Orders.
Questo crea una delle domande decisive della migrazione: quale sistema sarà responsabile di ciascun record dopo il go-live? Un valore migrato può essere sovrascritto da un feed ERP. L’inventario importato durante la migrazione può diventare irrilevante quando parte la sincronizzazione con il WMS. Le descrizioni dei Products possono essere gestite in un PIM, mentre le offerte marketplace provengono da connettori seller. I dati Customers possono essere arricchiti o governati in un CRM.
| Area dati | Possibile sistema autorevole | Relazione richiesta in VTEX |
|---|---|---|
| Contenuti Product | PIM, ERP o VTEX Catalog | Identificativi stabili per Product, SKU, Category, brand e specification |
| Prezzo | ERP, piattaforma di pricing o VTEX Pricing | Record di prezzo corretti per ogni contesto commerciale |
| Inventario | WMS, ERP, seller o VTEX Logistics | Quantità SKU-location valide e responsabilità chiara della sincronizzazione |
| Customer | CRM, Master Data o servizi account | Identità e relazioni di indirizzo coerenti |
| Order | VTEX Orders, OMS, ERP o flusso marketplace | Identificativi, stati ed elaborazione downstream affidabili |
| Offerta seller | Sistema seller o connettore marketplace | Corrispondenza Product-SKU, prezzo, stock e contesto di evasione corretti |
L’architettura API-first ed estensibile della piattaforma facilita queste integrazioni, ma non elimina le decisioni di governance dei dati. La migrazione deve stabilire identificativi stabili e responsabilità chiare prima che i flussi automatizzati inizino ad aggiornare l’ambiente di destinazione.
VTEX nel panorama più ampio delle piattaforme
VTEX si colloca più vicino alle piattaforme e-commerce componibili ed enterprise che ai builder di negozi hosted entry-level. Offre una base cloud gestita e, al tempo stesso, espone servizi specializzati, API, relazioni marketplace, opzioni per lo sviluppo dello storefront e controlli operativi di livello enterprise.
Rispetto a piattaforme SaaS più semplici, VTEX separa una quota maggiore del ciclo e-commerce in servizi governati in modo indipendente. Rispetto alle piattaforme open-source self-hosted, riduce la responsabilità diretta su infrastruttura e codice core, privilegiando configurazione, API, applicazioni e sistemi collegati. Rispetto a uno stack componibile interamente custom, offre una piattaforma e-commerce integrata anziché richiedere che ogni servizio venga selezionato e assemblato separatamente.
La rilevanza per la migrazione deriva proprio da questa posizione. VTEX può rappresentare cataloghi complessi, canali, seller, marketplace, strutture B2B e integrazioni, ma l’architettura di destinazione deve essere progettata in modo intenzionale. Products e Orders sono soltanto una parte del modello operativo: contesto commerciale, relazioni tra servizi e responsabilità dei sistemi determinano se la piattaforma sarà realmente utilizzabile.
Conclusione
VTEX è una piattaforma e-commerce cloud modulare la cui identità comprende Catalog, SKUs, specifications, pricing, promotions, inventario, logistica, trade policy, seller, marketplace, checkout, Orders, Master Data, storefront, applicazioni e integrazioni. La piattaforma supporta modelli operativi enterprise complessi proprio perché questi elementi sono rappresentati come livelli distinti ma collegati.
L’orientamento centrale di una migrazione verso VTEX è ricostruire deliberatamente tali relazioni. I Products devono essere rappresentati nella gerarchia Product-SKU di VTEX. Le specifications devono conservare il corretto significato a livello Product o SKU. La vendibilità deve collegare prezzo, inventario, seller, logistica e contesto di canale. I record Customers e Orders devono restare distinti dal comportamento attivo del checkout e dalle funzioni B2B. Storefront e integrazioni enterprise devono utilizzare identificativi stabili e avere responsabilità di sistema chiare. Questa architettura costituisce la base per tutti gli articoli successivi dell’hub VTEX.
Domande frequenti
Qual è la differenza tra un Product e uno SKU in VTEX?
Un Product è la definizione generale di un articolo, mentre uno SKU è la variante specifica acquistabile, associata allo stock e selezionata dal cliente. Ogni Product VTEX deve avere almeno uno SKU.
Perché le specifications sono importanti in VTEX?
Le specifications descrivono caratteristiche di Product o SKU e sono organizzate attraverso gruppi collegati alle Categories. Possono supportare variazioni, filtraggio, classificazione e presentazione nello storefront, quindi gli attributi della sorgente devono essere mappati in base alla loro reale funzione.
Che cosa rappresenta una trade policy?
Una trade policy stabilisce il contesto commerciale di un canale o di un’operazione. Può influenzare la disponibilità dei Products e altre condizioni di vendita, consentendo allo stesso account di servire mercati o canali differenti.
Come gestisce VTEX i seller marketplace?
VTEX può collegare le offerte dei seller a Products e SKUs condivisi. I seller possono possedere il contesto di prezzo, inventario ed evasione, mentre il marketplace governa la presentazione del catalogo e l’orchestrazione della transazione.
La migrazione dei Products li rende immediatamente vendibili in VTEX?
Non necessariamente. Uno SKU può richiedere anche specifications valide, immagini, attivazione, prezzo, inventario, contesto seller, disponibilità nella trade policy e logistica prima di poter essere acquistato.
Uno storefront VTEX fa parte dei dati migrati?
Lo storefront è un livello di implementazione separato. I record Product e contenuto possono alimentare l’esperienza, ma temi e codice frontend della sorgente devono essere implementati nell’architettura storefront VTEX scelta.