FCHEADERJSPLACEHOLDER

UCP e cataloghi Adobe Commerce: lo standard non è il problema, i dati lo sono

Fabio Canovi imprenditore digitale nel settore e-Commerce in Italia.
Fabio Canovi
Consulente Adobe · AI Specialist

La domanda che mi è arrivata più spesso negli ultimi mesi, in una forma o nell’altra, è questa: “devo integrare UCP?”. È la domanda sbagliata, e vorrei spiegare perché senza fare il finto contrarian, perché la risposta secondo me è utile.

Il Universal Commerce Protocol è la cosa più concreta successa all’agentic commerce da quando se ne parla. Google l’ha annunciato all’NRF l’11 gennaio, co-sviluppato con Shopify, Etsy, Wayfair, Target e Walmart. Ad aprile il consiglio tecnico si è allargato ad Amazon, Meta, Microsoft, Salesforce e Stripe. A maggio, al Google Marketing Live, il checkout UCP è andato live con i grandi retailer americani, con espansione annunciata su Canada e Australia e poi UK, e con l’apertura a verticali che non sono retail, tipo hotel e food delivery. Klarna si è agganciata. Non è più una specifica su GitHub, è infrastruttura che qualcuno sta usando per incassare.

E allora perché dico che “devo integrare UCP?” è la domanda sbagliata.

Cosa chiede davvero UCP

Se si va a leggere cosa serve concretamente per attivarlo, la lista è meno esotica di quanto il nome faccia pensare. Serve un Merchant Center configurato sul serio, con spedizioni, politiche di reso e informazioni di assistenza dichiarate in modo esplicito. Serve un attributo native_commerce nel feed, che segnala che quel prodotto può essere comprato senza rimbalzare l’utente sul sito. Serve consumer_notice per le categorie regolamentate, perché l’agente deve poter mostrare gli avvisi obbligatori. E poi servono descrizioni ricche, in linguaggio naturale, pensate per essere lette da un modello, e attributi strutturati e categorizzati. Sotto, un JSON-LD che descrive attributi, prezzo, disponibilità, opzioni di spedizione ed endpoint di checkout.

Guardando quella lista, la cosa che salta agli occhi è che di “protocollo” ce n’è pochissimo. C’è un formato in cui incartare le informazioni, certo. Ma il novanta per cento del lavoro sta nell’avere quelle informazioni, corrette, coerenti e disponibili via API. Il resto è impacchettamento.

Ed è per questo che secondo me la domanda giusta non è “devo integrare UCP”. È: se un agente interrogasse il mio catalogo adesso, riuscirebbe a rispondere a una domanda d’acquisto vera?

La lista dei tool era già la risposta

Qui devo raccontare una cosa che ho capito in ritardo.

A febbraio ho scritto qui di come mi ero costruito un MCP server su misura per Adobe Commerce. L’avevo fatto per un motivo prosaico e per niente strategico: mi ero stufato di aprire cinque schede dell’admin per rispondere a domande che tornavano ogni settimana. Così ho esposto a un agente un pugno di tool modellati sulle domande, non sugli endpoint. Uno per il catalogo, che restituisce stato, visibilità, categorie e assegnazione ai website. Uno per lo stock, con il supporto al multi-source inventory, perché con più magazzini “quanto ce n’è” è una domanda ambigua. Uno per i prezzi, che non mi dice solo quanto costa ma quale catalog price rule sta agendo, che è la vera domanda dietro “perché questo prodotto costa così”.

Mesi dopo, leggendo cosa UCP pretende da un feed, mi sono accorto che quella lista di tool era la stessa lista. Il prodotto è acquistabile davvero? È visibile su questo mercato? La disponibilità è affidabile o è un numero ottimista? Il prezzo che mostro è quello che pagherò alla cassa? Un agente che compra si fa esattamente le domande che mi facevo io con cinque schede aperte, e le vuole con una risposta sola, secca, e giusta.

Non l’avevo progettato pensando agli agenti che comprano. L’avevo progettato per non impazzire. Ma la sovrapposizione non è una coincidenza: sono le domande che qualsiasi cosa, umana o no, deve porsi per fidarsi di un catalogo.

E la parte scomoda è che, per rispondere a quelle domande su un’installazione vera, ho dovuto scrivere uno strato di normalizzazione sopra l’API. Non perché l’API di Adobe Commerce sia scarsa: è potente e verbosa. Ma perché l’informazione utile, in un catalogo reale, non sta mai in un posto solo. Sta sparsa tra stato, website, stock, categoria e regole di prezzo, e va ricomposta. Quel lavoro di ricomposizione, che io ho fatto per comodità mia, è esattamente il lavoro che UCP chiede a chiunque voglia farsi comprare da un agente.

La mia opinione, e il suo contro-argomento

Quindi la posizione che mi sento di difendere è questa: aspettare che uno standard vinca è il modo più elegante di non fare niente.

UCP, o quello che gli succederà, chiedono tutti la stessa cosa: attributi puliti, prezzi coerenti, disponibilità affidabile via API, descrizioni che dicano qualcosa di vero. Chi ha quel dato è pronto per qualsiasi protocollo, e l’integrazione diventa un lavoro di impacchettamento, noioso e finito. Chi non ce l’ha non sarà pronto per nessun protocollo, e nessuna integrazione lo salverà, perché stai chiedendo a un formato di sistemare un problema di modello dati.

