Trasferire dati in Jumpseller richiede più che associare colonne di origine a campi di destinazione. Jumpseller separa il Product principale, le sue varianti acquistabili, le personalizzazioni inserite dal cliente, i campi personalizzati descrittivi, l’appartenenza alle Categories, la navigazione, l’inventario, l’identità del Customer, gli Orders storici, i contenuti della vetrina online e i record di integrazione in relazioni differenti. Una piattaforma di origine può conservare diversi di questi significati nello stesso sistema di attributi o nella stessa tabella di un’estensione.
La domanda centrale non è quindi se un valore di origine possa essere copiato. Occorre stabilire quale oggetto Jumpseller debba possederlo e quale relazione debba restare intatta. Taglia e colore possono definire varianti con inventario proprio; il testo di un’incisione può restare un input associato alla riga dell’Order; il brand può essere un campo personalizzato usato per i filtri; una Category può organizzare Products senza riprodurre il vecchio menu; e un identificatore esterno può restare essenziale anche se il cliente non lo vede mai.
I Products sono record principali di catalogo, non unità vendibili complete
Un Product Jumpseller fornisce l’identità condivisa di catalogo per un’offerta vendibile. Può contenere nome, descrizioni, immagini, relazioni con Categories, stato, prezzi predefiniti, impostazioni di inventario, campi SEO, opzioni, campi personalizzati e altre informazioni di merchandising. Quando le opzioni generano varianti, però, il Product principale non possiede più da solo tutti i valori commerciali.
Le piattaforme di origine combinano spesso in modo diverso i dati del Product principale e delle unità effettivamente vendibili. Una piattaforma può memorizzare ogni taglia e colore come Product indipendente. Un’altra può mantenere un solo Product con SKU figli. Una terza può conservare un Product principale ma collocare immagini, costo, stock e modifiche di prezzo in una matrice posseduta da un’applicazione. La destinazione Jumpseller deve preservare la distinzione tra livello principale e livello figlio, anziché appiattire tutti i record sullo stesso piano.
| Modello del catalogo di origine | Interpretazione in Jumpseller | Conseguenza per le relazioni |
|---|---|---|
| Un record per ogni taglia e colore | Product principale con varianti generate dalle opzioni, quando i record appartengono alla stessa famiglia commerciale | Descrizioni condivise e Categories possono restare sul Product principale, mentre SKU, stock, prezzo, peso e immagini possono appartenere alle varianti. |
| Product principale con SKU figli | Product più combinazioni di varianti | Gli identificatori figli esistenti devono restare collegati alla corrispondente combinazione di opzioni. |
| Product semplice senza scelte selezionabili | Product con i propri valori commerciali | Non serve creare uno strato artificiale di varianti soltanto perché la sorgente espone una tabella di attributi. |
| Articolo digitale o non soggetto a spedizione | Product con significato di evasione e inventario diverso da un articolo fisico | Riferimenti di consegna, file e aspettative di spedizione devono restare distinti dai normali dati di stock. |
| Famiglia di Products generata da un’applicazione | Record Product più relazioni possedute dall’applicazione | I valori descrittivi possono rientrare nei campi standard, mentre regole generate o record collegati restano di proprietà dell’applicazione di origine o di un altro sistema di destinazione. |
Anche lo stato del Product porta significato. Uno stato di origine come attivo, nascosto, bozza, archiviato, fuori produzione o ordinabile in back-order può non corrispondere a un singolo stato di Jumpseller. La rappresentazione di destinazione dovrebbe distinguere visibilità pubblica, possibilità di acquisto, disponibilità di stock e conservazione stagionale, anziché ridurre ogni stato a semplicemente abilitato o disabilitato.
Opzioni, varianti, input del cliente e campi personalizzati sono strutture diverse
Le Product Options di Jumpseller possono generare vere varianti, ma non ogni valore simile a un’opzione appartiene a una griglia di varianti. Scelte come taglia o colore possono produrre combinazioni con SKU, prezzo, stock, peso, costo e relazioni con immagini propri. Altri input del Product raccolgono testo, messaggi più lunghi, file o selezioni opzionali senza creare una combinazione con inventario separato.
I Custom Product Fields hanno uno scopo diverso. Descrivono il Product e possono aiutare i clienti a trovarlo quando sono rappresentati con valori selezionabili adatti. Brand, materiale, famiglia olfattiva, tipo di compatibilità, stagione o specifica tecnica possono appartenere a questo livello quando non creano unità vendibili indipendenti.
| Significato per il business | Struttura Jumpseller appropriata | Cosa non deve andare perso |
|---|---|---|
| Taglia o colore con stock indipendente | Product Option che genera varianti | Identità della combinazione, SKU, inventario, prezzo, peso e relazioni con immagini |
| Incisione, dedica o breve messaggio | Input testuale inserito dal cliente | Il valore scelto deve restare associato alla riga dell’Order acquistato, non alla definizione del Product principale. |
| Istruzioni dettagliate di personalizzazione | Input in area di testo | L’input libero dell’acquirente non deve essere trasformato in metadata di catalogo riutilizzabili. |
| Grafica o documento fornito dall’acquirente | Input file | Il riferimento al file appartiene al contesto dell’acquisto, non all’inventario. |
| Confezione opzionale o extra a pagamento | Input selezionabile senza variante, quando rappresentabile | L’effetto sul prezzo e il valore scelto nella riga dell’Order devono restare distinti da una variante con stock. |
| Brand, materiale, aroma, classe di compatibilità o specifica | Custom Product Field | Il descrittore può sostenere informazioni o filtri dei Products senza moltiplicare le varianti. |
| Regola condizionale di configurazione | Relazione con applicazione o sistema esterno | Dipendenze, formule e visibilità condizionale non equivalgono a normali valori di opzione. |
Questa distinzione evita una moltiplicazione artificiale delle varianti. Un catalogo di origine che conserva colore, taglia, testo del monogramma, scelta della garanzia e specifiche tecniche in una sola tabella di attributi può richiedere quattro rappresentazioni Jumpseller differenti. Trattare tutti questi valori come dimensioni di variante genera combinazioni che non sono vere unità di inventario; trattarli tutti come campi personalizzati elimina invece la possibilità di selezionare e gestire correttamente le vere varianti.
Categories, navigazione e filtri formano relazioni di scoperta distinte
Le Categories di Jumpseller organizzano i Products e possono formare gerarchie principali-secondarie. Possono inoltre contenere nomi, descrizioni, immagini, ordinamento, informazioni SEO e appartenenza dei Products. I record Category sono quindi importanti per la struttura del catalogo, ma da soli non riproducono l’intero percorso della vetrina online.
La navigazione può collocare le Categories nel menu principale, in un menu Category o nel footer e può annidare tali voci indipendentemente dalla relazione Product-Category. Una tassonomia di origine può includere anche gruppi interni di merchandising, raccolte di campagne, brand, faccette di ricerca o etichette operative nascoste. Ogni raggruppamento richiede un significato esplicito nella destinazione.
| Raggruppamento di origine | Possibile proprietà in Jumpseller | Decisione di rappresentazione |
|---|---|---|
| Famiglia Product permanente | Category e appartenenza dei Products | Preservare gerarchia e appartenenza come struttura del catalogo. |
| Ramo della navigazione principale | Voce di navigazione che punta a una Category o a un’altra pagina | Tenere percorso e posizione nel menu separati dall’esistenza della Category. |
| Faccetta brand o materiale | Custom Product Field e relazione con filtro | Usare un descrittore quando il valore raggruppa Products senza definire una scelta acquistabile. |
| Faccetta taglia o colore | Product Option e relazione con filtro | Mantenere coerente il vocabolario delle opzioni affinché scelte equivalenti possano sostenere i filtri. |
| Campagna stagionale | Category, contenuto di landing page, contesto promozionale o collegamento del tema | Scegliere l’oggetto che possiede realmente la campagna invece di creare automaticamente una tassonomia permanente. |
| Etichetta di reportistica interno | Campo di back office o classificazione di sistema esterno | Non esporre un codice interno nella navigazione della vetrina solo perché proviene da una tabella Category. |
I filtri Jumpseller possono utilizzare Product Options che generano varianti e campi personalizzati selezionabili. La coerenza dei nomi diventa quindi parte del modello dati. “Color”, “Colour” e “Finish” possono rappresentare lo stesso concetto nella sorgente ma diventare filtri separati se vengono trattati come campi non correlati. Al contrario, valori con etichette simili possono dover restare distinti quando uno definisce una variante e l’altro è soltanto descrittivo.
Prezzi e inventario possono appartenere al Product, alla variante, al contesto Customer o alla location
Prezzo e stock non hanno significato senza il relativo proprietario. Un Product semplice può possedere un solo prezzo e una sola quantità. Un Product con varianti può spostare SKU, prezzo, costo, peso, immagini e inventario su ogni combinazione. I prezzi specifici per Customer possono introdurre una relazione separata tra Customer Category e listino. I prezzi per volume possono aggiungere soglie quantitative senza modificare l’identità di base del Product.
L’inventario può inoltre essere gestito per location. Quando esiste stock specifico per sede, il modello di destinazione deve preservare la relazione tra Product o variante, location di inventario, quantità e stato dello stock. Un’unica quantità totale non può indicare quale sede sia in grado di evadere l’articolo o quale integrazione sia l’autorità del dato.
| Valore commerciale | Possibile proprietario | Perché la proprietà conta |
|---|---|---|
| Prezzo base di vendita | Product o variante | Un prezzo del Product principale non può sostituire prezzi distinti per combinazioni realmente vendibili. |
| Prezzo di confronto o riferimento | Product o variante | Il valore di riferimento deve restare associato alla stessa unità vendibile del prezzo attivo. |
| Costo | Product o variante | I dati di margine diventano fuorvianti se il costo di una variante viene spostato sul Product principale. |
| Fascia quantità | Product o relazione di pricing | Soglia e prezzo unitario devono restare collegati. |
| Prezzo specifico per Customer | Relazione tra Customer Category e listino | Il prezzo dipende dalla classificazione dell’acquirente, non è un campo universale del Product. |
| Stock | Product o variante in una location | La quantità deve restare collegata all’unità vendibile e alla location corrette. |
| Stato di stock illimitato | Regola di disponibilità del Product o della variante | Una quantità vuota o pari a zero non equivale necessariamente a inventario illimitato. |
Anche i movimenti storici di stock sono distinti dallo stock corrente. Gli Orders possono modificare l’inventario quando cambiano stato, ma un Order importato rappresenta evidenza storica e non un’istruzione per ripetere il movimento di stock originale. La destinazione deve conservare separatamente lo stato finale desiderato dell’inventario e il contesto storico dell’Order.
Customers, Customer Categories, indirizzi e relazioni marketing richiedono significati distinti
Un record Customer Jumpseller rappresenta identità dell’account e informazioni di contatto, ma un profilo Customer di origine può includere molto più di nome ed email. Indirizzi, identificativi fiscali, dettagli aziendali, consenso marketing, stato dell’account, note, segmentazione, identificatori CRM esterni e appartenenza a Customer Categories possono avere proprietari diversi.
| Elemento account di origine | Significato nella destinazione Jumpseller | Confine della relazione |
|---|---|---|
| Nome ed email | Identità Customer e informazioni di contatto | L’identità non deve essere duplicata soltanto perché la persona possiede diversi Orders. |
| Indirizzi di fatturazione e spedizione | Contesto indirizzo collegato al Customer o all’Order storico | Gli indirizzi attuali dell’account e le istantanee degli Orders possono legittimamente essere diversi. |
| Informazioni aziendali o fiscali | Campo Customer, campo indirizzo o record aziendale esterno | Il valore appartiene all’oggetto che lo utilizza nel contesto dell’account o della transazione. |
| Gruppo Customer o fascia wholesale | Customer Category e relativo contesto di prezzo o accesso, quando rappresentabile | Un segmento commerciale non è soltanto un’etichetta se modifica prezzi o idoneità. |
| Consenso newsletter | Relazione marketing o piattaforma marketing esterna | Significato e origine del consenso devono restare distinti dalla semplice esistenza dell’account. |
| Saldo loyalty o stato membership | Record di applicazione o sistema esterno | Il solo record Customer non riproduce la relazione con il programma. |
| Identificatore CRM o ERP | Identificatore esterno stabile | La chiave deve restare collegata allo stesso record persona o azienda usato dal sistema esterno. |
Anche le password richiedono un’interpretazione separata. Un hash password della sorgente può usare uno schema non riutilizzabile da Jumpseller. In questo caso l’identità del Customer può restare significativa anche se le credenziali di autenticazione richiedono un diverso flusso di accesso all’account. Il modello dati non deve trattare un indirizzo email migrato come prova che la credenziale di login originale sia portabile.
Gli Orders preservano il contesto commerciale storico, non la configurazione corrente dello store
Un Order Jumpseller riunisce identità del Customer o del guest, righe dell’Order, varianti selezionate, valori delle opzioni inseriti dal cliente, indirizzi, prezzi, sconti, tasse, costi di spedizione, stato del pagamento, stato di evasione, note, timestamp e riferimenti esterni. Questi valori formano un’istantanea storica di ciò che è avvenuto al momento dell’acquisto.
Questa istantanea deve restare separata dai Products e dalle configurazioni correnti. Una vecchia riga Order può mantenere titolo Product, SKU, opzioni selezionate e prezzo anche dopo che il Product attivo è stato rinominato, riprezzato, disabilitato o eliminato. Un costo di spedizione storico può mostrare quanto è stato pagato senza definire il metodo di spedizione corrente. Un riferimento di pagamento può servire alla riconciliazione senza configurare il gateway attivo.
| Componente dell’Order | Significato storico | Relazione nella destinazione |
|---|---|---|
| Identità Product nella riga Order | Cosa è stato acquistato in quel momento | Preservare dove possibile il riferimento al Product o alla variante mantenendo anche il testo dell’istantanea. |
| Opzioni selezionate e input personalizzati | Scelte dell’acquirente per quella riga | Mantenerle con la riga Order anche quando cambia la definizione corrente del Product. |
| Prezzo, sconto e tassa | Istantanea commerciale | Non ricalcolare lo storico usando i Products o le impostazioni fiscali correnti. |
| Indirizzo di fatturazione e spedizione | Indirizzo al momento della transazione | Tenerlo separato dalle modifiche successive al profilo Customer. |
| Stato e riferimento del pagamento | Contesto storico del pagamento | Il record non possiede la configurazione attuale del gateway. |
| Stato di evasione e tracking | Contesto storico della consegna | Il record non definisce le regole correnti di corriere o magazzino. |
| Canale di origine o ID esterno | Chiave per riconciliazione e integrazione | Preservare la chiave quando un altro sistema la usa per identificare l’Order. |
Guest Orders, Orders annullati, parzialmente evasi, rimborsati e Orders che contengono input personalizzati espongono relazioni che un semplice Order pagato non mostra. Il modello di destinazione deve gestire questi stati senza trasformare record storici in configurazione attiva dei flussi operativi.
CMS Pages, Blog Posts, URL e contenuti del tema hanno proprietari diversi
I contenuti della vetrina Jumpseller possono includere CMS Pages, Blog Posts, descrizioni di Products e Categories, voci di navigazione, banner, sezioni del tema, immagini, contenuti di policy e campi SEO. Una piattaforma di origine può conservarli tutti nello stesso editor visuale di pagine o nella stessa tabella di contenuti, mentre Jumpseller li assegna a oggetti differenti.
| Contenuto di origine | Interpretazione in Jumpseller | Distinzione di proprietà |
|---|---|---|
| Contenuti About, contatti, policy o guide | CMS Page | Il contenuto stabile della pagina e il relativo percorso restano separati dalla posizione nel menu e dal layout del tema. |
| Articolo editoriale o annuncio | Blog Post | Data di pubblicazione, contesto autore, Categories o tag, media e permalink possono differire da una CMS Page. |
| Testo di Product o Category | Descrizione posseduta dal catalogo | Il contenuto appartiene all’oggetto del catalogo, non a una pagina generica separata. |
| Header, footer, banner o sezione homepage | Contenuto del tema o della navigazione | La collocazione nella presentazione non coincide con il record di business sottostante. |
| Meta title, meta description o permalink | Relazione SEO e di routing sull’oggetto proprietario | I metadata devono restare collegati al Product, Category, CMS Page o Blog Post che descrivono. |
| Redirect o vecchio percorso | Relazione di routing | Il vecchio URL resta utile anche quando l’oggetto di destinazione riceve un permalink diverso. |
Il codice del tema può leggere campi Product, campi personalizzati, Categories, menu e dati restituiti da applicazioni, ma non possiede quei record. Riprodurre il vecchio markup non sostituisce la corretta rappresentazione dei dati sottostanti. Allo stesso modo, copiare il corpo del contenuto senza collegamenti, media, percorso e proprietario può produrre una pagina che esiste ma non funziona più come parte della vetrina.
Applicazioni, API, webhook e identificatori esterni formano un livello dati circostante
Jumpseller può scambiare dati con sistemi esterni tramite applicazioni, API e webhook. Uno store di origine può affidarsi a un ERP per l’inventario, a un CRM per la classificazione dei Customers, a un servizio di evasione per gli stati delle spedizioni, a un marketplace per le inserzioni o a un’applicazione per abbonamenti, prenotazioni, recensioni, loyalty, bundle o configurazione dei Products.
Questi record devono essere classificati in base alla proprietà, non alla visibilità. Un valore mostrato in una pagina Product può essere autorevole in un PIM esterno. Una quantità di stock visibile in Jumpseller può essere sincronizzata da un ERP. Un tag Customer può derivare da un CRM. L’ID di un’inserzione marketplace può identificare un’offerta di canale anziché il Product core.
| Record di integrazione | Proprietario probabile | Requisito di rappresentazione |
|---|---|---|
| ID ERP del Product o della variante | ERP e relazione con il catalogo | Preservare la chiave sul Product o sulla variante corrispondente usata per la sincronizzazione. |
| ID magazzino o location | Sistema di inventario o evasione | Mantenere l’identità della location distinta da una semplice quantità di stock. |
| ID CRM del Customer | Relazione tra CRM e Customer | Evitare di creare una nuova chiave non correlata per la stessa persona o azienda. |
| ID inserzione marketplace | Inserzione del canale di vendita | Non confondere un’inserzione con il Product o la variante canonici. |
| Abbonamento, prenotazione o record loyalty creato da un’applicazione | Dominio dell’applicazione | Rendere espliciti i riferimenti al Product principale, al Customer e all’Order. |
| Stato di sincronizzazione webhook | Processo di integrazione | Trattare timestamp, ID evento e cursori come dati operativi dell’integrazione, non come contenuti della vetrina. |
Una destinazione coerente non deve riprodurre ogni tabella della sorgente. Deve però definire un proprietario per ogni identificatore e relazione che sostenga gestione del catalogo, continuità dei Customers, riconciliazione storica o sincronizzazione esterna.
La mappa di rappresentazione per Jumpseller deve risolvere il significato prima della memorizzazione
Il modello dati di Jumpseller può essere riassunto come una serie di decisioni sulla proprietà. I Products principali possiedono il merchandising condiviso. Le varianti possiedono le combinazioni vendibili. Gli input Customers appartengono prima all’interazione con il Product e poi alla riga dell’Order. I campi personalizzati descrivono i Products. Le Categories organizzano l’appartenenza al catalogo. La navigazione possiede la posizione nei menu. I Customers possiedono identità e contesto dell’account. Gli Orders possiedono le istantanee storiche della transazione. Applicazioni e sistemi esterni possiedono record e identificatori specializzati.
| Domanda sulla sorgente | Decisione di rappresentazione |
|---|---|
| Il valore crea un articolo con prezzo o stock indipendente? | Rappresentarlo a livello di variante anziché come campo personalizzato descrittivo. |
| Il valore viene inserito dall’acquirente per un singolo acquisto? | Mantenerlo come input del cliente e preservarlo con la riga Order. |
| Il valore descrive molti Products senza creare varianti? | Usare un campo personalizzato o una relazione di classificazione appropriati. |
| Il raggruppamento organizza Products o controlla la navigazione? | Separare appartenenza alla Category e posizione nei menu. |
| Il valore è configurazione corrente o evidenza storica? | Tenere catalogo e impostazioni operative correnti separati dalle istantanee degli Orders. |
| Un altro sistema usa l’identificatore come chiave? | Preservarlo sull’entità di destinazione che rappresenta lo stesso oggetto di business. |
| Il record è posseduto da un’applicazione anziché dal core di Jumpseller? | Conservare la relazione con l’applicazione invece di forzare il dato in un campo standard non pertinente. |
Risolvere queste domande produce uno store capace di gestire in modo coerente i dati migrati. La destinazione riflette cosa significa ogni record, quale oggetto lo possiede e come si collega al resto dell’ambiente Jumpseller.
Conclusione
Jumpseller cambia il significato dei dati separando Products principali, varianti, input dei clienti, campi personalizzati, Categories, filtri, navigazione, inventario, Customers, Orders, contenuti e integrazioni in relazioni distinte. Una tabella di attributi, una tabella Customers o un record di editor visuale di pagine della sorgente possono quindi richiedere diversi oggetti di destinazione anziché una sola corrispondenza diretta di campo.
Una migrazione coerente preserva la proprietà che sta dietro a ogni valore. I Products restano collegati alle vere varianti vendibili, i campi descrittivi restano distinti dalle scelte dell’acquirente, le Categories restano separate dalla navigazione, l’identità Customer resta distinta dai programmi delle applicazioni, gli Orders rimangono istantanee storiche e gli identificatori esterni restano collegati ai sistemi e alle entità che ne dipendono.
Domande frequenti
Le Product Options e i campi personalizzati di Jumpseller sono la stessa cosa?
No. Le Product Options possono creare varianti oppure raccogliere input dell’acquirente, a seconda del tipo di opzione. I campi personalizzati descrivono il Product e possono sostenere i filtri se rappresentati in modo appropriato. Un valore deve essere assegnato in base al fatto che crei una combinazione vendibile, raccolga una scelta una tantum del cliente oppure descriva il Product.
Quando un attributo di origine dovrebbe diventare una variante Jumpseller?
Dovrebbe diventare parte di una variante quando la scelta identifica una vera unità vendibile con significato commerciale o di inventario proprio, come SKU, prezzo, quantità, peso, costo o relazione con immagini distinti. Valori descrittivi e personalizzazioni libere dovrebbero restare fuori dalla griglia delle varianti.
Le Categories migrate riproducono automaticamente il vecchio menu?
No. Le Categories possiedono raggruppamento e gerarchia dei Products, mentre la navigazione possiede la posizione nei menu e la presentazione dei percorsi. Una Category può esistere senza apparire nel menu principale, mentre un menu può includere link a CMS Pages, Blog Posts, pagine di campagne o altre destinazioni.
Come devono collegarsi gli Orders storici ai Products correnti?
Gli Orders storici devono preservare le proprie istantanee di riga, opzioni selezionate, prezzi, indirizzi, stati e riferimenti esterni. Dove esiste una relazione affidabile con Product o variante può essere mantenuta, ma le modifiche successive del catalogo non devono riscrivere ciò che l’Order registrava al momento dell’acquisto.
Cosa succede ai dati di un’applicazione di origine che non hanno un campo nativo in Jumpseller?
Il record dovrebbe restare classificato sotto il reale proprietario, cioè l’applicazione o il sistema esterno. Riferimenti principali importanti e identificatori stabili possono essere preservati in una struttura di destinazione adatta, mentre il comportamento specializzato resta distinto dai normali campi Product, Customer o Order.
Uno stesso campo di origine può avere destinazioni diverse in Jumpseller per Products differenti?
Sì. Un campo di origine chiamato “Size”, “Type” o “Status” può avere significati diversi in differenti famiglie di Products. La destinazione dipende dal fatto che il valore crei una variante, descriva il Product, controlli la disponibilità, raccolga input del cliente, sostenga i filtri oppure appartenga a un flusso esterno.