Un cliente ya no tiene que visitar tu tienda para comprar en ella. En 2026, un agente de IA puede leer tu catálogo, añadir un producto y finalizar un pedido de WooCommerce en nombre del comprador, y lo hace todo a través de una interfaz, no en una pestaña del navegador. El pedido cae en tu panel de administración. El dinero entra. Y tu analítica no registra nada.
Esto no es hipotético. El propio blog de desarrolladores de WooCommerce expuso la hoja de ruta de IA y agentic commerce, incluidas pruebas de checkout instantáneo fuera del sitio con socios como Google y Stripe, y el ecosistema se cierra a su alrededor más rápido de lo que los plugins de rastreo logran seguir. En WPPoland construimos e instrumentamos tiendas WooCommerce para clientes que venden en toda la UE, y las primeras tiendas que reciben pedidos de agentes ya ven la brecha entre lo que vendieron y lo que sus paneles dicen que vendieron.
Aquí tienes el mecanismo, las cosas concretas que se rompen, por qué la Conversions API no te salva de forma automática y la manera de instrumentarlo bien.
La escala crece deprisa: según Stripe, su producto de pagos Link ya da servicio a unos 200 agentes de IA, frente a unos 70 en los datos de la empresa de septiembre (Upstarts Media, 18.10.2026). Stripe matiza que Anthropic y OpenAI usan Link, pero todavía no para compras realizadas por agentes.
Pedidos de agentes de IA que no aparecen en GA4
La respuesta corta: a tu analítica no le pasa nada, y ese es el problema. Tu pila de informes se construyó sobre el supuesto de que cada compra la precede una persona cargando páginas en un navegador. Un agente rompe ese supuesto. Completa el pedido del lado del servidor, así que cada señal basada en el navegador de la que depende tu analítica simplemente nunca se dispara.
Te quedas con un pedido de WooCommerce sin sesión coincidente en Google Analytics, sin evento coincidente en el píxel de Meta y sin atribución, porque no hubo clic, no hubo llegada con etiqueta UTM y no hubo navegador del que leer nada. Los ingresos son reales. El rastro está vacío.
Por qué GA4 y el píxel de Meta necesitan navegador
La mayor parte de la medición en WooCommerce es, por diseño, del lado del cliente. Google Analytics 4 recoge a través de gtag.js, un script que el navegador del visitante descarga y ejecuta. El píxel de Meta es la misma idea: un fragmento que se ejecuta en el navegador y reporta PageView, AddToCart, InitiateCheckout y Purchase a medida que el comprador avanza por el embudo. Google Tag Manager, el contenedor por el que la mayoría de las tiendas enrutan estas etiquetas, es también un entorno de ejecución del navegador.
Cada una de estas herramientas necesita una página renderizada y un script ejecutado. Ese es el único punto de fallo. Quita la sesión del navegador y habrás quitado el único sitio donde estas etiquetas iban a ejecutarse alguna vez.
Un checkout de agente quita la sesión del navegador.
Qué informes de WooCommerce fallan con pedidos de agentes
Merece la pena ser preciso, porque “la analítica se rompe” esconde cuántos informes distintos fallan a la vez.
- Embudo y eventos de compra de GA4. Sin
page_view, sinadd_to_cart, sinbegin_checkout, sinpurchase. El pedido nunca entra en GA4, así que los ingresos, la tasa de conversión y el abandono del embudo quedan todos subestimados. - La conversión del píxel de Meta. Ningún evento
Purchasellega a Meta desde el navegador, así que la venta falta en tu informe de anuncios y en la señal de optimización de la que aprende el algoritmo. - Atribución. Los modelos de atribución leen un clic, un referente, parámetros UTM o un client id almacenado de la sesión del navegador. Un pedido de agente no tiene ninguno de ellos, así que no se puede atribuir a un canal, una campaña ni una fuente. Aparece, en el mejor de los casos, como directo o sin asignar, y a menudo ni eso.
- Públicos de remarketing. A un comprador que el píxel nunca vio no se le puede añadir a un público de clientes ni excluir de uno de prospección. Seguirás pagando por anunciarte a personas que ya compraron a través de un agente.
- Retorno de la inversión publicitaria. Los ingresos en WooCommerce dejan de cuadrar con los ingresos de tus paneles de anuncios. El ROAS parece peor que la realidad, y la reacción natural, pero equivocada, es recortar precisamente las campañas que funcionan.
Nada de esto lanza un error. Eso es lo que lo hace peligroso. La tienda sigue funcionando, los pedidos siguen llegando y los paneles se alejan en silencio de la verdad.
Registra la Conversions API de Meta pedidos de agentes
La objeción obvia es que Meta ya resolvió el rastreo del lado del servidor. La Conversions API envía eventos directamente desde tu servidor, sin navegador. Así que los pedidos de agentes deberían estar cubiertos.
No lo están, al menos no con una instalación estándar, y la razón es la deduplicación. La Conversions API está diseñada para trabajar junto al píxel, no en su lugar. Se espera que envíes la misma conversión dos veces, una desde el píxel del navegador y otra desde el servidor, y Meta funde el par en uno mediante un event_id y un event_name compartidos. Ese es todo el propósito: medir de forma fiable sin contar dos veces.
Un pedido de agente no tiene mitad de navegador. No hay evento de píxel con el que emparejar el evento de servidor, y las configuraciones CAPI populares para WooCommerce construyen la clave de deduplicación en el momento en que se renderiza la página de agradecimiento. Para un pedido de agente esa página nunca se renderiza, así que la clave nunca se produce, y el evento de servidor o no se envía o se envía sin la información de identidad que Meta espera. El mismo modelo de deduplicación que te protege de contar dos veces los pedidos navegador-más-servidor es el que descarta en silencio un pedido que solo existió en el servidor.
El rastreo del lado del servidor es la dirección correcta. Pegarlo a un supuesto de navegador primero no es lo mismo que estar preparado para agentes.
Cómo rastrear compras de WooCommerce del lado del servidor
La solución duradera es dejar de tratar el renderizado de la página de agradecimiento como el momento de la verdad y empezar a tratar el propio pedido como el momento de la verdad. El pedido es lo único que existe de forma fiable sin importar cómo se haya realizado la venta.
En concreto:
- Dispara la compra del lado del servidor desde un hook de pedido. WooCommerce lanza
woocommerce_order_status_completedy hooks de pago relacionados en el servidor para todos los pedidos, de navegador o de agente. Envía tu compra de GA4 mediante el Measurement Protocol y tuPurchasede Meta mediante la Conversions API desde ese hook, para que la recogida ya no dependa de que cargue una página. - Deduplica por el id del pedido. Usa el id del pedido de WooCommerce como
event_id. Un pedido de navegador y su gemelo de servidor siguen fundiéndose en uno porque ambos llevan el mismo id de pedido, y un pedido solo de agente pasa limpio porque la clave no necesita contraparte de píxel. - Marca el origen del pedido. Guarda de dónde vino el pedido, el id de la pasarela o un campo meta dedicado, en el momento de su creación. Ahora cada informe puede separar los ingresos de agentes de los de navegador en lugar de fundirlos en una media que oculta el cambio.
- Reconstruye la atribución en torno a una identidad que de verdad tienes. Para los pedidos de agentes, la cuenta del cliente, el correo o los propios identificadores del agente son lo que tienes. Asígnalos deliberadamente a tus canales en vez de esperar que aparezca una cadena UTM.
Esto es ingeniería WooCommerce corriente, hooks, webhooks y eventos servidor a servidor, pero hay que diseñarla para el caso del agente desde el principio, en lugar de parchearla sobre un píxel que da por hecho un navegador.
Cómo registra WooCommerce el origen de un pedido
Antes de crear un campo de origen propio, mira los dos sitios donde WooCommerce ya escribe datos de origen, porque los dos se comportan de forma distinta con los pedidos de agentes.
El primero es la propiedad created_via del pedido. En el código fuente de WooCommerce, el checkout clásico por shortcode la fija en checkout (class-wc-checkout.php), la Store API la fija en store-api (OrderController.php) y el endpoint de pedidos de la REST API v3 la fija en rest-api, salvo que la petición traiga su propio valor de created_via (class-wc-rest-orders-controller.php). Ese último detalle sirve: una integración que crea pedidos de agentes por la REST API puede marcarlos con un valor propio. El límite está en la Store API. El checkout de bloques del navegador también pasa por la Store API, así que store-api por sí solo no separa a un comprador en una pestaña de un agente que llama al mismo endpoint.
El segundo es la atribución de pedidos. La documentación de atribución de pedidos de WooCommerce describe un conjunto de cookies sbjs_ que guardan el referente, los parámetros UTM, el tipo de dispositivo y las páginas vistas de la sesión; se leen solo cuando se realiza el pedido y se guardan como metadatos del pedido con el prefijo _wc_order_attribution. La etiqueta de origen en la lista de pedidos se construye a partir de un tipo de fuente: UTM, orgánico, referencia, directo, aplicación móvil, administración web o punto de venta. Todo lo demás cae en “Desconocido” (OrderAttributionMeta.php). Un agente que nunca carga tu tienda nunca recibe esas cookies, así que sus pedidos aparecen en la columna Origen como Desconocido, junto a cualquier otro pedido cuyos datos se perdieron.
El orden práctico es, por tanto: lee primero created_via, añade tu propia marca solo donde no pueda separar agente y navegador, y trata una proporción creciente de orígenes Desconocido como una primera señal de que el tráfico de agentes ha empezado.
Qué pasan ACP y UCP al comercio para la atribución
Que un pedido de agente llegue con alguna atribución depende del protocolo que haya detrás. El propio artículo de WooCommerce menciona el Agentic Commerce Protocol de Stripe y su trabajo con MCP; no menciona UCP ni AP2, así que comprueba qué implementa de verdad tu integración de pago o de agente antes de fiarte de cualquiera de los campos siguientes.
El Agentic Commerce Protocol lo mantienen OpenAI y Stripe, sigue en beta, se publica bajo licencia Apache 2.0 y versiona por fecha. En la especificación de checkout 2026-04-17, el agente trabaja con POST /checkout_sessions y después con /complete o /cancel sobre esa sesión. Tanto la llamada de creación como la de cierre aceptan un objeto opcional affiliate_attribution: un provider obligatorio, más un token o un publisher_id, ids opcionales de campaña, creatividad y subseguimiento, y un touchpoint con valor first o last. La especificación indica que es de solo escritura: se guarda junto al pedido resultante, pero no se devuelve en la respuesta. El pedido que se devuelve al cerrar lleva su propio id, el checkout_session_id, una permalink_url y un estado, y el comercio envía los eventos posteriores del pedido a la plataforma del agente, firmados con un HMAC en la cabecera Merchant-Signature. El checkout_session_id es la clave que merece guardarse en el pedido de WooCommerce: une el pedido con la conversación del agente que lo generó.
Actualización, . La sesión de checkout descrita arriba es ahora un camino solo para socios aprobados. El 24 de marzo de 2026, OpenAI limitó Instant Checkout en ChatGPT a socios aprobados, dejó que los comercios usen su propio proceso de pago y dijo que se centra en que los compradores encuentren productos, con ACP como vía para compartir datos de productos y promociones (OpenAI). En la mayoría de tiendas WooCommerce, una compra que empieza en ChatGPT termina, por tanto, como una visita a tu propio proceso de pago en el navegador. Esa visita carga la tienda, así que las cookies sbjs_, la columna Origen y tus etiquetas de GA4 y Meta la ven como cualquier otra sesión: la atribución ocurre en tu web, no en un campo de ACP. Antes de crear una regla para estas visitas, comprueba en los datos de tus pedidos con qué referente o parámetros UTM llegan de verdad.
El Universal Commerce Protocol tiene un campo de atribución genérico. La visión general de la especificación define un campo attribution que las plataformas pueden enviar en peticiones de carrito, checkout y catálogo, con los mismos parámetros de campaña e ids de clic, como gclid o fbclid, que de otro modo llegarían en una URL. UCP no impone un modelo de atribución, el campo es opcional y la especificación recuerda que los ids de clic y las claves de sesión pueden ser datos personales, así que tus reglas de consentimiento y conservación se aplican también a él. El pedido puede exponer una copia de solo lectura de la atribución del checkout, y los eventos del ciclo de vida del pedido van a la plataforma como webhooks con cabeceras Standard Webhooks.
AP2, anunciado el 16 de septiembre de 2025, es una capa de confianza para pagos, no una fuente de analítica. El Checkout Mandate y el Payment Mandate firmados prueban lo que autorizó el usuario. Te dicen que el pedido lo hizo un agente, no qué campaña llevó hasta él.
Límites del Measurement Protocol y de la Conversions API con pedidos de agentes
Llevar la recogida al servidor resuelve los eventos que faltan, pero las dos APIs tienen reglas con las que choca un pedido sin página.
El Measurement Protocol de GA4 espera, en flujos web, un client_id que coincida con el ID que la etiqueta de Google generó en el navegador del visitante. Un pedido de agente no tiene ese ID, así que tienes que crear uno, y conviene guardarlo en el pedido para que los reembolsos y los eventos posteriores lo reutilicen. Los eventos se pueden fechar hasta 72 horas hacia atrás, una petición lleva como máximo 25 eventos y el api_secret debe quedarse en el servidor. Google describe el protocolo como pensado para entornos del lado del servidor, con eventos que se unen a lo que recoge gtag.js, de modo que un pedido de agente enviado con un client id recién creado cuenta como un usuario nuevo, no como el final de una sesión de navegador anterior.
Los parámetros de eventos de servidor de Meta marcan un reloj más estricto: el event_time puede tener como mucho 7 días, y un solo evento más antiguo hace que Meta rechace la petición entera. Cada evento necesita un action_source, uno de email, website, app, phone_call, chat, physical_store, system_generated, business_messaging u other. Si envías website, el event_source_url es obligatorio, y un pedido de agente no tiene URL de página que poner ahí. La lista de Meta no tiene un valor para agentes de IA, así que elige uno a conciencia, deja anotado por qué y mantenlo, porque cambiar de valor más adelante complica comparar el antes y el después. La misma página confirma que un número de pedido es un event_id válido.
Esas ventanas son también tu margen de reintentos. Si falla el hook que envía el evento, un reintento en cola tiene 72 horas en GA4 y 7 días en Meta antes de que el evento se pierda.
Pedidos de agentes de IA en el SII de la AEAT
En España, esta brecha tiene una segunda capa. Un pedido de agente sigue teniendo que facturarse y, según el régimen, reportarse por el SII (Suministro Inmediato de Información), así que para la contabilidad el pedido existe perfectamente aunque GA4 nunca lo haya visto. Suele ser el primer sitio donde el dueño de la tienda nota el problema: el número de facturas en el registro que llega a la AEAT no cuadra con el número de transacciones en el panel de marketing. Conciliar las ventas del registro fiscal frente a las cifras del panel de anuncios es una forma práctica de siquiera detectar cuántos pedidos llegaron a través de agentes, antes de corregir la recogida del lado del servidor.
Debe una tienda WooCommerce dejar entrar a los agentes de IA
Antes de que un pedido de agente pueda desaparecer de GA4, el agente tiene que llegar a pasar por el checkout. The Verge publicó el 17 de octubre de 2026 que cada vez más servicios cierran la puerta a los agentes: Yelp solo admite agentes que pagan por su programa de licencias de datos, Delta Air Lines les impide comprar billetes, y JPMorgan Chase y Charles Schwab les bloquean el acceso a las cuentas por motivos de seguridad. Amazon bloqueó el agente de compras de Perplexity y demandó a la empresa; después de que un tribunal de apelación anulara la prohibición en agosto, Amazon presentó una demanda modificada. Al otro lado, Meta se ha asociado con Walmart, Gap, Sephora y Best Buy para que su asistente Muse pueda comprar allí, y Shopify ha abierto sus tiendas a los agentes.
Para una tienda WooCommerce, lo más útil viene después: los agentes también chocan con sistemas antibots que nunca se configuraron contra ellos. Hubo usuarios que informaron de problemas en el checkout de Walmart pese a la alianza con Meta. En WordPress, el mismo efecto lo producen las reglas del WAF, el Bot Fight Mode de Cloudflare, Turnstile o un CAPTCHA en el formulario de pedido y los límites de peticiones de un plugin de seguridad. Ese pedido no lo verás ni en GA4 ni en WooCommerce, porque nunca llegó a crearse.
La decisión es del dueño de la tienda, pero conviene tomarla a conciencia:
- Revisa los eventos del WAF y los registros del servidor para
/checkout/y para la Store API (/wp-json/wc/store/v1/checkout) y cuenta cuántas peticiones terminan en 403 o en un desafío. - Si quieres recibir pedidos de agentes, déjalos entrar mediante una integración que elijas tú (ACP o UCP), no desactivando la protección del formulario para todos.
- Si no quieres, bloquéalos de forma explícita con una regla para rutas o user agents concretos, en lugar de dejar al azar qué bot supera la capa antibots.
Las reglas de Walmart para agentes de compra, actualización del 23 de octubre de 2026: el 21 de octubre Walmart anunció tres piezas. Los Agent Profiles, que llegarán en el próximo mes, dan a cada agente que autoriza el cliente un perfil propio dentro de su cuenta, de modo que las compras del agente aparecen por separado. El cliente decide si aprueba cada pedido o si fija un límite de gasto. Walmart Agent Gateway permite a los agentes comprar mediante MCP en lugar de ir pulsando por páginas hechas para personas, y empieza como beta para empresas y desarrolladores. Las condiciones para agentes de IA establecen que el cliente aprueba por defecto las compras del agente, que los agentes nunca reciben los datos de la tarjeta ni pueden cambiar los métodos de pago, que el proceso de devoluciones de Walmart se aplica aunque el agente no actúe como se esperaba, y que se bloqueará a los agentes que incumplan las condiciones. Para el cliente, los Agent Profiles cierran el mismo hueco que este artículo trata desde el lado del comercio: distinguir los pedidos de agentes de los pedidos de personas. Cualquier tienda, en WooCommerce, Shopify o una plataforma propia, puede aplicar la idea ya: registrar al agente como origen propio del pedido, mantener una aprobación humana antes del pago y publicar qué pueden y qué no pueden hacer los agentes en tu web. Nuestro servicio de preparación para el comercio con IA cubre esa configuración.
Cuándo arreglar el rastreo de pedidos de agentes en WooCommerce
Por ahora, los pedidos de agentes son un hilo de agua para la mayoría de las tiendas, y precisamente por eso este es el momento adecuado para corregirlo. Las tiendas que instrumentan la recogida del lado del servidor mientras el volumen es pequeño tendrán cifras limpias y comparables cuando deje de serlo. Las tiendas que esperen pasarán 2027 intentando explicar una brecha cada vez mayor entre sus ingresos de WooCommerce y sus paneles de anuncios, y reconstruir la atribución bajo presión es mucho más caro que construirla una vez, con calma, ahora.
Si vendes a través de WooCommerce y empiezas a ver pedidos que tus píxeles no pueden explicar, esa es la señal. Es un problema de fontanería con una solución conocida, y es el tipo de trabajo que se paga solo la primera vez que una campaña que estabas a punto de recortar resulta haber sido rentable todo el tiempo.
Hacemos este trabajo como parte de nuestros proyectos de desarrollo WooCommerce, y va de la mano de la pregunta más amplia de si tu tienda es siquiera descubrible y comprable por agentes, que abordamos en nuestra guía de preparación para el comercio con IA y en la explicación del Universal Commerce Protocol. Si quieres entender cómo llegan los agentes a tu catálogo en primer lugar, nuestro servidor MCP de WooCommerce de solo lectura muestra la mecánica, y para los cimientos del lado del cliente que siguen importando, nuestra guía Google Analytics 4 para WordPress cubre el lado del navegador que los pedidos de agentes esquivan.
Última actualización: 20 de octubre de 2026.
