Analítica de tráfico con agentes: guía 2026

La analítica de tráfico impulsada por agentes es la práctica de capturar, clasificar y atribuir solicitudes realizadas por actores no humanos, y luego medir las tareas que esos agentes completan en nombre de personas humanas. Sustituye la sesión como unidad de medida por un modelo más simple: actor, tarea, resultado.

Si tus paneles todavía muestran una línea plana para el «tráfico de bots» junto a una porción creciente de visitas de agentes de IA sin datos de conversión asociados, no estás midiendo lo que realmente ocurre en tu sitio. Los agentes de compra de ChatGPT, Gemini y Perplexity están leyendo páginas de producto, comparando especificaciones y entregando recomendaciones a compradores que nunca llegan a desplazarse por la página por sí mismos. Es probable que tu pila de analítica no tenga ni idea de que esto está ocurriendo.

Tres acciones corrigen rápidamente los puntos ciegos más importantes:

• Activa el reenvío de registros del CDN o del edge para capturar solicitudes que nunca cargan un navegador ni activan una etiqueta de JavaScript.
• Añade una propiedad actor en el punto de ingesta, etiquetada como humano, agente o rastreador, antes de que los datos lleguen a un panel.
• Dirige esos registros a un almacén de datos en lugar de a una herramienta del lado del cliente, para poder vincular eventos de agentes con resultados a lo largo del tiempo.

Las lecturas de agentes suelen producirse mucho antes de una compra, preinformando a un comprador que llega con la decisión ya tomada. Son ingresos que tu configuración heredada de analítica está atribuyendo actualmente a «directo» o que está perdiendo por completo.

Conclusiones clave

La analítica de tráfico impulsada por agentes funciona cuando los equipos sustituyen las métricas de sesión por un modelo de actor, tarea y resultado respaldado por captura del lado del servidor y registros vinculados a la identidad.

Qué es el tráfico impulsado por agentes y por qué fallan las métricas de sesión

Tres tipos de actores llegan hoy a tus servidores, y no se comportan en absoluto igual. Un humano navega de forma interactiva, con pausas, desplazamientos y movimiento del ratón. Un crawler indexa contenido para un corpus, normalmente sin ningún interés en una tarea específica. Un agente actúa en nombre de una persona, obtiene una página, extrae datos y, a menudo, completa una tarea como una comparación o un paso de compra, sin llegar a renderizar visualmente la página.

Las métricas web estándar asumen que hay un humano al otro lado. Esa suposición deja de funcionar de inmediato con los agentes.

1. La tasa de rebote no significa nada cuando un agente obtiene una página, extrae el precio y la tabla de especificaciones, y se va. Eso es una tarea completada, no una visita abandonada.
2. El tiempo en página no puede aplicarse a una solicitud que termina en milisegundos porque no hay renderizado, ni lectura, ni desplazamiento.
3. La profundidad de desplazamiento requiere una ventana gráfica. Los agentes headless que realizan llamadas HTTP en bruto nunca generan una.

La solución es un modelo mental completamente distinto: actor, tarea, resultado. Clasificas quién hizo la solicitud, defines qué intentaba hacer y registras si tuvo éxito. Ese marco funciona tanto si el actor es un comprador, un crawler o un agente autónomo que compara cinco competidores antes de recomendar uno a un comprador.

Cómo funcionan realmente la detección y la captura de agentes

La mayor parte de la actividad de los agentes es invisible para las herramientas en las que los equipos de marketing ya confían. Esa es la parte incómoda. Google Analytics, las etiquetas de Adobe Analytics y la mayoría de las configuraciones de gestores de etiquetas dependen de la ejecución de JavaScript en un navegador. El tráfico de agentes omite cada vez más ese paso por completo.

La captura del lado del servidor y en el edge es lo que realmente detecta este tráfico. La telemetría de los proveedores muestra que aproximadamente el 59% del tráfico de agentes de ChatGPT llega a través de clientes HTTP sin procesar que nunca ejecutan un script, lo que significa que las herramientas de analítica del lado del cliente se pierden más de la mitad de la actividad por diseño, no por accidente. Si tu única instrumentación vive en un gestor de etiquetas, estás midiendo una porción cada vez menor de lo que realmente está ocurriendo.

