Wix combina creazione del sito, commerce, CRM, CMS, marketing e dati applicativi all’interno di un unico sito. Questa ampiezza rende il significato dei dati durante la migrazione più importante della semplice somiglianza tra campi. Un Product di origine può diventare un Product Wix Stores con opzioni, scelte, varianti, media, Categories, relazioni con il brand e inventario. Una persona può esistere come Contact, Member del sito, Customer collegato agli Orders o partecipante a un’altra applicazione business di Wix. Un record CMS di origine può appartenere a una collezione Wix CMS, mentre un Product, Blog Post, booking, event o record di un’app appartiene a un diverso proprietario dei dati in Wix.
Wix presenta inoltre un confine attivo legato alla versione del catalogo. Un sito Wix può utilizzare Catalog V1 oppure Catalog V3, ma non entrambi contemporaneamente. Catalog V3 introduce varianti universali, Customizations riutilizzabili, Inventory Items separati per variante e location, Categories gerarchiche, brand, sezioni informative riutilizzabili e altre entità di catalogo. La versione del catalogo del sito di destinazione è quindi parte del modello dati, non un dettaglio tecnico secondario.
Il compito centrale consiste nel preservare le relazioni padre-figlio e tra sistemi che danno significato ai dati. L’identità del Product deve restare collegata alla variante corretta, alla Category, al record di inventario, alla location, ai media e alla chiave esterna corretti. L’identità Contact deve rimanere distinta dall’accesso Member e dal consenso marketing. Gli Orders devono conservare le evidenze della transazione senza trasformarsi nella configurazione del checkout futuro. Collections CMS e dati delle app hanno bisogno di proprietari espliciti e non vanno appiattiti in generici contenuti di pagina.
La versione del catalogo Wix definisce un confine di titolarità dei dati
Catalog V1 e Catalog V3 non espongono esattamente la stessa struttura dei record. Un sito utilizza una sola versione del catalogo alla volta, quindi la rappresentazione dei dati deve seguire la versione attiva sul sito di destinazione. Catalog V3 è progettato attorno a servizi più espliciti per Products, varianti, Inventory Items, locations, Categories, brand, ribbons, sezioni informative e Customizations riutilizzabili.
Catalog V3 utilizza inoltre varianti universali: ogni Product ha almeno una variante, compresa una variante predefinita per i Products senza opzioni visibili. In questo modello prezzo, SKU, inventario e altri dettagli che definiscono l’elemento vendibile possono essere gestiti a livello di variante anche quando il cliente vede un semplice Product.
| Presupposto nello store di origine | Significato nel catalogo Wix | Conseguenza per la rappresentazione dei dati |
|---|---|---|
| Un Product senza opzioni non ha varianti | Catalog V3 rappresenta comunque una variante predefinita | Identità Product e identità dell’elemento vendibile restano collegate anche quando non è visibile alcuna scelta. |
| Ogni opzione è un dato descrittivo del Product | Le opzioni generano varianti; i modifiers raccolgono personalizzazioni senza creare varianti | Separare le scelte che incidono sullo stock dall’input dell’acquirente e dalle personalizzazioni opzionali. |
| Una singola quantità di inventario appartiene al Product | Gli Inventory Items di Catalog V3 collegano una variante a una location | Preservare sia la variante vendibile sia il contesto della location dietro ogni quantità. |
| Una collezione equivale a un albero di Categories | Versione del catalogo e modello Category di Wix determinano l’organizzazione dei Products | Rappresentare la gerarchia di origine attraverso le relazioni Category supportate dal sito di destinazione. |
| Dati Wix Stores e dati Wix CMS sono intercambiabili | Entità di catalogo Wix Stores ed elementi delle collezioni Wix CMS hanno proprietari diversi | Usare CMS soltanto per record che appartengono realmente alle collezioni CMS o a strutture di dati esterne. |
Una migrazione non dovrebbe quindi presumere che una mappatura dei campi creato per una versione del catalogo Wix valga senza modifiche per un’altra. Anche le integrazioni esterne richiedono ID entità e granularità di catalogo corretti. Un ERP che riconosce le varianti non può essere collegato in modo affidabile usando soltanto un ID del Product padre quando Catalog V3 gestisce l’inventario per variante e location.
Products, varianti universali, opzioni, scelte e modifiers
Un Product Wix è il record principale del catalogo. In Catalog V3 ogni Product ha almeno una variante. I Products con opzioni possono generare varianti attraverso combinazioni delle scelte disponibili. Ogni variante può avere SKU, prezzo, media e significato di inventario distinti. Le Customizations distinguono tra opzioni che generano varianti e modifiers che raccolgono input aggiuntivo dell’acquirente senza modificare l’identità della variante o dell’inventario.
Questa distinzione è fondamentale durante la migrazione di Products configurabili. Una taglia o un colore di origine che modifica SKU o stock corrisponde normalmente a dati di opzione e variante. Un campo per incisione, un messaggio regalo o una personalizzazione opzionale è invece più simile a un modifier. Un’applicazione di origine può combinare entrambe le cose in un unico configuratore; la migrazione deve quindi separare l’identità vendibile risultante dalle istruzioni fornite dall’acquirente.
| Configurazione di origine | Proprietario Wix | Significato da preservare |
|---|---|---|
| Product semplice con un solo SKU | Product più variante predefinita | Contenuto Product a livello padre; SKU vendibile, prezzo e identità di inventario a livello variante. |
| Combinazioni taglia/colore | Opzioni, scelte e varianti | Ogni combinazione acquistabile resta collegata alle scelte, allo SKU, al prezzo, ai media e allo stock corretti. |
| Testo per incisione o messaggio regalo | Modifier o risultato di personalizzazione posseduto da un’app | L’input dell’acquirente resta collegato alla corretta riga Order senza creare false varianti di inventario. |
| Upgrade opzionale | Modifier, Product separato o variante in base al significato di stock e prezzo | Il proprietario nella destinazione dipende dal fatto che l’upgrade crei o meno un elemento vendibile distinto. |
| Bundle o kit | Relazione Product, bundle posseduto da app o struttura inventario esterna | Componenti, autorità sullo stock, formazione del prezzo e dati risultanti nella riga Order devono restare comprensibili. |
| Subscription, booking, event o offerta di servizio | Product Wix Stores o altra applicazione business Wix in base al funzionamento | L’identità di catalogo resta distinta da fatturazione ricorrente, pianificazione, partecipazione o diritti di accesso. |
Le Customizations di Catalog V3 possono essere riutilizzate tra più Products. Questo crea un ulteriore confine relazionale: la definizione della customization può essere condivisa, mentre l’assegnazione al Product e il comportamento risultante di variante o modifier restano specifici del Product. Eliminare o modificare una definizione condivisa può incidere su diversi Products; i template di opzioni di origine vanno quindi rappresentati come entità riutilizzabili solo quando condividono realmente lo stesso significato di business.
Anche i media Product richiedono una titolarità chiara. I media del Product padre possono descrivere l’offerta complessiva, mentre l’immagine di una scelta o di una variante può identificare una combinazione specifica. Spostare tutte le immagini in una gallery indistinta può preservare i file ma perdere la relazione che aiuta il cliente a riconoscere la variante selezionata.
Categories, brand, Info Sections, ribbons e scoperta del catalogo
L’organizzazione del catalogo Wix può coinvolgere Categories gerarchiche, assegnazioni Product, brand, ribbons, sezioni informative riutilizzabili, ricerca, navigazione del sito e presentazione delle pagine. Questi record hanno funzioni diverse.
Le Categories di Catalog V3 possono formare alberi padre-figlio e supportare l’assegnazione di un Product a più Categories, con una relazione di Category principale. I brand rappresentano l’identità del produttore o del marchio. Le Info Sections forniscono informazioni Product ricche e riutilizzabili come specifiche, guide alle taglie, istruzioni di cura o dettagli sulla garanzia. I ribbons forniscono etichette promozionali. Pagine del sito e menu determinano invece navigazione e presentazione pubbliche.
| Concetto di origine | Proprietario nella destinazione Wix | Conseguenza per la rappresentazione |
|---|---|---|
| Gerarchia permanente di reparti | Albero Category e relazioni Product-Category | Preservare il significato durevole per navigazione e classificazione. |
| Produttore o brand | Entità Brand e associazione Product | Tenere l’identità del brand distinta da Categories e specifiche descrittive. |
| Specifiche tecniche | Campi Product, Info Sections, dati CMS o PIM esterno in base a riuso e titolarità | Non trasformare attributi descrittivi in varianti se non generano combinazioni vendibili. |
| Guida alle taglie o alle cure condivisa tra Products | Info Section riutilizzabile | Preservare un unico proprietario del contenuto e i riferimenti ai Products. |
| Etichetta sale, new o featured | Ribbon o presentazione merchandising | Tenere lo stato promozionale distinto dalla classificazione permanente dei Products. |
| Collection stagionale | Category, landing page, ribbon, campagna o presentazione curata in base alla finalità | Preservare il significato della campagna senza renderla un tipo Product permanente. |
| Voce di menu | Relazione di navigazione che punta a Category, pagina Product, pagina CMS o URL esterno | La navigazione non diventa proprietaria della classificazione Product. |
Lo stesso valore di origine può richiedere proprietari diversi in base all’uso. “Organic” potrebbe essere una specifica ricercabile, un badge Product, una Category o un campo di certificazione proveniente da un PIM esterno. La rappresentazione deve seguire il flusso che utilizza il valore, non l’etichetta impiegata dal sistema di origine.
Le relazioni tra variante e location determinano il significato dell’inventario
Gli Inventory Items di Catalog V3 rappresentano una specifica variante in una specifica location. Il record di inventario può registrare quantità, disponibilità, comportamento di preorder e altri significati di stock per quella combinazione variante-location. Ogni store dispone inoltre di una location predefinita, mentre locations aggiuntive possono rappresentare magazzini, filiali o punti di evasione.
Una piattaforma di origine può memorizzare una quantità per Product, una quantità per variante oppure quantità separate per magazzino e canale. Questi modelli non sono equivalenti.
| Modello di inventario di origine | Relazione nella destinazione Wix |
|---|---|
| Una quantità Product senza opzioni visibili | Variant predefinita → location inventario prevista → Inventory Item. |
| Stock a livello variante | Ogni combinazione vendibile di origine → variante Wix → Inventory Item per location. |
| Stock specifico per magazzino | Magazzino/filiale di origine → location Wix o sistema di magazzino esterno → quantità variante-location. |
| Disponibilità illimitata o produzione su ordine | Disponibilità della variante e significato del tracking inventario, non una quantità arbitrariamente elevata. |
| Stock in preorder | Inventory Item variante-location più regole di preorder quando il target supporta tale funzionamento. |
| Sistema esterno autoritativo per lo stock | ID variante/location Wix più chiave ERP o magazzino utilizzata per la sincronizzazione continuativa. |
| Allocazione marketplace | Variant → relazione canale/listing esterno → proprietario dello stock, invece di quantità duplicate senza controllo. |
In Catalog V3, la creazione del Product e la creazione dell’Inventory Item sono operazioni separate, salvo l’uso di un flusso combinato. Questa separazione rafforza il modello di titolarità: un Product può esistere senza un record di inventario completo e l’inventario non è interpretabile senza variante e location che lo possiedono.
Quando un ERP o un sistema di magazzino rimane autoritativo, la quantità iniziale di stock è meno durevole degli identificatori che mantengono allineati gli aggiornamenti successivi. Un ID esterno a livello Product non basta se il sistema esterno memorizza separatamente ogni coppia variante-location.
Contacts, Members, Customers e relazioni marketing
Wix CRM Contacts e Members del sito rappresentano relazioni diverse. Un Contact è un record relativo a persona o organizzazione utilizzato in CRM, comunicazioni, Orders e applicazioni business. Un Member è un utente del sito con autenticazione e, potenzialmente, profilo, ruolo, permessi o relazioni con contenuti ad accesso riservato. Un Customer commerce può essere collegato a un Contact e agli Orders senza riprodurre ogni comportamento dell’account di origine.
Un account Customer di origine può contenere indirizzi, cronologia Orders, password, ruoli aziendali, gruppi Customer, esenzioni fiscali, punti loyalty, iscrizioni, subscriptions, consenso e attributi specifici delle app. Questi valori devono essere assegnati all’entità Wix o al sistema esterno che ne gestirà l’uso futuro.
| Modello di identità di origine | Decisione sulla relazione Wix |
|---|---|
| Acquirente retail registrato | Identità Contact/Customer collegata a indirizzi e Orders; relazione Member solo quando è previsto accesso al sito. |
| Acquirente guest | Contesto Contact collegato all’Order senza inventare un account Member. |
| Subscriber esclusivamente newsletter | Contact più relazione di consenso/subscription alle comunicazioni, non automaticamente Customer o Member. |
| Utente di community o contenuti riservati | Member più relazione Contact e relativo proprietario di ruolo, permesso o accesso. |
| Contatto aziendale B2B | Contact più relazione azienda/CRM/account esterno; non automaticamente una gerarchia organizzativa completa. |
| Partecipante a programma loyalty | Contact/Customer più il registro Wix o esterno che possiede punti e stato loyalty. |
| Account di origine duplicati | Consolidati soltanto quando email, telefono, ID esterni, indirizzi, consenso e titolarità degli Orders confermano un’unica identità. |
Password e stato di autenticazione non devono essere trattati come normali campi profilo. Anche quando un Customer di origine diventa Member Wix, credenziali di accesso, stato dell’invito, ruoli e permessi hanno significato distinto in termini di sicurezza e ciclo di vita.
Anche il consenso marketing resta indipendente dalla cronologia degli acquisti. Un Contact che ha acquistato una volta non è automaticamente subscriber, e un subscriber potrebbe non aver mai acquistato. Preservare il consenso significa mantenere distinta la relazione di comunicazione dal record Contact stesso.
Gli Orders preservano la cronologia commerce e il contesto applicativo
Gli eCommerce Orders Wix gestiscono il ciclo successivo all’acquisto. Un Order può includere articoli acquistati, dettagli di pagamento, informazioni di fatturazione e spedizione, sconti, imposte, dati di delivery o pickup, stato di evasione, rimborsi, fatture e riferimenti esterni. Draft Orders, record di fatturazione, transazioni, fatture e fulfillments hanno proprietari correlati ma distinti.
La riga Product o variante di un Order storico è uno snapshot della transazione. Deve preservare ciò che è stato acquistato, comprese opzioni o personalizzazioni selezionate, anche se il catalogo corrente cambia in seguito. Le impostazioni attive di pagamento, imposte, spedizione, notifiche, fatturazione e inventario restano configurazione per i futuri Orders.
| Valore storico | Significato nell’Order Wix |
|---|---|
| Numero Order di origine | Riferimento esterno per servizio Customer e riconciliazione. |
| Riga Product/variante | Titolo acquistato, variante, SKU, quantità, prezzo e scelte selezionate. |
| Risultato di modifier o personalizzazione | Valore fornito dall’acquirente o generato dall’applicazione collegato alla corretta riga Order. |
| Sconto, imposta e costo di consegna | Spiegazione del totale storico, non configurazione delle regole correnti. |
| Dati di pagamento e rimborso | Cronologia finanziaria collegata all’Order e al proprietario della transazione. |
| Spedizione, delivery, pickup o evasione del servizio | Stato storico dell’evasione e contesto di tracking. |
| Fattura o riferimento contabile | Relazione Order/fattura più identificatore contabile esterno. |
| Riferimento al canale di vendita o all’app | Origine dell’Order e titolarità dell’applicazione esterna. |
Gli Orders Wix possono essere creati da diverse soluzioni business Wix e integrazioni, non soltanto da Wix Stores. Un record di origine migrato dovrebbe quindi preservare quale applicazione o canale ha generato la transazione quando la distinzione incide su reportistica, evasione o servizio Customer.
Gli Orders storici non dovrebbero inoltre creare Products correnti artificiali. Una riga Order relativa a un Product ritirato, un servizio una tantum o un addebito generato da un’app può rimanere comprensibile come snapshot senza aggiungere un nuovo Product al catalogo attivo.
Collections Wix CMS, data items, riferimenti e dati esterni
Wix CMS memorizza data items all’interno di collezioni. I data items possono contenere campi tipizzati e riferimenti ad altri elementi. Wix supporta inoltre connessioni a database esterni che espongono collezioni esterne tramite le interfacce dati Wix. Queste funzionalità rendono CMS utile per contenuti strutturati, directory, cataloghi personalizzati, librerie di risorse e dati applicativi, ma CMS non sostituisce Wix Stores, Contacts, Orders, Blog, Bookings, Events o altri proprietari specializzati.
Una tabella personalizzata di origine dovrebbe diventare una collezione Wix CMS soltanto quando il record di business appartiene realmente a un modello di contenuti o dati personalizzati. Un Product che deve partecipare a checkout Wix Stores, varianti, inventario e Orders deve restare un Product Wix Stores. Un Blog Post dovrebbe restare contenuto Blog se il comportamento editoriale è rilevante. Un booking deve rimanere collegato al sistema di prenotazione che possiede disponibilità e partecipazione.
| Record di origine | Proprietario nella destinazione Wix |
|---|---|
| Libreria di specifiche Product | Info Sections, campi Product, collezione CMS o PIM esterno in base a riuso e autorità. |
| Risorsa editoriale o directory | Collection CMS e data items con riferimenti espliciti e relazioni con pagine dinamiche. |
| Articolo blog | Wix Blog Post con significato relativo a pubblicazione, autore, Category/tag, media e URL. |
| Catalogo Product personalizzato non venduto direttamente | Collection CMS o database esterno; Wix Stores solo quando è richiesto comportamento commerce. |
| Record event, booking, corso o membership | Applicazione business Wix pertinente più relazioni Contact/Member e transazione. |
| Riga di database esterno | Relazione con collezione esterna, ID stabili e campi di riferimento. |
| Contenuto del page builder | Presentazione di pagina/sezione collegata a record CMS o commerce, non proprietario autoritativo dei dati. |
I campi di riferimento CMS preservano le relazioni tra record, ad esempio una risorsa collegata a un autore, una Category, un Product o una location. Appiattire tali relazioni in testo copiato elimina la possibilità di aggiornare e interrogare i record in modo indipendente.
Pagine del sito, URL, media, dati multilingua e SEO
I contenuti Wix possono includere pagine, pagine dinamiche, Blog Posts, contenuti gestiti dal CMS, media, menu, pagine Product, pagine Category, redirect, campi SEO, domini e varianti multilingua. Questi record determinano come catalogo e contenuti vengono presentati e trovati, ma non sostituiscono il Product, l’elemento CMS, il Contact o l’Order sottostante.
Un layout realizzato con page builder nel sistema di origine può combinare riferimenti Product, testo, immagini, form e widget applicativi. Il modello di destinazione dovrebbe separare contenuti riutilizzabili e record di business dalla sezione visuale che li rende visibili.
| Asset web di origine | Relazione di titolarità Wix |
|---|---|
| Titolo Product, descrizione, media, URL e dati SEO | Product Wix Stores e presentazione della pagina Product. |
| Landing page di Category | Category più relazione pagina/navigazione ed eventuale contenuto di supporto. |
| CMS Page o pagina di contenuto dinamico | Pagina del sito/pagina dinamica più collezione CMS e riferimenti ai data items. |
| Blog Post | Record Wix Blog con autore, pubblicazione, Category/tag, media e significato dell’URL. |
| Voce di menu | Relazione di navigazione che punta a pagina, Category, Product, pagina dinamica, anchor o URL esterno. |
| Contenuti multilingua | Campi e riferimenti specifici per lingua a livello di sito/contenuto/Product, non record duplicati e scollegati salvo scelta intenzionale. |
| URL di origine | Percorso di destinazione più relazione di redirect quando il percorso cambia. |
| Componente Theme o Editor | Configurazione di presentazione che fa riferimento a contenuti o entità commerce autoritative. |
Il vecchio URL dovrebbe puntare a un record di destinazione noto. Un redirect è una relazione tra percorsi, non un sostituto della decisione su quale Product Wix, Category, pagina, Blog Post o elemento dinamico sostituisce l’asset di origine. Anche link interni e riferimenti ai media devono conservare la destinazione prevista invece di mantenere percorsi di origine ormai obsoleti.
App, Velo, service plugin e titolarità dei sistemi esterni
Applicazioni Wix, codice Velo, service plugin, automazioni, webhook, database esterni e sistemi di terze parti possono possedere dati che non appartengono al catalogo Wix Stores. Reviews, subscriptions, loyalty, marketplace, contabilità, evasione, ricerca avanzata, feed Product, CRM e configuratori personalizzati possono introdurre record e identificatori propri.
Il fatto che un’applicazione di destinazione svolga una funzione simile non dimostra che i dati dell’applicazione di origine possano essere rappresentati direttamente. Devono essere compresi entità proprietaria, schema dati, chiavi relazionali e ciclo di vita.
| Segnale personalizzato o esterno | Proprietario nella destinazione |
|---|---|
| ID ERP di Product o variante | Product/variante più relazione ERP alla granularità di catalogo riconosciuta esternamente. |
| Chiave inventario del magazzino | Inventory Item variante-location più sistema di magazzino. |
| ID CRM di Contact o azienda | Contact più relazione CRM/azienda esterna. |
| ID listing marketplace | Relazione Product/variante/canale, non un generico campo Product. |
| Record Review, loyalty o subscription | App Wix o sistema esterno più riferimenti Product, Contact, Member o Order. |
| Stato di configuratore personalizzato | Proprietario App/Velo/CMS più Product/variante e risultato nella riga Order. |
| Record di database esterno | Collection esterna più campi di riferimento Wix e chiave durevole del sistema esterno. |
| Impostazione webhook o service plugin | Configurazione della destinazione che collega i sistemi, non record Customer o Product. |
Questo modello di titolarità evita di preservare dati personalizzati inutilizzabili. Un valore è durevole solo quando il team conosce il record padre, il sistema autoritativo, il ciclo di vita e chi lo utilizza. Generici custom fields non sostituiscono una relazione definita Product-app, Contact-CRM, Order-marketplace o CMS-database esterno.
Catene rappresentative di relazione in Wix
Le catene relazionali rendono esplicito il significato nella destinazione mostrando record padre, record dipendenti e proprietario esterno quando applicabile. Sono particolarmente utili in Wix perché commerce, CRM, Members, CMS e applicazioni possono contenere dati relativi allo stesso evento di business. Una catena completa mostra quale entità Wix è autoritativa e quali record si limitano a fare riferimento a quei dati o a presentarli.
| Modello di origine | Relazione nella destinazione Wix |
|---|---|
| Product di abbigliamento con stock per taglia/colore | Versione catalogo → Product → opzioni/scelte → varianti → media/SKU della variante → Inventory Items per location. |
| Regalo personalizzato | Product/variante → modifier o input posseduto dall’app → personalizzazione della riga Order → riferimento di evasione. |
| Inventario multi-location | Variant → location Wix → Inventory Item → chiave magazzino esterna quando un altro sistema resta autoritativo. |
| Customer che usa anche contenuti riservati | Contact/Customer → Orders e indirizzi; Member → autenticazione/ruolo/accesso; il consenso resta una relazione di comunicazione separata. |
| Risorsa gestita dal CMS e collegata ai Products | Collection CMS → data items/campi di riferimento → ID Product Wix Stores → pagina dinamica/navigazione. |
| Vendita marketplace | Order → riferimento origine/canale → snapshot Product/variante nella riga → cronologia transazione/evasione → ID marketplace esterno. |
| Category sensibile alla SEO | Albero Category/appartenenza Product → pagina del sito o route Category → navigazione → URL di destinazione → redirect dall’origine. |
Queste catene preservano la titolarità specifica di Wix riconoscendo al tempo stesso che una piattaforma di origine può aver combinato dati commerce, contenuti, identità e applicazioni all’interno dello stesso record o della stessa tabella.
Conclusione
La rappresentazione del modello dati in Wix parte dalla versione del catalogo del sito di destinazione e si estende a Wix Stores, locations di inventario, CRM Contacts, Members del sito, eCommerce Orders, collezioni CMS, pagine, contenuti Blog, app, Velo e sistemi esterni. Queste famiglie di record sono collegate, ma non sono intercambiabili.
Un buon modello di destinazione Wix assegna ogni valore di origine al Product, variante, customization, Category, location, Inventory Item, Contact, Member, Order, elemento CMS, record di contenuto, applicazione o sistema esterno che ne possiede il significato nel tempo. Questa struttura preserva le relazioni commerce e contenuto senza confondere i dati storici con la configurazione futura né appiattire dati applicativi specializzati in campi generici.
Domande frequenti
Perché la versione del catalogo Wix è importante durante la migrazione?
Un sito Wix utilizza Catalog V1 oppure Catalog V3 e le relazioni tra entità sono diverse. Catalog V3 usa varianti universali e servizi separati per inventario per variante e location, Categories, brand, Customizations, sezioni informative e altri record di catalogo.
Le opzioni Product e i modifiers Wix sono la stessa cosa?
No. Opzioni e scelte generano varianti che possono avere significato distinto per SKU, prezzo, media e inventario. I modifiers raccolgono personalizzazioni o input opzionali senza creare una variante o un’identità di inventario separata.
Ogni Wix Contact può diventare Member del sito?
No. Un Contact è un record CRM e di relazione commerciale. Un Member include autenticazione e può avere profilo, ruolo, permessi o accesso a contenuti riservati. Un acquirente può rimanere Contact/Customer senza ricevere un account Member.
Gli Orders Wix migrati configurano il funzionamento del checkout futuro?
No. Gli Orders preservano articoli acquistati, scelte, cronologia di pagamenti/rimborsi, indirizzi, evasione, fatture e riferimenti esterni. Il funzionamento corrente di pagamenti, imposte, spedizione, notifiche e inventario resta configurazione separata.
Quando i dati personalizzati di origine dovrebbero diventare una collezione Wix CMS?
CMS è appropriato quando i dati appartengono a un modello strutturato di contenuti o record personalizzati che beneficia di campi, riferimenti, query e pagine dinamiche. Products, Orders, Contacts, Blog Posts, Bookings, Events e altri record specializzati devono restare presso i proprietari Wix nativi quando quel comportamento è necessario.
Come vanno rappresentati i dati di app Wix e sistemi esterni?
Il valore va mantenuto con il relativo Product, variante, Contact, Member, Order, elemento CMS o altro record di business padre, conservando l’identificatore esterno usato dall’applicazione proprietaria. Una nota generica o un campo non strutturato non preserva la relazione necessaria alla sincronizzazione futura.