Feed pronti per il commercio agentico: cosa richiedono davvero UCP, ACP e AI Mode

Negli ultimi diciotto mesi nell'e-commerce è successo qualcosa di strutturale senza troppo clamore, e la maggior parte di ciò che se ne è scritto è stato o entusiasta all'eccesso o vago.

Ecco la versione concreta. Quando un acquirente chiede a un assistente AI di trovargli un prodotto, l'assistente non visita la tua homepage. Non vede le tue foto, la storia del tuo brand né la descrizione di prodotto su cui il tuo copywriter si è arrovellato. Legge dati di prodotto strutturati (un feed, un blocco di schema, una risposta API) e decide in base a quelli se consigliare te o qualcun altro.

Il tuo feed è sempre stato l'input dei tuoi annunci. Ora è l'input della raccomandazione stessa.

Oggi tre sistemi definiscono come funziona tutto questo: l'Universal Commerce Protocol (UCP) di Google, l'Agentic Commerce Protocol (ACP) di OpenAI e Stripe e il merchant program di Perplexity. Spesso se ne parla come se fossero la stessa cosa con loghi diversi. Non lo sono. Consumano dati diversi, in formati diversi, con requisiti diversi, e sono attivi in paesi diversi.

Questa guida spiega cosa richiede davvero ciascuno a livello di campi, cosa si sovrappone realmente e cosa no e, poiché la maggior parte dei lettori di questo blog non vende principalmente negli Stati Uniti, cosa conviene fare se il checkout agentico non è ancora arrivato nel tuo mercato.

Il panorama, senza giri di parole

Due osservazioni prima di proseguire.

Primo: scoperta e checkout sono problemi distinti. Essere trovabili da un agente AI è un problema di qualità dei dati che vale ovunque nel mondo, già oggi. Essere acquistabili all'interno di una superficie AI è un problema di integrazione del protocollo, attualmente limitato a pochi mercati. Confondere le due cose è l'errore più comune in assoluto nella copertura di questo tema, e porta i merchant fuori dagli Stati Uniti a concludere che nulla di tutto ciò li riguardi. È vero il contrario: il livello della scoperta riguarda tutti ed è lì che si concentra quasi tutto il valore oggi disponibile.

Secondo: i protocolli convergono sull'infrastruttura, non sui dati. UCP funziona esplicitamente insieme ad A2A, AP2 e MCP. ACP si basa sulla stessa idea di fondo. Ma i loro schemi di prodotto restano davvero diversi, e un feed costruito per uno non si adatta all'altro senza modifiche. È un problema di gestione dei feed, non di strategia, e ha una soluzione semplice: mantenere un'unica fonte di verità interna arricchita e generare da essa esportazioni specifiche per ciascuna destinazione.

Livello 1: la base per la scoperta (vale ovunque, già oggi)

Prima di qualsiasi lavoro specifico per un protocollo, c'è un insieme di requisiti comune a tutti questi sistemi. Se di questo articolo fai una sola cosa, fai questo livello. Non richiede alcun lavoro di integrazione ed è ciò che determina davvero se vieni consigliato.

Identificatori di prodotto

Il GTIN è la chiave di collegamento dell'intero ecosistema dello shopping basato sull'AI. Ognuno di questi sistemi usa identificatori standardizzati per abbinare il tuo prodotto allo stesso prodotto altrove: per confrontare i prezzi, aggregare le recensioni, sapere che la tua inserzione e quella di un sito di recensioni descrivono lo stesso oggetto.

I GTIN mancanti non producono un messaggio di errore. Producono silenzio: il tuo prodotto semplicemente non fa parte del confronto che l'agente sta eseguendo. Perplexity, in particolare, darebbe secondo quanto riportato un peso maggiore rispetto a Google alla completezza degli identificatori.

Verifica la copertura dei GTIN come percentuale degli SKU attivi. Se è sotto il 90%, quel numero è il tuo primo progetto.

Completezza degli attributi

Gli annunci Shopping tradizionali funzionavano con un insieme piuttosto ridotto di attributi obbligatori. Un agente ragiona su tutto ciò che gli fornisci. Ogni campo compilato è un potenziale motivo per cui l'agente può consigliarti: materiale, dimensioni, compatibilità, istruzioni di manutenzione, requisiti di alimentazione, condizioni di garanzia.

