Checklist técnico: enums canónicos en Delta API

Las señales de inventario son los campos explícitos de disponibilidad y a nivel de variante, in_stock, out_of_stock, preorder, backorder o unknown, además de availability_date y los ID estables de artículo, que los agentes de compra con IA leen para decidir si mostrar tu producto o no. La corrección única que más importa: haz que el valor de disponibilidad en tu feed coincida con lo que ve un comprador en tu página de destino, usando siempre la ortografía exacta del enum que el agente espera cada vez que cambie el stock.

Resumen rápido:

• Usa valores de disponibilidad aceptados exactos en cada variante; OpenAI rechaza las entradas ausentes, vacías o no válidas, y los ID estables de artículo y oferta conservan el seguimiento del SKU.
• Aplica los cambios de precio y disponibilidad mediante la Delta API; reserva las cargas SFTP completas para productos nuevos o cambios que afecten a todo el catálogo.
• Para artículos en preorder o backorder, proporciona availability_date en formato ISO 8601, con no más de un año de antelación, y muéstrala en la página del producto.
• Haz coincidir la disponibilidad del feed con los datos estructurados de la página de destino y mantén los precios visibles cuando los productos estén agotados, porque los agentes pueden comparar ambas fuentes.
• Después de cada actualización, confirma que el estado del producto procesado sea active; los productos marcados como out of stock siguen sin ser aptos hasta que se corrijan y se vuelvan a procesar.

Campos y valores exactos que los agentes de IA esperan de tu feed

Los agentes de compra con IA no deducen el estado del stock a partir del diseño de tu sitio web ni de tu texto de marketing. Leen un pequeño conjunto de campos estructurados, y si esos campos faltan, están mal escritos o son incoherentes, la fila del producto se descarta antes de que un comprador llegue siquiera a verla.

Los campos principales que los comerciantes deben mapear correctamente son availability (el propio estado), un booleano available, availability_date, item_id, group_id, offer_id y un variant_dict para productos con opciones como talla o color. La especificación del feed de productos de OpenAI requiere un valor availability explícito en cada fila y acepta exactamente cinco grafías: in_stock, out_of_stock, pre_order, backorder o unknown.

Los valores de availability omitidos, vacíos o no reconocidos hacen que toda la fila del producto sea rechazada de inmediato, lo que significa que el producto simplemente nunca aparece como candidato de recomendación.

Unas pocas reglas de mapeo evitan la mayoría de los rechazos:

• Usa una fila por variante en lugar de agrupar tallas o colores en un único listado.
• Mantén item_id y offer_id estables en las actualizaciones del feed para que el agente pueda seguir la misma variante a lo largo del tiempo.
• Usa group_id para indicar al agente qué filas pertenecen al mismo producto principal.
• Mantén los nombres de las opciones (como “Talla” o “Color”) escritos de forma idéntica en cada variante de un grupo.

Los datos estructurados de la página de destino deben reflejar exactamente el feed. Si tu marcado de Schema.org dice InStock mientras tu feed dice out_of_stock, los agentes que comprueban ambas fuentes marcarán la discrepancia y podrían ocultar el listado en lugar de adivinar cuál es el correcto.

Qué ocurre con la publicación cuando cambia el estado del stock

Marcar un producto como out_of_stock no solo añade una etiqueta. Elimina activamente el producto de la elegibilidad hasta que el feed se vuelva a procesar con un estado corregido.

Según la guía de feeds de producto de Ads de OpenAI, un producto out_of_stock deja de cumplir los requisitos para la publicación y no se reanudará hasta que vuelva a estar en in_stock y se vuelva a procesar. La misma lógica se aplica de forma general en las plataformas de agentes: la disponibilidad se trata como una condición de acceso, no como una sugerencia. Los ajustes a nivel de feed y una marca is_ads_eligible también pueden controlar si un producto entra o no en el procesamiento de anuncios, por separado de la elegibilidad para recomendaciones orgánicas.

La mayoría de los problemas de no publicación se remontan a una breve lista de causas:

• Un campo de disponibilidad dejado vacío en lugar de establecerse como unknown.
• Un valor enum mal escrito, como “instock” en lugar de in_stock.
• Una página de destino que devuelve un error o una imagen ausente cuando el agente intenta verificar el producto.
• Una regla de filtro o selector que excluye el producto tras una actualización rutinaria del feed.

Consejo profesional: Mantén el precio visible en tu página de destino incluso cuando un producto esté agotado. La guía de datos de producto de Google lo exige, y además mantiene la página utilizable para los compradores que llegan allí desde una respuesta en caché del agente.

