Hay un momento en el que identificar tráfico no deseado deja de ser un ejercicio de mirar el informe de adquisición y excluir la URL del bot conocido. Ese momento llega cuando el tráfico raro no viene de un país sospechoso ni de un referrer con spam evidente, sino de usuarios que se comportan como humanos pero no lo son, o de humanos que no deberían estar ahí. El filtro obvio —excluir bots por user-agent, bloquear IPs, segmentar por geografía— deja de servir justo ahí.
Lo he visto en un proyecto de una tienda de recambios industriales. El equipo había excluido los bots conocidos en GA4, tenía un segmento limpio de países y aun así las conversiones no cuadraban con los pedidos reales del ERP. La causa no era un bot clásico: era una herramienta de monitorización de precios que navegaba con un navegador headless, residencial y comportamiento casi indistinguible. El filtro obvio no lo detectaba porque no había nada obvio que detectar.
El problema del filtro evidente en la detección de visitas no humanas
La mayoría de recetas para identificar tráfico no deseado asumen que el intruso se delata: user-agent vacío, IP de datacenter, referrer con dominio raro, ratio de rebote del 100%. Ese perfil existe, sí, pero convive con otro mucho más incómodo: tráfico que genera eventos, hace scroll, pulsa enlaces internos y hasta rellena formularios sin enviarlos. Cuando el comportamiento es plausible, cualquier regla basada en umbrales simples produce falsos positivos o falsos negativos.
La primera consecuencia práctica es que las exclusiones automáticas dejan de ser fiables. Un segmento que excluye «bots conocidos» y «países de bajo valor» puede estar borrando visitas legítimas de una filial o de un proveedor que revisa el catálogo, mientras deja pasar el tráfico realmente indeseado. El filtro obvio no distingue entre «no me interesa» y «no es humano».
Señales que sí funcionan cuando el user-agent miente
Para identificar tráfico no deseado en ese escenario límite hay que bajar un nivel: dejar de confiar en la etiqueta y mirar la huella de la sesión. Estas señales no son infalibles, pero cambian el eje del análisis.
Cadencia temporal. Un usuario real tiene pausas irregulares. Un script que simula lectura suele repetir intervalos con una regularidad que se ve al graficar la duración entre eventos. No hace falta un modelo complejo: una consulta a los eventos con marca de tiempo y una desviación estándar baja ya delata patrones.
Profundidad de scroll anómala. Visitas que llegan al 100% de scroll en páginas muy largas en menos de lo humanamente posible, o que hacen scroll exactamente hasta el mismo píxel en cada visita, son sospechosas. El filtro por rebote no las detecta porque técnicamente no rebotan.
Combinación de dimensiones imposibles. Resolución de pantalla de servidor con un sistema operativo de escritorio moderno, idioma del navegador incoherente con la geolocalización de la IP, o un viewport que no cambia entre móvil y escritorio en la misma sesión. Ninguna señal aislada basta; la combinación sí.
Interacción con elementos invisibles. Clics en píxeles donde no hay ningún elemento clicable, o eventos en zonas que solo existen tras una animación. Un usuario real no pulsa el vacío; un bot que hace clic por coordenadas sí.
Un caso concreto: el scraper que parecía un cliente fiel
En otra cuenta, un comparador externo rastreaba precios cada pocas horas. Entraba desde IPs residenciales rotativas, ejecutaba JavaScript y hacía scroll. Las herramientas de analítica lo contaban como usuario recurrente con alta fidelidad. El equipo lo tenía marcado como «cliente valioso» en los informes de audiencia. Al cruzar los eventos de clic en «añadir al carrito» con los pedidos reales, la incoherencia saltó: sesiones con decenas de clics en carrito y cero pedidos, siempre desde el mismo rango de dispositivos.
La lección: para identificar tráfico no deseado de este tipo, el dato decisivo no fue el user-agent ni la IP, sino el cruce entre comportamiento declarado y resultado de negocio. Cuando la tasa de conversión por segmento es exactamente cero con un volumen alto, el segmento miente.
Lo que este enfoque no resuelve
Conviene ser honesto sobre los límites. Este método no funciona bien en sitios con muy poco tráfico: sin volumen suficiente, las señales estadísticas no se separan del ruido. Tampoco sirve para detectar tráfico no deseado de origen interno, como empleados o agencias que visitan el sitio con navegadores reales; ahí el problema no es técnico, es de gobernanza de datos.
Y hay un límite más incómodo: si el actor malicioso usa un navegador real con un humano detrás, ninguna señal técnica lo distingue de un usuario legítimo. La detección se vuelve una cuestión de intención, y la intención no se mide con logs.
Cómo montar un proceso realista de detección
Lo que sí funciona es un proceso por capas. Primero, una capa de exclusión conocida: bots declarados, IPs de datacenter, referrers spam. Segundo, una capa de comportamiento: sesiones con patrones temporales regulares, scroll imposible o clics fuera de elementos. Tercero, una capa de coherencia de negocio: segmentos con conversión cero y volumen alto, o con eventos de embudo que no terminan nunca.
Cada capa genera candidatos, no verdades. La decisión final se toma revisando muestras manualmente. Herramientas como los informes de adquisición de GA4, los logs de servidor y el seguimiento de eventos personalizados son suficientes para empezar; no hace falta una plataforma de detección de fraude para un sitio mediano.
La conclusión que me llevo después de varios proyectos es que identificar tráfico no deseado con precisión es menos un problema de filtros y más un problema de contraste entre fuentes. El filtro obvio te da una primera capa de limpieza, pero la detección fina exige cruzar lo que la analítica dice con lo que el negocio sabe. Cuando esos dos relatos no cuadran, ahí está el tráfico que ningún segmento automático te va a señalar.
Perfiles verificables: Sitio web
Publicado el 31 de October de 2026. Última revisión: 31 de October de 2026.