Il cambio di prospettiva è questo: un attributo non è più un valore di filtro. È un argomento. material: full-grain leather non è un facet: è la frase che l'agente usa quando un acquirente chiede quale di due borse invecchierà meglio.

Coerenza su ogni superficie

Questo è il requisito più spesso trascurato e quello che più probabilmente ti danneggerà.

Un acquirente umano che vede ₺2.499 sulla tua pagina prodotto e ₺2.399 in un risultato di comparazione alza le spalle e va avanti. Un agente tratta la discrepanza come un segnale sull'affidabilità dei tuoi dati, e un checkout che fallisce perché il prezzo è cambiato è un esito molto peggiore, per chi gestisce l'agente, del semplice non consigliarti.

Verifica la coerenza tra: le tue pagine prodotto, il feed di Merchant Center, i dati strutturati in pagina e le eventuali inserzioni sui marketplace. Prezzi, disponibilità, condizioni di spedizione e politica di reso devono coincidere. Le politiche di reso e di spedizione, in particolare, vengono sempre più spesso lette dagli agenti e riportate agli acquirenti.

Aggiornamento dei dati

<!-- İç link: /feed-update-frequency -->

L'aggiornamento notturno del feed non basta più. Lo Shopping Graph di Google si aggiorna su una scala misurata in miliardi di inserzioni all'ora e preferisce i dati in tempo reale; l'acquisizione dei feed di OpenAI accetta aggiornamenti anche ogni 15 minuti.

Il motivo non è estetico. Quando un agente è in grado di completare una transazione, dati di inventario non aggiornati non producono un acquirente un po' deluso: producono una transazione fallita. E i sistemi che fanno fallire le transazioni vengono penalizzati.

Obiettivo pratico: prezzo e disponibilità che si propagano entro 15 minuti per l'inventario a rotazione rapida, almeno ogni ora per tutto il resto. Per la maggior parte dei merchant questo significa passare dal recupero programmato dei file ad aggiornamenti basati su API o su push.

Accesso per il crawling

Controlla nel tuo robots.txt i crawler AI. Molti merchant li hanno bloccati d'istinto nel 2024 e nel 2025, durante il dibattito su "dobbiamo lasciare che l'AI si addestri sui nostri contenuti?", e non hanno mai rivisto la decisione. Bloccare il crawler che alimenta un indice di shopping è una decisione diversa dal bloccare un crawler di addestramento, e spesso viene presa per errore da un team che non l'ha mai vista come una decisione commerciale.

Livello 2: Google, gli attributi conversazionali

Questa è la parte più concreta, meno discussa e più immediatamente applicabile dell'intero tema, ed è la sezione che leggerei due volte.

Insieme a UCP, Google ha aggiunto alla specifica dei dati di prodotto di Merchant Center un insieme di attributi conversazionali. Sono facoltativi, integrano i tuoi dati di prodotto esistenti e il loro scopo dichiarato è aiutare i sistemi AI e gli agenti conversazionali a comprendere le sfumature specifiche dei tuoi prodotti. Google afferma che includerli non influisce sullo stato di approvazione dei prodotti esistenti.

Quest'ultimo punto è importante: il rischio è pari a zero. Stai aggiungendo dati descrittivi, non modificando nulla di ciò che Google convalida per l'approvazione.

Ecco l'insieme:

L'esempio completo di Google, per una variante di un telefono, combina item_group_title, variant_option, question_and_answer, product_highlight, product_detail, related_product, popularity_rank e document_link su un unico articolo, insieme agli attributi standard.

Perché proprio questi sei, e a cosa servono davvero

Guarda cosa fa ciascuno per un agente:

• question_and_answer è il copione dell'agente. Un acquirente chiede "si può lavare in lavastoviglie?" e l'agente o ha la tua risposta o non ce l'ha. Se non ce l'ha, o dice di non saperlo, e perdi la vendita, o consiglia un concorrente che ha compilato il campo.
• document_link dà all'agente un documento su cui ragionare. Le istruzioni di montaggio rispondono a "quanto è difficile montarlo?". Le schede tecniche rispondono a domande di compatibilità che non avresti potuto prevedere.
• related_product è il modo in cui il cross-sell sopravvive alla scomparsa del tuo sito dal percorso d'acquisto. required_part, in particolare, evita l'esito peggiore nel commercio agentico: un acquirente che compra qualcosa che da solo non funziona.
• item_group_title e variant_option risolvono il problema che affligge i feed con varianti da quando esistono: un agente che vede otto righe e non capisce che sono un solo prodotto in otto taglie. È il problema della strutturazione delle varianti in un nuovo contesto.
• popularity_rank è il modo in cui dici all'agente quali dei tuoi prodotti vendono davvero. Nessun altro può dargli questo segnale.