Cuándo usar la API Delta frente a una carga SFTP completa

No todos los cambios de inventario necesitan el mismo método de actualización, y usar el incorrecto es una fuente habitual de datos de disponibilidad desactualizados.

La guía de feeds de producto de Ads de OpenAI recomienda una división clara: usa la API Delta o una solicitud PATCH para cambios de precio y disponibilidad, y reserva las cargas completas por SFTP para añadir productos nuevos o hacer cambios masivos de campos en todo el catálogo.

1. Actualiza la disponibilidad y el precio mediante la API Delta siempre que un SKU se quede sin stock, vuelva a estar disponible o cambie de precio. Esta es la actualización de mayor impacto para inventario de rápida rotación, ya que llega al feed activo sin volver a subirlo todo.
2. Usa cargas completas por SFTP al lanzar productos nuevos, reestructurar grupos de variantes o cambiar campos que afectan a todo el catálogo de una sola vez.
3. Establece una cadencia según la velocidad del catálogo. Los deltas casi en tiempo real se adaptan a los SKU que se agotan con frecuencia; las actualizaciones por lotes cada hora o diarias cubren la mayoría de los catálogos; una actualización completa nocturna funciona como respaldo para detectar cualquier cosa que los deltas hayan pasado por alto.
4. Mantén sincronizado tu sistema de inventario como fuente de verdad con los parches delta. Un desajuste entre tu recuento interno de stock y lo que has aplicado al feed mediante parches crea exactamente el tipo de inconsistencia que hace que las filas se marquen más tarde.

Después de cualquier actualización, verifica que realmente se haya procesado. Consulta el producto y confirma que la respuesta de estado del feed muestra “active” en lugar de pendiente o rechazado, ya que un parche que falla silenciosamente deja activo el valor de disponibilidad anterior e incorrecto.

Cómo confirmar que tus señales de inventario se han ingerido correctamente

Enviar una actualización no es lo mismo que confirmar que un agente la ve de la manera en que pretendías. Una breve rutina de validación detecta discrepancias antes de que te cuesten visibilidad.

Empieza por el feed sin procesar: extrae una muestra de filas y comprueba que los valores de disponibilidad usan exactamente las grafías aceptadas, y que los valores de item_id y group_id son estables entre exportaciones en lugar de regenerarse en cada sincronización.

A continuación, confirma el procesamiento en el lado de la plataforma. La documentación de Global Catalog de Shopify describe respuestas del catálogo de agentes que incluyen campos inferidos como available, status y running_low, que los desarrolladores pueden consultar directamente para comprobar si la disponibilidad de una variante se procesó de la manera prevista por el feed.

Algunas comprobaciones que merece la pena realizar con regularidad:

• Compara el precio visible de la página de destino y la disponibilidad de Schema.org con el valor del feed para el mismo SKU.
• Usa un sandbox de pruebas de UCP para enviar una consulta de producto e inspeccionar la URL de pago y los datos de la variante que un agente recibiría realmente.
• Vigila las confirmaciones de «status: active» en las respuestas del feed, e investiga cualquier producto que desaparezca silenciosamente tras una actualización rutinaria, ya que una regla de filtrado suele ser la causa.

Consejo profesional: Trata los campos inferidos de las herramientas del catálogo storefront de Shopify como una señal de descubrimiento, no como un sustituto de los datos de disponibilidad y precio que proporcionas directamente.

Lista de acciones rápidas: corrige los problemas más importantes esta semana

No necesitas una migración completa de plataforma para cerrar la mayoría de las brechas en las señales de inventario. Una semana de correcciones enfocadas resuelve los problemas que provocan más filas rechazadas y pérdida de visibilidad.

1. Exporta una muestra de filas de productos y comprueba cada valor de disponibilidad frente a las cinco grafías aceptadas: in_stock, out_of_stock, preorder, backorder, unknown.
2. Asigna tus estados internos de stock a esos enums canónicos, y luego canaliza los cambios de precio y disponibilidad a través de la Delta API en lugar de esperar a la siguiente carga completa.
3. Añade availability_date en formato ISO 8601 para cualquier artículo preorder o backorder, y muestra esa fecha en la propia página de destino.
4. Consulta los datos del producto procesados y confirma que el estado del feed aparece como «active». Repite el ciclo de exportación y comprobación hasta que no vuelva ninguna fila rechazada.