Los registros de CDN y edge resuelven esto porque registran cada solicitud que llega a tu infraestructura, independientemente de si un navegador llega a pintar un píxel. Esa es la capa en la que realmente comienza la analítica del tráfico impulsado por agentes.

Un puñado de señales separan de forma fiable a los agentes de los humanos y de los bots genéricos una vez que observas los registros sin procesar:

• Cadenas de user-agent declaradas. Muchos agentes se identifican honestamente, al menos por ahora, con cadenas que hacen referencia al modelo o a la plataforma detrás de la solicitud.
• Ratios de activos por solicitud. Un humano al cargar una página descarga decenas de imágenes, fuentes y scripts. Un agente que extrae datos estructurados a menudo solicita solo el HTML o una carga útil JSON.
• Ausencia de beacon. Que no se dispare ningún píxel de analítica en una visualización de página que claramente ocurrió a nivel del servidor es en sí mismo una señal.
• Patrones de cabeceras y temporización. Los agentes tienden a solicitar páginas a velocidad de máquina, con órdenes de cabeceras y entropía de temporización que difieren del comportamiento típico de un navegador.
• llms.txt y activos estructurados. Un número creciente de sitios publica ahora un archivo llms.txt junto con esquemas OpenAPI, ofreciendo a los agentes (y a tus registros) una interfaz documentada y declarada con la que contrastar las solicitudes.

Validar los rangos de IP del modelo declarados o cotejar las cadenas de solicitud con la documentación publicada por el proveedor añade otra capa de confianza, aunque por sí sola nunca es totalmente infalible.

Consejo profesional: No te fíes solo de las cadenas de user-agent. Combínalas con una puntuación de ratio de activos para que una cadena suplantada siga quedando señalada si el patrón de solicitud no coincide con una sesión real de navegador.

Métricas clave que realmente muestran el impacto de los agentes

Informar sobre el tráfico de agentes con páginas vistas y sesiones da a las partes interesadas cifras que parecen impresionantes o alarmantes por razones equivocadas. Las métricas que importan rastrean solicitudes, tareas y resultados de negocio, no visitas.

La finalización de tareas necesita una definición real antes de que puedas medirla. Una tarea de recuperación tiene éxito cuando un agente extrae los datos que ha venido a buscar, como el precio o la disponibilidad. Una tarea de flujo de formulario tiene éxito cuando un proceso de varios pasos, como añadir al carrito, se completa sin errores. Una tarea de integración tiene éxito cuando una llamada de estilo API devuelve una respuesta válida y utilizable. Define esto de antemano o la métrica será ruido sin sentido.

Las conversiones asistidas por agentes merecen su propia línea en cada informe. Las guías que hacen un seguimiento correcto de esto muestran que el tráfico referido por agentes puede convertir a múltiplos del tráfico orgánico genérico una vez que se aísla y se mide correctamente, en lugar de integrarse en un cajón de sastre indiferenciado de «otros». Ese es el número que capta la atención de un CFO, no el volumen bruto de solicitudes.

• Desglosa la cuota de agentes por modelo individual, no solo en una categoría agregada de «bot».
• Informa de la finalización de tareas y la tasa de transferencia juntas. Una sin la otra oculta si el tráfico de agentes está haciendo algo útil.
• Haz un seguimiento de las tasas de bloqueo y error por separado de las tasas de error humanas. Un pico aquí suele indicar una regla de firewall mal configurada, no tráfico malicioso.

Construyendo el pipeline: esquema, etiquetado y almacenamiento

Lanzar analítica de tráfico impulsada por agentes es principalmente un problema de infraestructura antes de ser un problema de análisis. Este es el orden que funciona en la práctica.