Compilarli su larga scala

L'ostacolo reale: nessuno ha una colonna question_and_answer già pronta nel proprio PIM.

Ma la maggior parte dei merchant ha la materia prima: i temi ricorrenti dei ticket del servizio clienti, le FAQ in pagina, il contenuto delle recensioni, i motivi dei resi. Le coppie di domande e risposte di maggior valore si vedono di solito nelle domande a cui il tuo team di supporto risponde più spesso e nei motivi per cui i prodotti vengono resi. Un reso motivato con "non era compatibile con la mia macchina" è una domanda di compatibilità a cui dovresti rispondere nel feed.

Google consiglia di aggiungerli tramite un'origine dati supplementare invece di rielaborare il feed principale, ed è la scelta giusta dal punto di vista operativo, perché il team che gestisce i dati di prodotto e quello che gestisce i contenuti del supporto raramente coincidono.

Su scala di catalogo diventa un problema di regole: ricava item_group_title dal nome del prodotto padre, costruisci variant_option dagli attributi che già memorizzi come colore e taglia, calcola popularity_rank come percentile a partire dai tuoi dati di vendita e mappa document_link dalla tua libreria di manuali esistente in base allo schema degli SKU. In Feedance queste sono regole del feed applicate a ogni aggiornamento, e popularity_rank in particolare può essere ricalcolato automaticamente dai dati di vendita invece di essere gestito a mano.

Inizia dai tuoi primi 200 SKU per fatturato e da tre coppie di domande e risposte ciascuno. È una settimana di lavoro e copre la maggior parte delle impression visibili agli agenti.

Livello 3: l'ACP di OpenAI, una struttura davvero diversa

Se dai per scontato che il feed per ChatGPT sia il tuo feed Google con nomi di colonna diversi, costruirai la cosa sbagliata. Lo schema del feed di prodotto ACP è strutturalmente diverso, e le differenze dicono molto su ciò che vogliono i sistemi agentici.

I prodotti contengono le varianti. Il feed di Google è piatto: ogni variante è una riga a sé, collegata alle altre tramite item_group_id. ACP inverte la logica: l'oggetto prodotto è il record canonico e contiene un array di oggetti variante. Ogni variante ha il proprio id, titolo, prezzo, disponibilità, media e opzioni.

È un modello migliore per un agente, e vale la pena capire perché. Un feed piatto costringe l'agente a ricostruire "questa è una sola scarpa in nove taglie" a partire da una chiave di raggruppamento condivisa. Un feed annidato gli fornisce direttamente questa informazione. I merchant con cataloghi ricchi di varianti, la moda prima di tutti, ne traggono un reale vantaggio in termini di accuratezza.

I prezzi sono interi espressi in unità minori. { "amount": 7999, "currency": "USD" } corrisponde a 79,99 USD. Non una stringa decimale. Qualsiasi pipeline che esegue calcoli in virgola mobile sui prezzi va verificata prima che produca silenziosamente un valore sbagliato.

Le descrizioni sono oggetti, non stringhe. L'oggetto description accetta plain, html e markdown: puoi fornire qualsiasi combinazione.

I link alle politiche del venditore sono elementi di primo piano. L'oggetto seller contiene links, con tipo privacy_policy, terms_of_service, refund_policy, shipping_policy o faq. Rileggi quell'elenco: l'agente vuole la tua politica di reso come campo strutturato. In un mondo in cui l'acquirente non vede mai il tuo sito, le tue politiche devono viaggiare insieme al prodotto.

La condizione è un array. ["new"], e può applicarsi più di un valore, il che anticipa l'inventario di seconda mano e ricondizionato.

Una struttura minima:

