Tests Simultáneos: cuándo importa el efecto de interacción
Por qué correr tests A/B simultáneos suele ser seguro, cómo es un efecto de interacción real y el bug de asignación bastante más probable que él.

📚 Este artículo es parte de la guía Significancia Estadística en Tests A/B: La Guía.
Correr tests A/B simultáneos sobre los mismos usuarios es el estado normal de un programa de experimentación que funciona, no una concesión. La premisa que lo hace válido es que cada experimento puede analizarse aisladamente, lo que vale mientras las asignaciones sean independientes y los tratamientos no interactúen, y la forma bastante más común de que esa premisa caiga es un defecto de aleatorización, no una interacción genuina. Esta guía cubre qué es de hecho un efecto de interacción, por qué la experiencia publicada por grandes plataformas es que son raros, los bugs de asignación que se disfrazan de interacción, y un ejemplo trabajado 2x2 que muestra por qué “ninguna interacción significativa” normalmente quiere decir que el test jamás habría podido encontrar una. Forma parte de nuestra guía completa de test A/B y conversa con testear varias variantes.
Superponer es lo normal, no la excepción
En cualquier volumen relevante, el aislamiento deja de ser asequible. Kohavi y colegas, describiendo el sistema de experimentación de Bing para el KDD 2013, reportan más de 200 experimentos simultáneos corriendo en un día cualquiera, y plantean la combinatoria de forma cruda: con cinco variantes en cada una de quince áreas de experimentación simultáneas, números que ellos mismos llaman conservadores, los usuarios acaban en una de cinco elevado a quince, algo cercano a 30 mil millones de variantes posibles de Bing. Nadie valida 30 mil millones de configuraciones. El sistema tiene que construirse de forma que validarlas sea innecesario.
La respuesta de Google, descrita por Tang, Agarwal, O’Brien y Meyer para el KDD 2010, es una infraestructura en capas con tres conceptos: un dominio es una segmentación de tráfico, una capa corresponde a un subconjunto de los parámetros del sistema, y un experimento es una segmentación de tráfico en que ciertos parámetros reciben valores alternativos. Los parámetros que no pueden variar de forma independiente entre sí van a la misma capa, los experimentos dentro de una capa son mutuamente exclusivos, y el desvío de tráfico para experimentos en capas distintas es ortogonal. Una petición pasa por un experimento por capa.
El ejemplo que motiva su diseño es el argumento más corto que existe sobre por qué las capas existen: con un parámetro para el color de fondo de la página y otro para el color del texto, azul es un valor válido para los dos, y si los dos son azules al mismo tiempo la página queda ilegible. Eso es una interacción de verdad, y ninguna cantidad de estadística lo arregla. Se evita por construcción.
Qué es, de hecho, un efecto de interacción
Kohavi y colegas lo definen con precisión: existe interacción estadística entre dos tratamientos A y B si el efecto combinado de los dos no es igual a la suma de los dos efectos individuales. Y acto seguido nombran por qué eso importa, en una frase que es la razón entera de que este tema exista: la existencia de interacción viola la premisa básica usada para escalar la experimentación, la de que cada experimento puede analizarse aisladamente.
Listan tres daños. Las interacciones pueden perjudicar a los usuarios, porque combinaciones específicas disparan bugs inesperados. Distorsionan resultados de todos los experimentos involucrados, lo que pesa más cuando el efecto real del tratamiento es pequeño, ya que entonces una interacción pequeña logra producir resultados completamente engañosos en una métrica clave. Y no pueden evitarse por completo con tests y comprobaciones offline, porque equipos distintos no saben qué están subiendo los otros equipos.
Ese es el argumento para tomarse la interacción en serio. Aquí va el argumento para no entrar en pánico con ella, del mismo artículo: en nuestra experiencia, las interacciones son relativamente raras y con más frecuencia representan bugs que interacciones estadísticas verdaderas. Siguen prefiriendo la asignación ortogonal, equivalente a un factorial completo, y corren tests multivariados pequeños solo cuando hay interacción sospechada o detectada. El estudio de 2009 del mismo grupo hace un argumento vecino: en el mundo online, la disponibilidad de usuarios y la agilidad del test continuo hacen preferibles los tests univariados simultáneos frente a los diseños multivariados tradicionales, cuyos arreglos fraccionarios y de Plackett-Burman confunden interacciones de dos factores con efectos principales de todos modos.
La lectura operativa es un orden de prioridad: cuando la celda combinada parece equivocada, busca un bug antes de buscar una interacción.
El fallo bastante más probable que una interacción
La independencia de asignación es una suposición, y es una suposición que los esquemas de hash rompen en silencio. Kohavi, Longbotham, Sommerfield y Henne lo testearon directamente en 2009. Su montaje hashea la concatenación de un identificador de usuario con un identificador de experimento y después particiona el rango. Corrieron cinco experimentos simulados contra un millón de ids secuenciales de usuario y aplicaron tests chi cuadrado buscando correlación entre experimentos. Los resultados:
| Función de hash | Resultado de los tests de correlación |
|---|---|
| MD5 | No generó correlación alguna entre experimentos |
| SHA256 | Estuvo cerca, exigiendo una interacción de cinco vías para producir correlación |
| El algoritmo de hash de string incorporado en .NET | Falló incluso en un test de interacción de dos vías |
Y aquí viene el fallo que vale memorizar, porque es una optimización que cualquier ingeniero competente podría intentar. MD5 es caro, así que un sistema intentó usar caché: hashea el nombre del experimento una vez, hashea el id del usuario una vez, guarda los dos y aplica XOR entre ellos al asignar. El artículo reporta la consecuencia exacta. Con dos experimentos al 50/50, si el bit más significativo de los hashes de los dos nombres de experimento coincidía, los usuarios siempre recibirían la misma asignación en los dos experimentos; si no coincidía, los usuarios recibirían exactamente la asignación opuesta. De una forma u otra las asignaciones quedan perfectamente correlacionadas y los resultados de los dos experimentos quedan confundidos.
Nada de eso aparece como número extraño en ninguno de los dos experimentos leído por separado. Los dos parecen normales. Fabijan y colegas (KDD 2019) listan la misma propiedad como la tercera exigencia de un servicio de asignación, junto a probabilidad igual y consistencia entre visitas repetidas: cuando varios experimentos corren, no puede existir correlación entre experimentos. La manera de encontrar una violación es buscarla, que es el argumento a favor de un experimento de validación permanentemente en el aire, cubierto en test A/A, y de las comprobaciones de reparto en SRM, el reparto desigual de tráfico.
Ejemplo trabajado: un factorial 2x2, y por qué la interacción no dice nada
Dos equipos suben al mismo tiempo en el mismo flujo de checkout. El experimento A cambia el aviso de coste de envío. El experimento B cambia el botón de pago. La asignación es independiente, así que los usuarios caen en cuatro celdas de 50.000 cada una, a una tasa base de conversión del 4 por ciento. Pega las celdas en la calculadora conforme vayas leyendo:
Test z bilateral de dos proporciones. "Sin significancia" casi siempre significa que falta muestra, no que las versiones sean iguales.
| Celda | Usuarios | Conversiones | Tasa |
|---|---|---|---|
| Ninguno de los cambios | 50.000 | 2.000 | 4,000 por ciento |
| Solo A | 50.000 | 2.120 | 4,240 por ciento |
| Solo B | 50.000 | 2.090 | 4,180 por ciento |
| A y B juntos | 50.000 | 2.215 | 4,430 por ciento |
Efecto principal de A. Colapsando sobre B: 4.090 conversiones en 100.000 sin A contra 4.335 en 100.000 con A. Eso es 4,090 por ciento contra 4,335 por ciento, más 0,245 punto porcentual, más 5,99 por ciento relativo, z = 2,73, valor-p 0,0064, intervalo de más 0,069 a más 0,421 punto porcentual.
Efecto principal de B. Colapsando sobre A: 4.120 contra 4.305 en 100.000 cada uno, es decir 4,120 por ciento contra 4,305 por ciento, más 0,185 punto porcentual, más 4,49 por ciento relativo, z = 2,06, valor-p 0,0395, intervalo de más 0,009 a más 0,361 punto porcentual.
La interacción. El efecto de A cuando B está apagado es 4,240 menos 4,000, es decir más 0,240 punto porcentual. El efecto de A cuando B está encendido es 4,430 menos 4,180, es decir más 0,250 punto porcentual. La interacción es la diferencia de esas diferencias: más 0,010 punto porcentual. Su error estándar es la raíz cuadrada de la suma de las cuatro varianzas de celda, lo que da 0,1797 punto porcentual, resultando en z = 0,06, valor-p 0,9556, intervalo de menos 0,342 a más 0,362 punto porcentual.
Leído al pie de la letra, eso dice que no hay interacción. Leído con honestidad, dice algo más débil y mucho más útil. El error estándar de la interacción es exactamente el doble del error estándar de un efecto principal, que es el resultado general para una diferencia de diferencias y la razón de que una interacción de un tamaño dado exija alrededor de cuatro veces la muestra de un efecto principal de ese tamaño. En este diseño, la menor interacción detectable al 80 por ciento de potencia es 0,491 punto porcentual, algo cercano al 12,3 por ciento relativo, mientras que los efectos principales se resuelven hasta alrededor de 0,246 punto porcentual.
Así que la frase correcta en el informe no es “no hay interacción entre A y B”. Es “ninguna interacción mayor que alrededor de medio punto porcentual era detectable en esta muestra, y la distancia observada es de 0,01”. Como cada efecto principal es menor que la interacción que el test lograría ver, una interacción lo bastante grande como para cambiar cualquiera de las dos decisiones habría aparecido. Ese es el argumento que de hecho autoriza subir los dos, y es un argumento de potencia, no de valor-p. La misma disciplina de lectura vale para cualquier resultado no concluyente, como cubrimos en efecto mínimo detectable.
Testear todos los pares no escala, y Bing lo dice
Si decides comprobar la interacción en todos los pares de experimentos en curso, el conteo de pares crece de forma cuadrática y los falsos positivos crecen con él:
| Experimentos simultáneos | Pares a testear | Probabilidad de que al menos un par parezca interactivo por azar, al 5 por ciento |
|---|---|---|
| 2 | 1 | 5,0 por ciento |
| 4 | 6 | 26,5 por ciento |
| 6 | 15 | 53,7 por ciento |
| 10 | 45 | 90,1 por ciento |
| 15 | 105 | 99,5 por ciento |
| 20 | 190 | 99,99 por ciento |
Kohavi y colegas plantean el problema exactamente en esos términos: si estamos corriendo N experimentos a la vez, la complejidad de detectar interacciones par a par es cuadrática en N, y por causa de la escala su sistema necesita a veces correr cientos de miles de tests de hipótesis. Su respuesta no es dejar de testear, sino controlar la tasa de error, usando un algoritmo bayesiano empírico de tasa de descubrimiento falso para identificar los casos con más probabilidad de ser verdaderos positivos, tras lo cual la herramienta corre un diagnóstico más profundo y alerta a los dueños del experimento.
Para un equipo que corre un puñado de experimentos en vez de cientos, la versión práctica es más simple: no barras interacciones par a par por defecto. Comprueba un par específico cuando haya motivo, y si vas a comprobar muchos, aplica corrección, la misma aritmética cubierta en testear varias variantes.
Decidiendo qué aislar
| Situación | Superponer o aislar | Por qué |
|---|---|---|
| Dos cambios en superficies sin relación, por ejemplo checkout y onboarding | Superponer | La premisa de independencia es plausible y el tráfico vale más en otro lado |
| Dos cambios en el mismo elemento o en el mismo parámetro de configuración | Aislar | Es el caso del color de fondo con el color del texto; la combinación puede estar rota por construcción |
| Dos cambios en la misma página, en elementos distintos | Superponer, pero declarar el par como uno a comprobar después | Las interacciones son raras, pero es aquí donde se concentran |
| Un cambio que altera quién es elegible para el otro experimento | Aislar | La elegibilidad se vuelve variable post-tratamiento y las dos lecturas quedan comprometidas |
| Cualesquiera dos experimentos cuyo estado combinado nunca fue construido ni revisado | Aislar hasta revisar | La interacción real más común es un bug en una combinación no testeada |
| Un cambio de precio o de cobro junto con cualquier cosa | Aislar | Los estados combinados aquí son caros de equivocar y difíciles de revertir |
La prevención le gana a la detección, y los mecanismos usados a escala vale la pena copiarlos a escala pequeña. Bing, según el artículo de 2013, hace que cada experimento declare un conjunto de restricciones para que el sistema se niegue a correr experimentos conflictivos juntos, por ejemplo garantizando que un usuario nunca esté en dos experimentos de aspecto de anuncio al mismo tiempo; usa gestión de configuración para detectar experimentos que intentan cambiar el mismo parámetro antes del lanzamiento; y, cuando las interacciones no pueden evitarse, usa mapeos para excluir a los usuarios de un experimento del otro. Las capas de lanzamiento y los dominios anidados de Google, según el artículo de 2010, son la misma idea expresada como infraestructura.
Errores comunes con tests simultáneos
| Error | Qué produce |
|---|---|
| Reusar un único hash del id del usuario en todos los experimentos | Todo experimento recibe el mismo reparto de usuarios, y todos quedan confundidos |
| Guardar hashes en caché y combinarlos con XOR | Asignación perfectamente correlacionada o perfectamente opuesta, según el estudio de 2009 |
| Leer “ninguna interacción significativa” como “ninguna interacción” | Una conclusión que el diseño tenía algo cercano a una moneda de probabilidad de sostener |
| Barrer todos los pares buscando interacción sin control de multiplicidad | Con diez experimentos, alrededor del 90 por ciento de probabilidad de tener una interacción falsa que perseguir |
| Serializar todo experimento para evitar la interacción | El riesgo más raro evitado al coste del rendimiento del programa entero |
| Correr dos experimentos en el mismo elemento y leer los dos como limpios | La única configuración en que las interacciones de hecho se concentran |
| Tratar una interacción sospechosa como estadística antes de comprobar si es bug | Contradice la experiencia publicada de que las interacciones con más frecuencia representan bugs |
| Dejar que un experimento cambie la elegibilidad para otro | Selección post-tratamiento, de la que ningún análisis se recupera |
Hazlo automático con Donnu
Los tests simultáneos son seguros cuando la plataforma hace las asignaciones independientes y avisa cuando dejan de serlo. Donnu A/B condimenta el hash de asignación con el identificador del experimento, así que dos experimentos nunca heredan el reparto uno del otro, corre la comprobación de proporción de muestra en todo experimento y no solo en aquel que estás mirando, y permite declarar un experimento mutuamente exclusivo con otro cuando la combinación no debería existir. La superposición sigue siendo lo normal, porque es lo que permite a un equipo pequeño correr más de un test a la vez, y el aislamiento queda disponible para los pares específicos que lo necesitan.
Empieza una prueba gratis de 14 días y corre tus próximos dos experimentos al mismo tiempo sin andar adivinando si chocan.
Referencias
- Kohavi, R., Deng, A., Frasca, B., Walker, T., Xu, Y. y Pohlmann, N. Online Controlled Experiments at Large Scale. KDD 2013. Fuente de los más de 200 experimentos simultáneos en Bing y del número de cinco elevado a quince, de la definición de interacción estadística y de los tres daños que causa, de la afirmación de que las interacciones son relativamente raras y con más frecuencia representan bugs que interacciones estadísticas verdaderas, de los mecanismos de prevención por restricción, gestión de configuración y mapeo, y del problema cuadrático de detección par a par tratado con un algoritmo bayesiano empírico de tasa de descubrimiento falso. exp-platform.com.
- 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 del método de hash y partición, de los tests chi cuadrado sobre cinco experimentos simulados y un millón de ids secuenciales de usuario en que solo MD5 no produjo correlación mientras que SHA256 exigió una interacción de cinco vías y el hash de string de .NET falló en un test de dos vías, del atajo de caché con XOR que produce asignaciones idénticas o exactamente opuestas, y del argumento a favor de tests univariados simultáneos en vez de diseños multivariados tradicionales. exp-platform.com.
- Tang, D., Agarwal, A., O’Brien, D. y Meyer, M. Overlapping Experiment Infrastructure: More, Better, Faster Experimentation. KDD 2010. Fuente de las definiciones de dominio, capa y experimento, de la regla de que los parámetros que no pueden variar de forma independiente comparten una capa mientras que el desvío entre capas es ortogonal, de las capas de lanzamiento, y del ejemplo del color de fondo con el color del texto como combinación que se rompe por construcción. static.googleusercontent.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 de las tres exigencias de un servicio de asignación, incluida la de que no puede haber correlación entre experimentos cuando varios corren al mismo tiempo. 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 plataformas de experimentación, experimentos simultáneos y aleatorización. Material complementario en experimentguide.com.
Lee también: Test A/A · Testear varias variantes · SRM: reparto desigual de tráfico · Efecto mínimo detectable · Calculadora de significancia A/B/n gratis · Leia em português
Preguntas frecuentes
- ¿Puedo correr varios tests A/B al mismo tiempo sobre los mismos usuarios?
- Puedes, y a cualquier escala real no tienes elección. Kohavi y colegas (KDD 2013) describen más de 200 experimentos simultáneos corriendo en Bing en un día cualquiera, con usuarios cayendo en una de alrededor de 30 mil millones de variantes posibles del sitio. La exigencia no es aislamiento, es aleatorización independiente: la asignación de un usuario en un experimento no puede alterar la probabilidad de su asignación en otro. Con eso en pie, cada experimento puede analizarse por separado.
- ¿Qué es un efecto de interacción entre dos experimentos?
- Existe interacción estadística entre los tratamientos A y B cuando el efecto combinado de los dos no es igual a la suma de los dos efectos individuales, como definen Kohavi y colegas (KDD 2013). En la versión simple: si A da más 0,24 punto solo y B da más 0,18 solo, la aditividad predice más 0,42 cuando los dos corren juntos. La interacción es la distancia entre esa predicción y lo que la celda combinada muestra de hecho. El problema es que esa distancia viola la premisa que permite analizar cada experimento aisladamente.
- ¿El efecto de interacción es común en la práctica?
- Es raro. Kohavi y colegas (KDD 2013), escribiendo desde una plataforma que corre cientos de experimentos por día, afirman que en su experiencia las interacciones son relativamente raras y con más frecuencia representan bugs que interacciones estadísticas verdaderas. Por eso siguen prefiriendo la asignación ortogonal, equivalente a un factorial completo, antes que el test multivariado. La consecuencia práctica es directa: una interacción sospechosa debe investigarse primero como defecto y solo después como estadística.
- ¿Cuánta muestra necesito para detectar una interacción?
- Alrededor de cuatro veces lo que necesitas para un efecto principal del mismo tamaño, porque la interacción es una diferencia de diferencias y su error estándar es aproximadamente el doble. En un diseño 2x2 con 50.000 usuarios por celda a una tasa base del 4 por ciento, un efecto principal se resuelve hasta alrededor de 0,25 punto porcentual al 80 por ciento de potencia, mientras que la interacción solo se resuelve hasta alrededor de 0,50. Es decir, la mayoría de los tests que reportan ninguna interacción significativa nunca tuvo potencia para encontrar una, y la frase honesta es que ninguna interacción mayor que X fue detectada.
- ¿Qué se rompe de verdad cuando los experimentos se superponen?
- Correlación de asignación, bastante más a menudo que una interacción genuina. Kohavi y colegas (2009) testearon cinco experimentos simulados contra un millón de ids secuenciales de usuario y encontraron que solo MD5 no produjo correlación entre experimentos, mientras que el hash de string incorporado en .NET falló incluso en un test de dos vías. También documentan un atajo de caché que aplicaba XOR entre el hash del experimento y el hash del usuario, lo que hacía que los usuarios cayeran en asignaciones idénticas o exactamente opuestas en los dos experimentos según un solo bit. Los dos experimentos quedan confundidos y ninguno de los dos es legible.
- ¿Cuándo deben ser mutuamente exclusivos dos experimentos?
- Cuando la combinación puede producir una experiencia rota o nociva, cuando dos cambios tocan la misma superficie o el mismo parámetro de configuración, o cuando existe sospecha concreta de interacción. Tang y colegas (KDD 2010) dan la ilustración más limpia: con un parámetro para el color de fondo de la página y otro para el color del texto, azul es un valor válido para cada uno y un desastre para los dos al mismo tiempo. Su respuesta es agrupar en una misma capa los parámetros que no pueden variar de forma independiente, de modo que los experimentos dentro de una capa sean exclusivos y las capas distintas se superpongan libremente.
- ¿Debo testear la interacción entre todos los pares de experimentos que corren?
- Solo con control de multiplicidad, porque el conteo de pares crece de forma cuadrática. Diez experimentos simultáneos forman 45 pares, lo que a un umbral del 5 por ciento da alrededor del 90 por ciento de probabilidad de que al menos un par parezca interactivo solo por azar. Kohavi y colegas (KDD 2013) describen monitorear todos los experimentos en curso buscando interacciones par a par, a veces corriendo cientos de miles de tests de hipótesis, y usar un algoritmo bayesiano empírico de tasa de descubrimiento falso para contener los falsos positivos.