1. Activa primero el reenvío de logs del CDN. Captura campos que incluyan marca temporal, cadena completa de user-agent, ruta de la solicitud, código de respuesta, tamaño en bytes y cualquier dato de huella TLS que exponga tu CDN.
2. Añade propiedades actor y actor_name en la ingesta. Cada evento se etiqueta como humano, agente o rastreador, además de con un nombre específico cuando sea identificable (una cadena de modelo o plataforma), antes de llegar a cualquier tabla.
3. Aplica lógica de clasificación por capas. Empieza con el user-agent declarado, compáralo con señales de comportamiento como la proporción de recursos y el tiempo, y después confírmalo con tokens de autenticación o claves API donde existan. Ninguna señal por sí sola debería cargar con toda la decisión.
4. Vincula los eventos de agentes con identidades humanas siempre que sea posible. Los tokens de autenticación, las cookies de sesión y los ID de correlación te permiten conectar la tarea de recuperación de un agente con la persona que lo desplegó, cerrando la brecha entre «un agente visitó» y «el agente de este cliente visitó».
5. Dirige todo a un almacén de datos, no solo a una herramienta de paneles. El pipeline de analítica de agentes de BigQuery transmite eventos de interacción sin procesar mediante la Storage Write API y admite la reconstrucción de trazas a posteriori, lo que importa cuando necesitas reconstruir lo que un agente hizo realmente tres semanas después.
6. Organiza tu almacenamiento por niveles. Conserva logs sin procesar y granulares durante una ventana de auditoría definida, y después muestrea o agrega los datos más antiguos. Mantener para siempre la fidelidad completa es un problema de costes esperando a suceder, y además la mayoría de las auditorías solo necesitan una ventana reciente.

Consejo profesional: Define tu ventana de retención de auditoría en función de tu ciclo de disputa o cumplimiento más largo y realista, no de 30 o 90 días arbitrarios. Si un contracargo o una cuestión regulatoria puede surgir seis meses después, tus trazas deben sobrevivir ese tiempo.

Cerrar la brecha de atribución

Saber que un agente visitó tu sitio es una cosa. Demostrar qué persona u organización desplegó ese agente es un problema mucho más difícil, y es el que quita el sueño a los equipos de cumplimiento.

La brecha de atribución existe porque la mayoría de las empresas pueden registrar que un agente actuó, pero no demostrar qué persona autorizó la acción. Esa brecha se convierte en una exposición legal y regulatoria real en el momento en que un agente hace algo que una empresa después necesita rechazar o defender.

Esa es la conclusión principal del análisis de Okta sobre el riesgo de cumplimiento de la IA, y se aplica directamente a cualquier equipo que esté construyendo analítica de tráfico impulsada por agentes con fines de auditoría, no solo a los equipos de seguridad.

Una mitigación práctica que está ganando tracción es el protocolo canario: un enfoque mediado por el proveedor en el que las interacciones de los agentes llevan un marcador rastreable hasta la cuenta de origen. La investigación que evalúa este enfoque en agentes web, de comunicación y cibernéticos concluyó que vincula de forma fiable el comportamiento observado con una cuenta de origen en entornos no adversariales, aunque es realista esperar lagunas cuando un actor intenta activamente eludir la detección.

Algunos hábitos operativos cierran la mayor parte de la distancia restante:

• Trata los logs de agentes como registros inmutables, no como algo que sobrescribes o compactas demasiado pronto.
• Vincula cada evento de agente con una identidad cuando un token, una cookie o una clave API lo hagan posible.
• Establece un punto de coordinación permanente entre seguridad, legal y tus proveedores de plataforma antes de que un incidente fuerce la conversación.

Herramientas y patrones de panel que funcionan

No necesitas crear cada parte de esto desde cero. Unas pocas herramientas concretas ya cubren la mayor parte del flujo.

