Preparación del feed para el comercio agéntico: qué exigen realmente UCP, ACP y AI Mode

Algo estructural ha cambiado discretamente en el comercio electrónico durante los últimos dieciocho meses, y la mayor parte de lo que se ha escrito al respecto ha sido o bien exaltado o bien vago.

Esta es la versión concreta. Cuando un comprador pide a un asistente de IA que le encuentre un producto, el asistente no visita su página de inicio. No ve su fotografía, la historia de su marca ni la descripción de producto a la que su redactor dedicó tantos desvelos. Lee datos de producto estructurados (un feed, un bloque de schema, una respuesta de API) y, a partir de ellos, decide si le recomienda a usted o a otro.

Su feed siempre fue la materia prima de sus anuncios. Ahora es la materia prima de la propia recomendación.

Hoy son tres los sistemas que definen cómo funciona esto: el Universal Commerce Protocol (UCP) de Google, el Agentic Commerce Protocol (ACP) de OpenAI y Stripe y el programa para comerciantes de Perplexity. Con frecuencia se escribe sobre ellos como si fueran lo mismo con distintos logotipos. No lo son. Consumen datos distintos, en formatos distintos, con requisitos distintos, y están activos en países distintos.

Esta guía explica qué exige realmente cada uno a nivel de campo, qué se solapa de verdad, qué no y (como la mayoría de los lectores de este blog no venden principalmente en Estados Unidos) qué merece la pena hacer si el checkout agéntico aún no ha llegado a su mercado.

El panorama, sin adornos

Dos observaciones antes de seguir.

Primera: el descubrimiento y el checkout son problemas distintos. Ser encontrable por un agente de IA es un problema de calidad de datos que se aplica hoy en todo el mundo. Poder realizar transacciones dentro de una superficie de IA es un problema de integración de protocolos que actualmente se limita a unos pocos mercados. Confundir ambos es el error más habitual en la cobertura de este tema, y lleva a los comerciantes de fuera de EE. UU. a concluir que nada de esto les afecta. Es justo al revés: la capa de descubrimiento se aplica a todos y es donde se concentra actualmente casi todo el valor disponible.

Segunda: los protocolos convergen en la infraestructura, no en los datos. UCP funciona explícitamente junto con A2A, AP2 y MCP. ACP se basa en la misma idea general. Pero sus esquemas de producto siguen siendo realmente distintos, y un feed creado para uno no encaja directamente en el otro. Es un problema de gestión de feeds, no de estrategia, y tiene una solución sencilla: mantener una única fuente de verdad interna enriquecida y generar a partir de ella exportaciones para cada destino.

Capa 1: la base del descubrimiento (se aplica en todas partes, hoy)

Antes de cualquier trabajo específico de un protocolo, hay un conjunto de requisitos que comparten todos estos sistemas. Si no hace nada más de lo que propone este artículo, haga esta capa. No requiere ningún trabajo de integración y es lo que realmente determina si se le recomienda.

Identificadores de producto

El GTIN es la clave de unión de todo el ecosistema de compras con IA. Todos estos sistemas utilizan identificadores estandarizados para asociar su producto con el mismo producto en otros lugares: para comparar precios, para agregar opiniones, para saber que su ficha y la ficha de un sitio de reseñas describen el mismo objeto.

La ausencia de GTIN no genera ningún mensaje de error. Genera silencio: su producto simplemente no forma parte de la comparación que está haciendo el agente. En particular, se dice que Perplexity pondera la integridad de los identificadores de forma más estricta que Google.

Audite la cobertura de GTIN como porcentaje de los SKU activos. Si está por debajo del 90 %, esa cifra es su primer proyecto.

Integridad de los atributos

Los anuncios de Shopping tradicionales funcionaban con un conjunto bastante reducido de atributos obligatorios. Un agente razona sobre todo lo que usted le da. Cada campo rellenado es un posible motivo para que el agente le recomiende: material, dimensiones, compatibilidad, instrucciones de cuidado, requisitos de alimentación, condiciones de garantía.