Esta secuencia prioriza primero las correcciones con el retorno más rápido: valores canónicos e ID estables, luego la velocidad de actualización, después la gestión de preorder y, por último, la verificación. Cada paso cierra una brecha que, de otro modo, elimina silenciosamente productos de la consideración.

Definición e importancia de las señales de inventario en contextos de IA

En un contexto de compras con IA, una señal de inventario es cualquier dato estructurado que indica a un agente de compras si un producto puede comprarse realmente ahora mismo y en qué condiciones. Eso incluye el enum de disponibilidad, el booleano available, availability_date para artículos que todavía no pueden enviarse y el estado a nivel de variante para cada opción de talla o color.

Estas señales importan más en las compras impulsadas por agentes de lo que importaban en la búsqueda tradicional o en los anuncios display, porque un agente está haciendo una recomendación en nombre del comprador, a menudo sin que el comprador navegue primero por la página. Si el agente recomienda un producto que al final resulta estar agotado, el fallo se hace visible de inmediato y erosiona la confianza en las sugerencias del agente, no solo en tu marca.

Esa dinámica empuja a las plataformas hacia una aplicación más estricta de las normas de la que exigían los feeds de ecommerce más antiguos. La especificación de producto de OpenAI rechaza directamente las filas con valores de disponibilidad ausentes o mal formados, en lugar de asumir un estado por defecto. No existe un fallback de «probablemente en stock».

Para los comerciantes, esto replantea los datos de inventario: pasan de ser una cuestión de operaciones de backend a una cuestión de visibilidad. Un producto con un copy excelente, imágenes potentes y precios competitivos seguirá sin aparecer si su campo de disponibilidad está vacío o mal escrito. La propia señal se ha convertido en un mecanismo de acceso, lo que significa que hacerlo bien es un requisito previo para cualquier otra optimización, no una tarea paralela.

Cómo afectan las señales de inventario a la previsión de demanda impulsada por IA

Unos datos de disponibilidad precisos y actualizados de forma constante hacen más que mantener visible un único producto. Dan forma a cómo un agente, o los sistemas que alimentan sus recomendaciones, interpretan los patrones de demanda en un catálogo a lo largo del tiempo.

Cuando la disponibilidad cambia de forma fiable y rápida entre in_stock y out_of_stock, ese patrón se convierte en una señal utilizable: las roturas de stock frecuentes en un SKU sugieren una demanda alta en relación con la oferta, mientras que un SKU que rara vez deja de estar in_stock sugiere una disponibilidad más estable y predecible. Las señales desactualizadas o incoherentes rompen ese patrón. Un producto que sigue mostrando in_stock después de haberse agotado no solo induce a error al comprador, también enturbia cualquier inferencia posterior sobre la velocidad real de rotación de ese artículo.

La gestión de preorder y backorder influye directamente en esto. La guía de Google Merchant Center exige un availability_date en formato ISO 8601 para los artículos preorder y backorder, con un límite de hasta un año vista, específicamente para que los sistemas que leen el feed puedan distinguir entre «todavía no disponible, pero comprometido» y «simplemente agotado sin ningún plan». Esa distinción aporta un valor de señal real: un backorder con una fecha cercana se interpreta de forma muy distinta a uno sin fecha alguna.

Para los comerciantes, la conclusión práctica es que la calidad de la previsión aguas abajo depende de la higiene del feed aguas arriba. Las actualizaciones delta aplicadas con rapidez, en lugar de agruparse una vez por semana, mantienen la señal lo bastante fresca como para reflejar la demanda real en vez de una instantánea retrasada de ella.

Mejores prácticas para integrar señales de inventario con algoritmos de IA

Los comerciantes que evitan la mayoría de los problemas con las señales de inventario suelen seguir un conjunto breve de hábitos en lugar de un sistema complejo.

En primer lugar, trata el feed como la única fuente de verdad y envía cada cambio a través de él de inmediato, en lugar de actualizar primero el sitio web y el feed después. La documentación de Ads de OpenAI especifica columnas obligatorias, incluidas item_id, title, description, url, brand, image_url, price y availability, y espera que esos campos se mantengan actualizados mediante la Delta API en lugar de exportaciones periódicas.

En segundo lugar, mantén los datos de las variantes coherentes. La guía de fragmentos de producto de OpenAI recomienda una fila por variante con ID estables y opciones nombradas de forma coherente dentro de un grupo, ya que una denominación inconsistente (llamar al campo de color de una variante “Color” y al de otra “colour”) rompe la capacidad del agente para agruparlas correctamente.