• BigQuery Agent Analytics gestiona el flujo de captura a análisis: transmisión de eventos sin procesar, reconstrucción de trazas y ejecución de evaluaciones programáticas del comportamiento de los agentes a escala, lo cual importa una vez que superas unos pocos miles de solicitudes de agentes al día.
• El panel Agentic Traffic de Adobe ofrece una vista preconfigurada una vez que el reenvío de registros del CDN está en marcha, con filtros para la distribución del tráfico, líneas de tendencia y los mayores y menores cambios entre mercados, categorías y agentes individuales.
• Las herramientas basadas en etiquetas como GA4 siguen teniendo su lugar para medir el comportamiento humano, pero subestiman sistemáticamente la actividad de los agentes porque gran parte de ella nunca activa una etiqueta del lado del cliente. Un patrón útil es superponer GA4 junto con la captura del lado del servidor en lugar de sustituirlo por completo, para mantener intactos los informes de comportamiento humano mientras añades encima la capa de agentes.
• Los paneles de los proveedores son realmente útiles para supervisar tendencias, pero no sustituyen un modelo de trazas liderado por almacén de datos cuando necesitas evaluaciones reproducibles para una auditoría o una investigación de causa raíz.

Cómo el tráfico de agentes cambia el rendimiento y la planificación de recursos

Las solicitudes de agentes impactan en tu infraestructura de forma distinta al tráfico humano, y eso tiene implicaciones reales de capacidad que la mayoría de los equipos aún no han previsto.

Un visitante humano provoca una ráfaga de solicitudes paralelas: HTML, luego imágenes, fuentes, scripts y balizas analíticas, repartidas a lo largo de varios segundos. Un agente que extrae datos estructurados a menudo realiza una única solicitud eficiente para obtener exactamente lo que necesita y luego sigue adelante. Sobre el papel eso parece más ligero, pero a escala no lo es. Los agentes pueden acceder al mismo conjunto de páginas de alto valor, como las de precios o las de detalle de producto, con un volumen y una frecuencia que ningún humano individual tendría jamás, ya que no hay tiempo de lectura entre solicitudes.

Ese patrón aparece como una carga inesperada en endpoints específicos en lugar de una distribución uniforme por todo el sitio. Las decisiones de limitación de tasa y almacenamiento en caché que se ajustaron a patrones de navegación humana pueden fallar frente a los agentes, ya sea bloqueando tráfico legítimo de agentes que habría generado una venta o permitiendo que un agente con mal comportamiento machaque un endpoint que tu equipo suponía de bajo tráfico.

La respuesta práctica es tratar la carga de los agentes como su propia categoría de planificación de capacidad. Supervisa las tasas de solicitud por tipo de actor, no solo el tráfico agregado, y establece reglas de caché y limitación de tasa teniendo específicamente en cuenta los patrones de comportamiento de los agentes. Una página de producto que los agentes de compra consultan decenas de veces por hora necesita una estrategia de caché distinta a la de una que los humanos consultan unas pocas veces al día, incluso si el recuento total de solicitudes parece similar en un panel combinado.

La línea legal y ética en la monitorización del tráfico de agentes

Registrar la actividad de los agentes plantea preguntas que todavía no tienen respuestas completamente asentadas, y fingir lo contrario es un error.

Capturar datos detallados de las solicitudes, incluidos encabezados, tiempos y huellas de comportamiento, significa que en algunos casos también estás capturando datos que pueden vincularse a personas concretas, especialmente cuando un agente actúa en nombre de una cuenta de cliente identificada. Eso sitúa los registros de tráfico de agentes dentro de los mismos marcos de privacidad que ya regulan cualquier otra recopilación de datos que realice tu organización, ya sea una ley regional de privacidad o una política interna de gobernanza de datos.

Las cuestiones éticas van de la mano de las legales. Bloquear por completo a los agentes puede proteger los recursos del servidor, pero también puede cerrar un canal creciente de compradores que ahora hacen sus comparaciones de compra a través de un agente de IA en lugar de una pestaña del navegador. Un acceso demasiado permisivo, por otro lado, abre la puerta a abusos de scraping disfrazados de tráfico de agentes legítimo.

