Test A/A: validar el montaje antes de creer en el resultado
Qué es un test A/A, qué prueba realmente un A/A aprobado, cómo dimensionarlo y por qué la comprobación de reparto detecta más bugs reales que el valor-p.
📚 Este artículo es parte de la guía Significancia Estadística en Tests A/B: La Guía.
Un test A/A hace correr todo tu pipeline de experimentación mostrando la misma experiencia a los dos grupos, así que toda diferencia que reporte es ruido o defecto. Es la forma más barata de descubrir si tus resultados significan algo, y la peor leída, porque un A/A aprobado es un detector de fallo que volvió vacío, no un certificado de que el sistema está sano. Esta guía cubre qué valida de hecho un A/A, por qué un A/A significativo es esperado y no alarmante, cómo dimensionarlo para que el resultado limpio cargue información, y la comprobación de reparto que detecta más bugs reales que la lectura de conversión. Forma parte de nuestra guía completa de test A/B y hace pareja con SRM: reparto desigual de tráfico, que es el fallo que un A/A revela con más frecuencia.
Qué es un test A/A, y los dos trabajos que hace
Kohavi, Longbotham, Sommerfield y Henne, en el estudio de 2009 sobre experimentos controlados en la web, definen el test A/A, que señalan que a veces se llama test nulo, así: en vez de un test A/B, ejercitas el sistema de experimentación, asignando usuarios a uno de dos grupos, pero exponiéndolos exactamente a la misma experiencia. Nombran dos usos, y los dos son trabajos genuinamente distintos.
El primero es medición: recoger datos para evaluar su variabilidad en los cálculos de potencia. La varianza de tu propia métrica es insumo de todo tamaño de muestra que vas a calcular en tu vida, y un A/A te la entrega en la población, la instrumentación y la ventana exactas en que vas a testear, en vez de venir de una suposición de manual.
El segundo es validación: testear el sistema de experimentación, donde, en sus palabras, la hipótesis nula debería rechazarse alrededor del 5% de las veces cuando se usa un nivel de confianza del 95%. Ese es el trabajo que la mayoría de los equipos quiere decir cuando habla de test A/A, y es el que peor leen, porque aquella frase contiene la dificultad entera. El comportamiento correcto de un sistema correcto es producir un resultado significativo de vez en cuando.
Por qué un A/A significativo es el resultado esperado, no una alarma
Un test al 95% de confianza está construido para rechazar una nula verdadera el 5% de las veces. Esa es la definición del umbral, no un defecto suyo. Así que la pregunta “¿nuestro A/A salió significativo?” es la pregunta equivocada. La correcta es “¿nuestra tasa de rechazo se queda cerca del 5% a lo largo de muchas rondas?”
Corre suficientes A/A y un significativo deja de ser posible para volverse probable:
| Tests A/A corridos | Probabilidad de que al menos uno salga significativo |
|---|---|
| 1 | 5,0% |
| 2 | 9,8% |
| 3 | 14,3% |
| 5 | 22,6% |
| 10 | 40,1% |
| 20 | 64,2% |
| 40 | 87,1% |
Un equipo que corre un A/A semanal durante un año y trata cada semana significativa como incidente va a abrir unas dos o tres investigaciones sobre un sistema que funciona perfectamente. Un equipo que corre un A/A, lo ve pasar y declara la plataforma validada no aprendió casi nada. La señal de diagnóstico es la tasa, no la ronda. Es también por eso que el A/A mucho más útil es uno permanente, leído como tasa de rechazo de largo plazo, y no una ceremonia suelta antes del test grande.
La dirección del error también importa. Una tasa de rechazo materialmente por encima del 5% quiere decir que algo está inflando tus diferencias, y el estudio de 2009 nombra un culpable específico: los bots. Reportan casos en que los bots hicieron que muchas métricas salieran significativas cuando no deberían, con mucho más del 5% de falsos positivos en un test A/A, y señalan que en algunos sitios se cree que los bots generan hasta la mitad de las páginas vistas. Una tasa de rechazo materialmente por debajo del 5% tampoco es tranquilizadora, porque en general significa varianza sobreestimada, lo que cuesta potencia en silencio en todo test real que corras.
Ejemplo trabajado: tres rondas de A/A y qué dice cada una
Corre los números de abajo en la calculadora mientras lees. Cada uno es un A/A en el mismo producto, con una tasa base de conversión del 3%:
Test z bilateral de dos proporciones. "Sin significancia" casi siempre significa que falta muestra, no que las versiones sean iguales.
Ronda 1, la limpia. El control recibe 40.000 usuarios y 1.200 conversiones (3,000%); el segundo brazo recibe 40.130 usuarios y 1.236 conversiones (3,080%). La diferencia es +0,08 punto porcentual, z = 0,66, valor-p 0,5096, intervalo de confianza de -0,16 a +0,32 punto porcentual. El reparto, 49,919% contra 50,081%, da chi cuadrado 0,211, valor-p 0,646. Nada se dispara. Así es como se ve un A/A sano, y fíjate en que aquel intervalo todavía es ancho: es compatible con un sesgo real que va de alrededor del 5% relativo en contra del segundo brazo a alrededor del 11% relativo a su favor.
Ronda 2, la que “gana”. Los dos brazos reciben 40.000 usuarios; las conversiones se quedan en 1.200 y 1.300. Eso es +8,33% relativo, z = 2,03, valor-p 0,0422, intervalo de confianza de +0,01 a +0,49 punto porcentual. Formalmente significativo. El reparto es exactamente 50/50, chi cuadrado 0,000. Esta es la salida peor leída de todo el asunto. No existe tratamiento, así que el efecto no es real. Un brazo tuvo más suerte. La respuesta correcta es registrar y seguir, porque la tabla de tasas de arriba dice que esto pasa alrededor de 1 ronda de cada 20 en un sistema sin nada mal. Las respuestas equivocadas son salir a cazar un bug que no existe o, peor, concluir que la plataforma “detectó una diferencia” y por lo tanto funciona.
Ronda 3, la que importa. El control recibe 40.000 usuarios y 1.200 conversiones; el segundo brazo recibe 38.800 usuarios y 1.210 conversiones. La lectura de conversión está callada: +3,95% relativo, z = 0,97, valor-p 0,3339, intervalo de -0,12 a +0,36 punto porcentual. Quien lee solo el valor-p aprueba ese test. El reparto no está callado: 50,761% contra 49,239% da chi cuadrado 18,27, valor-p 0,0000191, mucho más allá del umbral de 0,01 usado por convención en una comprobación de reparto. Alrededor de 1.200 usuarios que deberían estar en el segundo brazo no están ahí.
La comprobación de reparto es la que paga su propio coste
La razón de que la ronda 3 sea la interesante es que las dos comprobaciones no son redundantes. La lectura de conversión pregunta si la métrica difiere. La comprobación de reparto pregunta si la maquinaria entregó la asignación pedida, que es una pregunta de fontanería que ninguna comparación de métrica responde.
Fabijan y colegas, estudiando el reparto desigual de tráfico en Microsoft para el KDD 2019, encontraron que alrededor del 6% de los experimentos en Microsoft presentan un SRM, y observan que un producto que corre diez mil experimentos al año puede esperar ver al menos uno por día. Su caso de MSN.com es específicamente una historia de A/A: un equipo observó un desbalance en un test A/A, y la investigación encontró un bug en el servicio de asignación en que el control recibía un bucket menos de los necesarios entre mil, de modo que un test 50/50 estaba en realidad montado como algo cercano a 49,9/50,1, una desviación que ellos describen, con razón, como no necesariamente un problema obvio.
Ese caso también es una lección sobre dimensionamiento, porque una desviación de 0,1 punto es muy difícil de ver:
| Total de usuarios en el A/A | Reparto observado a 49,9/50,1 | Chi cuadrado | Valor-p | ¿Señalado a 0,01? |
|---|---|---|---|---|
| 80.000 | 39.920 / 40.080 | 0,32 | 0,572 | no |
| 200.000 | 99.800 / 100.200 | 0,80 | 0,371 | no |
| 500.000 | 249.500 / 250.500 | 2,00 | 0,157 | no |
| 1.000.000 | 499.000 / 501.000 | 4,00 | 0,046 | no |
| 2.000.000 | 998.000 / 1.002.000 | 8,00 | 0,0047 | sí |
| 5.000.000 | 2.495.000 / 2.505.000 | 20,00 | 0,0000077 | sí |
Un defecto de ese tamaño necesita del orden de dos millones de usuarios antes de que una comprobación de rutina lo señale. Que es la lectura honesta de todo A/A limpio: descarta los sesgos que tu muestra podía ver, y no dice nada sobre los que no podía. La mecánica de la comprobación, los umbrales y las causas raíz habituales están en SRM: reparto desigual de tráfico, y puedes correr tus propios números en el verificador de test A/A gratis.
El artículo de 2019 también es útil por lo que dice sobre alcance. Lista tres exigencias para un servicio de asignación: los usuarios necesitan tener la misma probabilidad de ver cada variación, asignaciones repetidas de un mismo usuario necesitan ser consistentes, y cuando varios experimentos corren no puede haber correlación entre ellos. Violar cualquiera de las tres puede causar un desbalance, y un defecto en el servicio de asignación suele aparecer en varios experimentos a la vez, no en uno. Así que un fallo de reparto en un A/A raramente es un problema local, y es exactamente eso lo que lo hace valioso de detectar ahí.
Cómo dimensionar un A/A para que el resultado limpio signifique algo
Dimensionar un A/A es la misma aritmética de dimensionar cualquier test, con un cambio de encuadre: el efecto para el que calculas potencia no es una mejora deseada, es el mayor sesgo que aceptas dejar pasar sin detectar. Escribe ese número primero, después dimensiona para él.
Cálculo por aproximación normal de dos proporciones, 2 variaciones (50/50). Cambia los campos y mira el impacto en vivo.
Con una tasa base del 3%, mira lo que un A/A limpio descarta de hecho en distintos tamaños de muestra:
| Usuarios por brazo | Menor sesgo detectable al 80% de potencia | En términos relativos |
|---|---|---|
| 10.000 | 0,68 punto porcentual | 22,5% |
| 25.000 | 0,43 punto porcentual | 14,2% |
| 50.000 | 0,30 punto porcentual | 10,1% |
| 100.000 | 0,21 punto porcentual | 7,1% |
| 200.000 | 0,15 punto porcentual | 5,0% |
| 400.000 | 0,11 punto porcentual | 3,6% |
Lee esa tabla contra la ronda 1 de más arriba. Con 40.000 usuarios por brazo, aquel A/A tenía alrededor de 68,0% de potencia frente a un sesgo relativo del 10% y alrededor de 23,2% frente a uno del 5%. En otras palabras, si la plataforma estuviera favoreciendo a un brazo en un 5% en silencio, aquella ronda lo habría dejado pasar más de tres veces de cada cuatro. Llegar al 80% de potencia para un sesgo relativo del 5% exige alrededor de 207.938 usuarios por brazo. La misma lógica vale para leer cualquier resultado no concluyente, y está detallada en efecto mínimo detectable.
Dos restricciones prácticas encima de la aritmética. Déjalo correr al menos un ciclo semanal completo, para que el tráfico de día laborable y el de fin de semana estén ambos dentro de la ventana en vez de cortados por el borde. Y no pares el A/A antes de tiempo porque parece limpio, por la misma razón por la que no pararías un test real antes de tiempo: espiar un experimento en marcha repetidamente infla la tasa de falso positivo bastante por encima del 5% nominal, que es exactamente el número que un A/A existe para medir. Ese mecanismo está en el problema del peeking.
Cuándo correr uno, y cómo leer el resultado
| Situación | ¿Correr un A/A? | Qué estás buscando |
|---|---|---|
| Herramienta de experimentación nueva, o integración nueva de una existente | Sí, antes del primer test real | Reparto correcto, pérdida de evento, tasa de rechazo cerca del nominal |
| Migración a nuevo pipeline de analítica o data warehouse | Sí | Definiciones de métrica y joins que cambiaron en silencio |
| La aleatorización pasó del cliente al servidor, o al revés | Sí | Consistencia de asignación en visitas repetidas |
| Un test real produjo un resultado en el que nadie cree | Sí, pero como diagnóstico, no como veto | Si el problema es la maquinaria y no el resultado |
| De forma rutinaria, antes de cada experimento | No | Tráfico gastado aquí es tráfico no gastado decidiendo algo |
| De forma continua, en segundo plano | Lo ideal, si la asignación cabe | Tasa de rechazo de largo plazo y estabilidad del reparto en el tiempo |
Y las reglas de lectura, que importan más que las de ejecución:
- Un fallo de reparto es un incidente. Para, encuentra la causa raíz y trata todo experimento concurrente como sospechoso hasta saber el alcance.
- Una lectura de conversión significativa aislada, con reparto limpio, no es un incidente. Regístrala. Investiga solo si la tasa corriente se aleja bastante del 5%.
- Una ronda limpia está limitada por su muestra. Repórtala como “ningún sesgo por encima de X detectado en esta muestra”, no como “validado”.
- Nunca reportes un A/A con el vocabulario de un ganador. Ningún brazo ganó. Si el informe contiene la palabra “ganancia”, el encuadre ya salió mal.
Errores comunes con tests A/A
| Error | Qué produce |
|---|---|
| Tratar un A/A significativo como prueba de sistema roto | Semanas depurando una plataforma que se comporta exactamente como fue diseñada |
| Tratar un A/A limpio como prueba de sistema sano | Confianza falsa en un pipeline por el que un sesgo pequeño pasa de largo |
| Comprobar solo el valor-p de conversión, nunca el reparto | El fallo con más probabilidad de ser real pasa desapercibido |
| Dimensionar el A/A por conveniencia en vez de por sesgo tolerable | Un resultado limpio que no descarta nada que alguien quiera saber |
| Parar el A/A en cuanto parece limpio | El peeking infla justamente la tasa de falso positivo que el test existe para medir |
| Correr el A/A en una semilla compartida con un experimento en el aire | El A/A muestrea la población de aquel experimento en vez de sortear desde cero |
| Reportar un brazo del A/A como ganador | Un número sin causa detrás entra en el registro de decisión |
| Correr un A/A una sola vez, en el lanzamiento de la plataforma | El pipeline que importa es el que tienes ahora, no el que tenías entonces |
Hazlo automático con Donnu
Un A/A solo se paga si la comprobación de reparto corre cada vez y si la tasa de rechazo de largo plazo es algo que puedes ver. Donnu A/B corre la comprobación de proporción de muestra en todo experimento, A/A o no, y muestra un reparto suspendido como señal de calidad de datos que bloquea la lectura, no como una nota al pie debajo del resultado. La asignación se hashea por experimento, así que una ronda de validación nunca hereda la población de otro test, y una lectura no concluyente reporta el intervalo de confianza, que es lo que te dice cuánto sesgo pudo descartar de hecho aquella ronda.
Empieza una prueba gratis de 14 días y comprueba el reparto de tu próximo experimento antes de leer el resultado.
Referencias
- Kohavi, R., Longbotham, R., Sommerfield, D. y Henne, R. M. Controlled experiments on the web: survey and practical guide. Data Mining and Knowledge Discovery, 18(1), 2009. Fuente de la definición de test A/A y del nombre alternativo test nulo, de los dos usos declarados (evaluar variabilidad para cálculos de potencia y testear el sistema de experimentación), de la expectativa de que la nula se rechace alrededor del 5% de las veces al 95% de confianza, y del hallazgo de que los bots pueden llevar un A/A a mucho más del 5% de falsos positivos. exp-platform.com.
- Fabijan, A., Gupchup, J., Gupta, S., Omhover, J., Qin, W., Vermeer, L. y Dmitriev, P. Diagnosing Sample Ratio Mismatch in Online Controlled Experiments: A Taxonomy and Rules of Thumb for Practitioners. KDD 2019. Fuente del hallazgo de que alrededor del 6% de los experimentos en Microsoft presentan SRM, del bug en el servicio de asignación de MSN.com que convirtió un test 50/50 en algo cercano a 49,9/50,1, y de las tres exigencias que un servicio de asignación necesita satisfacer. exp-platform.com.
- Kohavi, R., Deng, A., Frasca, B., Walker, T., Xu, Y. y Pohlmann, N. Online Controlled Experiments at Large Scale. KDD 2013. Sobre monitoreo y alerta automáticos de calidad de datos en una plataforma que corre cientos de experimentos simultáneos. exp-platform.com.
- Kohavi, R., Tang, D. y Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020. Capítulos sobre confianza, calidad de datos e instrumentación de una plataforma de experimentación. Material complementario en experimentguide.com.
Lee también: SRM: reparto desigual de tráfico · Significancia estadística en test A/B · Efecto mínimo detectable · El problema del peeking · Verificador de test A/A gratis · Leia em português
Preguntas frecuentes
- ¿Qué es un test A/A?
- Un test A/A hace correr toda tu maquinaria de experimentación a plena carga mientras muestra exactamente la misma experiencia a los dos grupos. Kohavi y colegas (Data Mining and Knowledge Discovery, 2009), que también lo llaman test nulo, describen dos usos: recoger datos para evaluar la variabilidad en los cálculos de potencia, y testear el propio sistema de experimentación, donde la hipótesis nula debería rechazarse alrededor del 5% de las veces con un nivel de confianza del 95%. Cualquier diferencia que reporte es, por construcción, ruido o defecto, porque no existe tratamiento que pueda causar una diferencia real.
- ¿Un test A/A significativo quiere decir que el sistema está roto?
- No a partir de una sola ronda. Al 95% de confianza, un sistema correcto produce un A/A significativo alrededor de 1 vez de cada 20 por diseño, así que un resultado significativo es el comportamiento esperado, no evidencia de bug. Lo que importa es la tasa a lo largo de muchas rondas. Diez tests A/A dan alrededor de 40,1% de probabilidad de que al menos uno salga significativo, y veinte dan alrededor de 64,2%. Juzga el sistema por que la tasa de rechazo de largo plazo esté cerca del 5%, e investiga una ronda aislada solo si la comprobación de reparto también falla.
- ¿Cuánto tiempo debe correr un test A/A?
- Lo suficiente para detectar el tamaño de sesgo que de verdad te importa, que suele ser mucho más de lo que los equipos esperan. Con una tasa base del 3% y 40.000 usuarios por brazo, el test tiene alrededor de 68% de potencia frente a un sesgo relativo del 10%, pero solo alrededor de 23,2% frente a uno del 5%, así que un resultado limpio con ese tamaño descarta muy poco. Llegar al 80% de potencia para un sesgo relativo del 5% exige alrededor de 207.938 usuarios por brazo. Déjalo correr al menos un ciclo semanal completo, para que el efecto del día de la semana quepa dentro de la ventana en vez de quedar cortado por ella.
- ¿Qué prueba realmente un test A/A aprobado?
- Bastante menos de lo que la mayoría de los equipos supone. Es un detector de fallo, no un certificado. Un A/A limpio dice que el pipeline no produjo sesgo detectable con el tamaño de muestra que corriste, lo que deja mucho espacio para un sesgo menor del que esa muestra puede resolver. El caso de MSN.com documentado por Fabijan y colegas (KDD 2019) es la ilustración más clara: un bug asignó al control un bucket menos de los necesarios, convirtiendo un test 50/50 en algo cercano a 49,9/50,1, y un reparto torcido a ese nivel necesita del orden de dos millones de usuarios antes de que un chi cuadrado lo señale en el umbral habitual de 0,01.
- ¿Debo comprobar el reparto de tráfico o la tasa de conversión?
- Las dos, y la comprobación de reparto es la que paga su propio coste. La lectura de conversión en un A/A solo se dispara a la tasa nominal de falso positivo y dice poco cuando se dispara. La comprobación de reparto testea algo que la lectura de conversión no ve: si la aleatorización y el logging entregaron la asignación que pediste. Fabijan y colegas (KDD 2019) encontraron que alrededor del 6% de los experimentos en Microsoft presentan SRM, y un defecto en el servicio de asignación suele aparecer en varios experimentos a la vez, no en uno.
- ¿Puedo correr un test A/A junto con experimentos reales?
- Puedes, y un A/A corriendo permanentemente es el arreglo más útil, siempre que su asignación se sortee de forma independiente de todo otro experimento. Kohavi y colegas (2009) mostraron que algunos esquemas de hash fallan exactamente en esa exigencia de independencia, así que un A/A que comparte semilla con un test en el aire puede heredar la población de aquel test en vez de sortear desde cero. Déjalo correr de forma continua, alerta por la tasa de rechazo de largo plazo en vez de por cualquier ventana aislada, y trata un fallo de reparto como incidente de plataforma.
- ¿Un test A/A es lo mismo que un test A/B sin cambio?
- Mecánicamente sí, y ese es justamente el punto: el valor viene de poner el pipeline entero bajo carga con una respuesta correcta conocida. La diferencia está en cómo lo lees. En un test A/B un resultado significativo es un hallazgo candidato; en un A/A solo puede ser ruido o defecto. Esa inversión es lo que hace del A/A un diagnóstico, y es también por lo que un A/A nunca debe reportarse con el vocabulario de un ganador.