Un cliente che atterra su una pagina prodotto colma da solo le lacune. Legge la foto, deduce il materiale dal marchio, presume che la stima di consegna valga per il suo CAP e chiede se ha dubbi.
Un agente che acquista per quel cliente non fa nulla di tutto ciò. Legge solo ciò che è pubblicato in forma strutturata e tutto ciò che manca — per lui — non esiste. Se il campo materiale è compilato solo sul 40% delle SKU, si è invisibili per il 60% delle query filtrate per materiale. Se le finestre di consegna sono in prosa, non sono confrontabili.
Per chi utilizza MedusaJS, questa è una posizione favorevole: si controlla direttamente il modello dati e la superficie API, senza dover mediare con le logiche di una piattaforma. Ecco come sfruttarla.
Riferito a Medusa 2.x. Il panorama dei protocolli — ACP, UCP, MCP — è ancora in evoluzione, quindi consideri le integrazioni specifiche come stato attuale e il lavoro sui dati qui sotto come valido a prescindere dallo standard che prevarrà.
Gli attributi sono ora il prodotto
Nel catalogo Medusa la tentazione è lasciare che lo storefront trasmetta significato che i dati non hanno — una tabella specifiche ben progettata ma ricavata da una descrizione testuale. Funziona per le persone, non per le macchine.
La disciplina:
- Modellare gli attributi come dati tipizzati di primo livello, non come testo libero nella descrizione. Tutto ciò che un cliente potrebbe filtrare, confrontare o chiedere deve avere un campo dedicato.
- Usare un vocabolario controllato. Tremila valori colore inseriti come testo libero non raggruppano nulla. Ventiquattro opzioni definite permettono un filtro e un attributo confrontabile.
- Compilare gli identificativi. GTIN, MPN e brand sono ciò che permette di associare il prodotto a quello identico altrove. Se mancano, un agente non può confermare di avere davanti ciò che pensa.
- Esplicitare le unità di misura.
2,5non è una lunghezza.2,5 msì. - Sia trasparente sulle varianti. Se taglia e colore sono effettivamente indipendenti, li modelli come attributi separati invece di un elenco piatto di opzioni pre-combinate.
Quasi tutto questo coincide con il lavoro di catalogo che migliora la ricerca interna e la navigazione a filtri, il che è rassicurante: è utile anche se il traffico degli agenti non si concretizza nella sua categoria. Descriviamo la pipeline di arricchimento in pulizia di un grande catalogo con l’AI; la piattaforma dell’esempio cambia, il metodo resta lo stesso.
La disponibilità deve essere reale, non ottimistica
Qui i canali agenti penalizzano i negozi che le persone invece perdonano. Un cliente che ordina un prodotto indicato come disponibile e riceve una mail di ritardo si infastidisce moderatamente. Un agente che ha effettuato una transazione su quella base ha preso un impegno a nome del cliente usando informazioni che lei ha pubblicato come certe.
- Esponga l’inventario reale, per ogni sede se gestisce la spedizione da più punti — il modulo inventario di Medusa lo gestisce correttamente, quindi lo utilizzi invece di appiattire tutto su un unico numero.
- Pubblicare una previsione di consegna affidabile, calcolata in base a sede e stato dello stock, non come promessa statica in un blocco CMS.
- Distingua tra esaurito e fuori produzione. Implicano comportamenti completamente diversi da parte dell’agente.
- Mantenga aggiornata la disponibilità. Un valore di disponibilità memorizzato in cache che ha un’ora di ritardo è una risposta sbagliata data con sicurezza.
Definisca la sua posizione sull’overselling prima di aprire un canale agente, non dopo. Una tolleranza accettabile con l’intervento umano diventa un problema sistematico di accuratezza quando è una macchina a quotarla.
Le policy devono essere dati, non PDF
Le condizioni su resi, garanzia, soglie e restrizioni di spedizione sono spesso una pagina di testo scritta dall’ufficio legale. Un agente che chiede il mio cliente può restituire questo prodotto ha bisogno di una risposta strutturata.
Al minimo, renda leggibili dalle macchine: la finestra per i resi in giorni, chi paga la spedizione di ritorno, quali categorie sono escluse, il periodo di garanzia, la soglia per la spedizione gratuita e le destinazioni escluse dalla spedizione. Pubblici questi dati come campi strutturati restituiti dalla sua API e — separatamente — come markup schema.org sullo storefront, così entrambi i canali sono allineati.
La ragione commerciale è semplice: un agente che confronta due prodotti, di cui uno pubblica una politica di reso di 30 giorni e l’altro nulla, favorirà quello su cui può ragionare.
La superficie API di cui un agente ha bisogno
La Store API di Medusa è strutturata per risorse, il che va bene per uno storefront ma non per un agente. Un agente vuole operazioni orientate al compito: trova prodotti che corrispondono a questa descrizione, dimmi se questa taglia è disponibile a questo CAP, qual è la politica di reso su questo prodotto.
Costruisca uno strato leggero sopra i moduli Medusa che esponga queste operazioni, trattandolo come un prodotto a sé con propri standard di progettazione. Spieghiamo come progettarlo — incluso cosa non deve mai essere esposto — in il suo prodotto ha bisogno di un server MCP.
Due note specifiche su Medusa. Primo, il sistema a moduli rende questa operazione davvero agevole: lo strato rivolto agli agenti è un consumatore dei moduli prodotto, inventario e prezzi, non un loro fork. Secondo, lo tenga separato dall’API dello storefront: pattern di accesso, limiti di frequenza e modello di permessi sono diversi, e unirli peggiora entrambi.
Essere trovati o essere scelti per l’acquisto
Si tratta di due progetti distinti che spesso i team confondono.
- Essere trovati — un assistente raccomanda il suo prodotto in una risposta. Dipende da dati strutturati e indicizzabili dello storefront: markup schema.org, pagine prodotto pulite, contenuti reali e una policy crawler che consenta agli agenti giusti. È principalmente un ambito vicino alla SEO.
- Essere acquistati — un agente completa un acquisto sui suoi sistemi. Dipende da progettazione API, autenticazione, gestione dei pagamenti e dai protocolli emergenti.
La prima opzione è già disponibile per ogni negozio e offre un ritorno più immediato; la trattiamo in far raccomandare i suoi prodotti da ChatGPT e Perplexity. La seconda è ancora in evoluzione. Faccia la prima comunque, ora.
Un ordine di lavoro sensato
- Verifichi la completezza degli attributi su tutto il catalogo e ordini gli attributi in base all’effettivo utilizzo in ricerca, filtri o confronto.
- Corregga i vocabolari controllati prima di arricchire qualsiasi dato — altrimenti aggiunge righe a una tassonomia incoerente.
- Colmi le lacune, verificando a campione il risultato invece di fidarsi ciecamente.
- Strutturi le policy e le pubblichi sia come campi API sia come markup nello storefront.
- Verifichi l’accuratezza della disponibilità rispetto alla realtà per un mese. Se è errata per le persone, lo sarà ancora più rapidamente e pubblicamente per le macchine.
- Solo dopo costruisca lo strato API rivolto agli agenti, e solo allora scelga il protocollo.
I primi cinque passaggi valgono indipendentemente dal peso che il commercio tramite agenti avrà nella sua categoria, il che li rende un investimento sicuro in un ambito ancora incerto.
Il nostro team MedusaJS e il team di sviluppo Medusa realizzano questi cataloghi e le relative interfacce, con il team di ingegneria AI sul lato modello e il nostro lavoro più ampio di integrazione AI per inserirli nella strategia commerciale.
Domande frequenti
Gli agenti AI generano già vendite significative?
La situazione varia molto per categoria e la risposta onesta per la maggior parte dei negozi oggi è non ancora, ma decisamente più che l’anno scorso. Il motivo per agire ora è che il lavoro preparatorio — completezza degli attributi, disponibilità accurata, policy strutturate — migliora ricerca interna, filtri e visibilità organica a prescindere da come evolverà il canale agenti.
Cosa offre MedusaJS rispetto a una piattaforma SaaS, in questo contesto?
Controllo diretto sul modello dati e sulla superficie API. Può aggiungere attributi tipizzati senza dover gestire astrazioni come i metafield, esporre operazioni specifiche sui propri moduli e mantenere l'interfaccia per gli agenti separata dallo storefront. Su una piattaforma gestita, invece, lavora nei limiti di ciò che il fornitore ha deciso di rendere disponibile.
Conviene bloccare i crawler AI?
Distingua tra crawler che citano la fonte e scraper che non lo fanno. Bloccare tutto indiscriminatamente la esclude completamente dalle risposte AI, scelta che per la maggior parte dei retailer è svantaggiosa. Valuti ogni crawler singolarmente, documenti la decisione e la riveda periodicamente — si tratta di una questione di policy, non di impostazione predefinita.
Conviene implementare ora protocolli di checkout agentici?
I protocolli sono ancora in fase di consolidamento, quindi sviluppare su uno specifico comporta rischio di dover rifare il lavoro. L’attività sui dati e sulle API sottostanti non presenta questo rischio e richiede più tempo. Parta da lì; adottare un protocollo su una base pulita è relativamente rapido.
Quanto deve essere accurato il dato di inventario?
Più accurato di quanto la maggior parte degli store gestisca oggi. Un cliente che riceve una mail di ritardo si irrita; un agente che ha concluso una transazione sulla base della disponibilità pubblicata ha preso un impegno per conto del cliente usando i suoi dati come fatto. Definisca esplicitamente la tolleranza all’overselling prima di aprire il canale.
Parta dall’audit degli attributi
Ci invii i tassi di compilazione attributi del suo catalogo Medusa e le diremo cosa un agente può o non può vedere oggi. Di solito è meno di quanto i team si aspettino. Contatti il nostro team; rispondiamo entro un giorno lavorativo.