En tercer lugar, nunca permitas que la página de destino y el feed diverjan. Los datos estructurados de la página deben indicar el mismo valor de availability que el feed, y el precio debe seguir siendo visible incluso cuando el artículo no esté disponible, ya que varias plataformas hacen referencia a ese estado de la página al verificar una afirmación del feed.

En cuarto lugar, crea automatizaciones de actualización en torno a eventos de inventario en lugar de exportaciones manuales. Un webhook que se active con los cambios en el nivel de stock y desencadene un parche de la Delta API cierra la brecha entre que un artículo realmente se agote y que el feed lo refleje, algo que importa más para los SKU que se mueven más rápido.

Desafíos comunes y errores habituales al usar señales de inventario para IA

La mayoría de los fallos relacionados con las señales de inventario provienen de un pequeño conjunto de errores recurrentes, más que de casos límite exóticos.

El más común es dejar vacío el campo availability en lugar de establecerlo explícitamente como unknown. La especificación de OpenAI trata un valor vacío igual que uno no válido: la fila se rechaza en ambos casos, así que no hay un valor predeterminado seguro al que recurrir.

Muy cerca en frecuencia está la deriva ortográfica. Los sistemas internos suelen usar etiquetas como “Available”, “In Stock” o “0” y “1” para estados booleanos, y una exportación directa y sin mapear de esas etiquetas rara vez coincide con los enums exactos que requiere un agente. Cualquier capa de mapeo entre tu sistema de inventario y tu feed necesita traducir de forma coherente, no solo una vez durante la configuración, sino cada vez que se introduzca internamente un nuevo estado.

Las discrepancias entre la página de destino y el feed causan otro tipo de problema: la fila puede pasar la validación, pero la comprobación cruzada del agente con la página encuentra una contradicción y aun así suprime el anuncio. Esto ocurre a menudo con el almacenamiento en caché, cuando una actualización del feed se publica de inmediato pero la página de producto del sitio web mantiene en caché un estado antiguo de availability durante minutos o horas.

La gestión de variantes causa un problema menos visible pero costoso. Los comerciantes que agrupan todas las variantes en una sola fila, o que permiten que los valores de item_id se regeneren en cada exportación, dificultan que un agente siga el historial de un SKU específico, lo que puede afectar incluso a la confianza con la que se recomienda.

Por último, la dependencia excesiva de los campos inferidos es un error creciente. Las plataformas generan cada vez más datos complementarios de forma automática, pero Shopify deja claro que los campos inferidos son ayudas para el descubrimiento, no un sustituto de los datos de availability y price proporcionados por el comerciante.

Casos prácticos y ejemplos de señales de inventario funcionando como se pretende

Algunos escenarios concretos ilustran cómo estas mecánicas se desarrollan en la práctica.

Considera un comercio que realiza una venta flash sobre un lote limitado de un SKU popular. A medida que se venden las unidades, el sistema interno de inventario baja a cero, pero el comercio actualiza solo el sitio web, no el feed, y espera a la siguiente carga completa programada por SFTP esa noche. Durante varias horas, el agente sigue tratando el SKU como in_stock y continúa recomendándolo, lo que provoca pagos fallidos. Si el comercio hubiera canalizado ese cambio a través de la API Delta en el momento en que el stock llegó a cero, el cambio de disponibilidad habría llegado al agente dentro del ciclo normal de parcheo en lugar de esperar a un trabajo por lotes.

Un segundo caso implica el lanzamiento de una preventa. Un comercio establece la disponibilidad como preorder pero deja availability_date en blanco, asumiendo que el campo es opcional. Según las reglas de Google Merchant Center, esa omisión es exactamente el tipo de vacío que crea ambigüedad para cualquier sistema que intente decidir si merece la pena recomendar el producto ahora o más adelante. Añadir una fecha ISO 8601 con el formato correcto y mostrarla en la página de destino resuelve la ambigüedad y permite que la preventa aparezca con normalidad.

Un tercer ejemplo, más estructural: una línea de ropa con múltiples variantes en la que cada talla utilizaba una capitalización distinta para el mismo nombre de color entre ciclos de exportación (“Navy” frente a “navy”). La inconsistencia no desencadenó un rechazo, ya que el campo seguía teniendo un valor, pero fracturó el grupo de variantes, por lo que el agente vio lo que parecían productos separados y no relacionados en lugar de un solo artículo con opciones de talla. Estandarizar la denominación de las opciones en el punto de exportación resolvió la fragmentación.

Perspectiva experta: priorización cuando la capacidad de ingeniería es limitada

