La struttura del catalogo è l’architettura dei dati che determina come i Products vengono organizzati per esplorazione, merchandising, navigazione, landing page e ricerca da parte dei clienti. Un Product può esistere correttamente nel sistema amministrativo e risultare comunque difficile da trovare se la relazione con la Category, l’appartenenza a una collezione, il percorso di menu, la posizione di ordinamento o il contesto della landing page non sono rappresentati correttamente.
In uno store e-commerce, l’organizzazione del catalogo non coincide sempre con un semplice albero di Categories. Una piattaforma può utilizzare Categories annidate con relazioni padre-figlio. Un’altra può basarsi su collezioni manuali, collezioni automatiche, tag Product, campi di tassonomia, collegamenti di menu, tipi Product, landing page costruite con page builder o regole di merchandising guidate dalla ricerca. Due store possono apparire molto simili al cliente pur dipendendo da modelli dati molto diversi.
Una revisione tecnica della struttura del catalogo deve quindi distinguere più livelli: l’oggetto di raggruppamento sottostante, la relazione tra Products e gruppi, il percorso di navigazione usato dai clienti, il contenuto associato alle pagine Category o collection, le regole che determinano l’inclusione dei Products e la logica di visualizzazione che stabilisce quali elementi compaiono per primi.
Che cosa rappresenta la struttura del catalogo in uno store e-commerce
La struttura del catalogo stabilisce come i Products vengono disposti in percorsi di navigazione significativi. Aiuta i clienti a passare da un intento generale a Products specifici, per esempio Women > Shoes > Running Shoes, Electronics > Laptops > Gaming Laptops oppure Replacement Parts > Refrigerator Parts > Water Filters.
Questa struttura sostiene normalmente molto più della sola navigazione. Può influire sulle landing page di Category, i breadcrumb, i collegamenti interni, le pagine di ingresso SEO, i Products in evidenza, le regole di merchandising, la ricerca dei Products, la classificazione per marketplace, il reporting e il modo in cui il personale gestisce il catalogo.
Una struttura di catalogo può comprendere diversi oggetti dati e livelli di presentazione:
| Componente del catalogo | Che cosa rappresenta | Funzionamento dello store interessato |
|---|---|---|
| Category o collection | Raggruppamento di Products usato per navigazione o merchandising | Pagine Category, elenchi Product, filtri e ricerca dei Products |
| Gerarchia padre-figlio | Relazione tra gruppi ampi e più specifici | Profondità dei menu, breadcrumb, percorsi di navigazione e struttura URL |
| Assegnazione Product | Collegamento tra Products e Category o collection | Visibilità dei Products nelle pagine di navigazione |
| Voce di menu | Collegamento di navigazione dello store verso Category, collection, pagina o URL esterno | Modo in cui i clienti raggiungono le pagine del catalogo |
| Percorso breadcrumb | Percorso gerarchico o di navigazione mostrato nello store | Orientamento, collegamenti interni e chiarezza della navigazione |
| Contenuto della Category | Testo, immagini, banner, metadati, blocchi o contenuto di landing page | SEO, merchandising e spiegazione della pagina Category |
| Regole di ordinamento e visualizzazione | Ordine manuale, ordinamento predefinito, posizionamento in evidenza o ranking algoritmico | Quali Products il cliente vede per primi |
| Regola di inclusione dinamica | Condizioni che includono automaticamente Products in un gruppo | Collezioni automatiche, Categories intelligenti, gruppi stagionali e manutenzione operativa |
Questi livelli possono essere strettamente collegati in una piattaforma e separati in un’altra. È una delle ragioni principali per cui una migrazione del catalogo non può essere valutata contando soltanto le Categories.
Struttura dei dati e relazioni più comuni
Una Category, collection o altro gruppo di catalogo dispone normalmente di un proprio record. Questo può contenere ID interno, nome, slug, riferimento al padre, percorso, stato, ordine, descrizione, immagine, campi SEO, impostazioni di visualizzazione, regole di assegnazione Product e indicatori di visibilità nello store.
Una struttura tipica può includere:
| Campo dati | Funzione tipica | Perché è importante |
|---|---|---|
| ID interno | Identificativo stabile del sistema | Mantiene collegate assegnazioni e riferimenti |
| Nome | Etichetta del gruppo per amministrazione o cliente | Governa visualizzazione, menu e riconoscimento da parte del personale |
| Slug o handle | Identificativo adatto agli URL | Influisce sugli URL della pagina e sui riferimenti da menu o link |
| ID padre | Definisce la Category superiore | Crea gerarchia e profondità di navigazione |
| Percorso o livello | Memorizza la posizione completa nella gerarchia | Supporta breadcrumb, ordinamento e menu annidati |
| Stato o visibilità | Abilita, disabilita, nasconde o pubblica il gruppo | Determina se i clienti possono accedere alla pagina |
| Posizione di ordinamento | Controlla l’ordine dei gruppi o dei Products | Influisce sulle priorità di navigazione e merchandising |
| Descrizione e contenuto | Fornisce spiegazione o testo della landing page | Sostiene SEO, intento d’acquisto e contesto per il cliente |
| Immagine o banner | Rappresentazione visiva del gruppo | Influisce su griglie di Categories e landing page |
| Titolo e descrizione SEO | Metadati per i motori di ricerca | Supportano la presentazione nei risultati organici |
| Relazione di assegnazione Product | Collega Products al gruppo | Determina che cosa compare negli elenchi Product |
| Regola di inclusione | Seleziona automaticamente Products in base a condizioni | Alimenta smart collection o Categories dinamiche |
| Riferimento di menu | Collega il gruppo alla navigazione | Determina se il cliente raggiunge naturalmente la pagina |
L’assegnazione Product è spesso memorizzata separatamente dal record del gruppo. Una relazione molti-a-molti può consentire allo stesso Product di appartenere a più Categories o collections. Un modello rigido a Category singola può richiedere una Category principale. Un modello basato su regole può non memorizzare ogni assegnazione direttamente e includere invece Products in base a condizioni come tipo Product, tag, vendor, brand, valore di attributo, prezzo, stato dell’inventario o data di pubblicazione.
La distinzione tra assegnazione memorizzata e assegnazione calcolata è importante. Una Category statica contiene collegamenti Product espliciti. Una collection dinamica viene ricostruita dalle regole. Una Category guidata dalla ricerca può dipendere da un indice. Una landing page gestita da un’estensione può mostrare Products tramite blocco, widget, modulo o chiamata API anziché mediante l’appartenenza nativa alla Category.
Alberi di Category, collections e modelli tassonomici
Le piattaforme differiscono profondamente nel modo in cui modellano l’organizzazione del catalogo.
Alcune usano principalmente alberi di Categories. Le Categories superiori contengono quelle figlie, che a loro volta possono contenere livelli più profondi, mentre i Products vengono assegnati a uno o più nodi. Questo modello è comune negli store con cataloghi grandi, ricambi, assortimenti B2B, Products tecnici o navigazioni dipartimentali profonde. Offre una gerarchia forte, ma richiede controllo accurato di profondità, denominazione, relazioni padre-figlio e assegnazioni Product.
Altre piattaforme privilegiano le collections. Una collection può comportarsi nello store come una pagina Category, ma la logica sottostante può essere manuale, automatica, basata su tag, tipo Product o altre regole. Le collections consentono maggiore flessibilità di merchandising senza imporre un albero rigido. In cambio, menu, breadcrumb e significato padre-figlio possono dover essere configurati separatamente.
I modelli tassonomici aggiungono un altro livello. Una tassonomia è un sistema di classificazione governato che definisce famiglie Product e attributi previsti. Può essere nativa della piattaforma, importata da un marketplace, gestita da un PIM o mantenuta per feed e canali pubblicitari. La tassonomia non coincide necessariamente con la navigazione dello store. Un Product può essere classificato in un modo per i clienti e in un altro per Google Shopping, feed marketplace, approvvigionamento o reporting.
Lo stesso gruppo commerciale può quindi assumere forme diverse:
| Concetto commerciale | Possibile rappresentazione nella piattaforma |
|---|---|
| Running shoes | Category figlia, collection, smart collection, tipo Product, gruppo di tag, nodo tassonomico o landing page |
| Clearance items | Collection manuale, collection automatica, gruppo di regole prezzo, pagina basata su tag o campagna di merchandising |
| Replacement filters | Percorso Category profondo, tassonomia di compatibilità, risultato di ricerca a faccette o famiglia Product gestita da PIM |
| New arrivals | Collection automatica basata su data di pubblicazione, tag, data di uscita o regola di merchandising |
| Brand page | Category, collection, pagina vendor, landing page, risultato di ricerca o pagina generata da app |
Una migrazione può conservare l’etichetta modificando il modello. Questo può essere accettabile se la rappresentazione di destinazione sostiene lo stesso modo di navigare. Diventa rischioso se un albero di Categories viene appiattito in collections, una smart collection diventa un gruppo statico o una landing page di Category viene ridotta a un semplice elenco Product.
Navigazione, menu e breadcrumb sono livelli di dati separati
Un gruppo di catalogo può esistere senza comparire nel menu dello store. Un menu può puntare a una pagina che non è una Category nativa. Un breadcrumb può derivare dalla gerarchia, dal percorso di menu, dal percorso URL, dall’assegnazione Product, dalla logica del tema o da un’app.
Questa separazione conta perché i clienti sperimentano la struttura del catalogo attraverso la navigazione, non attraverso i record del database. Una Category può migrare correttamente come record, ma il cliente può perdere il percorso che prima lo guidava fino a quella pagina.
I menu hanno spesso una propria struttura dati. Una voce può contenere etichetta, destinazione del collegamento, voce padre, posizione, impostazioni di visibilità, ambito di mercato o lingua, icona, immagine, badge, layout mega-menu e riferimenti a blocchi personalizzati. I mega menu possono includere collegamenti alle Categories, Products in evidenza, immagini, blocchi promozionali o sottomenu curati manualmente.
Anche i breadcrumb possono funzionare diversamente. Alcune piattaforme li derivano dall’albero delle Categories. Altre usano il percorso di menu, la collection principale del Product, il percorso URL o regole del tema. Un Product assegnato a più Categories può richiedere un percorso principale per la visualizzazione del breadcrumb. In assenza di tale percorso, i breadcrumb possono diventare incoerenti o fuorvianti.
Per la pianificazione del catalogo, la distinzione tecnica fondamentale è:
| Livello | Domanda tecnica |
|---|---|
| Gruppo di catalogo | La Category, collection o nodo tassonomico esiste? |
| Relazione Product | I Products sono collegati al gruppo corretto? |
| Navigazione | I clienti possono raggiungere il gruppo attraverso il percorso di menu previsto? |
| Breadcrumb | Lo store mostra il percorso e il contesto previsti? |
| Landing page | La pagina del gruppo mantiene contenuto, merchandising e modalità di visualizzazione? |
Un risultato affidabile richiede che tutti e cinque i livelli funzionino insieme.
Assegnazione Product e presenza in più percorsi
L’assegnazione Product determina dove vengono visualizzati i Products. In cataloghi semplici, un Product può appartenere a una sola Category. Negli store maturi, i Products compaiono normalmente in più contesti: brand, reparto, gruppo promozionale, collection stagionale, gruppo di compatibilità, percorso ricambi, guida regalo, contesto bundle o pagina di campagna.
Il modo in cui questa presenza multipla viene gestita dipende dalla piattaforma. Alcune permettono un numero illimitato di assegnazioni a Categories. Altre usano collections, tag, tipi Product, campi vendor, canali di vendita o campi personalizzati. Alcune supportano una Category principale per percorsi canonici e breadcrumb. Altre considerano equivalenti tutte le appartenenze.
Questo influisce su più aspetti dello store:
| Modalità di assegnazione | Possibile effetto |
|---|---|
| Il Product appartiene a più Categories | Può comparire in più percorsi, ma percorso canonico e breadcrumb possono richiedere regole |
| Il Product ha una Category principale | Gerarchia più forte, ma meno contesti di navigazione se mancano assegnazioni secondarie |
| Il Product è assegnato tramite tag o regola | Manutenzione più semplice, ma i risultati dipendono dalla qualità dei tag e dalla precisione delle regole |
| Il Product compare tramite ricerca o logica di un’app | Visualizzazione flessibile, ma la migrazione dei soli dati Category nativi può non preservarne il funzionamento |
| Il Product è nascosto in un canale ma visibile in un altro | Store, marketplace, cataloghi B2B e regionali possono divergere |
Un Product di alto valore può migrare correttamente come record e fallire comunque dal punto di vista commerciale se scompare da un importante percorso di Category. La convalida basata soltanto sul conteggio Products non rileva il problema se i campioni di assegnazione non includono Categories critiche per i ricavi e Products presenti in più gruppi.
Gruppi statici, gruppi dinamici e smart collections
I gruppi di catalogo possono essere statici o dinamici. Un gruppo statico memorizza assegnazioni Product esplicite. Un gruppo dinamico include Products quando soddisfano determinate condizioni.
Il raggruppamento dinamico può dipendere da:
- tag Product;
- tipo Product;
- vendor o brand;
- prezzo o stato promozionale;
- disponibilità dell’inventario;
- data di pubblicazione o uscita;
- valori degli attributi;
- valori delle varianti;
- gruppo cliente o mercato;
- metafield Product o campi personalizzati;
- regole gestite da app;
- condizioni dell’indice di ricerca.
Smart collections e Categories automatiche possono ridurre la manutenzione manuale, ma introducono dipendenze tecniche. Il gruppo non è soltanto il nome di una Category: è un insieme di regole più un modello Product che deve continuare a soddisfarle.
Una collection dinamica come Summer Dresses Under $100 può dipendere da tipo Product, tag stagionale, genere, Category, prezzo, inventario e stato di pubblicazione. Se uno di questi campi cambia modello nella piattaforma di destinazione, la collection può diventare incompleta o troppo ampia. Una Category che prima si aggiornava automaticamente può diventare statica dopo la migrazione se la piattaforma di destinazione non riesce a rappresentare la stessa logica condizionale.
I gruppi dinamici richiedono una verifica più rigorosa di quelli statici perché il rischio può manifestarsi in ritardo. La collection può apparire corretta al lancio e smettere di includere i nuovi Products in futuro se la regola non è stata ricreata o non viene mantenuta.
Landing page di Category e strutture di contenuto
Le pagine Category contengono spesso molto più di un elenco Product. Una landing page può includere testo introduttivo, contenuto SEO, banner, video incorporati, guide all’acquisto, blocchi FAQ, collegamenti interni, sottocategorie in evidenza, caroselli Product, riquadri promozionali o sezioni create con page builder.
Questi contenuti possono essere memorizzati in luoghi diversi a seconda della piattaforma:
| Tipo di contenuto | Possibile posizione di memorizzazione |
|---|---|
| Descrizione Category | Campo Category nativo, descrizione collection, blocco CMS, metafield, campo personalizzato |
| Immagine banner | Immagine Category, sezione del tema, blocco page builder, libreria media, dati di app |
| Metadati SEO | Campi SEO nativi, campi di plugin/modulo, campi CMS, impostazioni tema |
| Products in evidenza | Ordinamento manuale Category, modulo merchandising, blocco Product, regola app |
| Contenuto di guida all’acquisto | Pagina CMS, blocco di contenuto Category, articolo blog, template page builder |
| Collegamenti interni | HTML della descrizione, blocchi menu, sezioni tema, dati di modulo personalizzato |
Una landing page può quindi sembrare una Category ma dipendere tecnicamente da dati CMS, impostazioni del tema, campi personalizzati o estensioni. Se questi componenti non vengono identificati, la Category può migrare come semplice pagina elenco e perdere il contenuto che le dava valore.
Qui Section 6 deve restare distinta dai temi SEO di Section 2. Questo approfondimento tecnico non riguarda la strategia dei redirect: riguarda la memorizzazione strutturale e le dipendenze dietro il contenuto delle pagine Category. La pianificazione di URL e redirect appartiene altrove; l’architettura dati della pagina Category appartiene qui.
Ordinamento, merchandising e regole di visualizzazione
Le pagine Category e collection dipendono spesso da regole di presentazione. L’ordine dei Products può essere alfabetico, dal più recente, per prezzo, per volume di vendite, curato manualmente, sensibile alla disponibilità, basato sul punteggio di ricerca, guidato dal margine o controllato da un’app.
I dati di merchandising possono includere:
- posizione manuale dei Products nella Category;
- indicatori di Product in evidenza;
- Products fissati in alto;
- Products promossi;
- Products esclusi;
- regole di ordinamento specifiche per Category;
- visibilità specifica per gruppo cliente;
- visibilità per mercato o canale;
- ordinamento sensibile all’inventario;
- ranking gestito da app;
- regole del provider di ricerca che promuovono o retrocedono Products.
Questi dettagli sono facili da perdere perché a prima vista non sembrano parte della struttura del catalogo. Una Category può contenere i Products corretti ma presentarli nell’ordine sbagliato. Nelle Categories ad alto traffico, l’ordine può influire su ricavi, smaltimento delle scorte, stagionalità e ricerca dei Products.
Quando le piattaforme di origine e destinazione usano modelli di merchandising diversi, la conservazione può richiedere la conversione di un elenco di posizioni manuali, la ricostruzione delle regole delle collections, il ripristino delle regole di ranking della ricerca o l’accettazione di un nuovo modello di ordinamento. La decisione corretta dipende da quanto lo store si affida a una presentazione Product curata.
Funzionamenti specifici delle diverse piattaforme
Le famiglie di piattaforme creano difficoltà differenti per il catalogo.
Le piattaforme SaaS separano spesso collections, menu di navigazione, tag Product e sezioni del tema. Questo può semplificare l’amministrazione, ma anche creare distanza tra l’oggetto dati e il percorso nello store. Una collection può esistere senza essere inserita nel menu. Un tag può alimentare una collection automatica. Un tema o un’app può controllare filtri, banner e blocchi Product nelle pagine collection.
Le piattaforme Open-Source espongono spesso alberi di Categories più profondi, set di attributi, moduli e relazioni a livello database. Possono supportare gerarchie complesse e comportamenti di catalogo personalizzati, ma lo store può dipendere da estensioni, tabelle personalizzate, sistemi di URL rewrite o override del tema che non fanno parte dei record Category standard.
Le piattaforme enterprise e B2B possono definire cataloghi per gruppo cliente, listino prezzi, account aziendale, canale di vendita, area geografica, contratto o flusso di approvazione. Un Product può esistere globalmente ma essere mostrato soltanto in determinate viste di catalogo specifiche per cliente. La struttura delle Categories può quindi dipendere da permessi, gerarchia degli account, ruoli degli acquirenti o prezzi contrattuali.
Gli store collegati ai marketplace o governati da un PIM possono mantenere una struttura di navigazione per lo store e una diversa struttura di classificazione per i canali esterni. Il PIM può governare tassonomia, attributi, famiglie Product e assegnazioni alle Categories, mentre lo store consuma soltanto l’output pubblicato. In questo modello, la pianificazione deve identificare quale sistema sia davvero autorevole per il catalogo.
Che cosa può cambiare quando il modello di catalogo viene ricreato
La struttura del catalogo può cambiare in modi che non emergono dal semplice conteggio dei record.
| Cambiamento strutturale | Possibile effetto |
|---|---|
| Un albero profondo diventa un insieme di collections piatte | I clienti perdono gerarchia, breadcrumb e percorsi di affinamento |
| Categories statiche diventano collections dinamiche | La manutenzione futura migliora, ma la precisione delle regole diventa fondamentale |
| Collections dinamiche diventano gruppi statici | Il lancio può sembrare corretto, ma l’inclusione futura dei Products diventa manuale |
| Il contenuto Category diventa semplice testo descrittivo | Layout della landing page, collegamenti interni e blocchi promozionali possono indebolirsi |
| La struttura di menu viene ricostruita separatamente | Le Categories esistono, ma possono mancare i percorsi di navigazione previsti |
| Le assegnazioni Product vengono ricalcolate dai tag | L’appartenenza ai gruppi dipende dalla coerenza dei tag e dal disegno delle regole |
| L’ordine manuale viene perso | La Category contiene i Products corretti ma offre un merchandising più debole |
| La Category principale non viene preservata | Breadcrumb, percorsi canonici e reporting possono diventare incoerenti |
Non ogni cambiamento è sbagliato. Una migrazione può essere l’occasione per semplificare un albero disordinato, sostituire Categories duplicate con collections più pulite o passare dal raggruppamento manuale a quello basato su regole. Il punto importante è che si tratta di decisioni architetturali, non di effetti collaterali accidentali.
Che cosa dovrebbero controllare i merchant
La verifica del catalogo dovrebbe iniziare da percorsi di navigazione rappresentativi, non dall’elenco completo delle Categories.
Una revisione pratica dovrebbe includere:
- percorsi Category che generano più ricavi;
- pagine Category o collection con elevato traffico organico;
- gerarchie profonde con più livelli padre-figlio;
- Products assegnati a più Categories o collections;
- smart collections o Categories automatiche;
- pagine Category con contenuti di landing page;
- pagine con ordinamento Product manuale, posizionamento in evidenza o regole di merchandising;
- strutture di menu, mega menu e funzionamento dei breadcrumb;
- cataloghi specifici per gruppo cliente, B2B, mercato o canale;
- strutture di catalogo governate da PIM, ERP, provider di ricerca, app, moduli o codice personalizzato.
Per ogni campione, il merchant dovrebbe confrontare struttura dati e comportamento nello store. Il gruppo esiste? I Products corretti sono assegnati? Il percorso è raggiungibile dalla navigazione? I breadcrumb hanno senso? La pagina preserva contenuto e significato del merchandising? Se il gruppo era basato su regole, continua ad aggiornarsi automaticamente? La piattaforma di destinazione rappresenta la stessa gerarchia oppure l’ha trasformata in un modello diverso?
La revisione deve inoltre identificare la proprietà dei dati. Se la gerarchia del catalogo viene mantenuta in un PIM, ERP, feed marketplace o modulo amministrativo personalizzato, la piattaforma dello store può non essere la vera fonte del modello. Preservare soltanto lo store può quindi non preservare il processo operativo.
Quando la struttura del catalogo richiede una revisione più approfondita
La struttura del catalogo richiede una revisione più approfondita quando la navigazione dipende da elementi che vanno oltre i record Category standard.
Una revisione approfondita è normalmente necessaria quando:
- le piattaforme di origine e destinazione adottano modelli diversi di Category, collection o tassonomia;
- lo store usa gerarchie profonde, Products presenti in più Categories o un comportamento importante legato alla Category principale;
- le pagine Category includono contenuti ricchi, blocchi CMS, banner, layout page builder o strutture di collegamenti interni;
- smart collections, gruppi automatici, regole di ricerca, tag, attributi o logica di app governano l’inclusione dei Products;
- ordine manuale, posizionamento in evidenza, Products fissati o regole di merchandising incidono sui ricavi;
- menu, mega menu, breadcrumb o logica del tema sono separati dai record Category;
- cataloghi per gruppo cliente, B2B, mercato, canale o contratto influenzano la visibilità;
- PIM, ERP, marketplace o sistemi di ricerca governano parte del modello di classificazione del catalogo.
Quando il modello di catalogo non può essere rappresentato tramite un trasferimento diretto di Categories o collections, il progetto deve definire una rappresentazione di destinazione per gerarchia, navigazione, campi personalizzati, menu, contenuto delle landing page e proprietà dei sistemi esterni. Qualsiasi progettazione personalizzata della migrazione deve restare legata a questo risultato specifico del catalogo.
Conclusione
La struttura del catalogo è l’architettura dei dati alla base della navigazione dei Products. Collega Categories, collections, tassonomie, assegnazioni Product, menu, breadcrumb, landing page, regole di ordinamento e merchandising nel percorso rivolto al cliente che conduce dall’intento alla scoperta del Product.
Una transizione affidabile non conserva soltanto i nomi delle Categories. Deve preservare le relazioni e il funzionamento che rendono il catalogo utilizzabile: gerarchia, raggiungibilità, logica di assegnazione, raggruppamento dinamico, contesto dei contenuti e ordine di merchandising. La preparazione più solida consiste nell’esaminare il catalogo come insieme di percorsi di navigazione e dipendenze strutturali prima di presumere che i record Category rappresentino da soli l’intera esperienza di catalogo.
Domande frequenti
Categories e collections sono la stessa cosa?
No. Possono apparire simili nello store, ma dipendere da modelli dati diversi. Le Categories implicano spesso una gerarchia. Le collections possono essere manuali, basate su regole, tag o tema. La struttura di destinazione corretta dipende dal funzionamento che lo store deve mantenere.
Perché una Category può esistere ma non comparire nella navigazione?
I record Category e i menu sono spesso separati. Una Category o collection può esistere nell’amministrazione senza essere collegata al menu dello store, al mega menu, al percorso breadcrumb o alla struttura della landing page usata dai clienti.
Qual è la differenza tra gruppi di catalogo statici e dinamici?
Un gruppo statico memorizza assegnazioni Product esplicite. Un gruppo dinamico include Products quando soddisfano regole come tag, tipo Product, vendor, prezzo, disponibilità, valore di attributo o data di pubblicazione. I gruppi dinamici richiedono la conservazione delle regole, non soltanto del nome.
Perché l’assegnazione Product è importante se tutti i Products sono migrati?
I clienti non navigano direttamente nei record Product. Navigano attraverso Categories, collections, risultati di ricerca e menu. Un Product migrato può perdere visibilità commerciale se manca da un percorso di navigazione importante.
Quando la gerarchia del catalogo richiede una gestione personalizzata?
Può essere necessaria quando la gerarchia dipende da dati di estensioni, menu personalizzati, regole dinamiche, contenuti page builder, proprietà esterna di PIM o ERP, cataloghi specifici per cliente oppure da un modello della piattaforma di origine che non trova una corrispondenza diretta nella piattaforma di destinazione.