Cómo medir la detección de bots sin bloquear a clientes reales
Un análisis técnico señala que la precisión agregada es una métrica engañosa y detalla qué grupos de tráfico y qué registros necesita un banco de pruebas realista.
La forma más rápida de perder la confianza en un sistema anti-bots no es dejar pasar a un rastreador: es bloquear a un cliente real. Un bot que se cuela cuesta ancho de banda o contenido; una persona bloqueada cuesta una venta y una escalada de soporte. Una entrada publicada en el blog de WebDecoy sostiene que un banco de pruebas de detección no puede quedarse en un único número de precisión, porque esa cifra agregada esconde dónde duele cada error.
El problema de las clases desequilibradas
El tráfico de bots es un problema de clases desequilibradas: la mayor parte de lo que llega a una aplicación es legítimo y los ataques que merece la pena parar son una porción pequeña del total. Con esas proporciones, un porcentaje alto de aciertos puede describir un detector flojo. El ejemplo que da el texto: 100.000 peticiones, de las que 99.000 son legítimas y 1.000 automatizadas. El detector caza 900 ataques y además marca 200 peticiones legítimas. La precisión global sale 99,7%, un titular excelente para un sistema que deja pasar 100 ataques y trata como bot a 200 clientes, con un veredicto equivocado casi una vez de cada seis.
La propuesta es mirar tres métricas a la vez. Precisión, la proporción de detecciones correctas sobre el total de detecciones; exhaustividad, las detecciones correctas sobre los ataques reales; y tasa de falsos positivos, las peticiones humanas marcadas sobre el total de peticiones humanas conocidas. En el ejemplo: 81,8%, 90% y alrededor del 0,2%. Ese último número parece minúsculo hasta que se escala a un millón de peticiones legítimas al día, que son unas 2.000 peticiones de clientes diarias con el tratamiento equivocado.
El texto enlaza con la guía de métricas de clasificación de Google y recuerda que mover un umbral mueve las tres cifras a la vez. De ahí salen tres objetivos operativos distintos: el bloqueo duro favorece la precisión, el desafío busca equilibrio entre las dos primeras y la monitorización prefiere exhaustividad, porque una señal amplia se revisa después antes de actuar sobre ella.
Cómo se construye el banco de pruebas
El conjunto de datos tiene que parecerse a producción. Tres grupos de etiquetas: tráfico humano conocido (sesiones autenticadas, compras completadas que no se revirtieron, casos confirmados por soporte), automatización conocida (Playwright, Puppeteer, Selenium, curl, bots lentos, clientes distribuidos de bajo volumen, navegadores headless con cabeceras realistas) y tráfico genuinamente ambiguo, que se deja marcado como desconocido en lugar de forzarlo a una de las dos categorías. Los rastreadores de buscadores, los monitores de disponibilidad, los escáneres de accesibilidad y los callbacks de pago caen en el segundo grupo: son automatización, no amenaza. Si el conjunto humano son solo empleados con portátiles recientes, el banco mide portátiles de empleados, no clientes.
Quedan dos condiciones de método. Congelar la política durante cada prueba, registrando versión del motor, umbral, señales disparadas, acción propuesta y resultado real de la sesión: sin ese resultado solo se cuentan detecciones y no se sabe si la acción habría interrumpido a alguien. Y arrancar en modo sombra, donde cada petición se evalúa pero la respuesta no cambia; lo que se habría desafiado se sirve igual y lo que se habría bloqueado llega a la aplicación.
La razón de tanto cuidado es que una tasa agregada oculta daño concentrado en un navegador concreto, una red móvil o una ruta de alto valor. La pregunta útil no es cuál es el porcentaje de falsos positivos, sino cuántas sesiones humanas conocidas desafió o bloqueó cada regla en cada ruta protegida, y qué pasó después.
