Cosa rende una scheda prodotto leggibile da un agente d'acquisto

Fa una cosa diversa da quella che fa una persona. Una persona guarda le foto, si fa un'idea, legge due righe di descrizione e decide con criteri che non sa spiegare del tutto. Un agente parte da una richiesta con vincoli espliciti (un budget, una taglia, una data di consegna, una compatibilità) e cerca di verificare quei vincoli uno per uno. Quello che non riesce a verificare, lo tratta come rischio.

La conseguenza pratica ribalta una regola di merchandising consolidata. Nel commercio umano l'ambiguità è a volte utile: non dichiarare i tempi di spedizione evita di scoraggiare l'acquisto, e la scheda vince sull'immagine. Per un agente l'ambiguità è un motivo di esclusione: se non trova la data, non può garantire il vincolo, e passa alla scheda successiva.

Non si tratta di scrivere per una macchina invece che per una persona. Si tratta di rendere risolvibili le informazioni che oggi sono presenti ma implicite: dentro un'immagine, dentro un menu che si apre al clic, dentro una frase che dice "spedizione rapida" invece di un numero di giorni.

Il criterio non è la presenza del dato, è la sua risolvibilità: un valore, un'unità di misura, un posto stabile dove leggerlo. La tabella distingue le due cose, perché quasi tutti i cataloghi che guardo hanno il dato e non hanno la forma.

Perché sono gli unici due vincoli che rendono inutile tutto il resto. Un prodotto perfetto fuori stock non è un'opzione, e un prodotto oltre budget non entra nel confronto. Un agente che deve restituire tre alternative valide li verifica per primi, e quello che non passa quel filtro non arriva mai alla valutazione delle caratteristiche.

Il problema tecnico più comune riguarda proprio questi due campi. In molti e-commerce prezzo e disponibilità non esistono nell'HTML servito: compaiono dopo una chiamata al carrello, o dopo che l'utente ha selezionato una variante. Per un occhio umano è invisibile, perché il browser esegue tutto e la pagina appare completa. Per chi legge la risposta del server, quei campi sono vuoti.

La verifica è banale e la consiglio a chiunque abbia un catalogo: scarica l'HTML di una scheda senza eseguire JavaScript e cerca il prezzo. Se non c'è, la tua scheda migliore è invisibile a chiunque non renderizzi la pagina, e questo include una parte dei sistemi che oggi confrontano prodotti.

Poi c'è la coerenza. Prezzo sulla scheda, prezzo nel feed e prezzo nei dati strutturati devono coincidere. Quando divergono il sistema non sceglie il più basso: registra un'incoerenza, e un'incoerenza su un dato commerciale è la peggiore da avere, perché mette in dubbio anche i campi corretti.

Le varianti sono il punto dove la maggior parte dei cataloghi diventa illeggibile, perché mescolano due strutture: un prodotto che è un concetto (il modello) e le sue varianti che sono le cose acquistabili (taglia, colore, capacità). Se la pagina espone solo il concetto, nessun vincolo di taglia o colore è verificabile.

La forma che funziona tiene i due livelli distinti e collegati: il modello come contenitore, ogni variante con il proprio identificatore, prezzo, disponibilità e attributi. Non serve una pagina per variante. Serve che le varianti siano leggibili dalla pagina del modello, tutte, non solo quella selezionata di default.

L'errore opposto è altrettanto costoso: moltiplicare le pagine e lasciare che ognuna dichiari di essere il prodotto principale. Il risultato è una famiglia di schede quasi identiche in concorrenza tra loro, dove il sistema non capisce quale rappresenti il modello e sceglie in modo instabile. Un canonical corretto e una relazione dichiarata tra modello e varianti risolvono entrambi i casi.

Le recensioni servono a un agente per una ragione diversa da quella per cui servono a una persona. Una persona le legge per rassicurarsi. Un agente le usa come fonte di attributi che il catalogo non dichiara: se venti recensioni ripetono che il capo veste stretto, quello diventa un attributo di fatto, e verrà usato per rispondere a una domanda sulla vestibilità anche se la tua scheda tace.

Questo rende le recensioni una leva di leggibilità, non solo di conversione. Se un attributo emerge ripetutamente dalle recensioni e non è nella scheda, la scheda è incompleta su un punto che il mercato considera rilevante. Vale la pena leggerle con quell'occhio: sono un elenco gratuito di attributi mancanti.

Sui claim la regola è semplice: quello che non è verificabile non aiuta e può danneggiare. "Il migliore della categoria" non è un dato e non entra in nessun confronto. "Impermeabile fino a 5 metri per 30 minuti" è un dato, entra in un confronto e può far vincere la scheda su una domanda specifica. Sostituire un superlativo con una misura è probabilmente l'intervento con il miglior rapporto tra sforzo e risultato su una scheda prodotto.

Con quattro controlli che si fanno su una scheda in mezz'ora, prima di coinvolgere chiunque.

Non riempire gli attributi con valori generici per completare il tracciato. Un attributo popolato male è peggio di uno vuoto, perché produce un confronto sbagliato invece di un dato mancante, e il dato mancante almeno è onesto.

Non aggiungere dati strutturati che contraddicono la pagina visibile. Un prezzo nello schema diverso dal prezzo a schermo è un'incoerenza dichiarata, e le linee guida dei motori la trattano come tale.

Non partire da tutto il catalogo. Un ciclo su venti o cento prodotti rappresentativi dice quali sono i problemi sistemici, e i problemi sistemici sono quasi sempre pochi e ripetuti. Sistemarli sul campione produce la specifica con cui sistemarli su tutto il resto, e in quest'ordine il lavoro finisce.