Semantica di prodotto leggibile dalle macchine: separare cosa vendi da come lo vendi

Dalla serie

Obiettivo

Distinguere catalogo, tassonomia, ontologia e semantic layer e modellare correttamente Product, Variant, Offer, Price, Availability e Policy come concetti separati e governati.

Il punto pratico

Se vuoi che un agente commerciale prenda decisioni affidabili, non basta esporre una pagina prodotto ben scritta. Devi modellare in modo esplicito cosa è il prodotto, cosa è una variante vendibile, cosa è l’offerta, e quali fatti sono dinamici. In pratica, separa almeno questi concetti: - Product: l’identità commerciale o concettuale - Variant: la configurazione vendibile, per esempio colore o taglia - OfferGlossarioOfferLe condizioni con cui un prodotto o una variante è reso acquistabile da uno specifico seller.Apri la voce completa: le condizioni di vendita, inclusi seller, prezzo, valuta, mercato e policy - Price e Availability: fatti dinamici, da leggere dai sistemi autorevoli al momento giusto - Taxonomy: la classificazione per navigazione e filtro - Ontology: le relazioni e il significato dei concetti La regola utile è semplice: il semantic layerGlossarioSemantic LayerUn livello che espone dati provenienti da sistemi diversi usando entità, significati e metriche coerenti.Apri la voce completa serve a rendere i significati consumabili, non a inventare una nuova verità. Può aiutare discovery, ranking e ragionamento iniziale, ma checkout, stock e prezzo devono sempre tornare alle autorità corrette prima dell’azione. Per un Solution Architect, il lavoro vero è definire ownership e freshness: chi possiede il dato, con quale latenza è valido, e in quale punto del flusso l’agente deve rileggere il fatto dinamico. • Product è identità; Offer è condizione di vendita. Non mischiarli. • Price e Availability non vanno dedotti dal testo della pagina. • Ogni consumer deve sapere quale sistema è autorevole per quel campo.

Trade-off che contano

La separazione semantica migliora chiarezza, interoperabilità e affidabilità decisionale, ma introduce disciplina di modellazione e governance. I principali trade-offGlossarioTrade-offUno scambio in cui migliorare un risultato ne indebolisce o ne rende più costoso un altro.Apri la voce completa sono questi: - Più precisione semantica, più effort di modellazione e manutenzione del catalogo - Più fonti autorevoli, più bisogno di regole di riconciliazione e osservabilitàGlossarioOsservabilitàLa capacità di comprendere il comportamento di un sistema a partire dai segnali che produce.Apri la voce completa - Più disaccoppiamento tra discovery e transazione, più passaggi di verifica prima dell’azione - Più riuso del semantic layer, più attenzione a non trasformarlo in una seconda fonte di verità Il vantaggio è concreto: eviti che un agente selezioni il prodotto giusto ma la variante sbagliata, oppure legga un prezzo corretto ieri ma non più valido oggi. Il costo è che devi accettare una certa complessità architetturale e non cercare scorciatoie tipo “la pagina web è il record canonico”. In un contesto enterprise, questo trade-off è sano: meglio un flusso un po’ più esplicito che un sistema elegante ma commercialmente errato. • Il semantic layer aiuta la lettura, non sostituisce l’authority. • La discovery può essere semantica; la transazione deve essere deterministica. • Molti errori nascono quando si appiattiscono varianti e offerte.

Esempio enterprise realistico

Immagina un retailer omnicanale che vende laptop, accessori e servizi aggiuntivi. Il catalogo marketing descrive bene i prodotti per i clienti, ma il team agentico vuole usare gli stessi dati per raccomandare e comporre il carrello. All’inizio il gruppo prova a trattare la scheda prodotto come fonte unica. Funziona in demo, ma emergono subito errori: un laptop viene suggerito senza distinguere la variante con 16 GB da quella con 32 GB, il prezzo esposto non riflette una promozione appena terminata, e la disponibilità mostrata non considera il mercato di consegna. La correzione architetturale è dividere i livelli: - il PIM mantiene descrizioni e attributi stabili - il catalogo semantico espone Product, Variant e relazioni - il pricing service governa price e promozioni - l’inventory service governa availability - il policy service governa resi, vincoli e idoneità del mercato L’agente può usare il catalogo semantico per capire cosa proporre, ma prima di confermare l’acquisto deve rileggere prezzo, stock e policy dai sistemi autorevoli. In questo modo la semantica migliora la qualità della decisione senza compromettere la correttezza transazionale. • Il catalogo marketing non basta per l’azione automatizzata. • La variante giusta può avere disponibilità e prezzo diversi dal prodotto base. • Le decisioni finali devono rileggere i fatti dinamici dalle autorità corrette.

Per approfondire

Fonti esterne autorevoli per approfondire la separazione tra prodotto, offerta, prezzo e dati strutturati leggibili dalle macchine. • Schema.org Product — Schema.org — https://schema.org/Product • Merchant listing Product and Offer structured data — Google Search Central — https://developers.google.com/search/docs/appearance/structured-data/merchant-listing • Shopify Catalog and product discovery for agentic storefronts — Shopify — https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/products