{
  "id": "SKU12345",
  "title": "Trail Running Shoe",
  "description": { "plain": "Waterproof trail shoe with cushioned sole." },
  "url": "https://example.com/products/SKU12345",
  "media": [
    { "type": "image", "url": "https://example.com/images/SKU12345.jpg",
      "alt_text": "Black trail running shoe", "width": 1200, "height": 1200 }
  ],
  "variants": [
    {
      "id": "SKU12345-BLK-10",
      "title": "Black / 10",
      "barcodes": [{ "type": "gtin", "value": "1234567890123" }],
      "price": { "amount": 7999, "currency": "USD" },
      "list_price": { "amount": 9999, "currency": "USD" },
      "availability": { "available": true, "status": "in_stock" },
      "variant_options": [
        { "name": "color", "value": "Black" },
        { "name": "size", "value": "10" }
      ],
      "categories": [
        { "value": "Apparel & Accessories > Shoes", "taxonomy": "merchant" }
      ],
      "condition": ["new"],
      "seller": {
        "name": "Example Store",
        "links": [
          { "type": "refund_policy", "title": "Returns policy",
            "url": "https://example.com/returns" }
        ]
      }
    }
  ]
}

Il file del feed è accompagnato da un'intestazione che contiene feed_id, account_id, target_merchant e target_country: nota che il paese è impostato a livello di feed, il che significa che i merchant multimercato inviano un feed per ogni mercato.

Il modello di consegna raccomandato da OpenAI prevede un feed completo una volta al giorno tramite caricamento di file, con aggiornamenti in corso di giornata inviati tramite API. I cataloghi piccoli possono fare entrambe le cose tramite API.

Un punto su cui è bene essere lucidi: il checkout in chat di OpenAI ha avuto un primo anno più complicato di quanto lasciassero intendere gli annunci, e l'azienda ha riconosciuto pubblicamente che la prima implementazione di Instant Checkout era meno flessibile del previsto, spostando l'enfasi sulla scoperta dei prodotti con un rimando al sito del merchant per il pagamento. Se devi stabilire delle priorità, considera la scoperta ACP come l'opportunità a breve termine e il checkout ACP come una scommessa a più lungo termine.

Livello 4: Perplexity

Il merchant program di Perplexity è il meno documentato dei tre e, proprio per questo, quello raccontato in modo più impreciso. Le guide che pubblicano una specifica dettagliata dei campi per Perplexity stanno estrapolando da Google: non esiste una specifica ufficiale dei campi pubblicata.

Ciò che si sa:

• Il programma è gratuito e basato su candidatura; l'onboarding si è progressivamente ampliato nel corso del 2025 e del 2026.
• Il feed viene consegnato in CSV o XML, tramite API, SFTP o un bucket S3 dedicato, nel formato Google Shopping.
• La completezza dei dati di prodotto funziona come fattore di ranking: dati più completi danno al sistema più elementi su cui lavorare quando genera confronti e riepiloghi di pro e contro.
• La completezza degli identificatori, i dati delle recensioni e il markup Schema.org in pagina sembrano avere un peso maggiore rispetto a quello che attribuisce loro Google.
• Un feed non è strettamente necessario per essere citati (un catalogo scansionabile con uno schema Product pulito può comparire), ma un feed aumenta le probabilità di essere un prodotto consigliato.
• Le funzionalità transazionali sono limitate agli Stati Uniti. Fuori dagli Stati Uniti puoi essere citato e linkato, ma non vendere tramite la piattaforma.

La lettura pratica: per Perplexity il lavoro consiste nella cura del markup Schema.org sulle pagine prodotto più i dati delle recensioni, non in una nuova integrazione del feed. Se le tue PDP emettono già un markup Product e Offer valido con GTIN, prezzo, disponibilità e aggregateRating, hai già fatto gran parte del lavoro.

Livello 5: il checkout, e la geografia reale

È qui che la copertura tende a lasciarsi trasportare, quindi cerchiamo di essere precisi su ciò che è davvero attivo.

Checkout UCP. Disponibile per merchant selezionati, con idoneità dei prodotti negli Stati Uniti, in Canada e in Australia al momento della stesura. Compare come pulsante Acquista sulle inserzioni idonee in AI Mode e in Gemini. Resti tu il venditore registrato. I clienti pagano tramite Google Pay usando le credenziali già presenti nel loro Google Wallet. La partecipazione richiede di soddisfare i requisiti tecnici, inviare un modulo di manifestazione di interesse e completare l'implementazione e, aspetto fondamentale, solo le inserzioni con l'attributo di prodotto native_commerce(checkout_eligibility) mostreranno il pulsante Acquista.

Quest'ultimo dettaglio è il punto chiave a livello di feed. Tutto il resto del checkout UCP è lavoro di integrazione lato backend; il segnale di idoneità, invece, risiede nei tuoi dati di prodotto.