Un punto intermedio viable trata el acceso de los agentes como tratarías cualquier otra integración automatizada: documentada, limitada por tasa y monitorizada, con condiciones claras sobre lo que está permitido. Publicar un archivo llms.txt es una parte de eso, ya que ofrece a los agentes bien comportados una interfaz documentada en lugar de obligarlos a adivinar la estructura de tu sitio.

La política de retención importa tanto como la política de recopilación. Conserva registros detallados de agentes solo durante el tiempo que realmente exija tu ventana de auditoría o disputa, y aplica a esos registros los mismos controles de acceso que aplicarías a cualquier otro conjunto de datos que contenga información conductual o vinculada a la identidad.

Integración de la analítica de agentes con la seguridad y la detección de fraude

La analítica del tráfico de agentes y la detección de fraude resuelven problemas que se solapan, y tratarlas como sistemas separados crea puntos ciegos en ambos lados.

Un scraper malicioso y un agente de compras legítimo pueden parecer casi idénticos en la capa de red: solicitudes automatizadas, sin ejecución de JavaScript, una cadena de user-agent declarada o falsificada. El enfoque de clasificación por capas que identifica agentes legítimos, comprobando conjuntamente la identidad declarada, las señales de comportamiento y la autenticación, es el mismo enfoque que detecta abusos. Construir esto como un solo sistema en lugar de dos significa que tu equipo de fraude no está reinventando la detección de señales que tu equipo de analítica ya ha desarrollado.

La integración práctica empieza con una taxonomía compartida de actores. Si tu canalización de analítica etiqueta una solicitud como agente, crawler o humano, tus herramientas de seguridad deberían leer y actuar sobre esa misma etiqueta en lugar de ejecutar su propia capa separada de detección de bots con definiciones distintas. Las taxonomías divergentes entre equipos son la forma en que un agente de compras con IA legítimo acaba bloqueado por una regla de seguridad cuya existencia nadie del lado de analítica conocía.

La otra mitad son las alertas compartidas. Un pico repentino de solicitudes de agentes a un endpoint de pago puede ser un conocido agente de compras probando cambios de precio en todo tu catálogo, o puede ser un intento de credential stuffing disfrazado de tráfico de agentes. Encauzar las anomalías relacionadas con agentes a través del mismo flujo de incidentes que seguridad ya utiliza para el fraude, en lugar de mediante una alerta separada solo de analítica que nadie del equipo de seguridad supervisa, es lo que realmente permite detectar a tiempo la diferencia para que importe.

Cómo cambian las prioridades de analítica de agentes según el sector

No todos los sectores necesitan el mismo énfasis dentro de una configuración de analítica de tráfico impulsada por agentes, y tratarla como una solución única para todos hace perder tiempo de ingeniería en las señales equivocadas.

Los sitios de ecommerce y retail se preocupan sobre todo por la finalización de tareas en las páginas de producto y precios, además de la tasa de transferencia de agente a humano, ya que esa es la métrica que vincula directamente la actividad del agente con los ingresos. El mayor punto ciego de un retailer suelen ser las páginas de precios machacadas por agentes de comparación sin que exista un seguimiento de conversiones correspondiente.

Los sitios de medios y publicaciones dan más peso a la distinción entre rastreador y agente, ya que la cuestión de negocio suele girar en torno a la concesión de licencias y la reutilización de contenido más que a la conversión. Distinguir un rastreador que construye un corpus de un agente que recupera un solo artículo para la pregunta específica de un usuario cambia cómo debe valorarse y gobernarse ese tráfico.

El software B2B y las plataformas SaaS tienden a priorizar la categoría de tareas de integración, ya que los agentes que interactúan con estos sitios con frecuencia realizan llamadas de estilo API en nombre de otro sistema en lugar de un único comprador humano. Las tasas de error y bloqueo por actor importan más aquí que la tasa de transferencia, porque el «humano» al otro lado puede estar varios pasos alejado de la propia solicitud.

Los sitios de servicios financieros son los más cercanos a las preocupaciones de atribución y gobernanza descritas antes, ya que la exposición regulatoria en torno a acciones no autorizadas de agentes es máxima en esa categoría. El enfoque de atribución basado en canarios y el registro inmutable importan más aquí que en casi cualquier otro vertical.

