Torna al blog

Auto generate product descriptions: evita dati incoerenti

Auto generate product descriptions: evita dati incoerenti

Auto generate product descriptions con record canonici e controlli su GTIN, varianti, JSON-LD e feed per evitare dati ecommerce incoerenti.

Di Team editoriale Veliu9 min di lettura

In breve

Per auto generate product descriptions senza propagare errori, costruisci prima un record canonico per SKU e variante, poi blocca ogni divergenza tra pagina, JSON-LD Product e feed.

  • Un record canonico per ogni SKU e variante impedisce che prezzo, stock e attributi di un articolo contaminino gli altri.
  • Il motore AI deve generare soltanto testo sostenuto dai campi forniti e segnalare ogni fatto mancante.
  • Pagina, JSON-LD Product e feed devono essere confrontati campo per campo prima della pubblicazione.
  • GTIN e categorie richiedono fonti e test espliciti, mai deduzioni dal titolo.
  • La qualità si misura con denominatori, divergenze e latenza di propagazione, non con il solo volume di descrizioni.

Per auto generate product descriptions senza propagare errori, serve un record canonico per ogni SKU e variante: 79,90 € nella pagina e 74,90 € nel feed rendono inaffidabile anche un testo impeccabile. Questa guida è destinata a marketing manager e team ecommerce che vogliono generare descrizioni da CSV, PIM, il sistema che gestisce le informazioni di prodotto, o feed mantenendo coerenti prezzo, disponibilità, varianti e identificatori.

ChatGPT e Gemini possono, in alcune esperienze e configurazioni, recuperare informazioni pubblicate sul web o rese disponibili tramite integrazioni; accesso e uso dipendono da prodotto, modalità, indicizzazione e disponibilità della fonte. Sette controlli collegano quindi il copy alle metriche che contano nel workflow, tra cui copertura dei campi, divergenze e velocità di aggiornamento.

Una descrizione fluida non corregge un GTIN errato.

Il principio operativo è semplice: il catalogo fornisce fatti verificati, il motore AI produce soltanto il testo autorizzato e una divergenza critica blocca la pubblicazione. Le scelte di citazione e presentazione restano ai singoli motori.

1. Come si genera senza una fonte verificabile?

Non si genera. Il generatore viene dopo la preparazione dei dati. Per una scarpa disponibile nelle taglie 39, 40 e 41, la fonte autorevole deve distinguere le tre varianti anche quando titolo, fotografia e descrizione sono condivisi.

Un record canonico è la scheda strutturata considerata autorevole per un singolo SKU, cioè il codice interno che identifica un articolo vendibile. Prima di scrivere, assegna a ogni campo una fonte nominata, una versione e un responsabile.

RequisitoCampoCriterio di accettazione
Identità stabileidValore unico, persistente e mai riciclato
Famiglia di variantiitem_group_idStesso gruppo, id distinto per variante
MarcabrandNome canonico uguale negli output
Identificatoregtin, oppure mpn e brandIdentificatore verificato, mai dedotto
Offertaprice, priceCurrency, availabilityPrezzo, valuta e stato validi
Categoriagoogle_product_category, product_typeCategoria standard e percorso interno distinti
Destinazionipagina, JSON-LD, feedMappatura campo per campo

Il GTIN è il codice globale del prodotto, spesso riportato sotto il codice a barre. L’MPN è il codice articolo assegnato dal produttore. JSON-LD Product/Offer è un blocco di dati strutturati nella pagina, mentre il feed è un file o flusso che invia prodotti e offerte a una piattaforma come Google Merchant Center.

I fatti arrivano dalla fonte catalogo. Il modello riceve solo i valori consentiti e non può completarli perché sembrano plausibili.

2. Ogni variante deve avere una verità propria

Crea un record per ogni combinazione realmente acquistabile. L’id identifica la variante, item_group_id la collega alla famiglia e prezzo, disponibilità, colore o taglia restano al livello più specifico.

I nomi e i valori sono didattici. Se la versione blu costa 24,90 € ed è disponibile, mentre quella rossa costa 26,90 € ed è esaurita, la frase condivisa “disponibile a 24,90 €” contamina almeno una variante.

La variante è l’unità di verità.

Questa separazione protegge anche la conversione: il cliente che apre la variante rossa deve vedere il suo prezzo e il suo stock, non i dati del prodotto padre. Il controllo è tecnico, ma l’impatto è commerciale.

3. La completezza si misura prima della scrittura

Costruisci una matrice di completezza, cioè una tabella che indica per ogni SKU se ciascun campo è presente e valido. Controlla almeno prezzo, valuta, disponibilità, identificatore, spedizione e resi quando tali dati rientrano nell’offerta pubblicata.

La sola presenza inganna. priceCurrency: "euro" contiene un valore, ma non supera ISO 4217, lo standard dei codici valuta, che richiede EUR; availability: "disponibile" non appartiene ai valori di schema.org ItemAvailability.

La metodologia richiede un denominatore.

