Punti Chiave
- Mantieni la gerarchia a 3 o 4 livelli. Strutture più profonde creano debito di manutenzione e confondono sia gli utenti che i motori di ricerca.
- Denomina le categorie in base a come i buyer cercano i prodotti, non a come i tuoi team interni li organizzano.
- Separa la struttura tassonomica dall'assegnazione degli attributi. Risolvono problemi diversi.
- Una tassonomia senza governance si degrada rapidamente. Definisci responsabilità e un processo di modifica dal primo giorno.
- Un sistema PIM è il posto giusto per mantenere la tassonomia su larga scala. I fogli di calcolo collassano di fronte alla complessità.
La tassonomia prodotti è la struttura categoriale che organizza il tuo catalogo. Se implementata bene, aiuta i buyer a trovare i prodotti rapidamente, permette ai motori di ricerca di comprendere la tua offerta e fornisce al tuo team operativo una base solida per filtraggio, reporting e distribuzione multi-canale. Se implementata male, crea lacune di reperibilità, spinge i buyer ad abbandonare le ricerche e genera anni di lavoro di pulizia.
La maggior parte dei problemi di tassonomia non sono difetti di design. Sono difetti di governance che hanno iniziato con una struttura ragionevole e poi sono cresciuti senza controllo.
Cosa include effettivamente la tassonomia prodotti
La tassonomia non è la stessa cosa degli attributi, e confondere i due causa veri problemi a valle.
La tua tassonomia è l'albero gerarchico: categorie padre, categorie figlie e raggruppamenti logici che si trovano tra loro. Una categoria padre come "Utensili Elettrici" raggruppa più categorie figlie come "Trapani", "Avvitatori ad Impatto" e "Levigatrici". Gli attributi sono le caratteristiche assegnate ai prodotti all'interno di quelle categorie, come voltaggio, materiale o capacità di carico. Entrambi hanno importanza, ma esistono a livelli diversi del tuo modello di dati prodotto e richiedono processi decisionali diversi.
Una tipica tassonomia ben strutturata per un produttore di attrezzature industriali potrebbe assomigliare a questa: Utensili Elettrici > Utensili Pneumatici > Avvitatori ad Impatto. Ogni livello restringe il tipo di prodotto. Attributi come dimensione del disco, intervallo di coppia e tipo di connettore descrivono quindi i singoli SKU all'interno degli Avvitatori ad Impatto. Mescolare questi livelli, ad esempio creando una categoria chiamata "Avvitatori ad Impatto ad Alta Coppia", collassa un valore di attributo nella struttura. Sembra innocuo inizialmente. Moltiplicalo per un catalogo di 40.000 SKU e finisci con centinaia di nodi foglia semi-ridondanti che sono praticamente impossibili da mantenere.
Quanto profonda dovrebbe essere la tua tassonomia prodotti
Tre o quattro livelli sono il limite pratico per la maggior parte dei cataloghi. Al di là di ciò, gli utenti perdono l'orientamento e il tuo team dati spende tempo significativo nel mantenimento di nodi che vedono quasi nessun traffico.
Un albero a tre livelli funziona bene per cataloghi focalizzati: categoria ampia, tipo di prodotto, sottotipo. Un quarto livello è giustificato quando i tipi di prodotto sono abbastanza complessi da garantirlo, come l'equipaggiamento di sicurezza che si suddivide per tipo di pericolo, poi zona del corpo, poi standard di certificazione. Quello che raramente funziona è un quinto o sesto livello aggiunto per accommodare casi limite o strutture SKU legacy importate da un ERP. Questi casi sono meglio gestiti con attributi e filtri.
La domanda guida per ogni livello aggiuntivo è: un buyer naviga effettivamente qui, o si tratta solo di logica di organizzazione interna?
Se la risposta è la seconda, appiattiscila. La logica interna appartiene agli attributi, non alla gerarchia. Alcuni cataloghi con gamme di prodotti ristrette funzionano effettivamente meglio con una tassonomia piatta a due livelli, dove la categoria di livello superiore si collega direttamente ai tipi di prodotto senza raggruppamenti intermedi. La chiave è se i livelli intermedi aggiungono valore navigazionale reale per il buyer, non se si presentano più ordinati sulla carta. Le varianti di prodotto, come taglie, colori o configurazioni, non dovrebbero mai diventare nodi tassonomici. Appartengono allo strato di attributi.
Denominare le categorie di tassonomia prodotti in modo che i buyer possano usarle
I nomi delle categorie dovrebbero riflettere come i buyer descrivono i prodotti nelle query di ricerca, non abbreviazioni interne o gergo industriale che il tuo team usa nelle operazioni di magazzino.
Nei progetti che abbiamo implementato per distributori di componenti elettrici, spesso trovavamo categorie etichettate con codici o nomi di famiglie di prodotti interni che avevano senso per il team di approvvigionamento ma erano invisibili ai buyer che cercavano per applicazione o standard. Una categoria denominata "Quadri di commutazione BT tipo B" non corrisponde a come un facility manager cerca. "Quadri di distribuzione a bassa tensione" lo fa. La soluzione non è sempre una ristrutturazione completa. A volte è rinominare i nodi esistenti e aggiungere sinonimi come alias di ricerca all'interno del tuo PIM.
Convenzioni di naming da applicare in modo coerente:
- Usa nomi plurali per i nomi delle categorie: "Interruttori Automatici", non "Interruttore Automatico".
- Evita i marchi nei labels delle categorie a meno che tu non venda linee di prodotti specifiche per marca dove il marchio è il termine di ricerca primario.
- Usa il termine industriale più comune, non il termine tecnico più preciso, a meno che i tuoi buyer siano ingegneri che cercano per specifica.
- Sii coerente con la capitalizzazione e la grammatica in tutti i livelli dell'albero.
L'incoerenza nei nomi è il problema di tassonomia più comune che vediamo negli audit dei cataloghi, e si compone rapidamente. Se sia "Guanti di Sicurezza" che "Guanti Protettivi" esistono come nodi separati, i buyer e i motori di ricerca li tratteranno come cose diverse.
La relazione tra tassonomia e SEO
La struttura categoriale influisce direttamente sulle prestazioni della ricerca organica. Ogni nodo categoria che si risolve in un URL è una pagina che Google può eseguire il crawl, indicizzare e classificare. Una tassonomia ben strutturata crea un insieme di pagine categoria con chiari segnali tematici e breadcrumb trails puliti. Una tassonomia gonfia con centinaia di nodi foglia sottili crea spreco di crawl budget, cannibalizzazione di keywords e rischi di contenuto duplicato dove le pagine categoria padre e figlio mirano a query quasi identiche. I tag canonical possono mitigare alcuni di questi problemi, ma sono un workaround per un problema strutturale, non una soluzione.
La ricerca dell'Istituto Baymard ha rilevato che il 33% dei siti mobile non riesce a visualizzare le categorie di prodotti come elementi di navigazione di livello superiore, il che interrompe direttamente la reperibilità per gli utenti che arrivano senza un intento di ricerca chiaro e si affidano alla navigazione categoriale per orientarsi.
Per i cataloghi B2B specificamente, le pagine a livello di categoria spesso catturano traffico di ricerca nel mezzo del funnel. Un buyer che cerca "avvitatori ad impatto pneumatici 1/2 pollice" sta cercando una categoria o un elenco filtrato, non uno SKU specifico. Se la tua tassonomia non crea una struttura URL che corrisponda a queste query, perdi quel traffico prima che il visitatore raggiunga mai una pagina di prodotto.
Anche il contenuto della pagina categoria è importante qui. Un breve paragrafo descrittivo su una pagina categoria, che copra cosa include la categoria e quali specifiche contano, migliora significativamente le classifiche e aiuta i buyer a confermare che sono nel posto giusto.
Ampiezza della categoria e il ruolo del filtraggio faceted
Al livello superiore, punta a 7-12 categorie. Sotto di esse, ogni nodo padre dovrebbe avere tra 5 e 15 figli. Questi non sono limiti rigidi ma riflettono come i buyer effettivamente scansionano i menu di navigazione e come i motori di ricerca ponderano la profondità della categoria.
Quando un nodo padre ha solo uno o due figli, il livello intermedio è di solito non necessario. Quando ne ha 30 o più, i buyer non possono scansionarlo efficientemente e la categoria probabilmente ha bisogno di ristrutturazione in sottocategorie o si basa più pesantemente sul filtraggio faceted.
Il filtraggio faceted e la tassonomia servono scopi correlati ma distinti. La tassonomia gestisce il raggruppamento navigazionale primario. I filtri faceted gestiscono gli attributi variabili all'interno di una categoria, come dimensione, materiale, standard e prezzo. L'errore è usare la tassonomia per fare quello che i filtri dovrebbero gestire. Quando i buyer hanno bisogno di restringere i risultati per più criteri sovrapposti, è un problema di filtraggio, non un problema di tassonomia. Mantenere questa separazione significa anche che la tua tassonomia prodotti rimane stabile man mano che le gamme di prodotti crescono, perché i nuovi valori di attributo non richiedono nuove categorie.
Mappatura degli attributi e allineamento tassonomico
Ogni categoria nella tua tassonomia dovrebbe avere un insieme di attributi definito: i campi specifici che si applicano ai prodotti in quella categoria e nessun altro. È qui che la connessione tra tassonomia e PIM diventa concreta.
In AtroCore, ogni nodo categoria può portare il suo gruppo di attributi. Quando un prodotto viene assegnato a una categoria, eredita automaticamente gli attributi rilevanti. Questo previene il problema comune di prodotti che mancano campi di specifica chiave, che accade quando l'assegnazione degli attributi è manuale e incoerente. Per un produttore che gestisce componenti industriali su dozzine di famiglie di prodotti, questa eredità strutturata è la differenza tra un modello di dati pulito e un catalogo pieno di lacune.
L'insieme di attributi dovrebbe essere definito al livello più basso applicabile. Se tutti gli utensili elettrici condividono gli stessi campi di certificazioni di sicurezza, quelli appartengono al livello "Utensili Elettrici". Se le specifiche di coppia si applicano solo agli utensili ad impatto, quelle appartengono al livello "Utensili ad Impatto". Assegnare attributi troppo in alto nella gerarchia crea rumore. Assegnarli troppo in basso significa che vengono duplicati su categorie sorelle. In entrambi i casi, la completezza dei dati soffre, e i dati di prodotto incompleti sono il motivo più comune per cui i buyer abbandonano una pagina di prodotto B2B senza convertire.
Governance della tassonomia: la parte che la maggior parte delle aziende salta
Una tassonomia prodotti costruita in un trimestre può diventare un problema di manutenzione dati entro un anno se non esiste un processo di governance. I prodotti vengono aggiunti, le categorie si moltiplicano, e i team prendono decisioni locali che entrano in conflitto con la struttura originale.
La governance non deve essere complessa. Deve definire chi può proporre una nuova categoria o rinominare una categoria esistente, come appare il processo di approvazione prima che un cambiamento vada in live, e con quale frequenza la tassonomia viene verificata per nodi ridondanti o vuoti. Quelle tre cose, documentate e assegnate a proprietari designati, sono sufficienti per prevenire la deriva strutturale che rompe la maggior parte delle implementazioni di tassonomia di prodotto.
I nostri clienti spesso vengono da noi dopo aver gestito i loro cataloghi per diversi anni senza questo. Tipicamente hanno nodi categoria con meno di 5 prodotti, nodi duplicati con nomi leggermente diversi, e nomi di categoria che non corrispondono più alle offerte di prodotto attuali perché l'offerta si è evoluta ma la struttura no.
Il processo di audit è semplice in un sistema come AtroCore: filtra le categorie per numero di prodotti, contrassegna i nodi sotto una soglia, rivedi rispetto ai dati di analisi della ricerca, e unisci o depreca di conseguenza. Senza un PIM, quell'audit è un esercizio manuale che quasi mai accade secondo il programma.
Tassonomia per distribuzione multi-canale
I produttori e i distributori B2B raramente pubblicano il loro catalogo in un unico posto. Una strategia di prodotto omnichannel significa che gli stessi dati di prodotto devono essere classificati correttamente su un negozio web, ERP, portali distributore e marketplace come Amazon o piattaforme specifiche del settore che usano i loro standard tassonomici, inclusa la Classificazione Globale Prodotti GS1 o eCl@ss.
La risposta pratica è mantenere una tassonomia prodotti interna come struttura di dati master, la singola fonte di verità per la categorizzazione dei prodotti, quindi mapparla a schemi esterni secondo necessità. Provare a costruire la tua tassonomia interna attorno a GS1 o eCl@ss da zero produce quasi sempre una struttura che è troppo rigida per la gestione dati prodotto quotidiana. Lo strato di mapping gestisce la traduzione.
AtroPIM lo supporta con le sue funzionalità di gestione dei canali. Definisci una volta la tua tassonomia interna, poi configura le mappature di categoria e attributi per canale. Quando un prodotto passa a un marketplace o a un feed distributore, porta la classificazione tradotta che quel canale si aspetta, senza toccare la struttura master.
Akeneo gestisce adeguatamente la distribuzione multi-canale per i casi d'uso mid-market ma diventa costoso man mano che il numero di canali cresce. Pimcore offre flessibilità al costo della complessità di implementazione. Salsify si concentra sui canali retail e funziona bene per i beni di consumo ma manca di profondità per i cataloghi B2B industriali. Il modello open-source di AtroPIM e l'architettura modulare danno ai produttori la flessibilità di configurare la logica tassonomica e le mappature di canale senza vincoli di licensing per posto, il che ha importanza su larga scala.
Dove il lavoro di tassonomia vive effettivamente
I fogli di calcolo funzionano per cataloghi con poche centinaia di SKU. Al di là di ciò, diventa ingestibile. I fogli di calcolo non possono applicare regole di gerarchia, non supportano l'eredità degli attributi e non hanno cronologia delle modifiche. Quando due team modificano lo stesso file, i conflitti non vengono rilevati.
Un sistema PIM è l'infrastruttura giusta per la tassonomia su larga scala. Memorizza l'albero di categorie, applica regole strutturali, collega le categorie ai set di attributi e traccia ogni modifica con un timestamp e utente. Per i produttori o i distributori che gestiscono migliaia di SKU su più lingue e canali di vendita, la tassonomia vive nel PIM e il PIM alimenta tutto ciò che segue.
Quell'infrastruttura si ripaga oltre il catalogo stesso. L'onboarding dei fornitori diventa più veloce quando i nuovi prodotti arrivano con la mappatura categoriale e i requisiti di attributo già definiti. I prodotti si adattano alle giuste categorie padre e figlie, ereditano il set di attributi corretto e sono pronti per la revisione senza un passaggio di categorizzazione manuale per ogni voce. La logica di cross-sell e upsell dipende anche dalla tassonomia pulita: quando i prodotti sono categorizzati in modo coerente e i loro attributi sono completi, diventano possibili regole di relazione prodotto affidabili: accessori che corrispondono a un prodotto principale, componenti compatibili, specifiche alternative a un prezzo diverso. Niente di questo funziona quando la categorizzazione è incoerente.
La domanda non è se hai bisogno di un PIM per la gestione della tassonomia. È se il dolore di non averne uno è diventato visibile.
La maggior parte delle aziende raggiunge quel punto di flesso quando il loro catalogo cresce oltre 2.000-3.000 SKU attivi, o quando un secondo canale di vendita richiede una struttura di classificazione prodotto diversa.
Ottenere la tassonomia prodotti giusta prima di scalare è significativamente meno costoso che ristrutturarla dopo. La struttura core, le convenzioni di naming, i limiti di profondità, la logica di mappatura degli attributi e il processo di governance dovrebbero tutti essere definiti prima che i prodotti vengono importati. Una migrazione di tassonomia dopo il fatto, quando migliaia di SKU sono già assegnati a una struttura incoerente, è uno dei progetti di pulizia dati più lunghi che un team di catalogo possa affrontare. Tutto dopo una build iniziale pulito è manutenzione e iterazione, che è gestibile. Retrofit di un'importazione di foglio di calcolo piatta in una gerarchia governata non lo è.