Qué deberían cambiar realmente los equipos de analítica

Mantén tus informes predeterminados orientados a humanos exactamente como están. No rehagas un panel en el que un responsable de marketing ya confía solo para calzar los datos de agentes dentro de él. En su lugar, crea una vista paralela, una que pueda verse diferente porque está midiendo algo estructuralmente distinto.

El mayor cambio organizativo es dónde vive la telemetría de agentes en el día a día. Debe estar en las conversaciones de respuesta ante incidentes y de compras, no enterrada en una presentación trimestral de analítica que nadie lee hasta que algo falla. Y si vas a dedicar tiempo de ingeniería a optimizar primero algo para la legibilidad de los agentes, dedícalo a las páginas de precios y de producto. Ahí es donde los agentes realmente toman decisiones en nombre de un comprador, y es donde el retorno de ese trabajo aparece más rápido.

— Xhurian

Convertir la visibilidad de los agentes en fichas optimizadas

Medir el tráfico de agentes te dice que los agentes están leyendo tus páginas de producto. No te dice por qué un agente recomendó a un competidor en lugar de a ti, y esa brecha es exactamente lo que cierra Ecentic.

Ecentic se conecta directamente a tu tienda de Shopify o WooCommerce y simula cómo ChatGPT, Gemini, Claude y Perplexity evalúan realmente tus fichas frente a las de la competencia; después, te devuelve diagnósticos en lenguaje claro sobre qué es exactamente lo que te está costando una recomendación. Los clientes que utilizan las herramientas de optimización de Ecentic han informado de aumentos significativos tanto en visitas impulsadas por IA como en ventas tras implementar sus reescrituras de fichas sugeridas. En lugar de limitarte a contar solicitudes de agentes, obtienes un perfil UCP validado para la legibilidad de los agentes y un ciclo de reescaneo que hace seguimiento de tu tasa de selección a lo largo del tiempo a medida que cambian los modelos.

Si ya estás reenviando registros de CDN y etiquetando actores, la pieza que falta es saber qué hacer con esa visibilidad. Ejecuta un escaneo introductorio gratuito en tu tienda y comprueba exactamente en qué punto están tus fichas con los agentes que ya las están leyendo.

Fuentes

• Atribución de agentes basada en canary (arXiv)
• Por qué el cumplimiento de la IA es un problema de identidad de la alta dirección (blog de Okta)
• Documentación de analítica de agentes de BigQuery
• Tráfico de agentes | Visibilidad de marca de Adobe

Preguntas frecuentes

¿Qué es la analítica de tráfico impulsado por agentes?

Es la práctica de capturar, clasificar y atribuir las solicitudes realizadas por agentes de IA que actúan en nombre de humanos, y después medir las tareas que completan en lugar de basarse en métricas de sesión.

¿Por qué las métricas de sesión fallan para el tráfico de agentes?

Métricas como la tasa de rebote y el tiempo en página asumen que un humano está renderizando y leyendo una página, pero los agentes a menudo realizan una única solicitud eficiente y se van, lo que hace que esos números carezcan de sentido.

¿Cómo se detecta el tráfico de agentes de IA en un sitio web?

La captura de registros del lado del servidor y de CDN, combinada con el análisis del user-agent, las proporciones entre recursos y solicitudes, y la validación de llms.txt, revela de forma fiable la actividad de los agentes que las herramientas del lado del cliente pasan por alto.

¿Qué es la brecha de atribución en la analítica de agentes?

Es la dificultad de demostrar qué humano u organización autorizó la acción de un agente específico, lo que crea riesgo legal y de cumplimiento que los protocolos basados en canary y el registro inmutable ayudan a reducir.

¿Puede ecentic ayudar con la optimización del tráfico de agentes?

Sí. ecentic simula cómo los agentes de compra con IA evalúan los listados de productos en tiendas Shopify y WooCommerce y proporciona recomendaciones específicas para mejorar la visibilidad y las conversiones impulsadas por agentes.