Nel marzo 2026 Google ha annunciato un onboarding UCP semplificato tramite Merchant Center, insieme a funzionalità per carrello, catalogo e collegamento dell'identità, e ha segnalato un'espansione globale nel corso del 2026.

Checkout ACP. Richiede l'implementazione di tre flussi (un feed di prodotto, un'API di checkout e il pagamento delegato tramite un PSP come Stripe) ed è aperto ai partner approvati.

Perplexity Buy with Pro. Limitato agli Stati Uniti.

Se vendi fuori dagli Stati Uniti

La maggior parte dei nostri clienti vende in Turchia, nel Golfo e in Europa. Ecco la situazione reale in questo caso:

Il checkout agentico non è ancora disponibile per te. La scoperta agentica lo è, completamente, già oggi.

Un acquirente di Istanbul che chiede a Gemini o a ChatGPT di confrontare dei prodotti sta già ricevendo una risposta costruita su dati di prodotto strutturati. Che quella risposta includa i tuoi prodotti dipende interamente dai Livelli 1 e 2 descritti sopra: copertura degli identificatori, completezza degli attributi, attributi conversazionali, aggiornamento e coerenza dei dati. Niente di tutto ciò richiede un'integrazione di protocollo, una società negli Stati Uniti o una candidatura per l'accesso anticipato.

Quindi, per un merchant fuori dagli Stati Uniti, la sequenza è chiara:

1. Completa il Livello 1. È un vantaggio puro e migliora anche la performance attuale di Shopping e Performance Max.
2. Affronta subito il Livello 2. Gli attributi conversazionali sono disponibili nella specifica standard di Merchant Center, non comportano rischi per l'approvazione e quasi nessuno nel tuo mercato li ha compilati.
3. Tieni d'occhio il Livello 5. Quando il checkout arriverà nel tuo mercato, i merchant che hanno lavorato sui Livelli 1 e 2 si integreranno in poche settimane. Quelli che non l'hanno fatto partiranno da un catalogo incompleto.

Il vantaggio di muoversi presto non è che venderai su ChatGPT in questo trimestre. È che la qualità dei dati di catalogo richiede mesi per essere sistemata e non si può comprare in fretta quando la finestra si apre.

⚠️ Una scadenza non facoltativa

A prescindere da tutto quanto detto sopra, e molto più urgente: la Content API for Shopping di Google viene dismessa il 18 agosto 2026. Dopo quella data, le chiamate ai vecchi endpoint v2.1 smettono di funzionare.

Questo riguarda solo le integrazioni programmatiche: caricamenti manuali, recuperi programmati e feed da Google Sheets non sono interessati. I merchant che usano integrazioni ufficiali delle piattaforme (il canale Google & YouTube di Shopify, Google Listings & Ads di WooCommerce) sono gestiti dalla piattaforma. Le integrazioni personalizzate e alcuni strumenti di terze parti devono migrare manualmente alla Merchant API v1.

Due cose da controllare oggi stesso: in Merchant Center, vai su Impostazioni → Origini dati e guarda la colonna Origine. Se indica "Content API", hai un'azione da intraprendere. E tieni presente che le etichette dei feed non vengono trasferite automaticamente: se la struttura delle tue campagne Google Ads dipende dalle etichette dei feed, una migrazione fatta con poca cura può interrompere la pubblicazione delle campagne.

Se il tuo feed arriva a Merchant Center tramite Feedance, questa migrazione è gestita da noi e la configurazione della tua esportazione non cambia.

Cosa significa "pronto per gli agenti", campo per campo

Mettendo insieme i livelli in un'unica vista operativa:

Leggere questa tabella in orizzontale è l'esercizio utile: nota quanta parte del comportamento nella colonna di destra dipende da campi facoltativi, che la maggior parte dei cataloghi lascia vuoti.

La checklist di preparazione

Requisiti di base: falli per primi, valgono per ogni superficie

• [ ] Copertura dei GTIN superiore al 90% degli SKU attivi
• [ ] Prezzo e disponibilità che si propagano in un intervallo tra 15 minuti e un'ora, non durante la notte
• [ ] Prezzo, disponibilità, spedizione e resi coerenti tra sito, feed e marketplace
• [ ] Tutte le immagini di almeno 500×500 (richiesto anche da Google a partire dal 31 gennaio 2027)
• [ ] Markup Schema.org Product e Offer valido su ogni PDP, con aggregateRating dove hai recensioni
• [ ] Crawler AI non bloccati per errore in robots.txt
• [ ] google_product_category mappato correttamente, non lasciato all'inferenza
• [ ] Migrazione dalla Content API confermata come completata