La mayoría de los equipos no tienen capacidad para arreglarlo todo de una vez, por lo que la secuenciación importa más que la exhaustividad. La asignación canónica de disponibilidad va primero: es la única corrección que evita un rechazo directo, y nada más importa si la fila nunca entra en el sistema. La automatización Delta para tus SKU de mayor rotación va en segundo lugar, ya que es ahí donde una disponibilidad desactualizada cuesta más en recomendaciones perdidas.

Los equipos con recursos limitados deberían resistir la tentación de invertir en exceso en enriquecimiento (descripciones más completas, atributos ampliados) antes de que lo básico esté consolidado. Un valor de disponibilidad coherente y correctamente escrito en cada página supera a una ficha bellamente redactada que contradice silenciosamente su propio feed. Una vez que los fundamentos se mantienen, la automatización impulsada por webhooks hace que sigan manteniéndose sin trabajo manual continuo.

— Xhurian

Cómo ecentic te ayuda a cerrar más rápido las brechas en las señales de inventario

Encontrar una discrepancia entre el feed y la página comprobando manualmente las filas frente a las páginas de destino lleva horas que un equipo pequeño rara vez tiene. Construimos nuestra plataforma para simular cómo ChatGPT, Gemini, Claude y Perplexity evalúan realmente tus fichas, para que veas exactamente dónde fallan la disponibilidad, los datos de variantes o los datos estructurados antes de que eso te cueste una recomendación.

Nuestros diagnósticos señalan enums no coincidentes, campos availability_date ausentes y contradicciones entre feed y página en un inglés sencillo, y después te permiten publicar la corrección directamente en tu plataforma de comercio electrónico con un solo clic. Empieza con un análisis gratuito o compara nuestros planes en la página de precios para ver cuál se adapta al tamaño de tu catálogo.

Preguntas frecuentes

¿Cuáles son los valores de disponibilidad aceptados para los feeds de compras con IA?

Los valores aceptados son in_stock, out_of_stock, pre_order (o preorder), backorder y unknown, y el campo debe contener una de estas grafías exactas. La especificación del feed de productos de OpenAI rechaza cualquier fila con un valor de disponibilidad ausente, vacío o no reconocido.

¿Cuál es la diferencia entre la Delta API y las cargas por SFTP?

La Delta API está diseñada para cambios frecuentes y específicos, como actualizaciones de precio o disponibilidad en productos individuales, mientras que las cargas completas por SFTP son adecuadas para cambios masivos o para añadir nuevos productos al catálogo. La guía de feeds de anuncios de OpenAI recomienda usar deltas para inventario con movimiento rápido y reservar las cargas completas para cambios más amplios del catálogo.

¿Marcar un producto como out_of_stock lo elimina inmediatamente?

Sí. Un producto out_of_stock deja de ser apto para entrega y recomendación hasta que se actualiza de nuevo a in_stock y se vuelve a procesar, según la documentación de Ads de OpenAI. No hay un periodo de gracia en el que un artículo sin stock siga apareciendo con normalidad.

¿Cómo deben formatearse las fechas de preorder y backorder?

El campo availability_date debe usar el formato ISO 8601 y puede establecerse con hasta un año de antelación, según la especificación de datos de producto de Merchant Center de Google. Esta fecha también debe aparecer en la página de destino del producto para que los compradores vean la misma información que proporciona el feed.

¿Puede ecentic corregir automáticamente los desajustes de señales de inventario?

Nuestra plataforma diagnostica desajustes entre tu feed y las páginas de destino, y ofrece publicación con un clic para aplicar campos corregidos en Shopify o WooCommerce. El precio empieza con el plan Compete a 14,90 $ al mes, con niveles superiores disponibles para catálogos más grandes.

Fuentes

• Products – Agentic Commerce | OpenAI Developers
• Especificación de datos de producto - Ayuda de Google Merchant Center
• Global Catalog MCP | Documentación para desarrolladores de Shopify

Enlaces principales de especificaciones y documentación para implementadores

Para casos límite y reglas de validación exactas, acude directamente a la documentación original en lugar de depender de resúmenes de terceros. La especificación del feed de productos de OpenAI y la guía de feeds de productos de Ads cubren en detalle los campos obligatorios, los valores enum y los canales de actualización. La ayuda de Merchant Center de Google documenta availability_date y las reglas de coincidencia con la página de destino, y la documentación de Global Catalog de Shopify explica cómo las respuestas del catálogo de agentes manejan la disponibilidad inferida y a nivel de variante. Para implementar datos estructurados junto con estos feeds, esta guía de schema markup cubre los tipos que los comerciantes suelen necesitar primero.