Gli attributi Product sono informazioni strutturate che descrivono che cosa sia un prodotto, come possa essere confrontato e in che modo i clienti possano restringere un catalogo ampio fino a ottenere un insieme pertinente di Products. In un catalogo ridotto può bastare il titolo del prodotto, mentre store più grandi dipendono da attributi come materiale, colore, taglia, capacità, compatibilità, tensione, finitura, brand, vestibilità, istruzioni di cura, quantità per confezione, certificazione, anno del modello o caso d’uso.
I sistemi di filtro trasformano queste informazioni strutturate in percorsi che aiutano il cliente a trovare ciò che cerca. Un filtro non è soltanto un controllo visibile in una barra laterale. È il risultato di decisioni su dove vengono memorizzate le informazioni Product, se i valori sono normalizzati, quali campi possono diventare faccette, come le Categories stabiliscono i filtri rilevanti e se lo store, il tema, il servizio di ricerca o un’app riescono a interpretare quei valori in modo coerente.
La difficoltà tecnica nasce dal fatto che le piattaforme e-commerce non gestiscono attributi e filtri secondo un unico modello. Una piattaforma può utilizzare attributi Product nativi. Un’altra può basarsi su tag, collezioni, metafield, campi di tassonomia, opzioni Product, campi specifici per Category, dati di filtro gestiti da un’app o regole dell’indice di ricerca. La stessa caratteristica commerciale può quindi essere un campo di confronto in uno store, una faccetta di filtro in un altro, un’opzione di variante in un terzo e un campo personalizzato in un altro ancora.
Che cosa rappresentano gli attributi Product in uno store e-commerce
Un attributo Product è una caratteristica strutturata associata a un prodotto, una famiglia di Products, una variante, una Category o una tassonomia di catalogo. Gli attributi permettono allo store di descrivere i Products con un formato coerente, così che clienti, personale, sistemi di ricerca, strumenti di reporting e canali esterni possano interpretare il catalogo oltre le descrizioni Product in testo libero.
Gli attributi possono svolgere funzioni diverse:
| Funzione dell’attributo | Esempi comuni | Funzionamento dello store interessato |
|---|---|---|
| Informazioni descrittive | Materiale, finitura, istruzioni di cura, dimensioni, capacità | Pagine di dettaglio Product e tabelle comparative |
| Ricerca e filtro | Colore, taglia, brand, compatibilità, specifica tecnica | Filtri di Category, faccette di ricerca e affinamento della navigazione |
| Informazioni per il merchandising | Stagione, collezione, stile, badge, caso d’uso | Raggruppamento Products, etichette, ordinamento e presentazioni promozionali |
| Informazioni operative | Classe di pericolo, requisito di stoccaggio, classe di spedizione, tipo di garanzia | Evasione degli ordini, conformità, gestione del servizio e processi interni |
| Informazioni per canali o feed | Categoria prodotto Google, attributi marketplace, condizione, genere, fascia d’età | Feed marketplace, annunci, canali shopping e distribuzione delle informazioni Product |
| Regole commerciali personalizzate | Visibilità B2B, indicatore Product con restrizioni, compatibilità dei ricambi | Presentazioni specifiche per cliente, idoneità e funzionamento delle estensioni |
Un buon sistema di attributi non è soltanto un elenco di campi. È una struttura governata che definisce quali caratteristiche contano, dove si applicano, quale tipo di dati contengono, come vengono denominati i valori, se tali valori sono riutilizzabili e se lo store può sfruttarli per aiutare i clienti a trovare Products pertinenti.
Struttura dei dati e campi più comuni
I dati degli attributi contengono normalmente molto più di un’etichetta visibile. Dietro un filtro dello store come Color: Black, una piattaforma può memorizzare un codice interno, un’etichetta di visualizzazione, un tipo di dati, un ID valore, l’etichetta del valore, l’ambito di applicazione, la posizione nell’ordinamento, l’assegnazione alla Category, la traduzione e l’impostazione che stabilisce se il campo può essere usato come filtro.
Una tipica struttura di attributi può includere:
| Componente dei dati | Che cosa controlla | Esempio |
|---|---|---|
| Codice o chiave dell’attributo | Identità interna del campo usata dalla piattaforma o dalle integrazioni | color, screen_size, material |
| Etichetta dell’attributo | Nome visualizzato al cliente o nell’amministrazione | Color, Screen Size, Material |
| Tipo di dati | Modalità con cui il valore viene memorizzato e convalidato | Testo, numero, decimale, booleano, data, elenco a selezione singola, selezione multipla, file, JSON |
| Insieme di valori | Elenco controllato dei valori ammessi | Black, White, Navy, Red |
| ID o slug del valore | Riferimento interno stabile del valore | black, navy-blue, value_1042 |
| Ambito di applicazione | Dove si applica l’attributo | Globale, specifico per Category, specifico per tipo Product, specifico per mercato |
| Livello proprietario | Se il valore appartiene al Product, alla variante, alla Category o a un oggetto personalizzato | Materiale a livello Product; colore a livello variante |
| Impostazione di visualizzazione | Se il valore compare nella pagina Product | Visibile, nascosto, solo amministrazione, solo canale |
| Impostazione di filtro | Se il valore può diventare filtro dello store o faccetta di ricerca | Filtrabile, ricercabile, confrontabile, ordinabile |
| Localizzazione | Etichette tradotte e valori specifici per mercato | Color / Couleur / Farbe |
| Ordine | Come vengono mostrati i valori ai clienti | XS, S, M, L, XL invece dell’ordine alfabetico |
Questi dettagli determinano se gli attributi restano significativi quando il catalogo cresce, quando i clienti filtrano i Products, quando lo store supporta più lingue o quando i Products vengono distribuiti verso canali esterni.
Il tipo di dati è particolarmente importante. Un attributo numerico come potenza, capacità di archiviazione o dimensione dello schermo non dovrebbe essere sempre memorizzato come semplice testo. I valori testuali possono essere leggibili, ma sono più difficili da ordinare, confrontare, usare in filtri per intervallo, normalizzare o convertire tra unità. Valori come 12, 12 in, 12 inches, 1 ft e 30.48 cm possono rappresentare informazioni correlate, ma la piattaforma può considerarli stringhe indipendenti se la struttura dei dati non è normalizzata.
Differenze tra attributi, opzioni, varianti, tag e campi personalizzati
Attributi, opzioni, varianti, tag e campi personalizzati possono apparire simili nello store, ma non hanno lo stesso significato tecnico.
Le opzioni definiscono normalmente le scelte disponibili al cliente nella pagina Product. Se una scelta genera uno SKU acquistabile con prezzo, inventario, immagine, codice a barre o modalità di evasione propri, quella scelta appartiene al modello delle varianti. Gli attributi, invece, descrivono o classificano in genere i Products, anche quando vengono utilizzati anche per i filtri.
I tag sono spesso etichette di classificazione più leggere. Possono essere utili per raggruppare Products, costruire collezioni, attivare regole di merchandising o alimentare filtri semplici. Tuttavia, di norma sono meno governati degli attributi formali. Un sistema di tag può ammettere duplicati, grafie incoerenti, etichette usate nei processi interni e significati commerciali diversi. Questa flessibilità diventa problematica quando i tag vengono mostrati direttamente ai clienti come filtri.
Campi personalizzati, metafield o campi gestiti da estensioni possono memorizzare informazioni Product strutturate al di fuori del modello standard degli attributi. Possono contenere dati di compatibilità, specifiche tecniche, badge, etichette Product, specifiche scaricabili, informazioni sulla garanzia, valori nutrizionali, dati di compatibilità dei ricambi o identificativi per le integrazioni. Alcuni campi personalizzati servono soltanto alla visualizzazione; altri alimentano filtri, ricerca, app, tabelle comparative o feed esterni.
La distinzione tecnica è importante perché un valore può esistere nello store senza poter essere utilizzato nel modo previsto. Un materiale salvato nella descrizione può essere visibile ma non filtrabile. Un colore salvato come tag può servire a una semplice collezione ma non essere collegato ai campioni colore. Una taglia salvata come opzione di variante può supportare l’acquisto ma non funzionare come filtro per un’intera Category se la piattaforma non indicizza i valori delle opzioni. Un metafield personalizzato può contenere dati puliti ma rimanere invisibile al sistema di filtri dello store finché non viene configurato come sorgente di filtro.
Set di attributi, tassonomie e campi specifici per Category
I cataloghi ampi raramente usano un unico elenco di attributi per tutti i Products. Una scarpa, un laptop, una bottiglia di vino, un ricambio auto e un cosmetico richiedono campi descrittivi diversi. I sistemi di attributi dipendono quindi spesso da tipi Product, set di attributi, modelli di Category o strutture tassonomiche.
Un set di attributi definisce quali attributi appartengono a una famiglia di Products. Per esempio, l’abbigliamento può richiedere taglia, colore, tessuto, vestibilità, lunghezza delle maniche e istruzioni di cura. L’elettronica può richiedere dimensione dello schermo, memoria, processore, tensione, connettività, garanzia e compatibilità. L’arredamento può richiedere materiale, finitura, dimensioni, portata, tipo di ambiente, necessità di montaggio e classe di consegna.
Una tassonomia è un modello di classificazione strutturato che stabilisce come vengono raggruppati i Products e quali attributi sono rilevanti all’interno di ogni gruppo. Marketplace e canali pubblicitari impongono spesso tassonomie perché Categories diverse richiedono dati Product differenti. Un feed Product può essere rifiutato o ottenere risultati peggiori se mancano attributi importanti per la Category, se sono associati in modo errato o se vengono memorizzati in formati non supportati.
Gli attributi specifici per Category sono particolarmente importanti per i filtri. Uno store non dovrebbe mostrare il filtro della larghezza degli pneumatici in una Category di cosmetici, né un filtro per il tipo di pelle in una Category di elettronica. I sistemi di filtro migliori comprendono il contesto della Category: mostrano i filtri pertinenti quando aiutano il cliente a decidere e nascondono i campi irrilevanti che aggiungono soltanto rumore.
Quando la piattaforma di origine e quella di destinazione adottano modelli tassonomici diversi, gli attributi possono dover essere riassegnati anziché trasferiti campo per campo. Un campo globale nella piattaforma di origine può diventare specifico per Category nella piattaforma di destinazione. In base all’architettura di destinazione, un set di attributi personalizzato può dover diventare un tipo Product, un metafield a livello di collezione, un campo di feed per un marketplace o una faccetta dell’indice di ricerca.
Come filtri e ricerca a faccette utilizzano i dati degli attributi
Un filtro restringe l’elenco dei Products in base a un valore selezionato. Una faccetta è una dimensione di esplorazione prodotta dallo store, dal motore di ricerca o dal sistema di product discovery. Le faccette mostrano spesso conteggi, valori disponibili e possibilità di affinamento in base all’insieme corrente di Products. Entrambi dipendono da dati strutturati, ma il loro funzionamento può variare molto.
Il filtro dipende normalmente da quattro livelli:
| Livello | Che cosa deve funzionare |
|---|---|
| Memorizzazione dei dati | Il valore esiste in un campo che la piattaforma può leggere |
| Normalizzazione dei dati | I valori equivalenti sono denominati e formattati in modo coerente |
| Indicizzazione o configurazione | Il campo è autorizzato a diventare filtro o faccetta |
| Visualizzazione nello store | Il tema, l’app di ricerca o il sistema di product discovery rappresenta correttamente il filtro |
Un attributo migrato può superare il primo livello e fallire comunque nell’esperienza del cliente. Il valore può esistere nell’amministrazione ma non essere indicizzato. Può essere indicizzato ma apparire sotto etichette duplicate. Può comparire come filtro ma produrre risultati incompleti perché alcuni Products memorizzano il valore a livello variante e altri a livello Product.
La ricerca a faccette aggiunge ulteriore complessità perché l’indice di ricerca può non usare lo stesso modello dati del database Product. Un provider di ricerca può appiattire campi Product, unire valori delle varianti, suddividere il testo in token, ignorare tipi di campo non supportati, limitare il numero di valori di una faccetta o richiedere una configurazione esplicita prima che un campo possa essere usato per affinare i risultati. Negli store con molte estensioni, il funzionamento visibile dei filtri può appartenere a un’app di ricerca anziché alla piattaforma core.
Come differiscono i modelli delle piattaforme
Le piattaforme e-commerce espongono i dati utilizzati per la ricerca dei Products attraverso strutture differenti.
Alcune piattaforme SaaS usano soprattutto opzioni Product, tag, tipi Product, collezioni e metafield. I filtri possono dipendere dalle impostazioni native di product discovery, dal supporto del tema, dalla configurazione della ricerca o da sorgenti di filtro gestite da app. Queste piattaforme possono essere efficienti per cataloghi standard, ma richiedono configurazione accurata quando lo store dipende da molte specifiche tecniche, campi di compatibilità o filtri specifici per Category.
Alcune piattaforme Open-Source usano attributi formali, set di attributi, navigazione a livelli, attributi configurabili e indici di filtro gestiti da estensioni. Questi sistemi possono sostenere dati Product ricchi, ma richiedono anche una governance più rigorosa degli attributi. Attributi duplicati, insiemi di valori incoerenti, ambiti errati e codici attributo sovraccarichi possono peggiorare sia l’usabilità amministrativa sia la ricerca nello store.
Le architetture enterprise e composable possono separare le informazioni Product dalla ricerca nello store. Un PIM può essere il sistema di riferimento per le definizioni degli attributi. Una piattaforma commerce può governare i Products vendibili. Un motore di ricerca può governare le faccette. Un CMS può gestire i blocchi di contenuto Product. Un connettore marketplace può gestire i campi specifici del canale. In questi ambienti, migrare gli attributi non è soltanto un’attività della piattaforma commerce: è una decisione sull’architettura dei dati e sulla fonte autorevole.
Gli store orientati ai marketplace aggiungono un altro livello. Amazon, Google, eBay, Walmart e altri canali possono richiedere attributi specifici per Category, etichette di feed, identificativi Product, campi di conformità e valori normalizzati che non corrispondono in modo diretto ai filtri interni dello store. Un valore può essere importante per l’idoneità al marketplace anche se il cliente non lo vede mai nello store.
Funzioni specifiche delle piattaforme e casi limite
I problemi relativi ad attributi e filtri emergono spesso in dettagli invisibili durante una semplice esportazione dei Products.
Un caso limite frequente riguarda la proprietà del valore a livello Product rispetto al livello variante. Il colore può essere un’opzione di variante nell’abbigliamento, un attributo Product nell’arredamento e una faccetta di filtro in entrambi. Se la piattaforma di destinazione indicizza soltanto attributi a livello Product, i valori a livello variante possono non produrre i filtri previsti. Se invece appiattisce tutti i valori delle varianti sul Product principale, il cliente può filtrare fino a un Product che contiene il colore selezionato ma dover comunque scegliere manualmente la variante corretta.
Un altro caso limite riguarda il vocabolario controllato. Un elenco governato di valori mantiene puliti i filtri. Senza questo controllo, lo stesso significato può apparire come Navy, Navy Blue, navy, Dark Blue e Midnight. Alcune piattaforme li considerano valori distinti. Altre possono unirli soltanto tramite configurazione manuale o regole di ricerca. Quanto più coerente è l’autorità sui valori, tanto più affidabile è il funzionamento dei filtri.
Anche gli attributi a selezione multipla possono creare problemi. Un Product può essere compatibile con più modelli, ingredienti, tipi di ambiente, taglie o casi d’uso. Alcune piattaforme memorizzano i valori multipli come array. Altre usano stringhe separate da virgole, tag, tabelle di relazione, campi serializzati o record gestiti da app. Il modello di memorizzazione influisce su filtri, ricerca, esportazione dei feed e reporting.
Localizzazione e ambito di mercato aggiungono ulteriore complessità. L’etichetta di un valore può essere tradotta mantenendo stabile l’ID interno. Nei modelli meno robusti, ogni lingua può creare valori testuali separati. Se Red, Rouge e Rot vengono trattati come valori indipendenti, i filtri multilingue possono frammentarsi. Anche i dati Product specifici per mercato possono cambiare quali filtri compaiono nelle diverse aree geografiche.
Gli attributi nascosti o riservati all’amministrazione devono essere gestiti con attenzione. Uno store può usare indicatori interni per approvvigionamento, raggruppamento dei fornitori, classe di margine, flusso di merchandising, gestione dei materiali pericolosi o esclusione da determinati canali. Esporli come filtri può confondere i clienti o rendere visibili informazioni che dovrebbero rimanere interne.
Che cosa può cambiare quando gli attributi vengono ricreati in un altro modello
Quando gli attributi vengono ricreati in un modello di piattaforma diverso, conservare i record non equivale a conservarne il funzionamento. Lo store deve mantenere la funzione utile di ogni campo, non soltanto il suo valore testuale.
| Cambiamento strutturale | Possibile effetto |
|---|---|
| Gli attributi diventano tag | Raggruppamento più rapido, ma controllo più debole, duplicati e filtri meno precisi |
| I tag diventano attributi | Filtri più puliti per il cliente, ma i tag dei processi interni possono diventare inadatti alla visualizzazione |
| Le opzioni di variante diventano attributi | Confronto migliore, ma possibile perdita del significato di scelta acquistabile |
| Gli attributi diventano metafield | Memorizzazione flessibile, ma i filtri possono richiedere configurazione esplicita |
| I valori numerici diventano testo | I valori restano visibili, ma ordinamento, filtri per intervallo e confronto possono peggiorare |
| Gli attributi globali diventano campi specifici per Category | Maggiore pertinenza, ma i Products possono richiedere la corretta assegnazione alla Category prima che i filtri funzionino |
| I filtri gestiti da estensioni diventano filtri nativi | Configurazione più semplice nella destinazione, ma possibile perdita di funzioni di ricerca avanzate |
Questi cambiamenti possono essere accettabili quando preservano il significato commerciale. Uno store può trasformare intenzionalmente tag disordinati in attributi strutturati per rendere più puliti i filtri. Può spostare un attributo usato raramente in un metafield nascosto. Può normalizzare le unità prima della migrazione affinché i filtri per intervallo funzionino meglio nella piattaforma di destinazione.
Il rischio nasce quando la trasformazione è involontaria. Un valore migrato può essere visibile ma non più ricercabile. Un filtro può apparire ma restituire risultati incompleti. Un campo tecnico può essere conservato ma scollegato dai feed marketplace. Un Product può mantenere il testo dell’attributo ma perdere la relazione tra set di attributi, Category e percorso con cui il cliente trova ciò che cerca.
Come la qualità degli attributi influenza lo store
La qualità degli attributi emerge direttamente nel percorso del cliente. Una struttura debole può far sembrare incompleto, caotico o poco affidabile anche un catalogo che contiene tutti i Products.
I valori duplicati dividono i risultati. Se un cliente filtra per Black, i Products etichettati black, Blk o Matte Black possono essere esclusi pur appartenendo all’insieme desiderato.
Unità incoerenti indeboliscono il confronto. Un filtro per capacità o dimensione non è utile se alcuni Products usano litri, altri millilitri e altri testo descrittivo libero.
Campi sovraccarichi producono filtri poco chiari. Un campo come Material / Finish può contenere Oak - Natural, Oak / Walnut, Powder-coated steel e Leather, black. Per il cliente materiale e finitura potrebbero dover essere dimensioni separate, mentre il campo originario le combina.
Una compilazione incompleta nasconde Products validi. Se solo una parte dei Products di una Category contiene il valore necessario, i risultati filtrati possono sembrare completi pur escludendo articoli pertinenti. Il rischio è particolarmente alto nei cataloghi tecnici, di compatibilità, ricambi, B2B e regolamentati.
Filtri irrilevanti riducono la fiducia. Mostrare ogni attributo globale in ogni Category può creare elenchi lunghi che i clienti ignorano. Un buon sistema di filtro è selettivo e riflette i fattori decisionali che contano nella Category specifica.
Che cosa dovrebbero controllare i merchant
I merchant dovrebbero esaminare attributi e filtri attraverso campioni rappresentativi di Categories, non soltanto confrontando il numero totale di Products.
Una verifica pratica dovrebbe includere:
- Categories ad alto traffico in cui i filtri incidono sulla conversione;
- famiglie di Products con numerose specifiche tecniche;
- Categories in cui i clienti filtrano per compatibilità, idoneità, capacità, taglia, materiale o caso d’uso;
- attributi con molti valori o grafie incoerenti;
- valori che dovrebbero essere numerici ma sono memorizzati come testo;
- filtri alimentati da app, provider di ricerca, moduli o codice personalizzato;
- valori multilingue o multi-mercato;
- tag interni o campi nascosti che non dovrebbero diventare filtri rivolti ai clienti;
- attributi specifici di marketplace o canale che influiscono sull’accettazione dei feed Product.
Per ogni campione, la revisione deve rispondere a domande concrete. Quali campi sono soltanto descrittivi? Quali devono essere ricercabili? Quali devono diventare filtri? Quali devono restare nascosti? Quali valori richiedono normalizzazione? Quali campi si applicano soltanto a determinate Categories? Quali appartengono a Products, varianti, Categories o sistemi esterni? Quale funzionamento dei filtri dipende da tema, app, indice di ricerca o logica di un’estensione?
La verifica più solida mette a confronto tre prospettive: dati amministrativi, funzionamento dello store e output esterno. I dati amministrativi mostrano dove risiedono i valori. Lo store mostra se i clienti riescono effettivamente a usarli. L’output esterno mostra se marketplace, annunci, PIM, ricerca o sistemi di reporting continuano a ricevere i valori previsti.
Quando i dati richiedono una revisione più approfondita
I dati di attributi e filtri richiedono una revisione più approfondita quando lo store dipende da ricerca strutturata, confronto tecnico o percorsi decisionali specifici per Category.
Una revisione approfondita è normalmente necessaria quando:
- filtri importanti dipendono da campi personalizzati, metafield, app, moduli o provider di ricerca;
- la piattaforma di origine e quella di destinazione adottano modelli diversi per set di attributi o tassonomie;
- valori a livello Product e a livello variante vengono mescolati;
- gli attributi devono alimentare feed marketplace, dati PIM o indici di ricerca esterni;
- i valori richiedono normalizzazione, separazione, unione, conversione delle unità o pulizia del vocabolario controllato;
- il funzionamento dei filtri dipende dal contesto della Category, dal gruppo cliente, dal mercato, dalla lingua o dal tema dello store;
- le specifiche tecniche sono commercialmente importanti e non possono essere ridotte a semplici campi testuali.
Quando la mappatura degli attributi influisce sul modo in cui i clienti trovano Products nello store, il requisito può richiedere una mappatura avanzata di campi o relazioni, normalizzazione dei valori, configurazione dei filtri nella piattaforma di destinazione o una progettazione personalizzata della migrazione. I campi personalizzati e i filtri gestiti da estensioni devono essere interpretati soltanto dopo aver compreso il modello degli attributi e il funzionamento previsto per il cliente.
Conclusione
Gli attributi Product e i sistemi di filtro costituiscono l’architettura dei dati che sostiene la ricerca dei Products. Collegano le caratteristiche Product con l’esplorazione delle Categories, le faccette di ricerca, il confronto, il merchandising, i feed esterni e il processo decisionale del cliente.
Una migrazione affidabile non si limita a trasferire i valori degli attributi. Deve mantenere il significato, il livello proprietario, il tipo di dati, la pertinenza per Category, la coerenza dei valori e il funzionamento nello store che rendono utili quegli attributi. La preparazione più sicura consiste nell’esaminare il modello degli attributi prima di definire definitivamente le decisioni di migrazione, soprattutto quando filtri, ricerca, campi personalizzati, tag, tassonomie o feed Product esterni determinano il modo in cui i clienti trovano e valutano i Products.
Domande frequenti
Gli attributi Product sono la stessa cosa dei filtri Product?
No. Gli attributi sono caratteristiche Product strutturate. I filtri sono controlli di ricerca rivolti al cliente che possono utilizzare attributi, tag, opzioni, metafield, campi dell’indice di ricerca o dati gestiti da app.
Tutti gli attributi Product dovrebbero diventare filtri nello store?
No. Dovrebbero diventare filtri soltanto gli attributi che aiutano il cliente a restringere le scelte in un contesto di Category significativo. Campi interni, valori compilati solo parzialmente, tag disordinati e attributi globali irrilevanti possono peggiorare l’esperienza d’acquisto.
Perché i filtri possono smettere di funzionare anche se i dati degli attributi sono ancora presenti?
Un valore può esistere nell’amministrazione ma non funzionare come filtro se non è indicizzato, non è configurato come filtrabile, è memorizzato al livello proprietario sbagliato, è duplicato con etichette incoerenti oppure è controllato da un tema, un’app o un sistema di ricerca che non legge quel campo.
Qual è la differenza tra attributi e tag?
Gli attributi sono normalmente più strutturati e governati. I tag sono spesso etichette flessibili usate per raggruppamento, processi interni, merchandising o filtri semplici. Possono diventare disordinati quando mescolano significati interni e significati destinati ai clienti.
Quando i dati degli attributi richiedono una gestione personalizzata?
Può essere necessaria una gestione personalizzata quando gli attributi risiedono in campi personalizzati, tabelle di estensioni, record gestiti da app, indici di ricerca o strutture PIM, oppure quando i valori richiedono normalizzazione, separazione, unione o trasformazione specifica per Category prima di poter sostenere il modello di ricerca della piattaforma di destinazione.