El cambio de mentalidad es este: un atributo ya no es un valor de filtro. Es un argumento. material: full-grain leather no es una faceta: es la frase que utiliza el agente cuando un comprador pregunta cuál de dos bolsos envejecerá mejor.

Coherencia en todas las superficies

Este es el requisito que más a menudo se omite y el que más probablemente le perjudicará.

Un comprador humano que ve ₺2,499 en su página de producto y ₺2,399 en un resultado de comparación se encoge de hombros y sigue adelante. Un agente trata la discrepancia como una señal sobre la fiabilidad de sus datos, y un checkout que falla porque el precio ha cambiado es un resultado mucho peor para el operador del agente que simplemente no recomendarle.

Audite la coherencia entre: sus páginas de producto, su feed de Merchant Center, sus datos estructurados en la página y cualquier anuncio que tenga en marketplaces. Los precios, la disponibilidad, las condiciones de envío y la política de devoluciones deben coincidir. Las políticas de devolución y de envío, en particular, son leídas cada vez más por los agentes y citadas a los compradores.

Actualidad

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

La actualización nocturna del feed ya no es suficiente. El Shopping Graph de Google se actualiza a una escala que se mide en miles de millones de fichas por hora y prefiere los datos en vivo; la ingesta de feeds de OpenAI acepta actualizaciones con una frecuencia de hasta cada 15 minutos.

El motivo no es estético. Cuando un agente es capaz de completar una transacción, unos datos de inventario desactualizados no producen un comprador ligeramente decepcionado: producen una transacción fallida. Y los sistemas que hacen fallar transacciones pierden peso.

Objetivo práctico: que el precio y la disponibilidad se propaguen en 15 minutos para el inventario de alta rotación y, como mínimo, cada hora para todo lo demás. Para la mayoría de los comerciantes, esto implica pasar de la obtención programada de archivos a actualizaciones basadas en API o por envío (push).

Acceso de los rastreadores

Revise su robots.txt en lo que respecta a los rastreadores de IA. Muchos comerciantes los bloquearon de forma refleja en 2024 y 2025, durante el debate sobre si "debemos dejar que la IA se entrene con nuestro contenido", y nunca revisaron la decisión. Bloquear el rastreador que alimenta un índice de shopping es una decisión distinta de bloquear un rastreador de entrenamiento, y con frecuencia se toma por accidente, por parte de un equipo que nunca la vio como una decisión comercial.

Capa 2: Google, atributos conversacionales

Es la parte más concreta, la menos comentada y la que permite actuar de forma más inmediata de todo el tema, y es la sección que yo leería dos veces.

Junto con UCP, Google añadió un conjunto de atributos conversacionales a la especificación de datos de producto de Merchant Center. Son opcionales, complementan sus datos de producto existentes y su finalidad explícita es ayudar a los sistemas de IA y a los agentes conversacionales a entender los matices específicos de sus productos. Google afirma que incluirlos no afecta al estado de aprobación de sus productos existentes.

Ese último punto es importante: el riesgo es nulo. Está añadiendo datos descriptivos, no cambiando nada de lo que Google valida para la aprobación.

Este es el conjunto:

El propio ejemplo práctico de Google, para una variante de un teléfono, combina item_group_title, variant_option, question_and_answer, product_highlight, product_detail, related_product, popularity_rank y document_link en un mismo artículo junto con los atributos estándar.

Por qué estos seis y para qué sirven realmente

Fíjese en lo que hace cada uno por un agente:

