Tráfico de Bots en Test A/B: limpiar antes de leer
El tráfico de bots en un test A/B solo invalida el resultado cuando cae desigual entre las variantes. Cómo separar ruido de sesgo, detectar y filtrar.
📚 Este artículo es parte de la guía Significancia Estadística en Tests A/B: La Guía.
El tráfico de bots no invalida un test A/B por existir, lo invalida cuando cae desigual entre las variantes. Un robot distribuido de forma no sesgada solo añade ruido y reduce el poder del experimento; un robot que actúa como un solo usuario y alimenta siempre a la misma variante desplaza la métrica de ese brazo y cambia al ganador. Esta guía muestra la diferencia entre ruido y sesgo, por qué ejecutar JavaScript no separa persona de robot, un ejemplo trabajado en el que un crawler borró una ganancia real del 13 por ciento, y el método de detección que proponen los autores del tema. Forma parte de nuestra guía completa de test A/B y es el vecino directo del sesgo de instrumentación: allí el instrumento mide mal, aquí quien está siendo medido no es gente.
Ruido y sesgo son problemas diferentes
La intuición común es que un bot es suciedad y que la suciedad lo estropea todo. La literatura de experimentación es más precisa que eso.
Crook, Frasca, Kohavi y Longbotham, en el artículo de KDD 2009 que catalogó siete trampas de los experimentos controlados en la web, plantean la distinción así: para la experimentación, la preocupación principal es eliminar los robots que causan sesgo. Si el tráfico de un robot se distribuye entre las variantes de forma no sesgada, su presencia añade ruido al dato y reduce el poder del experimento, pero no invalida los resultados. Los robots vistos como múltiples usuarios únicos, porque resetean cookies o se ejecutan desde varias máquinas, no introducen sesgo. El caso que sí introduce sesgo es el robot que actúa como un único usuario y genera tráfico de forma consistente hacia una sola variante.
Eso cambia el orden de las prioridades. Un sitio puede tener una fracción enorme de accesos automatizados y aun así ejecutar experimentos fiables, siempre que el sorteo lance esos accesos a los dos brazos en la misma proporción. Y un sitio con poquísimos bots puede tener un resultado completamente equivocado por culpa de un único agente que insiste en una URL.
| mecanismo del robot | identidad | cómo se reparte | efecto en el test |
|---|---|---|---|
| Crawler que resetea la cookie en cada visita | muchas, efímeras | tiende a simétrica | ruido, pérdida de poder |
| Robot ejecutándose desde varias máquinas | muchas | tiende a simétrica | ruido, pérdida de poder |
| Robot con cookie estable y comportamiento extremo | una, persistente | queda atrapado en una variante | sesgo, cambio de ganador |
| Crawler que solo busca un patrón de URL | cualquiera | un solo brazo en test de URL dividida | sesgo, cambio de ganador |
| Monitor de disponibilidad golpeando una ruta fija | una, persistente | un solo brazo | sesgo, cambio de ganador |
| Robot compartiendo máquina con una persona | mixta | sigue el brazo de la persona | contamina la métrica de ese brazo |
La última fila merece un párrafo. Los mismos autores observan que los robots implementados automatizando un navegador real soportan toda la funcionalidad de ese navegador, incluidas cookies y JavaScript, y que cuando un robot así se ejecuta en una máquina que también usa una persona, robot y persona suelen compartir la misma cookie. Si la identidad del usuario está guardada en una cookie, algo muy habitual, ese identificador pasa a comportarse a veces como persona y a veces como robot. No existe filtro por identificador que resuelva ese caso de forma limpia.
El caso del portal MSN
El relato más útil de la literatura sobre este tema es corto y específico. En un experimento del portal MSN se hizo un cambio pequeño en un único módulo de la página. El resultado apareció con tasa de clic estadísticamente diferente en varias áreas de la página, incluidas áreas sin ninguna relación con el cambio.
La investigación encontró la causa: robots que aceptaban cookies y ejecutaban JavaScript. Según los autores, ejecutar código en JavaScript es una de las características más comunes usadas para separar personas de robots, y algunos proveedores de analítica llegan a afirmar que el marcado de página vía JavaScript es tan robusto que hace innecesaria cualquier detección adicional de robots. En aquel caso, sin embargo, los robots estaban ejecutando eventos de clic, que en el portal MSN se disparan cuando un usuario pulsa un enlace, a tasas extremas del orden de 100 por minuto durante 2,5 horas.
El detalle que le interesa a quien lee un panel de test A/B no es el número en sí, es la forma de la anomalía: diferencia significativa donde no hubo cambio. Esa es la señal más barata de que hay algo no humano en el dato, y se lee gratis en cualquier scorecard que muestre métricas secundarias junto a la primaria.
Ejemplo trabajado: el crawler que borró una ganancia real
Todos los números de abajo salieron de la misma calculadora de significancia incrustada justo después, con test bilateral, y puedes reproducir cada fila pegando los recuentos.
El escenario es un test de URL dividida en una página de producto. La variante B vive en una URL propia. Un crawler de comparación de precios descubre esa URL y pasa a visitarla, en varias sesiones, sin comprar nunca nada.
Lectura A, el dato real de las personas. A recibió 40.000 visitantes y 1.200 pedidos, una tasa del 3,000 por ciento. B recibió 40.000 visitantes y 1.360 pedidos, 3,400 por ciento. La calculadora devuelve un lift relativo del 13,33 por ciento, z igual a 3,2141 y valor p de 0,001309, con intervalo de confianza de 0,156 a 0,644 puntos porcentuales para la diferencia absoluta. B gana, y gana con holgura.
Lectura B, el dato tal como llega al panel. El crawler sumó 6.000 visitas a la variante B, ninguna de ellas con pedido. Ahora B tiene 46.000 visitantes y los mismos 1.360 pedidos, una tasa del 2,957 por ciento. La calculadora devuelve un lift relativo de menos 1,45 por ciento, z igual a menos 0,3742 y valor p de 0,708243, con intervalo de menos 0,271 a 0,184 puntos porcentuales. El resultado no solo no es significativo: el signo se invirtió, y la lectura de superficie es “la variante nueva perdió”.
| lectura | visitantes A | pedidos A | visitantes B | pedidos B | tasa B | lift relativo | valor p | veredicto |
|---|---|---|---|---|---|---|---|---|
| Solo personas | 40.000 | 1.200 | 40.000 | 1.360 | 3,400% | +13,33% | 0,001309 | gana B |
| Con 3.000 visitas de robot en B | 40.000 | 1.200 | 43.000 | 1.360 | 3,163% | +5,43% | 0,175281 | no concluyente |
| Con 6.000 visitas de robot en B | 40.000 | 1.200 | 46.000 | 1.360 | 2,957% | menos 1,45% | 0,708243 | pierde B |
Fíjate en la fila del medio. Con la mitad de la contaminación el experimento no se convierte en una derrota, se convierte en un empate. El empate es el desenlace más caro de los tres, porque nadie investiga un empate: la variante se descarta en silencio y la ganancia del 13 por ciento nunca se implementa.
Test z bilateral de dos proporciones. "Sin significancia" casi siempre significa que falta muestra, no que las versiones sean iguales.
Vale registrar que la dirección del destrozo depende de qué lado de la fracción toca el robot. En el ejemplo de arriba el robot infló el denominador y hundió la tasa. Un robot que dispara eventos de clic, como en el caso del MSN, infla el numerador y levanta la tasa de la variante donde vive, produciendo un ganador que no existe. Los dos fallos tienen el mismo origen y el mismo remedio.
Por qué la lista de bots conocidos no basta
La capa de defensa más común es la lista de agentes conocidos. La documentación de Google Analytics informa de que el tráfico de bots y spiders conocidos se excluye automáticamente, usando una combinación de investigación de Google con la International Spiders and Bots List mantenida por el Interactive Advertising Bureau. La misma página registra que, por ahora, no es posible desactivar esa exclusión ni ver cuánto tráfico de bots conocidos fue excluido.
Eso es útil y es insuficiente, por dos motivos estructurales.
El primero es el criterio de entrada en la lista: cataloga agentes que se declaran. Un rastreador de búsqueda, un verificador de enlaces, un previsualizador de red social y un monitor de disponibilidad se identifican porque ser identificables forma parte de su función. Un agente que no quiere ser reconocido simplemente no aparece con un nombre catalogable.
El segundo es la falta de visibilidad. Cuando la exclusión ocurre antes de que el dato llegue a tu informe y el volumen excluido no se expone, no puedes responder a la única pregunta que importa para experimentación: lo que fue eliminado cayó igual en los dos brazos? Una exclusión simétrica es inofensiva. Una exclusión que eliminó más de un lado que del otro es, en sí misma, una fuente de sesgo.
| capa | qué atrapa | qué no atrapa |
|---|---|---|
| Lista de agentes conocidos (IAB y similares) | rastreadores de búsqueda, herramientas de SEO, previsualizadores de enlaces, monitores | agente que no se declara |
| Exigir ejecución de JavaScript | script simple, cliente HTTP puro | navegador automatizado (el caso del MSN) |
| Umbral de eventos por sesión | comportamiento extremo y obvio | robot calibrado para parecer humano |
| Test A/A y resorteo retroactivo | sesgo de asignación, sea cual sea su origen | no dice quién es el robot, solo que hay asimetría |
La última fila es la que cierra el problema, y es la propuesta original de los autores del artículo de 2009.
Detección por test A/A y por resorteo retroactivo
Los autores reconocen que identificar todos los robots es difícil en general y que no existe una forma clara de evaluar cómo de bien se comporta un algoritmo de detección sobre dato real. La salida que proponen es elegante: usar el propio experimento controlado como función de evaluación, al menos para los robots más críticos para el análisis, aquellos capaces de distorsionar resultados por aceptar cookies y comportarse como usuarios extremos.
El esquema es el test A/A: los usuarios se dividen en control y tratamiento, pero no existe diferencia sistemática entre las dos versiones a las que se los expone. La hipótesis nula en un test A/A debería rechazarse en torno al 5 por ciento de las veces cuando se usa un nivel de confianza del 95 por ciento. Si eso no se sostiene, existe sesgo introducido por comportamiento extremo de usuarios, que muy probablemente son robots asignados a una variante específica. Los autores destacan que hace falta ejecutar múltiples tests A/A para tener confianza sobre la existencia de robots sesgados.
El detalle operativo más valioso viene a continuación: esos tests no tienen que ser en vivo. Según los autores, basta con ejecutarlos de forma retroactiva, resorteando los usuarios y asignándolos a control y tratamiento, y evaluando la hipótesis de que los dos grupos son iguales. En términos prácticos, eso significa que puedes auditar el sesgo de robots sobre el dato histórico que ya tienes, hoy, sin consumir una semana de tráfico.
Firmas prácticas en tu propio dato
Antes de invertir en detección sofisticada, existen consultas baratas que resuelven la mayoría de los casos. Todas parten del mismo principio: el robot que sesga es el robot que se comporta como usuario extremo.
- Cola de eventos por identificador. Ordena los identificadores por número de eventos en el periodo. Si la cima de la lista tiene órdenes de magnitud más que la mediana, mira esos identificadores uno a uno. El tratamiento estadístico de la cola larga está en outliers y capping, y conviene notar que el capping trata el síntoma sin responder si el extremo era una persona.
- Ritmo dentro de la sesión. Las personas tienen intervalos irregulares entre eventos. Una cadencia casi constante, o decenas de eventos por minuto sostenidos durante horas, es una firma mecánica.
- Distribución por variante de los identificadores extremos. Esta es la consulta que decide si tienes ruido o sesgo: toma el 1 por ciento superior de identificadores por volumen y comprueba cómo se reparten entre los brazos. Reparto igual es ruido. Reparto desigual es tu problema.
- Reparto de tráfico general. Una desviación en la proporción de visitantes entre las variantes es la alarma más barata del arsenal, y vale tanto para robots como para cualquier otro fallo de recolección. El procedimiento completo está en reparto desigual de tráfico y se puede ejecutar en el verificador de SRM.
- Métricas que no deberían haber cambiado. Es la firma del caso MSN. Si el experimento tocó un módulo y tres áreas no relacionadas se movieron, la hipótesis de robot entra por delante de la hipótesis de efecto.
- Simetría del propio filtro. Después de aplicar cualquier regla de exclusión, compara cuántos registros eliminó de cada brazo. Un filtro asimétrico es una nueva fuente de sesgo.
Dónde filtrar el tráfico de bots: recolección, ingesta o análisis
| punto | ventaja | riesgo |
|---|---|---|
| En la recolección (el evento ni se envía) | dato limpio desde el origen | lo descartado no puede auditarse después |
| En la ingesta (marcado y separado) | permite comparar bruto contra limpio | exige guardar el volumen marcado |
| En el análisis (excluido en la consulta) | regla revisable, reproducible | la regla puede tocarse después de ver el resultado |
La configuración más defendible suele ser la del medio: marcar en la ingesta, guardarlo todo, excluir en el análisis mediante una regla escrita en el plan de análisis preregistrado. Así consigues reportar las dos lecturas, bruta y limpia, y demostrar que la conclusión no depende del filtro. Cuando las dos lecturas discrepan, eso es información, no una vergüenza: es exactamente el hallazgo que justifica investigar antes de decidir.
Checklist antes de confiar en el número
- La regla de exclusión está escrita antes de que empiece el test? Un filtro elegido después es un grado de libertad.
- Puedes ver el volumen filtrado por variante? Si no, no puedes afirmar que el filtro fue simétrico.
- El reparto de tráfico pasa sobre el dato ya limpio? Verificar antes de filtrar responde a la pregunta equivocada.
- La cima de identificadores por volumen está repartida igual entre los brazos?
- Alguna métrica sin relación con el cambio se movió?
- Existe una batería de tests A/A, en vivo o retroactiva, sobre este mismo segmento de tráfico?
- La conclusión sobrevive a las dos lecturas, bruta y limpia?
Errores comunes
- Tratar el volumen de bots como si fuera el problema. Lo que rompe el experimento es la asimetría, no el volumen.
- Confiar en que ejecutar JavaScript separa persona de robot. El caso MSN existe justamente para desmentirlo.
- Filtrar después de ver quién ganó. Si el filtro cambia al ganador y fue elegido después, el resultado no es defendible, aunque el filtro sea técnicamente correcto.
- Excluir sin contar lo que se excluyó. Un filtro asimétrico sustituye un sesgo por otro.
- Ejecutar un único test A/A y concluir que todo está bien. Un A/A aislado rechaza la nula el 5 por ciento de las veces por construcción. La señal está en la distribución de una batería.
- Confundir robot con fraude. Buena parte del tráfico automatizado es legítimo y declarado. El objetivo aquí es medir gente, no castigar a nadie.
- Aplicar capping y dar el caso por cerrado. Limitar la cola reduce la varianza y no responde si el extremo era humano.
Hazlo automático en Donnu
El problema práctico rara vez es la falta de ganas de filtrar. Es que la decisión sobre bots ocurre lejos del panel: alguien escribió una regla en algún sitio, meses atrás, y nadie es capaz de decir si eliminó más de un brazo que del otro en este experimento concreto.
En Donnu, la proporción observada de visitantes por variante queda visible junto al resultado desde el primer día del test, y no escondida en un informe de salud aparte, porque la asimetría de asignación es el síntoma común a los robots, a los fallos de recolección y a los errores de sorteo. Si quieres rehacer cualquier cuenta a mano, la calculadora de significancia acepta los recuentos brutos y los filtrados para que compares las dos lecturas lado a lado, y el verificador de SRM contrasta el reparto de tráfico antes de que mires al ganador.
Referencias
- Crook, T., Frasca, B., Kohavi, R. y Longbotham, R. Seven Pitfalls to Avoid when Running Controlled Experiments on the Web. KDD 2009. Fuente de la trampa 5 (descuidar el filtrado de robots); de la distinción entre el robot distribuido de forma no sesgada, que añade ruido y reduce el poder sin invalidar resultados, y el robot que actúa como usuario único alimentando una variante, que crea un sesgo significativo; de la observación de que los robots vistos como múltiples usuarios únicos por resetear cookies o ejecutarse desde varias máquinas no introducen sesgo; del caso del portal MSN, con diferencias estadísticamente significativas en áreas no relacionadas de la página causadas por robots que aceptaban cookies y ejecutaban JavaScript disparando eventos onclick a cerca de 100 por minuto durante 2,5 horas; del registro de que algunos proveedores de analítica afirman que el marcado vía JavaScript hace innecesaria la detección adicional de robots; del caso del robot que comparte cookie con una persona en la misma máquina; y del esquema de evaluación mediante tests A/A, incluida la variante retroactiva por resorteo de los usuarios. exp-platform.com.
- Google. [GA4] Bot traffic. Centro de Ayuda de Google Analytics. Fuente de la afirmación de que el tráfico de bots y spiders conocidos se excluye automáticamente, de que la identificación usa una combinación de investigación de Google con la International Spiders and Bots List mantenida por el Interactive Advertising Bureau, y de que no es posible desactivar esa exclusión ni ver cuánto tráfico de bots conocidos fue excluido. support.google.com.
- Interactive Advertising Bureau. IAB/ABC International Spiders and Bots List. Fuente de la existencia y del alcance de la lista de agentes automatizados declarados usada como referencia de mercado para la exclusión de tráfico no humano. iab.com.
- Kohavi, R., Deng, A., Frasca, B., Walker, T., Xu, Y. y Pohlmann, N. Online Controlled Experiments at Large Scale. KDD 2013. Fuente del contexto de escala en el que se ejecutan estas verificaciones, con cada experimento exponiendo varios millones de usuarios y más de 200 experimentos concurrentes por día, y de la descripción del sistema de alerta que detecta automáticamente eventos de calidad del dato. exp-platform.com.
Lee también: Sesgo de instrumentación · Reparto desigual de tráfico (SRM) · Test A/A: validar el montaje · Outliers y capping · Plan de análisis preregistrado · Calculadora de significancia · Leia em português
Preguntas frecuentes
- ¿El tráfico de bots invalida un test A/B?
- No siempre. Crook, Frasca, Kohavi y Longbotham separan los dos casos con claridad: si el tráfico de un robot se distribuye entre las variantes de forma no sesgada, el robot añade ruido al dato y reduce el poder del experimento, pero no invalida el resultado. Lo que invalida es el robot que actúa como un único usuario y genera tráfico de forma consistente hacia una sola variante, porque ahí desplaza la métrica de ese brazo. La pregunta operativa, por lo tanto, no es cuánto bot existe, es si el bot cayó igual de los dos lados.
- ¿Los bots aceptan cookies y ejecutan JavaScript?
- Sí. Es exactamente el punto del relato de Crook, Frasca, Kohavi y Longbotham sobre el portal MSN: un cambio pequeño y localizado en un módulo apareció como diferencia estadísticamente significativa en áreas no relacionadas de la página, y la causa eran robots que aceptaban cookies y ejecutaban JavaScript, disparando eventos de clic a tasas del orden de 100 por minuto durante 2,5 horas. Los autores registran que algunos proveedores de analítica llegan a afirmar que el marcado de página con JavaScript es lo bastante robusto como para prescindir de la detección de robots, y el caso demuestra que no lo es.
- ¿Google Analytics 4 ya elimina bots por sí solo?
- Elimina una parte. La documentación de Google Analytics dice que el tráfico de bots y spiders conocidos se excluye automáticamente, usando una combinación de investigación de Google con la International Spiders and Bots List mantenida por el Interactive Advertising Bureau. La misma página registra dos limitaciones importantes: no es posible desactivar esa exclusión ni ver cuánto tráfico de bots fue excluido. Es decir, la lista atrapa al agente automatizado que se identifica, y tú no recibes el volumen filtrado para auditarlo.
- ¿Cómo detectar si hay sesgo de bots en mi experimento?
- Crook, Frasca, Kohavi y Longbotham proponen usar tests A/A como función de evaluación. En un test A/A, la hipótesis nula debería rechazarse en torno al 5 por ciento de las veces con un nivel de confianza del 95 por ciento. Si eso no se sostiene, existe sesgo introducido por comportamiento extremo de usuarios, muy probablemente robots asignados de forma desigual. Los autores observan además que estos tests no tienen que ser en vivo: se pueden ejecutar de forma retroactiva, resorteando los usuarios ya registrados y contrastando la hipótesis de que los dos grupos son iguales.
- ¿Un bot que resetea cookies sesga el resultado?
- Según los mismos autores, no. Los robots que aparecen como varios usuarios únicos porque resetean cookies o se ejecutan desde varias máquinas no introducen sesgo. El caso peligroso es el opuesto: el robot que mantiene una identidad estable, cae en una sola variante y se comporta como un usuario extremo. Vale registrar que una identidad puede ser compartida: cuando un robot se ejecuta en una máquina que también usa una persona, ambos suelen compartir la misma cookie, y ese mismo identificador pasa a comportarse a veces como persona y a veces como robot.
- ¿Debo filtrar bots antes o después de calcular la significancia?
- Antes, y con la regla de filtrado escrita en el plan de análisis, no elegida después de mirar el resultado. Un filtro definido a posteriori es un grado de libertad más en el análisis, y un grado de libertad que cambia al ganador es indistinguible de un sesgo de selección. El orden defendible es: regla de exclusión declarada, dato limpio, verificación del reparto de tráfico sobre el dato ya limpio, y solo entonces el test de significancia.