Per pubblicare una percentuale servono dominio o merchant anonimizzato, data e ora della scansione, numero di SKU e varianti, regole applicate e limite noto. Senza una scansione reale allegata, questo articolo non attribuisce percentuali alla qualità di alcun catalogo.

Separa inoltre gli hero SKU, i prodotti con maggiore priorità commerciale o traffico, dalla long tail, gli articoli meno visitati o più specifici. Un esempio didattico con 98 hero completi su 100 e 420 articoli completi su 1.400 mostra perché una media unica nasconde la copertura debole.

Imposta infine un blocco: se manca un fatto obbligatorio, il processo restituisce missing_fields e non produce testo pronto alla pubblicazione.

4. GTIN e tassonomia richiedono test, non supposizioni

GS1, l’organizzazione che amministra lo standard, scrive nella pagina Global Trade Item Number (GTIN): “GTINs can be used by a company to uniquely identify all of its trade items”. La pagina GS1 sui GTIN chiarisce quindi il punto operativo: il codice identifica uno specifico articolo commerciale e non può essere ricavato dal titolo.

Valida il GTIN controllando formato e cifra di controllo secondo le regole applicabili. Non aggiungere zeri per inventare un identificatore diverso o aggirare una validazione; in alcuni contesti tecnici GS1 consente invece la rappresentazione a 14 cifre con zeri iniziali, quindi la trasformazione deve preservare l’identità originale ed essere documentata.

Quando il produttore non assegna un GTIN, usa mpn con brand se appropriato. Un vaso artigianale senza codice industriale può richiedere identifier_exists=no nel feed, purché l’assenza sia autentica e documentata.

Per la categoria, adotta come policy consigliata del workflow un percorso nella Google Product Taxonomy, la classificazione merceologica standard di Google, quando è pertinente al mercato e alla destinazione. google_product_category non è universalmente obbligatorio per ogni articolo, mentre product_type conserva la struttura commerciale del negozio.

L’attrattiva della scorciatoia è evidente: lasciare che il modello deduca categoria e codice dal titolo riduce il lavoro iniziale. I dati disponibili nel titolo non sostengono questa scelta: “Sneaker Retro 84” non contiene la cifra di controllo del GTIN e non distingue con certezza una calzatura lifestyle da una scarpa sportiva.

5. Il testo può variare, i fatti bloccati no

Un motore AI può scegliere ritmo, apertura e ordine degli attributi. Non deve modificare i campi che determinano identità, offerta, conformità o policy.

ClasseEsempiRegola
Fatti bloccatimarca, GTIN, prezzo, misure, resiCopia dalla fonte approvata
Testo vincolatoapertura, tono, ordine degli attributiGenera solo dai campi forniti
Dati vietati se assenticertificazioni, compatibilità, prestazioniSegnala il campo mancante

Per una lampada dichiarata in alluminio, il testo può indicare “corpo in alluminio”. Se la fonte non riporta IP44, la fotografia in giardino non autorizza una certificazione di resistenza all’acqua.

Usa un prompt contract, cioè un contratto verificabile per input e output:

Il contratto limita la creatività nei punti rischiosi, ma non sostituisce la validazione successiva. Un’istruzione testuale non equivale a un vincolo applicato ai dati.

6. Pagina, JSON-LD e feed devono coincidere

La documentazione Google Product distingue proprietà del prodotto e dell’offerta. La Product data specification di Google Merchant Center definisce attributi del feed come [price], [availability], [link] e [image_link].

FontePaginaProduct/Offer JSON-LDMerchant Center
priceprezzo mostratooffers.price[price]
priceCurrencyvaluta coerenteoffers.priceCurrencyvaluta in [price]
availabilitystato leggibilevalore ItemAvailability[availability]
urlURL varianteOffer.url[link]
imageimmagine varianteProduct.image[image_link]

Google afferma nella pagina Product data specification: “The price in your product data must match the price on your landing page”. Per marketing significa che un feed aggiornato e una pagina rimasta al valore precedente costituiscono una divergenza misurabile, anche se copy e campagna non sono cambiati: nel commercio agentico, la coerenza tra pagina e feed diventa una prova verificabile.

Il controllo deve includere il contenuto visibile. Un JSON-LD con 74,90 € sotto una pagina che mostra 79,90 € lascia due versioni della stessa offerta.

Per il rapporto tra feed e superfici AI, vedi Google Shopping Feed Optimization: Price Gaps Block Ads. Una singola offerta deve conservare gli stessi fatti in ogni rappresentazione.

7. La pubblicazione automatica deve poter dire no

Prima del rilascio, esegui controlli sintattici, semantici e commerciali. Un JSON valido può contenere un identificatore inventato; un feed ben formato può contraddire la pagina.

Blocca la pubblicazione quando trovi almeno uno di questi eventi:

  • identificatore non valido o non sostenuto dalla fonte;
  • price senza priceCurrency;
  • availability fuori dai valori previsti;
  • variante senza legame alla famiglia quando necessario;
  • claim assente dalla fonte;
  • divergenza critica tra pagina, Product/Offer e feed;
  • categoria incerta quando la policy richiede revisione.