• question_and_answer es el guion del agente. Un comprador pregunta "¿se puede meter en el lavavajillas?" y el agente tiene su respuesta o no la tiene. Si no la tiene, o dice que no lo sabe (lo que hace perder la venta) o recomienda a un competidor que sí rellenó el campo.
• document_link da al agente un documento sobre el que razonar. Las instrucciones de montaje responden a "¿es difícil de montar?". Las fichas técnicas responden a preguntas de compatibilidad que usted no podía prever.
• related_product es la forma en que la venta cruzada sobrevive a la desaparición de su sitio web del recorrido de compra. required_part, en particular, evita el peor resultado del comercio agéntico: un comprador que adquiere algo que no funciona por sí solo.
• item_group_title y variant_option resuelven el problema que ha perseguido a los feeds de variantes desde que existen: un agente que ve ocho filas y no entiende que son un solo producto en ocho tallas. Es el problema de la estructuración de variantes en un nuevo contexto.
• popularity_rank es usted diciéndole al agente cuáles de sus productos se venden realmente. Nadie más puede darle esa señal.

Cómo rellenarlos a escala

El obstáculo real: nadie tiene una columna question_and_answer en su PIM.

Pero la mayoría de los comerciantes sí tienen la materia prima: los temas de las incidencias de atención al cliente, las FAQ de producto en la página, el contenido de las opiniones y los motivos de devolución. Los pares de preguntas y respuestas más valiosos suelen verse en las preguntas que su equipo de soporte responde con más frecuencia y en los motivos por los que se devuelven los productos. Una devolución que dice "no encajaba en mi máquina" es una pregunta de compatibilidad que debería estar respondiendo en el feed.

Google recomienda añadirlos mediante una fuente de datos complementaria en lugar de rehacer su feed principal, lo cual es lo acertado desde el punto de vista operativo, porque el equipo responsable de los datos de producto y el equipo responsable del contenido de soporte rara vez son el mismo.

A escala de catálogo, esto se convierte en un problema de reglas: derive item_group_title del nombre de su producto principal, construya variant_option a partir de los atributos que ya almacena como color y talla, calcule popularity_rank como percentil a partir de sus propios datos de ventas y asigne document_link desde su biblioteca de manuales existente según el patrón de SKU. En Feedance son reglas de feed que se aplican en cada actualización, y popularity_rank en particular puede recalcularse automáticamente a partir de los datos de ventas en lugar de mantenerse a mano.

Empiece por sus 200 SKU con más ingresos y tres pares de preguntas y respuestas para cada uno. Es una semana de trabajo y cubre la mayoría de sus impresiones visibles para los agentes.

Capa 3: el ACP de OpenAI, una forma realmente distinta

Si da por hecho que el feed de ChatGPT es su feed de Google con otros nombres de columna, construirá algo equivocado. El esquema de feed de productos de ACP es estructuralmente distinto, y las diferencias dicen mucho de lo que quieren los sistemas agénticos.

Los productos contienen variantes. El feed de Google es plano: cada variante es su propia fila, vinculada a las demás mediante item_group_id. ACP invierte esto: un objeto de producto es el registro canónico y contiene un array de objetos de variante. Cada variante tiene su propio id, título, precio, disponibilidad, medios y opciones.

Es un modelo mejor para un agente, y conviene entender por qué. Un feed plano obliga al agente a reconstruir que "esto es una sola zapatilla en nueve tallas" a partir de una clave de agrupación compartida. Un feed anidado le da ese dato directamente. Los comerciantes con catálogos con muchas variantes (la moda por encima de todos) obtienen aquí una mejora real de la precisión.

Los precios son enteros en unidades menores. { "amount": 7999, "currency": "USD" } equivale a 79,99 USD. No es una cadena decimal. Cualquier flujo que haga cálculos con decimales en coma flotante sobre los precios debe revisarse antes de que produzca algo erróneo sin avisar.

Las descripciones son objetos, no cadenas. El objeto description acepta plain, html y markdown; puede proporcionar cualquier combinación.

Los enlaces a las políticas del vendedor son de primer nivel. El objeto seller contiene links, tipificados como privacy_policy, terms_of_service, refund_policy, shipping_policy o faq. Vuelva a leer esa lista: el agente quiere su política de devoluciones como un campo estructurado. En un mundo en el que el comprador nunca ve su sitio web, sus políticas tienen que viajar con el producto.

