Analítica de checkout de agentes WooCommerce

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, incluida una ruta nativa del agente hasta el checkout, 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.

#¿Qué le pasa a tu analítica cuando un agente de IA compra?

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é tu rastreo vive en el 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é se rompe, exactamente

Merece la pena ser preciso, porque “la analítica se rompe” esconde cuántos informes distintos fallan a la vez.

1. Embudo y eventos de compra de GA4. Sin page_view, sin add_to_cart, sin begin_checkout, sin purchase. El pedido nunca entra en GA4, así que los ingresos, la tasa de conversión y el abandono del embudo quedan todos subestimados.
2. La conversión del píxel de Meta. Ningún evento Purchase llega 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.
3. 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.
4. 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.
5. 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.

#La Conversions API no es un rescate automático

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.

#La solución: mueve el evento de compra al pedido

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_completed y 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 tu Purchase de 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.

#Contexto español: el agente no te libra del SII ni 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.

#Qué significa esto para tu informe en 2026

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 julio de 2026.