Ogni esecuzione deve produrre un log con timestamp, versione della fonte, regole applicate, esito e responsabile dell’approvazione. Se la descrizione della taglia 41 viene approvata manualmente, il log deve mostrare chi ha approvato e quale versione del record ha esaminato.

Dove fermare un fatto errato prima della pubblicazione: 1. Fonte autorevole (PIM, ERP o feed master); 2. Record canonico (Campi e varianti distinti); 3. Tassonomia (Categoria verificata o revisionata); 4. Testo vincolato (Solo fatti consentiti); 5. Validazione (Schema, claim e divergenze); 6. Output coerenti (Pagina, JSON-LD e feed)
Dove fermare un fatto errato prima della pubblicazione

Qui il vantaggio operativo consiste nel correggere i campi e gli output che impediscono al catalogo di essere leggibile e associabile, oltre a misurare il problema. Il merchant conserva il controllo su fonte, policy, prezzi e approvazioni.

Perché la coerenza decide se un agente riesce a vendere?

ChatGPT, Gemini e AI Overviews possono, a seconda dell’esperienza, dell’indicizzazione e delle integrazioni disponibili, usare informazioni pubblicate sul web o fornite tramite canali strutturati. Non condividono necessariamente gli stessi accessi, e ciascun motore decide citazioni e come comporre al momento la vetrina di prodotti mostrata all’utente.

Un record coerente può facilitare l’associazione tra la borraccia BT500 blu, il suo SKU, il prezzo in EUR e lo stato InStock. La descrizione espone attributi in linguaggio naturale; JSON-LD e feed rendono alcuni campi espliciti; tassonomia e identificatori aiutano a distinguere prodotti simili.

Questo è il ponte verso l’agente che vende.

La promessa controllabile riguarda un catalogo più leggibile, associabile e disponibile tramite endpoint adatti, non una raccomandazione o una posizione garantita. GEO, AEO e SEO per ecommerce spiega come ricerca tradizionale e motori generativi possono usare segnali differenti.

Le metriche devono mostrare copertura e ritardi

Il numero di descrizioni generate misura volume. Per valutare il workflow servono metriche con formula, periodo e denominatore.

  1. Copertura valida per campo: SKU o varianti con campo presente e valido diviso il perimetro che dovrebbe possederlo.
  2. Tasso di divergenza: combinazioni SKU-campo discordanti tra fonte, pagina, JSON-LD e feed divise per tutte le combinazioni controllate.
  3. Job bloccati: processi con missing_fields critici divisi per processi avviati.
  4. Latenza di propagazione: tempo tra la modifica nella fonte e il nuovo valore in ciascun output; riporta mediana e 95° percentile, il valore entro cui ricade il 95% degli aggiornamenti.
  5. Accuratezza di `facts_used`: fatti sostenuti dalla fonte divisi per tutti i fatti dichiarati, su un campione casuale per mercato e categoria.

Prezzo e disponibilità possono cambiare con frequenze diverse tra merchant e cataloghi. Per questo conviene servirli dalla fonte aggiornata e misurare la latenza effettiva, invece di fissare nella descrizione una frase come “disponibile in tutte le taglie”.

Nota metodologica, Team editoriale Veliu. L’analisi copre i campi e le regole documentati nelle fonti primarie citate, con esempi sintetici marcati come tali. Non include una scansione merchant reale; completezza, divergenza e latenza devono quindi essere misurate sul catalogo interessato, indicando perimetro, data, campione e pagine non raggiungibili.

Il test finale chiude la divergenza iniziale

Considera tre varianti didattiche dello zaino “Linea 22”:

VariantePrezzo fonteDisponibilità
Nero69,90 €InStock
Verde72,90 €InStock
Sabbia72,90 €OutOfStock

Per la variante verde, pagina e feed mostrano 72,90 €, ma Offer JSON-LD conserva 69,90 €. Il controllo sul prezzo deve bloccare la pubblicazione finché il dato strutturato non torna a 72,90 €, anche se la descrizione è corretta.

Il prezzo discordante dell’apertura trova qui la sua causa: non era un problema di stile, ma una divergenza tra rappresentazioni della stessa offerta.

Controlla ora un campione di 50 varianti su pagina, JSON-LD e feed, registrando per ogni differenza campo, fonte, timestamp e responsabile della correzione.

Veliu porta questo lavoro dentro l’agente del brand, un venditore autonomo che studia come motori e clienti chiedono i tuoi prodotti, prepara il negozio e sta al banco con le persone e con gli agenti AI che arrivano a comprare. Nel momento prepara costruisce il record canonico di ogni SKU e variante, con identificatori validi, tassonomia allineata e descrizioni generate solo dai fatti approvati. Il metodo arriva da oltre 50K clienti, oltre 300K transazioni delegate, oltre 100 milioni di euro transati e oltre un anno di R&D.

Ricevi il prossimo pezzo quando esce

Ti mandiamo le nuove note su come rendere il catalogo leggibile e acquistabile dagli agenti AI man mano che escono.

Iscriviti alla newsletter