Competitivi: la maggior parte del tuo mercato non li ha ancora fatti

• [ ] question_and_answer compilato sui tuoi primi 200 SKU, con almeno 3 coppie ciascuno
• [ ] item_group_title e variant_option su ogni famiglia di varianti
• [ ] popularity_rank calcolato dai tuoi dati di vendita
• [ ] document_link mappato dalla tua libreria esistente di manuali e schede tecniche
• [ ] related_product per accessori e parti necessarie
• [ ] video_link sui prodotti di punta
• [ ] Completezza degli attributi superiore al 95% sul decile di prodotti con il fatturato più alto

Frontiera: per i merchant nei mercati idonei

• [ ] Feed ACP generato e consegnato, completo ogni giorno più aggiornamenti in corso di giornata via API
• [ ] Candidatura al merchant program di Perplexity inviata
• [ ] Modulo di interesse UCP inviato, idoneità native_commerce segnalata sulle inserzioni idonee
• [ ] Traffico e ordini generati dagli agenti tracciati separatamente negli analytics

Quest'ultimo punto merita di essere sottolineato. Gli ordini generati dagli agenti non verranno attribuiti come quelli da ricerca o da social a pagamento, e se non li tracci al momento dell'integrazione non potrai dimostrare che qualcosa di tutto questo abbia funzionato. Imposta la misurazione prima di averne bisogno.

Vale la pena occuparsene?

Una risposta equilibrata, perché il tema attira più certezze di quante ne giustifichino i dati.

Motivi di scetticismo. L'adozione del checkout è stata più lenta di quanto lasciassero intendere gli annunci di lancio. OpenAI ha pubblicamente rivisto il proprio approccio dopo il primo tentativo di Instant Checkout. La maggior parte delle funzionalità transazionali è limitata geograficamente. I dati pubblicati sul fatturato incrementale sono scarsi, e i moltiplicatori di crescita che suonano impressionanti di solito partono da una base molto piccola.

Motivi per agire comunque. Quasi tutto ciò che rientra nei Livelli 1 e 2 migliora la tua attuale performance a pagamento, indipendentemente dal fatto che il commercio agentico mantenga o meno le promesse. Attributi completi, identificatori accurati e dati di inventario aggiornati fanno funzionare meglio Performance Max già oggi. Gli attributi conversazionali non comportano rischi per l'approvazione. E la qualità dei dati di catalogo è un progetto di mesi senza scorciatoie: i merchant che inizieranno quando l'opportunità sarà evidente partiranno in svantaggio.

L'impostazione che suggeriamo: non costruire per il commercio agentico, costruisci un catalogo completo e corretto. Essere pronti per gli agenti è l'aspetto che ha un catalogo completo e corretto nel 2026. Il lavoro sui protocolli è uno strato sottile in cima, ed è la parte che si può fare rapidamente una volta che i dati sottostanti sono a posto.

Se vuoi una base di partenza prima di impegnarti in qualcosa di tutto questo, il nostro strumento gratuito di audit del feed di prodotto valuta qualsiasi feed in base a completezza dei dati, qualità dei dati e stato tecnico: un indicatore ragionevole di quanto di tutto questo hai già.

Fonti

• Google Merchant Center Help — About the Universal Commerce Protocol (UCP): https://support.google.com/merchants/answer/16837055
• Google Merchant Center Help — How to use conversational attributes: https://support.google.com/merchants/answer/17085370
• Google Merchant Center Help — Product data specification: https://support.google.com/merchants/answer/7052112
• Google Developers Blog — Under the Hood: Universal Commerce Protocol: https://developers.googleblog.com/under-the-hood-universal-commerce-protocol-ucp/
• Google for Developers — Migrate from Content API for Shopping to Merchant API: https://developers.google.com/merchant/api/guides/compatibility/overview
• OpenAI Developers — Product Feed Spec (Agentic Commerce): https://developers.openai.com/commerce/specs/spec
• OpenAI Developers — Agentic Commerce key concepts: https://developers.openai.com/commerce/guides/key-concepts
• Agentic Commerce Protocol: https://www.agenticcommerce.dev/
• Universal Commerce Protocol: https://ucp.dev