El estado es un array. ["new"], y puede aplicarse más de un valor, lo que anticipa el inventario de segunda mano y reacondicionado.

Una estructura mínima:

{
  "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" }
        ]
      }
    }
  ]
}

El archivo del feed va acompañado de una cabecera con feed_id, account_id, target_merchant y target_country; tenga en cuenta que el país se define a nivel de feed, lo que significa que los comerciantes multimercado envían un feed por mercado.

El patrón de entrega recomendado por OpenAI es un feed completo una vez al día mediante subida de archivo, con actualizaciones durante el día enviadas a través de la API. Los catálogos pequeños pueden hacer ambas cosas mediante la API.

Conviene ser realista en una cosa: el checkout dentro del chat de OpenAI ha tenido un primer año más complicado de lo que sugerían los anuncios, y la empresa ha reconocido públicamente que la implementación inicial de Instant Checkout era menos flexible de lo previsto, por lo que ha desplazado el énfasis hacia el descubrimiento de productos con traspaso al sitio del comerciante para el pago. Si tiene que priorizar, trate el descubrimiento de ACP como la oportunidad a corto plazo y el checkout de ACP como una apuesta a más largo plazo.

Capa 4: Perplexity

El programa para comerciantes de Perplexity es el menos documentado de los tres y, por eso mismo, el que más se describe de forma errónea. Las guías que publican una especificación detallada de campos de Perplexity están extrapolando a partir de Google: no se ha publicado ninguna especificación oficial de campos.

Lo que se sabe:

• El programa es gratuito y requiere solicitud; la incorporación se ha ido ampliando a lo largo de 2025 y 2026.
• El feed se entrega en CSV o XML, mediante API, SFTP o un bucket de S3 dedicado, en formato Google Shopping.
• La integridad de los datos de producto funciona como factor de clasificación: unos datos más completos dan al sistema más con lo que trabajar al generar comparaciones y resúmenes de ventajas e inconvenientes.
• La integridad de los identificadores, los datos de opiniones y el marcado Schema.org en la página parecen tener más peso que en Google.
• No es estrictamente necesario un feed para ser citado (un catálogo rastreable con un schema Product limpio puede aparecer), pero un feed mejora las probabilidades de ser un producto recomendado.
• Las funciones transaccionales se limitan a EE. UU. Fuera de EE. UU. puede ser citado y enlazado, pero no vender a través de la plataforma.

La lectura práctica: para Perplexity, el trabajo consiste en la higiene del marcado Schema.org en sus páginas de producto más los datos de opiniones, no en una nueva integración de feed. Si sus páginas de producto ya emiten un marcado Product y Offer válido con GTIN, precio, disponibilidad y aggregateRating, ya ha hecho la mayor parte.

Capa 5: el checkout, y la geografía real

Aquí es donde la cobertura suele dejarse llevar, así que seamos precisos sobre lo que está realmente activo.

Checkout de UCP. Disponible para comerciantes seleccionados, con productos aptos en Estados Unidos, Canadá y Australia en el momento de redactar este artículo. Aparece como un botón de compra en las fichas aptas de AI Mode y Gemini. Usted sigue siendo el vendedor oficial. Los clientes pagan con Google Pay utilizando las credenciales que ya tienen en su Google Wallet. Para participar hay que cumplir los requisitos técnicos, enviar un formulario de interés y completar la implementación y, lo que es fundamental, solo las fichas que incluyan el atributo de producto native_commerce(checkout_eligibility) mostrarán el botón de compra.

Ese último detalle es la conclusión a nivel de feed. Todo lo demás del checkout de UCP es trabajo de integración en el backend; la señal de aptitud en sí reside en sus datos de producto.

En marzo de 2026, Google anunció una incorporación simplificada a UCP a través de Merchant Center, junto con funciones de carrito, catálogo y vinculación de identidad, y ha indicado que se expandirá a nivel mundial a lo largo de 2026.