E qui arrivo alla parte su cui non ho misure, solo esperienza, e la dichiaro per quello che è: negli anni passati a progettare e mantenere cataloghi Adobe Commerce per merchant di mezza Europa, la condizione che ho trovato più spesso non è il catalogo mal fatto, è il catalogo che funziona per un umano. Attributi usati in modo creativo perché “tanto in scheda si capisce”. Varianti distinguibili solo dalla foto. Un prezzo che dipende da tre regole sovrapposte e da chi guarda. Tutto questo regge benissimo finché dall’altra parte c’è una persona che compensa con il buon senso. Un agente non compensa niente: legge quello che c’è e conclude.

Il contro-argomento serio, e me lo faccio da solo, è che UCP passa da Merchant Center, quindi è roba da chi si occupa di feed e advertising, non da chi mette le mani sulla piattaforma. Lo capisco, ma non lo compro. Un feed è un’esportazione: se il dato a monte è ambiguo, l’esportazione è ambigua con una sintassi migliore. Il feed si può aggiustare a mano una volta, non due volte al mese per sempre.

Dove sta Adobe in tutto questo

Vale la pena dirlo, visto che passo le giornate su queste piattaforme. Il Catalog Agent, che Adobe ha reso generalmente disponibile a fine luglio e di cui ho scritto il mese scorso, va nella direzione giusta: prende il problema per il verso corretto, cioè quello della qualità e della leggibilità del catalogo, invece di inseguire l’integrazione con questo o quel canale. Che sia acceso di default su ogni deployment, senza un listino a parte, dice qualcosa su come Adobe legge la faccenda.

Il che non toglie che il lavoro sporco resti in casa del merchant. Nessun agente, nemmeno il migliore, decide al posto tuo se due varianti sono davvero due prodotti diversi.

Da dove comincerei

Se dovessi dare una sola indicazione, non sarebbe “guarda UCP”. Sarebbe: prendi le venti domande che un cliente fa prima di comprare, e verifica se il tuo sistema sa rispondere a ognuna con un dato, non con una scheda prodotto ben scritta. Se ci riesci, l’integrazione con qualsiasi protocollo è un progetto noioso e stimabile. Se non ci riesci, hai trovato la cosa da fare per prima, ed è la stessa cosa che avresti dovuto fare comunque.

Non so quale standard vincerà, e chi lo sa con certezza a settembre 2026 sta indovinando. So che tutti quanti chiedono lo stesso dato, e che quel dato o ce l’hai o non ce l’hai.

La domanda che lascio aperta è un’altra, e me la sto facendo anch’io: quando il compratore è un agente, chi in azienda è responsabile della qualità di quel dato? Perché finora era una questione tecnica, gestita da chi manteneva il catalogo. Sta per diventare una questione commerciale, e non sono sicuro che le due persone si parlino.

Mini-FAQ

Cos’è il Universal Commerce Protocol (UCP)?
È uno standard aperto, annunciato da Google all’NRF di gennaio 2026 e sviluppato con Shopify, Etsy, Wayfair, Target e Walmart, che definisce come un agente AI può leggere un catalogo e completare un acquisto senza passare dal sito del merchant.

Cosa serve a un merchant per essere pronto a UCP?
Un Merchant Center configurato con spedizioni, resi e assistenza, l’attributo native_commerce nel feed, consumer_notice per le categorie regolamentate, descrizioni in linguaggio naturale e attributi strutturati. A monte, però, serve un modello dati coerente: il feed è un’esportazione, non una correzione.

Adobe Commerce supporta UCP?
La domanda che conta di più è un’altra: se il catalogo espone attributi puliti, prezzi coerenti e disponibilità affidabile via API, l’integrazione con UCP o con qualsiasi protocollo concorrente diventa un lavoro di impacchettamento. Se quel dato non c’è, nessuna integrazione lo sostituisce.

Conviene aspettare che uno standard vinca?
No, e non per fretta. Tutti i protocolli agentici in circolazione chiedono lo stesso tipo di dato. Il lavoro di pulizia del catalogo va fatto comunque e non è sprecato qualunque standard si affermi.


Chi sono. Sono Fabio Canovi, consulente Adobe italiano specializzato nell’AI agentica, presso il gruppo Lutech, certificato Adobe Commerce, Adobe Experience Manager, Adobe Analytics e Adobe Target. Costruisco integrazioni AI agentiche basate su MCP per il mondo Adobe, e scrivo di quello che imparo mentre le realizzo.

Fabio Canovi imprenditore digitale nel settore e-Commerce in Italia.
Chi sono
Sono Fabio Canovi, consulente Adobe presso il gruppo Lutech. Tra i primi in Italia certificato Adobe Commerce e certificato AEM, Analytics e Target (Master su Target). Negli ultimi due anni ho unito le competenze Adobe con l’AI agentica, lavorando con Claude Code e Cowork e costruendo MCP su misura per portare gli agenti dentro le piattaforme e-commerce reali.

Articoli correlati