Come rendere una scheda prodotto utilizzabile dagli agenti AI

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 riguarda anche la persona: una promessa come "spedizione rapida" non permette di sapere se il prodotto arriverà prima di una scadenza. Un agente incaricato di rispettare quella data può cercare chiarimenti, segnalare l'incertezza o preferire un'alternativa verificabile. Non esiste una regola di esclusione identica per tutti i sistemi; esiste un'informazione mancante che rende il confronto più difficile.

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é possono rendere irrilevanti le altre caratteristiche rispetto alla richiesta. Se il cliente deve acquistare subito entro un budget, un prodotto non disponibile o troppo costoso non soddisfa quei vincoli. Prezzo e disponibilità sono quindi controlli prioritari in quel compito, non una sequenza obbligatoria seguita da ogni agente in ogni ricerca.

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 riferirsi alla stessa variante e alle stesse condizioni. Una divergenza rende ambiguo il dato da usare e può richiedere una nuova verifica. Non possiamo dedurre quale valore sceglierà ogni sistema: possiamo correggere il disallineamento e dichiarare quando e a quali condizioni il prezzo è valido.

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 possono fornire a persone e agenti informazioni che il catalogo non dichiara. Se più clienti segnalano che un capo veste stretto, emerge un'indicazione da verificare sulla vestibilità. Un sistema può considerarla nel confronto, ma non è un attributo certificato né una fonte che ogni agente userà allo stesso modo. La scheda dovrebbe distinguere specifiche del produttore ed esperienze dei clienti.

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.