Migrare verso Storeden significa più che inserire record in un nuovo ambiente di amministrazione. Storeden opera come un ambiente di commercio cloud che può collegare gestione del catalogo, inventario, gestione degli Orders, pagamenti, temi, applicazioni, vendita marketplace, logistica, risorse API e dati dell’ecosistema TeamSystem più ampio. Questo modello operativo cambia il modo in cui vanno interpretati i dati migrati.
Uno store di origine può contenere Products, Categories, Customers, Orders, record SEO, campi gestiti da app, identificativi marketplace o riferimenti ERP che apparivano completi nella piattaforma precedente. Dopo la migrazione, gli stessi valori devono sostenere struttura del catalogo Storeden, disponibilità sui canali di vendita, processi degli Orders, integrazioni e reportistica aziendale. La domanda sul modello dati non è quindi soltanto se i record arrivano: è se mantengono il corretto significato commerciale all’interno di Storeden.
Il significato dei dati in Storeden, in sintesi
La pianificazione della migrazione deve separare il trasferimento dei record dalla loro interpretazione operativa. Un valore che nello store di origine appare come opzione Product, nota di Order, etichetta di pagamento, metodo di spedizione, gruppo Customer, campo personalizzato o riferimento marketplace può richiedere un trattamento diverso in Storeden.
| Area dati | Significato da mantenere | Domanda sulla responsabilità in Storeden | Perché la differenza conta |
|---|---|---|---|
| Products | Identità vendibile nel catalogo | Nome, descrizione, immagini, prezzo, inventario, collocazione nelle Categories, visibilità e disponibilità sui canali | Un Product può esistere ma restare difficile da vendere, trovare, gestire o pubblicare correttamente. |
| Varianti e opzioni | Scelta del cliente e significato operativo dello SKU | Scelte assimilabili a varianti, valori degli attributi, relazioni SKU, effetti sulle scorte, logica immagini e differenze di prezzo | La struttura delle opzioni incide su selezione in vetrina, evasione, inventario e feed marketplace. |
| Categories e navigazione | Scoperta dei Products e gerarchia di merchandising | Raggruppamento in Categories, logica dei menu, collocazione dei Products, filtri attesi e percorsi SEO | Il catalogo può sembrare completo nel back office mentre la capacità del cliente di trovare i Products peggiora. |
| Inventario | Disponibilità e affidabilità dell’evasione | Quantità, riferimenti SKU, disponibilità multicanale, dipendenze logistiche e fonti di inventario collegate a TeamSystem | Il significato delle scorte può dipendere da più di un canale o sistema. |
| Customers | Identità di account, acquirente e assistenza | Profilo Customer, cronologia di fatturazione/spedizione, contatti, contesto aziendale e riferimenti esterni | I record Customer devono sostenere assistenza, ricerca Orders, continuità dell’account e uso marketing. |
| Orders | Contesto commerciale storico | Products acquistati, relazione con il Customer, totali, imposte, etichette di pagamento, dettagli di spedizione, stati e origine marketplace | La cronologia è utile solo se il personale può comprenderla e utilizzarla dopo la migrazione. |
| Pagamenti e spedizioni | Etichette storiche rispetto alla configurazione attiva | Informazioni conservate negli Orders rispetto alla configurazione di pagamenti, corrieri, logistica e imposte | La cronologia migrata non configura il comportamento futuro del checkout. |
| Record marketplace | Contesto di vendita specifico del canale | ID inserzione, Categories marketplace, prezzi di canale, regole di disponibilità e origine degli Orders | La continuità marketplace può richiedere più della normale migrazione di Products e Orders. |
| Dati di app e API | Responsabilità del processo e identità dell’integrazione | Dati gestiti dalle app, riferimenti API, ID esterni, trigger di automazione e collegamenti con l’ecosistema TeamSystem | I processi collegati possono richiedere configurazione o progettazione separata nella destinazione anche quando i record standard migrano. |
| SEO e contenuti | Reperibilità e continuità | URL, redirect, metadati, descrizioni Product, contenuti Category, nomi immagini e pagine controllate dal tema | Continuità per motori di ricerca e utenti dipende da presentazione e routing, non solo dai record importati. |
I dati Product diventano un catalogo Storeden gestito
I record Product sono il centro più visibile di una migrazione verso Storeden, ma il significato di un Product va oltre la singola riga di dati. Un Product di origine può includere titoli, descrizioni, codici, SKU, brand, fornitori, classi fiscali, prezzi ordinari e promozionali, visibilità, Categories, immagini, relazioni tra varianti, Products correlati, campi personalizzati, attributi marketplace e chiavi esterne di inventario.
Storeden deve usare questi valori per formare un catalogo gestibile centralmente e distribuibile sui canali di vendita previsti. Vanno distinti tre livelli di responsabilità: il Product commerciale visto dal cliente, l’articolo operativo gestito dal personale e la rappresentazione per canale o sistema esterno utilizzata da marketplace, servizi di inventario o sistemi contabili.
| Elemento di origine | Interpretazione in Storeden | Conseguenza sulla relazione |
|---|---|---|
| Titolo e descrizioni Product | Contenuto di catalogo rivolto al cliente | Lingua, formattazione e identità del Product devono restare associate allo stesso articolo commerciale. |
| SKU o codice Product | Identità operativa o tra sistemi | Varianti, righe Order, aggiornamenti delle scorte e integrazioni devono riferirsi all’articolo vendibile corretto. |
| Immagini | Relazione media del Product o della variante | Immagine principale, galleria e immagini specifiche delle varianti non devono essere ridotte a un elenco non ordinato di file. |
| Prezzo ordinario e promozionale | Valore commerciale che può dipendere da tempo o canale | I prezzi storici negli Orders restano evidenza dell’acquisto; i prezzi futuri appartengono al processo di definizione dei prezzi nella destinazione. |
| Assegnazione alle Categories | Organizzazione del catalogo | L’appartenenza a una Category non va confusa con la posizione nei menu o con la tassonomia marketplace. |
| Visibilità o stato | Stato di pubblicazione | Products attivi, nascosti, in bozza o ritirati devono ricevere un significato intenzionale nella destinazione. |
| Campo personalizzato | Dato descrittivo, operativo, di canale o integrazione | La destinazione corretta dipende da chi legge o aggiorna il valore dopo la migrazione. |
Un Product è quindi completo soltanto quando identità, relazioni tra varianti, Categories, media, contesto di prezzo e chiavi esterne descrivono lo stesso articolo vendibile.
Varianti, opzioni e attributi hanno responsabilità diverse
Taglia, colore, materiale, quantità della confezione, testo di personalizzazione, scelta di bundle, intervallo di abbonamento e preferenza di consegna possono apparire tutti come “opzioni” in un export di origine, ma non rappresentano necessariamente lo stesso tipo di record. La rappresentazione in Storeden deve distinguere una variante vendibile da informazioni descrittive del Product, input associato alla riga di Order, logica applicativa e attributi specifici di canale.
La distinzione è importante perché una vera variante può avere SKU, scorte, prezzo, immagine, peso, comportamento fiscale o identità marketplace propri. Un attributo descrittivo può servire per filtrare o comprendere il Product senza creare un articolo vendibile separato. Una personalizzazione può appartenere alla riga di Order anziché al record principale del Product. Il funzionamento di un bundle può essere calcolato da un’app o da un sistema di inventario esterno.
| Modello nell’origine | Significato nella destinazione | Relazione da mantenere chiara |
|---|---|---|
| Taglia o colore con SKU e scorte | Variante vendibile | Product padre, valori selezionati, inventario, prezzo, immagine e riga Order devono riferirsi alla stessa variante. |
| Materiale o proprietà tecnica | Attributo descrittivo o valore di filtro | Mantenere il significato strutturato senza creare false varianti con inventario proprio. |
| Testo di personalizzazione | Input dell’acquirente associato all’acquisto | Conservare il valore nella riga Order pertinente quando deve restare visibile nella cronologia. |
| Bundle o kit | Relazione commerciale o di inventario composta | Stabilire se la logica dei componenti appartiene a Storeden, a un’app o a un sistema esterno. |
| Attributo marketplace | Tassonomia di canale o requisito dell’inserzione | Mantenerlo separato dal modello Product canonico della vetrina, salvo che i due usino davvero lo stesso significato. |
| Codice collegato all’ERP | Chiave tra sistemi | Conservare l’identificativo stabile senza esporlo inutilmente come contenuto della vetrina. |
Questa interpretazione evita un catalogo visivamente corretto che però non identifica più l’articolo effettivamente prezzato, disponibile, pubblicato o evaso.
Categories, navigazione e tassonomie di canale sono strutture separate
Una Category nell’origine può fungere da elemento padre del catalogo, voce di menu, landing page SEO, gruppo promozionale, regola di filtro, segmento di reportistica o collegamento a una tassonomia marketplace. Storeden non deve ereditare tutti questi significati attraverso un solo record Category.
| Struttura di origine | Ruolo in Storeden | Conseguenza sulla responsabilità |
|---|---|---|
| Albero Category padre-figlio | Organizzazione canonica del catalogo | Appartenenza dei Products e gerarchia restano relazioni tra dati. |
| Menu della vetrina | Presentazione della navigazione | Ordine e label dei menu possono riferirsi alle Categories ma non costituiscono il modello Category. |
| Descrizione e metadati Category | Contenuto della landing page | Contenuto e significato SEO devono restare associati alla route pubblica corretta. |
| Filtro o facet | Logica di scoperta basata su valori strutturati | L’attributo sottostante deve rimanere coerente tra i Products. |
| Collezione manuale o gruppo campagna | Relazione di merchandising | Può richiedere selezione editoriale, regole o presentazione tramite tema anziché una Category permanente. |
| Category marketplace | Tassonomia specifica del canale | Conservare il collegamento separatamente dall’albero Category della vetrina Storeden. |
Separare queste strutture permette al catalogo Storeden di sostenere la gestione centrale mentre ciascuna vetrina o marketplace presenta i Products secondo il proprio modello di scoperta.
I valori di inventario richiedono un sistema di riferimento dichiarato
Una quantità nell’origine può rappresentare scorte fisiche, quantità vendibile, quantità riservata, disponibilità del fornitore, giacenza di magazzino, disponibilità di canale, capacità di preordine o un valore sincronizzato da un ERP. Storeden deve ricevere il valore di inventario coerente con il proprio ruolo, insieme agli identificativi necessari per mantenerlo collegato al futuro sistema di riferimento.
| Modello di inventario | Significato | Decisione sulla responsabilità in Storeden |
|---|---|---|
| Una quantità per Product | Disponibilità vendibile semplice | Storeden può gestire il valore quando nessun altro sistema mantiene le scorte. |
| Quantità per variante o SKU | La disponibilità appartiene all’articolo vendibile figlio | Identità della variante e scorte devono restare allineate. |
| Scorte gestite da ERP o magazzino | Responsabilità operativa esterna | Storeden può ricevere disponibilità sincronizzata mentre il sistema esterno rimane autorevole. |
| Disponibilità specifica del marketplace | Allocazione per canale | Mantenere le regole di canale distinte dalla quantità fisica o canonica del Product. |
| Scorte di un bundle | Derivate dalla disponibilità dei componenti | Conservare identificativi dei componenti e responsabilità del calcolo. |
| Articolo senza gestione scorte o servizio | La disponibilità non è una quantità fisica | Evitare di inventare relazioni di inventario che non esistevano nel modello di origine. |
La migrazione può conservare quantità iniziali quando opportuno, ma soprattutto deve preservare le chiavi di Product o variante che consentiranno ai futuri aggiornamenti di raggiungere il record corretto.
Dati Customer e account svolgono più ruoli
I record Customer possono rappresentare acquirenti, titolari di account, contatti newsletter, account aziendali, referenti d’acquisto B2B, destinatari di fatturazione, destinatari di spedizione, Customers marketplace, record CRM o identità collegate a TeamSystem. Ridurli a un unico elenco piatto di Customers può diminuire l’utilità dello store di destinazione.
La pianificazione deve definire cosa significa continuità del Customer per l’azienda. Alcuni store necessitano soprattutto di consultare Orders passati. Altri richiedono accesso all’account, segmentazione, relazioni B2B, idoneità marketing, riferimenti di fatturazione o continuità con sistemi esterni.
| Valore relativo al Customer | Domanda sul modello dati | Aspetto da considerare in Storeden |
|---|---|---|
| Nome ed email | Si tratta di un vero account, di un record acquirente o di un contatto? | Record duplicati o parziali possono incidere su assistenza e attività marketing. |
| Indirizzi di fatturazione e spedizione | Gli indirizzi sono completi e collegati al Customer o Order corretto? | Il personale ne ha bisogno per consultare Orders storici e fornire assistenza. |
| Gruppo o segmento Customer | Il valore è descrittivo, legato ai prezzi o alle autorizzazioni? | Prezzi e accessi possono richiedere configurazione nella destinazione o progettazione separata. |
| Dati aziendali o fiscali | L’azienda utilizza processi B2B o di fatturazione? | Le informazioni societarie possono essere rilevanti per contabilità e cronologia Orders. |
| ID esterni | CRM, ERP, contabilità o marketing dipendono dall’ID? | Conservare o collegare gli identificativi quando restano necessari operativamente. |
| Consensi e dati marketing | L’origine contiene informazioni sensibili sulle preferenze? | Non considerare la migrazione dei contatti come autorizzazione automatica al riutilizzo dei dati marketing senza verifica. |
Un modello Customer utile in Storeden deve permettere al personale di riconoscere, assistere e segmentare correttamente i Customers. Il solo numero di record non conserva il significato di account, segmentazione, B2B, consenso o sistemi esterni.
Gli Orders conservano relazioni commerciali storiche
Un Order in Storeden è utile quando spiega la transazione storica: chi ha acquistato, quale Product o variante è stato scelto, quantità e prezzo applicati, quali sconti e imposte hanno modificato il totale, come erano descritti pagamento e spedizione, quale canale ha originato l’Order e quali stati o informazioni di tracking sono seguiti.
| Valore storico dell’Order | Significato da mantenere | Aspetto separato della destinazione |
|---|---|---|
| Label Product e variante | Identità dell’articolo acquistato | La struttura Product corrente può evolvere senza riscrivere la riga storica. |
| Prezzo, sconto e imposta | Fotografia commerciale al momento dell’acquisto | Prezzi futuri, campagne e regole fiscali appartengono alla configurazione corrente. |
| Etichetta di pagamento o riferimento di transazione | Indicazione di come l’Order è stato pagato | Non crea un collegamento di pagamento attivo. |
| Metodo di spedizione e tracking | Contesto storico di evasione | Non definisce tariffe dei corrieri o regole logistiche correnti. |
| Stato e note | Stato operativo passato | I nuovi processi degli Orders possono utilizzare stati differenti. |
| Origine marketplace | Attribuzione del canale e contesto di reportistica | Inserzioni e sincronizzazione correnti restano record separati. |
Questa separazione mantiene leggibile la cronologia degli Orders senza attribuire alle etichette storiche la responsabilità del futuro funzionamento di checkout, pagamenti, imposte o evasione.
I record marketplace e multicanale formano un livello parallelo
Il ruolo multicanale di Storeden rende i dati marketplace un livello parallelo, non una semplice serie di campi Product aggiuntivi. Identificativi delle inserzioni, Categories di canale, titoli delle offerte, prezzi di canale, regole di disponibilità, attributi marketplace, riferimenti del venditore e origine degli Orders possono tutti riferirsi allo stesso Product canonico pur restando gestiti da un canale o connettore specifico.
| Record di canale | Relazione canonica | Confine di responsabilità |
|---|---|---|
| Identificativo inserzione | Collega un Product o una variante Storeden a un’offerta esterna | Conservarlo quando il futuro connettore o processo di reportistica continua a utilizzarlo. |
| Category marketplace | Collega il Product alla tassonomia del canale | Non unirla all’albero Category della vetrina Storeden. |
| Prezzo di canale | Valore commerciale per una destinazione specifica | Stabilire se il prezzo finale viene pubblicato da Storeden, middleware o marketplace. |
| Scorte di canale | Disponibilità allocata o sincronizzata | Mantenere la regola di canale distinta dalle scorte fisiche o canoniche. |
| Origine marketplace dell’Order | Contesto storico del canale di vendita | Conservarla negli Orders quando serve a reportistica e assistenza. |
| Attributo del feed | Dato Product richiesto dal canale | Conservarlo separatamente quando non rappresenta il significato canonico del Product. |
La relazione decisiva è quella tra un solo articolo commerciale canonico e più rappresentazioni di canale. La migrazione deve conservare questa identità senza duplicare ogni record marketplace come se fosse un Product Storeden indipendente.
App, API e collegamenti TeamSystem definiscono la responsabilità dei record
Storeden può partecipare a un ecosistema più ampio di applicazioni, API, contabilità, inventario, logistica, marketplace e processi collegati a TeamSystem. Questi collegamenti generano record che possono comparire nello store ma restare creati e gestiti altrove.
| Sistema responsabile | Dati tipici | Regola di rappresentazione nella destinazione |
|---|---|---|
| Commercio core di Storeden | Products, Categories, Customers, Orders | Conservare direttamente in Storeden le relazioni tra tipi di dati supportati. |
| Applicazione o connettore | Reviews, dati loyalty, opzioni personalizzate, feed, stato di automazione | Verificare se l’applicazione di destinazione espone un record equivalente e un identificativo durevole. |
| ERP, contabilità, CRM o magazzino | Codici Product, responsabilità sulle scorte, chiavi Customer, riferimenti fattura | Conservare la chiave tra sistemi senza duplicare inutilmente l’intero modello del sistema esterno. |
| Marketplace | Inserzione, offerta, tassonomia e stato del canale | Conservare soltanto i record necessari al processo di canale che continuerà dopo la migrazione. |
| Tema o livello di vetrina | Layout, blocchi, menu e comportamento di presentazione | Ricostruire la presentazione separatamente dai record commerciali canonici. |
| Processo API | Importazione, aggiornamento, sincronizzazione o logica degli eventi | Trattare il processo come progettazione dell’integrazione, non come un campo statico migrato. |
Quando l’origine contiene tabelle di applicazioni non supportate o dati proprietari di connettori, il modello di migrazione deve conservare significato aziendale e chiave esterna soltanto se esiste un responsabile definito nella destinazione.
Contenuti, URL e dati SEO hanno relazioni proprie
Descrizioni Product, testi delle Categories, pagine, Blog Posts, immagini, metadati, link interni, menu e redirect possono essere distribuiti in diverse aree dello store di origine. Storeden deve separare la responsabilità dei contenuti da quella del catalogo anche quando il contenuto appare su una route Product o Category.
| Elemento di contenuto o route | Relazione con i dati commerciali | Significato nella destinazione |
|---|---|---|
| URL Product | Route pubblica verso un Product | La route può cambiare mentre l’identità del Product rimane stabile tramite chiavi interne ed esterne. |
| URL Category | Route pubblica verso un raggruppamento del catalogo | Gerarchia Category, slug, posizione nel menu e redirect sono collegati ma distinti. |
| Metadati | Descrizione per i motori di ricerca di una risorsa pubblica | Mantenerli associati al Product, alla Category o alla pagina corretti. |
| Contenuto avanzato della pagina | Presentazione editoriale o gestita dal tema | Ricostruirlo nel livello contenuti o vetrina appropriato quando non è normale testo di catalogo. |
| Immagini e contesto alt | Media collegati a Products o contenuti | Conservare associazione e sequenza, non soltanto i file. |
| Link interno | Relazione tra route pubbliche | Riscriverlo quando i percorsi dell’origine cambiano. |
| Redirect | Regola di continuità da una vecchia route | Conservarlo come logica di routing anziché come contenuto Product. |
Questa separazione evita di caricare la migrazione del catalogo con il comportamento del tema e allo stesso tempo protegge contenuti e route che rendono i Products reperibili.
Conclusione
Storeden cambia il significato dei dati quando un Product gestito centralmente viene rappresentato attraverso varianti, Categories, inventario, marketplace, applicazioni e sistemi aziendali esterni. Lo stesso valore di origine può essere un dato di catalogo, un attributo di canale, una fotografia storica di un Order, una chiave di connettore o contenuto della vetrina, a seconda di chi lo gestisce e di come viene aggiornato.
Un modello coerente per Storeden deve quindi definire un’unica identità Product canonica, conservare le relazioni tra varianti e Orders, dichiarare il sistema di riferimento dell’inventario, separare le Categories della vetrina dalle tassonomie marketplace e mantenere solo gli identificativi esterni necessari alle integrazioni che continueranno. È un modello multicanale più chiaro del semplice trasferimento di ogni campo dell’origine in Storeden senza contesto di responsabilità.
Domande frequenti
Perché i dati Product richiedono più di una semplice importazione in una migrazione verso Storeden?
Perché devono sostenere presentazione della vetrina, collocazione nelle Categories, affidabilità delle scorte, prezzi, immagini, prontezza dei canali e gestione da parte del personale. Un record Product è incompleto quando varianti, Category, visibilità o attributi marketplace non mantengono più lo stesso significato.
Gli Orders migrati configurano pagamenti e spedizioni in Storeden?
No. Gli Orders migrati conservano informazioni storiche su pagamenti e spedizioni come riferimento. Checkout, pagamenti, spedizioni, logistica, imposte ed evasione futuri appartengono a record correnti e configurazione operativa separati nella piattaforma di destinazione.
Quando i dati marketplace vanno esaminati separatamente?
Quando lo store di origine usa inserzioni, prezzi, Categories, attributi, regole sulle scorte, origine degli Orders o identificativi specifici dei canali. Questi valori possono non comportarsi come normali campi Product della vetrina.
Come vanno gestiti campi personalizzati e ID esterni?
Vanno classificati in base al loro uso aziendale. Se sostengono ERP, contabilità, CRM, logistica, sincronizzazione marketplace o reportistica, possono richiedere un collegamento strutturato dei campi, una gestione dedicata nella destinazione o una progettazione separata, anziché un semplice trasferimento di campo.
Perché il numero di record non basta a verificare la corretta rappresentazione dei dati in Storeden?
Perché non mostra se le varianti identificano ancora gli articoli vendibili, se l’inventario appartiene al sistema corretto, se i record marketplace restano collegati, se gli Orders conservano il contesto commerciale o se gli identificativi esterni collegano ancora i sistemi giusti. La relazione tra i dati è la misura decisiva.
In che modo le integrazioni marketplace o di canale devono influire sulla responsabilità dei dati in Storeden?
Occorre stabilire quale sistema gestisce Product canonico, valore di inventario, identità Customer, stato Order e ID esterno dell’inserzione. Le chiavi tra sistemi ancora necessarie vanno conservate, ma i record generati dalle integrazioni non devono essere duplicati come se Storeden fosse la loro fonte originaria.