Checkout de ACP. Requiere implementar tres flujos (un feed de productos, una API de checkout y el pago delegado a través de un PSP como Stripe) y está abierto a partners aprobados.

Perplexity Buy with Pro. Limitado a EE. UU.

Si vende fuera de EE. UU.

La mayoría de nuestros clientes venden en Turquía, el Golfo y Europa. Esta es la situación real en ese caso:

El checkout agéntico todavía no está disponible para usted. El descubrimiento agéntico sí lo está, por completo, hoy.

Un comprador de Estambul que pide a Gemini o ChatGPT que compare productos está recibiendo ahora mismo una respuesta construida a partir de datos de producto estructurados. Que esa respuesta incluya sus productos depende por completo de las capas 1 y 2 anteriores: cobertura de identificadores, integridad de los atributos, atributos conversacionales, actualidad y coherencia. Nada de eso requiere una integración de protocolos, una entidad en EE. UU. ni una solicitud de acceso anticipado.

Por eso, el orden para un comerciante de fuera de EE. UU. está claro:

1. Complete la capa 1. Todo son ventajas y, además, mejora el rendimiento actual de Shopping y Performance Max.
2. Aborde la capa 2 ahora. Los atributos conversacionales están disponibles en la especificación estándar de Merchant Center, no conllevan ningún riesgo de aprobación y casi nadie en su mercado los ha rellenado.
3. Vigile la capa 5. Cuando el checkout llegue a su mercado, los comerciantes que hayan completado las capas 1 y 2 se integrarán en semanas. Los que no, empezarán con un catálogo incompleto.

La ventaja de moverse pronto no es que vaya a realizar transacciones en ChatGPT este trimestre. Es que la calidad de los datos del catálogo tarda meses en corregirse y no se puede comprar con prisas cuando se abra la ventana.

⚠️ Un plazo que no es opcional

Al margen de todo lo anterior, y mucho más urgente: la Content API for Shopping de Google deja de funcionar el 18 de agosto de 2026. A partir de esa fecha, las llamadas a los antiguos endpoints v2.1 dejarán de funcionar.

Esto afecta solo a las integraciones programáticas: las subidas manuales, las obtenciones programadas y los feeds de Google Sheets no se ven afectados. Los comerciantes con integraciones oficiales de plataforma (el canal Google & YouTube de Shopify, Google Listings & Ads de WooCommerce) dependen de la plataforma, que se encarga de ello. Las integraciones personalizadas y algunas herramientas de terceros deben migrarse manualmente a Merchant API v1.

Dos cosas que debe comprobar hoy: en Merchant Center, vaya a Configuración → Fuentes de datos y mire la columna Fuente. Si indica "Content API", tiene una tarea pendiente. Y tenga en cuenta que las etiquetas de feed no se trasladan automáticamente: si la estructura de sus campañas de Google Ads depende de las etiquetas de feed, una migración hecha sin cuidado puede hacer que las campañas dejen de publicarse.

Si su feed llega a Merchant Center a través de Feedance, nosotros nos encargamos de esta migración y la configuración de su exportación no cambia.

Qué significa "listo para agentes", campo por campo

Reuniendo las capas en una única visión operativa:

Leer esa tabla en horizontal es el ejercicio útil: observe cuánto del comportamiento de la columna derecha depende de campos que son opcionales y que la mayoría de los catálogos dejan vacíos.

La lista de comprobación de preparación

Lo imprescindible: hágalo primero, se aplica a todas las superficies

• [ ] Cobertura de GTIN superior al 90 % de los SKU activos
• [ ] Precio y disponibilidad propagados en un plazo de 15 minutos a una hora, no de un día para otro
• [ ] Precio, disponibilidad, envíos y devoluciones coherentes entre el sitio, el feed y los marketplaces
• [ ] Todas las imágenes de al menos 500×500 (también exigido por Google a partir del 31 de enero de 2027)
• [ ] Marcado Schema.org Product y Offer válido en todas las páginas de producto, con aggregateRating cuando tenga opiniones
• [ ] Rastreadores de IA no bloqueados por accidente en robots.txt
• [ ] google_product_category asignado correctamente, no dejado a la inferencia
• [ ] Migración de la Content API confirmada como completada

