Efecto de Arrastre entre Tests A/B: el residuo anterior
El efecto de arrastre entre tests A/B contamina el siguiente experimento en los mismos buckets. Medimos 93% de falso positivo en un A/A y la corrección.
📚 Este artículo es parte de la guía Significancia Estadística en Tests A/B: La Guía.
Cuando el segundo test reaprovecha los mismos buckets del primero, el residuo del primero entra en la lectura del segundo como si fuera efecto. En la simulación de este artículo, un test A/A corrido justo después de un experimento que dejó al grupo de tratamiento 0,60 punto porcentual abajo acusó resultado significativo en 93,30 por ciento de las réplicas, contra el 5 por ciento nominal. Con re-sorteo de los usuarios en cada experimento, la misma medición volvió a 4,47 por ciento. El problema no está en la estadística ni en el volumen de tráfico: está en quién fue sorteado hacia dónde, y cuándo. Esta guía muestra por qué el sistema de buckets crea el problema, mide cuánto tiempo sobrevive el residuo, prueba que la verificación de SRM no lo detecta, y describe la corrección. Forma parte de nuestra guía completa de test A/B y complementa test A/A para validar el montaje y efecto novedad.
El sistema de buckets y el precio de la comodidad
Las plataformas grandes no sortean al usuario directamente hacia el experimento. Sortean al usuario una vez hacia un bucket, y después asignan buckets a los experimentos. Kohavi, Deng, Frasca, Longbotham, Walker y Xu describen el diseño y su ventaja: es flexible y permite el reuso fácil de usuarios en experimentos posteriores. El mismo grupo describe, en el artículo sobre la plataforma de Bing a escala, el mecanismo de aislamiento que corre encima de eso: una línea numérica, equivalente a las capas de Google, garantiza que un usuario quede en un único experimento por línea, con la asignación hecha por un hash pseudoaleatorio de un identificador anónimo.
La comodidad es real. El costo también. Si el sorteo no se repite en cada experimento, quien estaba en el tratamiento ayer tiende a estar en el tratamiento de nuevo hoy, y carga consigo todo lo que el test anterior hizo con él: el hábito que creó, la frustración que causó, el registro que completó, el carrito que abandonó.
El resultado clásico está en el artículo de Kohavi, Deng, Frasca, Longbotham, Walker y Xu: un experimento corrió y las métricas no relacionadas con el cambio se movieron en direcciones inesperadas, con significancia estadística alta. Al correrlo de nuevo en una muestra mayor, muchos de esos efectos simplemente desaparecieron. La explicación era el arrastre.
Cuánto tiempo sobrevive el residuo
Los autores reportan dos mediciones. En la primera, el experimento se corrió en tres etapas: 7 días de A/A en los buckets, 47 días de A/B encendido, y después más de tres semanas monitoreando los mismos buckets con el experimento ya apagado. El efecto de arrastre en el criterio principal, sesiones por usuario, era visible y parece morir alrededor de la tercera semana después del fin del experimento. En la segunda, un bug expuso a los usuarios del tratamiento a una experiencia muy mala: incluso después de tres meses, los buckets todavía no habían vuelto a los niveles anteriores al experimento.
Simulamos esa dinámica para poder medir el efecto sobre la decisión. El diseño: 1.000 buckets de 60 usuarios cada uno, 60.000 usuarios por lectura, tasa base de 5 por ciento, un test 1 que dejó al grupo de tratamiento 0,60 punto porcentual abajo, y un residuo que decae con vida media de 14 días. Después de eso, un test 2 se corre como A/A puro, es decir, sin ningún efecto real, y medimos cuántas veces acusa significancia. Son 3.000 réplicas por línea, con error estándar de Monte Carlo de 0,40 punto porcentual alrededor de 5 por ciento.
| descanso entre los tests | residuo ese día | reusando el bucket: falso positivo | lift medido promedio | con re-sorteo: falso positivo |
|---|---|---|---|---|
| 0 día | -0,6000 pp | 93,30% | -0,6032 pp | 4,47% |
| 7 días | -0,4243 pp | 67,93% | -0,4196 pp | 4,87% |
| 14 días | -0,3000 pp | 39,87% | -0,2982 pp | 4,90% |
| 21 días | -0,2121 pp | 23,10% | -0,2155 pp | 5,13% |
| 28 días | -0,1500 pp | 13,90% | -0,1496 pp | 6,00% |
| 42 días | -0,0750 pp | 7,03% | -0,0743 pp | 4,97% |
| 60 días | -0,0308 pp | 5,07% | -0,0292 pp | 4,47% |
| 90 días | -0,0070 pp | 4,77% | -0,0055 pp | 5,43% |
Dos lecturas salen de ahí.
La primera: el descanso funciona, pero es demasiado caro. Tres semanas de espera todavía dejaban el falso positivo en 23,10 por ciento, casi cinco veces el nominal. Solo con 60 días de bucket parado la lectura volvió a su lugar. Pocos equipos tienen capacidad de tráfico para darle dos meses de vacaciones a la mitad de la base entre un test y otro.
La segunda: re-sortear resuelve independientemente del descanso. La columna de la derecha queda entre 4,47 y 6,00 por ciento en todas las líneas, incluso con descanso cero. Es la diferencia entre esperar a que el problema pase y desarmar el problema.
Un ejemplo trabajado, con la calculadora
Este es un único test A/A corrido inmediatamente después del experimento anterior, sin ningún descanso, sobre los mismos buckets:
- A (buckets que estaban en el control del test 1): 30.000 visitantes, 1.464 conversiones, tasa de 4,8800 por ciento.
- B (buckets que estaban en el tratamiento del test 1): 30.000 visitantes, 1.300 conversiones, tasa de 4,3333 por ciento.
Pegando esos números en la calculadora de significancia, el veredicto es:
- estadístico z de -3,1939
- valor p de 0,001404
- diferencia absoluta de -0,5467 punto porcentual
- diferencia relativa de -11,20 por ciento
- intervalo de confianza de 95 por ciento de -0,8821 a -0,2112 punto porcentual
- resultado significativo, ganador: A
Un valor p de 0,001404 en un test donde las dos variaciones son idénticas. Nada fue cambiado. Ningún código fue desplegado. La conclusión que sale de ese panel, si nadie sabe lo que pasó antes, es que la variación derrumbó la conversión en 11 por ciento.
Corra usted mismo los números en la calculadora de abajo:
Test z bilateral de dos proporciones. "Sin significancia" casi siempre significa que falta muestra, no que las versiones sean iguales.
El SRM no detecta esto
La verificación de proporción de muestra es la defensa estándar contra un sorteo roto, y es una buena defensa: ver SRM y reparto desigual de tráfico. Simplemente no es la defensa para este problema.
Corriendo el test de chi cuadrado sobre el reparto del ejemplo de arriba:
| verificación | resultado |
|---|---|
| visitantes en A | 30.000 |
| visitantes en B | 30.000 |
| reparto esperado | 50/50 |
| estadístico de chi cuadrado | 0,0000 |
| valor p del SRM | 1,0000 |
| desvío detectado | no |
El sorteo está perfecto. El conteo está perfecto. El problema no es cuántos usuarios cayeron en cada brazo, es cuáles. Ningún verificador de proporción ve eso, porque la información que delata el arrastre no está en los conteos del test actual, está en el historial de quién estuvo dónde en el test anterior.
Esa es la misma clase de trampa de Demasiado bueno para ser verdad y la ley de Twyman: un resultado demasiado fuerte en métricas que ni siquiera deberían haberse movido es señal de problema de medición, no de descubrimiento.
Qué pasa con un test que sí tiene efecto de verdad
El caso del A/A es didáctico, pero el daño real aparece cuando existe un efecto genuino para medir y el arrastre lo distorsiona. Corrimos el mismo diseño con un efecto real de +4 por ciento relativo, es decir, +0,20 punto porcentual, 3.000 réplicas por línea:
| descanso | reusando: tasa de resultado significativo | lift medido promedio | re-sorteando: tasa significativa | lift medido promedio |
|---|---|---|---|---|
| 0 día | 63,33% | -0,4051 pp | 19,07% | +0,1931 pp |
| 7 días | 25,53% | -0,2274 pp | 21,33% | +0,2027 pp |
| 14 días | 8,57% | -0,0977 pp | 19,00% | +0,1950 pp |
| 21 días | 4,53% | -0,0167 pp | 20,53% | +0,1981 pp |
| 28 días | 6,10% | +0,0516 pp | 20,83% | +0,2015 pp |
| 60 días | 16,27% | +0,1698 pp | 19,23% | +0,1946 pp |
Lea la columna del lift medido con atención. El efecto real es de +0,20 punto porcentual. Con descanso cero y buckets reusados, el test mide -0,4051, es decir, signo cambiado. Y el 63,33 por ciento de resultados significativos no son victorias: son condenas. En casi dos tercios de las réplicas, una variación que de hecho mejora la conversión es declarada perdedora con significancia estadística.
Note también la línea de 21 días, donde la tasa de significancia cae a 4,53 por ciento. No es una buena noticia: es el punto en que el residuo negativo cancela casi exactamente el efecto positivo real, y el test concluye empate sobre una mejora que existe. El arrastre no empuja el resultado siempre hacia un lado, empuja hacia el lado del test anterior.
La columna del re-sorteo, en contraste, mide entre +0,1931 y +0,2027 punto porcentual en todos los intervalos, con el efecto real de +0,2000 en medio del rango.
La corrección: re-aleatorización localizada
La causa raíz, en la formulación de los autores de Bing, es directa: el sistema de buckets no re-sortea en cada experimento. Depende de una reasignación infrecuente de los buckets, y entre una reasignación y otra la asignación queda constante por un período relativamente largo.
Cambiar la función de hash resuelve, pero tiene un costo operativo pesado: el sistema de buckets acopla todos los experimentos de una misma línea, así que cambiar la función exige detener todos los experimentos de esa línea, lo que lastima capacidad y agilidad.
La alternativa que ellos describen es un sistema de buckets en dos niveles:
- El nivel de arriba define qué unidades entran en el experimento.
- La asignación de tratamiento ocurre en el nivel de abajo, con una semilla de hash distinta para cada experimento.
Eso garantiza un sorteo por experimento, de modo que la asignación de tratamiento queda independiente de cualquier evento histórico, incluido el arrastre de experimentos anteriores.
El costo declarado por ellos es uno solo, y es importante: no se puede usar un control compartido. Cada experimento necesita su propio control, para que cualquier residuo de un experimento anterior quede mezclado entre control y tratamiento en vez de concentrado en un lado.
A cambio viene un beneficio que compensa bien. Con re-aleatorización localizada, se puede correr un test A/A retrospectivo sin gastar tiempo de calendario: usted cambia la función de hash y reevalúa los últimos días antes del experimento como si fueran un A/A. Por la propiedad de independencia de la re-aleatorización localizada, comparar retrospectivamente a los usuarios que habrían sido asignados a control y tratamiento en cualquier período anterior al experimento es un A/A legítimo. Si ese A/A muestra efecto en las métricas principales, con valor p por debajo de 0,2 por ejemplo, por culpa de un reparto con mala suerte, se cambia la clave de hash y se intenta de nuevo, antes de gastar un día de tráfico.
Qué hacer si usted no controla la plataforma
No todo equipo puede reescribir el sistema de asignación de la herramienta que usa. Lo que queda, en orden de preferencia:
- Verifique si su herramienta ya re-sortea por experimento. Muchas herramientas modernas hacen el hash con una combinación de identificador del usuario e identificador del experimento, que es exactamente la re-aleatorización localizada. Si es el caso, el problema no existe para usted y vale confirmarlo por escrito, no por suposición.
- Corra un A/A retrospectivo antes de cada test. Tome los días anteriores, aplique el reparto que el test nuevo va a usar y verifique si las métricas principales empatan. Es el test que habría detectado el caso de 93,30 por ciento en el primer intento.
- Trate un valor p por debajo de 0,2 en el A/A como señal amarilla, no como aprobación. El criterio es de los propios autores de Bing y es deliberadamente laxo, porque el costo de una falsa alarma aquí es cambiar una clave de hash, y el costo de dejarlo pasar es un trimestre de decisión equivocada.
- Registre en el reporte qué experimento corrió antes en esos buckets. Sin ese registro, nadie logra siquiera levantar la hipótesis de arrastre cuando el resultado salga raro.
- Desconfíe de métricas que se movieron sin motivo. Si el cambio fue en el pie de página y la métrica de búsqueda se movió con significancia alta, la hipótesis principal no es un descubrimiento.
- El descanso es el último recurso, y usted necesita dimensionarlo. En nuestra simulación, 21 días todavía dejaban 23,10 por ciento de falso positivo. Si va a esperar, espere de verdad y mida con un A/A antes de volver a testear.
Hágalo automático con Donnu
El arrastre es un problema de arquitectura de sorteo, no de análisis. En Donnu la asignación de cada experimento sale de un hash que combina el identificador del usuario con el identificador de ese experimento, así que dos tests seguidos nunca heredan el mismo reparto: quien fue tratado ayer se esparce entre control y variación hoy. El panel también guarda qué experimentos corrieron antes sobre la misma población, para que la hipótesis de arrastre sea lo primero que alguien logre revisar cuando una métrica no relacionada se mueva. Si su herramienta actual sortea al usuario una vez y reaprovecha el reparto, ese es el ítem que necesita cambiar antes de que cualquier refinamiento estadístico valga algo.
Preguntas frecuentes
Las respuestas cortas están en la sección de preguntas frecuentes de esta página, generadas a partir del mismo material medido aquí.
Referencias
- Ron Kohavi, Alex Deng, Brian Frasca, Roger Longbotham, Toby Walker y Ya Xu. Trustworthy Online Controlled Experiments: Five Puzzling Outcomes Explained, KDD 2012. Trae la sección sobre efecto de arrastre: la descripción del sistema de buckets, el caso en que métricas no relacionadas se movieron con significancia alta y desaparecieron en una muestra mayor, el residuo que muere alrededor de la tercera semana en un caso y no desaparece en tres meses en el otro, la re-aleatorización localizada por sistema de buckets en dos niveles, el costo del control no compartido y el test A/A retrospectivo con el criterio de valor p por debajo de 0,2.
- Ron Kohavi, Alex Deng, Brian Frasca, Toby Walker, Ya Xu y Nils Pohlmann. Online Controlled Experiments at Large Scale, KDD 2013. Describe la arquitectura de experimentación de Bing, incluyendo la línea numérica de asignación ortogonal (equivalente a las capas de Google), el aislamiento que garantiza un único experimento por línea, y la asignación por hash pseudoaleatorio de identificador anónimo hecha ya en la llegada de la solicitud.
- Ron Kohavi, Alex Deng, Roger Longbotham y Ya Xu. Seven Rules of Thumb for Web Site Experimenters, KDD 2014. Contexto sobre por qué el piso de muestra en experimentación online es mayor de lo que sugieren los manuales, con la regla de 355 veces el cuadrado del coeficiente de asimetría por variación, recomendada cuando el módulo de la asimetría pasa de 1.
Lee también
Preguntas frecuentes
- ¿Qué es el efecto de arrastre entre tests A/B?
- Es cuando los mismos usuarios que fueron afectados por el primer experimento son reaprovechados en el experimento siguiente, y el residuo del primero contamina la lectura del segundo. El término viene del sistema de buckets usado por las plataformas grandes: los usuarios son sorteados una vez en buckets, y son los buckets los que van siendo asignados de experimento en experimento. Como el sorteo no se repite en cada test, quien estuvo en el tratamiento ayer tiende a estar en el tratamiento de nuevo hoy, cargando consigo todo lo que el test anterior hizo con él.
- ¿Cuánto tiempo dura el efecto de arrastre?
- Más de lo que sugiere la intuición. Kohavi y coautores registran dos casos en Bing: en uno de ellos, un experimento de 47 días dejó un residuo medible en los mismos buckets por cerca de tres semanas después de apagado; en el otro, un bug que expuso a los usuarios a una experiencia muy mala dejó los buckets sin volver a los niveles anteriores incluso después de tres meses. En la simulación de este artículo, con vida media de 14 días, la tasa de falso positivo de un test A/A solo volvió al nivel nominal de 5 por ciento después de 60 días de descanso.
- ¿El test A/A detecta el efecto de arrastre?
- Lo detecta, y es la principal defensa disponible cuando usted no puede re-sortear. En nuestra simulación, un test A/A corrido inmediatamente después de un experimento que dejó el tratamiento 0,60 punto porcentual abajo acusó resultado significativo en 93,30 por ciento de las réplicas, contra el 5 por ciento esperado. Un único A/A de esos devolvió 4,8800 por ciento contra 4,3333 por ciento, con valor p de 0,001404 e intervalo de confianza de menos 0,8821 a menos 0,2112 punto porcentual: un resultado fuerte y completamente falso.
- ¿La verificación de SRM no detecta ese problema?
- No, y esa es la parte peligrosa. El SRM busca desvío en la PROPORCIÓN de usuarios entre los brazos, y en el efecto de arrastre el reparto está perfecto. En nuestro ejemplo trabajado, los dos brazos recibieron exactamente 30.000 usuarios y el test de chi cuadrado devolvió estadístico 0,0000 y valor p 1,0000. El sorteo está bien, el conteo está bien, y aun así la lectura está mal. Ningún verificador de proporción va a levantar la mano aquí.
- ¿Cuál es la corrección definitiva del efecto de arrastre?
- Re-sortear los usuarios en cada experimento, lo que Kohavi y coautores llaman re-aleatorización localizada. La implementación que describen es un sistema de buckets en dos niveles, en el que el primer nivel define quién entra en el experimento y el segundo hace la asignación de tratamiento con una semilla de hash distinta por experimento. En nuestra simulación, con re-sorteo la tasa de falso positivo quedó entre 4,47 y 6,00 por ciento en todos los intervalos de descanso probados, incluido el descanso cero.
- ¿Cuál es el costo de re-sortear en cada experimento?
- Usted pierde el control compartido. Kohavi y coautores registran esa desventaja de forma explícita: con re-aleatorización por experimento, cada experimento necesita su propio control, para que cualquier residuo del experimento anterior quede mezclado por igual entre control y tratamiento. A cambio aparece una ganancia que compensa bien: se puede correr un test A/A retrospectivo sin gastar tiempo de calendario, reevaluando los últimos días antes del experimento como si fueran un A/A. Si ese A/A acusa efecto en las métricas principales, con valor p por debajo de 0,2 por ejemplo, se cambia la clave de hash y se intenta de nuevo.