Ventaja competitiva: la mayor parte de su mercado no lo ha hecho

• [ ] question_and_answer rellenado en sus 200 SKU principales, con 3 o más pares cada uno
• [ ] item_group_title y variant_option en todas las familias de variantes
• [ ] popularity_rank calculado a partir de sus propios datos de ventas
• [ ] document_link asignado desde su biblioteca existente de manuales y fichas técnicas
• [ ] related_product para accesorios y piezas necesarias
• [ ] video_link en los productos estrella
• [ ] Integridad de los atributos superior al 95 % en su decil de mayores ingresos

La vanguardia: para comerciantes de mercados aptos

• [ ] Feed de ACP generado y entregado, completo a diario más actualizaciones intradía por API
• [ ] Solicitud al programa para comerciantes de Perplexity enviada
• [ ] Formulario de interés de UCP enviado y aptitud native_commerce indicada en las fichas que cumplan los requisitos
• [ ] Tráfico y pedidos originados por agentes etiquetados por separado en la analítica

Este último punto merece subrayarse. Los pedidos generados por agentes no se atribuirán como los de búsqueda o redes sociales de pago, y si no los etiqueta en el momento de la integración no podrá demostrar que nada de esto ha funcionado. Configure la medición antes de necesitarla.

¿Merece la pena?

Una respuesta equilibrada, porque el tema atrae más certezas de las que respaldan los datos.

Motivos para el escepticismo. La adopción del checkout ha sido más lenta de lo que daban a entender los anuncios de lanzamiento. OpenAI reformuló públicamente su enfoque tras el primer intento de Instant Checkout. La mayoría de las funciones transaccionales tienen restricciones geográficas. Los datos publicados sobre ingresos incrementales son escasos, y los multiplicadores de crecimiento que suenan impresionantes suelen partir de una base muy pequeña.

Motivos para actuar de todos modos. Casi todo lo de las capas 1 y 2 mejora su rendimiento de pago actual, tanto si el comercio agéntico cumple las previsiones como si no. Unos atributos completos, unos identificadores exactos y unos datos de inventario actualizados hacen que Performance Max funcione mejor hoy. Los atributos conversacionales no conllevan ningún riesgo de aprobación. Y la calidad de los datos del catálogo es un proyecto de meses sin atajos: los comerciantes que empiecen cuando la oportunidad sea evidente partirán con desventaja.

El enfoque que proponemos: no construya para el comercio agéntico; construya un catálogo completo y correcto. Estar preparado para los agentes es el aspecto que tiene un catálogo completo y correcto en 2026. El trabajo de protocolos es una capa fina por encima, y es la parte que puede hacerse rápidamente una vez que los datos de debajo están bien.

Si quiere una referencia antes de comprometerse con nada de esto, nuestra herramienta gratuita de auditoría de feeds de productos puntúa cualquier feed en cuanto a integridad de los datos, calidad de los datos y estado técnico, lo que es un indicador razonable de cuánto de todo esto ya tiene.

Fuentes

• Ayuda de Google Merchant Center: Acerca del Universal Commerce Protocol (UCP): https://support.google.com/merchants/answer/16837055
• Ayuda de Google Merchant Center: Cómo utilizar los atributos conversacionales: https://support.google.com/merchants/answer/17085370
• Ayuda de Google Merchant Center: Especificación de datos de producto: 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: Migrar de Content API for Shopping a 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: Conceptos clave de Agentic Commerce: https://developers.openai.com/commerce/guides/key-concepts
• Agentic Commerce Protocol: https://www.agenticcommerce.dev/
• Universal Commerce Protocol: https://ucp.dev