SRM: reparto desigual de tráfico en test A/B
Qué es el SRM, cómo funciona la prueba chi cuadrado, qué desvío tan pequeño ya invalida el test A/B y cómo encontrar la causa raíz.
📚 Este artículo es parte de la guía Significancia Estadística en Tests A/B: La Guía.
El SRM es una diferencia estadísticamente significativa entre el reparto de tráfico que configuraste y el que realmente ocurrió, y es la verificación que decide si el resto de tu análisis significa algo. Si un test 50/50 termina en 50,6 contra 49,4, eso no es un detalle de redondeo. Es evidencia de que algo decidió dónde cayó cada visitante, y en el momento en que algo más allá del aleatorizador está eligiendo, los dos grupos dejan de ser comparables y la diferencia de conversión entre ellos no es el efecto de tu cambio. Esta guía cubre qué es la verificación, qué desvío tan pequeño ya reprueba, cómo leer el resultado del chi cuadrado, de dónde vienen los desvíos y qué hacer cuando encuentras uno. Forma parte de nuestra guía completa de test A/B y es la otra mitad, junto a significancia estadística en test A/B, de un resultado confiable.
Qué significa el SRM de verdad
La aleatorización es el argumento entero de un test A/B. Es ella la que permite afirmar que la única diferencia sistemática entre control y variante es el cambio que subiste. El reparto de muestra es la evidencia observable más barata de que la aleatorización funcionó, porque ya sabes la respuesta de antemano: configuraste 50/50, esperas algo cerca de 50/50.
“Cerca de” está haciendo trabajo pesado en esa frase, y la prueba chi cuadrado de bondad de ajuste es lo que lo vuelve preciso. Hace una sola pregunta: si la asignación fuera realmente justa, ¿con qué frecuencia el azar por sí solo produciría una diferencia al menos de este tamaño? Cuando esa probabilidad cae por debajo del umbral de alarma, el azar deja de ser una explicación plausible.
La consecuencia es severa y vale decirla sin rodeos. Fabijan y colegas, escribiendo sobre experimentación en Microsoft, Booking.com, Outreach.io y Online Dialog, describen el SRM como una condición que en la mayoría de los casos invalida por completo el resultado del experimento. No es una salvedad al pie. Es una señal de alto.
Qué desvío tan pequeño ya reprueba
La parte incómoda del SRM es que la tolerancia se encoge a medida que el test crece. La diferencia absoluta que dispara la alarma crece más o menos con la raíz cuadrada de la muestra total, así que, como porcentaje del tráfico, se va apretando. Un reparto que describirías como “prácticamente igual” muchas veces ya es un SRM.
| Total de visitantes | Menor diferencia que dispara | Reparto resultante |
|---|---|---|
| 2.000 | 116 visitantes | 52,90 / 47,10 |
| 10.000 | 258 visitantes | 51,29 / 48,71 |
| 20.000 | 366 visitantes | 50,91 / 49,09 |
| 50.000 | 576 visitantes | 50,58 / 49,42 |
| 100.000 | 816 visitantes | 50,41 / 49,59 |
| 200.000 | 1.152 visitantes | 50,29 / 49,71 |
Números calculados con la misma prueba chi cuadrado de bondad de ajuste que usa la calculadora de abajo, con umbral de alarma del 1% y reparto esperado de 50/50. La columna del medio es la diferencia entre las dos ramas.
Lee la última fila otra vez. Con 200.000 visitantes, un reparto de 50,29 contra 49,71 es SRM. Ningún ser humano mirando un panel marcaría eso. Ese es el motivo entero de que la verificación tenga que ser automática y numérica, y no una mirada.
Completa al menos dos variaciones. La asignación esperada es el peso relativo del split (1 y 1 = 50/50, 9 y 1 = 90/10).
| Variación | Visitantes observados | Esperado | % real |
|---|
Test de chi-cuadrado de bondad de ajuste entre la división observada y la esperada. Da la alarma cuando el valor-p cae por debajo de 0,01: con ese split, una diferencia así es demasiado rara para ser azar. El SRM invalida el test, revisa el motor de asignación antes de leer la conversión.
Leyendo el chi cuadrado sin ceremonia
El estadístico es lo bastante simple para calcularlo a mano, y vale hacerlo una vez para que el número deje de parecer una caja negra. Para cada grupo tomas la distancia al cuadrado entre observado y esperado, la divides por el esperado, y sumas todo.
Con 48.005 visitantes en total y reparto configurado en 50/50, cada grupo esperaba recibir 24.002,5. El control recibió 24.301, la variante recibió 23.704, así que cada uno está a 298,5 de su expectativa.
chi cuadrado = (24.301 - 24.002,5)^2 / 24.002,5
+ (23.704 - 24.002,5)^2 / 24.002,5
= 89.102,25 / 24.002,5 x 2
= 7,42 (1 grado de libertad)
valor p = 0,0064El grado de libertad es el número de grupos menos uno, así que un test de dos ramas tiene uno. El valor p responde a la única pregunta que importa: una moneda honesta produciría una diferencia de este tamaño o mayor cerca de 6 veces en 1.000. No es imposible, pero es una mala apuesta cuando la explicación alternativa es un bug que puedes ir a buscar.
Dos observaciones que evitan discusión. Primera: el umbral del SRM es deliberadamente más rígido que el 0,05 que usas para conversión, porque cada test que corres es una oportunidad más de disparar una falsa alarma, y el coste de investigar una es de algunas horas mientras que el coste de dejar pasar una es una decisión equivocada. Un umbral del 1% es un estándar de trabajo común y es el que usa la calculadora de arriba. Segunda: el valor p del SRM no mide el tamaño del sesgo. Solo dice cuánto puedes confiar en que el desequilibrio es real. Un sesgo sistemático minúsculo y real en un test enorme produce un valor p aterrador y quizá apenas mueva tu métrica, mientras que un sesgo grande en un test pequeño puede pasar rozando. Úsalo como disparador de investigación, nunca como nota de gravedad.
Ejemplo trabajado: la ganadora que no existía
Un equipo de e-commerce testea un checkout reconstruido. El test se configura 50/50 y corre hasta 48.005 visitantes. Este es el marcador que llevan a la reunión.
- Control: 24.301 visitantes, 1.094 compras, 4,502%
- Variante: 23.704 visitantes, 1.156 compras, 4,877%
Corre esos números y obtienes z = 1,943, valor p = 0,0520, mejora relativa de +8,33% e intervalo de confianza sobre la diferencia de -0,003 a +0,753 puntos porcentuales. Fuera de la significancia por poco, en dirección positiva, y lo bastante grande para importar comercialmente. El instinto de la sala es correr dos días más.
Test z bilateral de dos proporciones. "Sin significancia" casi siempre significa que falta muestra, no que las versiones sean iguales.
El instinto está equivocado, y no por el valor p. El reparto es 50,62 / 49,38, que, como calculamos arriba, es SRM con p = 0,0064. Los 597 visitantes que nunca llegaron a la variante son la historia, y nadie en la sala sabe quiénes eran.
He aquí por qué reequilibrar no salva esto. Supongamos que preguntamos cuál habría sido el resultado si esos 597 visitantes hubieran aparecido. Dos escenarios honestos de contorno:
Si se hubieran comportado exactamente como el control y convertido al 4,502%, la variante mostraría 24.301 visitantes y cerca de 1.183 compras. Resultado: p = 0,0561, ganancia +8,14%, intervalo de -0,009 a +0,742 puntos porcentuales.
Si fueran visitantes que no lograron completar y hubieran convertido a cero, la variante mostraría 24.301 visitantes y 1.156 compras, una tasa de 4,757%. Resultado: p = 0,1808, ganancia +5,67%, intervalo de -0,118 a +0,629 puntos porcentuales.
El resultado observado queda entre “casi ahí” y “claramente nada”, y los datos no consiguen decir cuál de los dos es. Esa es la definición de experimento inválido. En este caso la causa raíz era una redirección que agotaba el tiempo en conexiones móviles lentas, lo que significa que el segundo escenario está más cerca de la verdad: los visitantes que desaparecieron eran desproporcionadamente los menos propensos a comprar, y su ausencia infló la tasa de la variante. Después de corregir la redirección y correr de nuevo, el reparto volvió en 24.102 / 24.088 (chi cuadrado 0,004, p = 0,949) y el resultado fue 4,502% contra 4,583%: p = 0,6675, ganancia +1,81%, intervalo de -0,290 a +0,453 puntos porcentuales. Inconcluso, y honesto.
De dónde vienen los desvíos
La taxonomía del KDD 2019 es útil justamente porque organiza las causas por la etapa en la que aparecen, que es también cómo decides de quién es la corrección. El artículo identifica 25 causas distintas agrupadas en cinco etapas.
| Etapa | Qué sale mal | Síntoma típico |
|---|---|---|
| Asignación | El aleatorizador no es independiente: semilla compartida, bucket heredado de un test anterior, regla de exclusión que pilla una sola rama | Desvío presente desde la primera hora, estable en tamaño, visible en un test A/A |
| Ejecución | Una variante carga más despacio, una redirección falla, el flag llega tarde, la telemetría nunca dispara para parte de los usuarios | El desvío aparece solo en ciertos dispositivos o conexiones, y las métricas de rendimiento empeoran del mismo lado |
| Procesamiento de logs | Filtro de bots, deduplicación o un join que descarta filas de forma desigual entre las variantes | El desvío aparece en el data warehouse pero no en los logs crudos de asignación |
| Análisis | Disparo o filtro aplicado a un solo grupo, segmento definido después del hecho, recorte de fechas que corta una rama | Desvío presente en el informe filtrado y ausente en el informe completo |
| Interferencia | Otro experimento corriendo a la vez, con segmentación correlacionada con la tuya | El desvío aparece solo mientras el otro test está en el aire |
La distinción entre la etapa de análisis y las demás es la que más tiempo ahorra. Si el reparto está bien en la población completa y roto solo en tu vista filtrada, el experimento probablemente está sano y tu consulta no.
El orden de diagnóstico que encuentra más rápido
Fabijan y colegas publican diez reglas prácticas para estrechar la causa. Condensadas en el orden que resuelve la mayoría de los casos rápido:
- Compara el informe filtrado con el informe completo. Si el desvío solo existe en la vista filtrada, la condición de disparo está mal, no el experimento. Relaja el filtro por etapas hasta que desaparezca.
- Segmenta por atributo de usuario. Un desvío confinado a un navegador, una versión de app o un país es causa localizada, normalmente un recurso que la variante asume y ese segmento no tiene.
- Segmenta por tiempo. Evidencia más fuerte el primer día que luego desaparece apunta a caché, despliegue tardío de la variante o inicio escalonado, no a un aleatorizador roto.
- Mira las métricas de rendimiento del lado que perdió gente. Una variante que aumentó el tiempo de carga pierde telemetría de los usuarios más lentos, y eso produce el desvío y la métrica peor por la misma causa raíz.
- Mira el engagement. Si el engagement medio por usuario es mayor en la rama que perdió usuarios, la causa está golpeando más a los usuarios menos comprometidos, y viceversa.
- Cuenta cuántos experimentos fueron afectados. Varios tests sin relación saltando a la vez significa causa sistémica, que vive en la plataforma y no en ningún test específico.
- Corre un test A/A. Un desvío en un A/A es problema de plataforma por definición, y la calculadora de test A/A es la forma más barata de mantener esa línea base honesta.
La regla 7 merece destaque porque invierte el clima de la sala. Cuando un test salta SRM, la discusión siempre es sobre si ese test específico está roto. Un A/A resuelve eso sin ninguna de esas políticas, porque no hay resultado al que nadie esté apegado.
Qué hacer cuando encuentras uno
Las reglas aquí son cortas, y una de ellas es impopular.
No reequilibres. Recortar la rama mayor o reponderar los conteos asume que los visitantes que sobraron o faltaron eran un sorteo aleatorio. El desvío es la evidencia de que no lo eran. Lo que hagas después hereda el sesgo.
No reportes el resultado con una salvedad. Un test que saltó no es un resultado más débil, es un resultado desconocido, y un número en una diapositiva sobrevive a todo asterisco que le claves.
Encuentra la etapa primero, la causa después. La tabla de arriba convierte una cacería vaga en tres o cuatro verificaciones dirigidas, y la mayoría de los desvíos se resuelve en las dos primeras reglas de la lista de diagnóstico.
Guarda el test reprobado en el acervo. Un desvío que diagnosticaste es una mejora permanente en la plataforma y pertenece al repositorio de experimentos exactamente igual que una ganadora que subió. Los programas que borran los tests inválidos redescubren el mismo bug cada trimestre.
Comprueba temprano y al final. Correr la verificación el primer día pilla bugs de asignación y de despliegue mientras reiniciar todavía es barato. Correrla otra vez al final pilla problemas de procesamiento de logs y de análisis, que solo aparecen después de que el dato es agregado. Ninguna de las dos es peeking, porque estás mirando el reparto de tráfico y no la métrica de resultado. El problema del peeking vale para mirar el resultado y decidir si paras, que es un acto completamente distinto.
Errores comunes con el SRM
| Error | Qué produce |
|---|---|
| Nunca correr la verificación | Todo sesgo de este tipo sube en silencio, y el programa no distingue victoria real de reparto roto |
| Mirar el reparto en vez de testearlo | A escala, un desvío que importa parece perfectamente equilibrado en un panel |
| Tratar el valor p del SRM como nota de gravedad | Los tests enormes saltan por sesgos reales minúsculos con valores p aterradores; los tests pequeños esconden sesgos grandes |
| Reequilibrar o reponderar las ramas | Preserva el sesgo y elimina su evidencia |
| Comprobar solo el informe filtrado | Confunde una consulta de análisis rota con un experimento roto |
| Reiniciar sin encontrar la causa | El mismo desvío vuelve, normalmente en el test que más importaba |
| Usar umbral de 0,05 | Demasiada falsa alarma en un programa movido, lo que entrena al equipo a ignorar la verificación |
Hazlo automático en Donnu
Una verificación de SRM solo protege el programa si corre en todos los tests sin que nadie tenga que acordarse de pedirla. Donnu A/B compara el reparto observado con el configurado de forma continua, salta el desvío antes de que los números de conversión sean presentados y no después, y retiene el veredicto en vez de mostrar una ganancia que el reparto ya invalidó. El reparto, los conteos esperados y el resultado del chi cuadrado quedan al lado del resultado, así que la primera pregunta de la reunión ya está respondida antes de que nadie abra la discusión.
Empieza una prueba gratis de 14 días y corre la verificación contra tu propio reparto de tráfico.
Referencias
- 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 la taxonomía de cinco etapas, de las diez reglas prácticas, de la tasa de aproximadamente 6% de SRM en Microsoft y del número de LinkedIn sobre análisis con disparo. exp-platform.com.
- Kohavi, R., Deng, A., Longbotham, R. y Xu, Y. Seven Rules of Thumb for Web Site Experimenters. KDD 2014. Sobre verificaciones de calidad de datos y por qué el objeto de un experimento es el efecto sostenido, no el número de la primera mirada. 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 automático de calidad de datos en una plataforma grande de experimentación. 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. Material complementario en experimentguide.com.
Lee también: Qué es un test A/B · Significancia estadística en test A/B · El problema del peeking · Errores que invalidan un test A/B · Verificador de SRM gratis · Leia em português · Read in English
Preguntas frecuentes
- ¿Qué es el SRM en un test A/B?
- El SRM (sample ratio mismatch, o reparto desigual de muestra) es una diferencia estadísticamente significativa entre el reparto de tráfico que configuraste y el reparto que realmente ocurrió. Si configuraste 50/50 y terminaste con el 50,6% de los visitantes en el control, esa diferencia es azar o es un bug, y una prueba chi cuadrado de bondad de ajuste dice cuál de los dos. Cuando la prueba salta, los dos grupos han dejado de ser poblaciones comparables, así que la diferencia de conversión entre ellos ya no puede leerse como efecto del cambio. Fabijan y colegas (KDD 2019) describen el SRM como una condición que, en la mayoría de los casos, invalida por completo el resultado del experimento.
- ¿Qué desvío tan pequeño ya cuenta como SRM?
- Menor de lo que casi todo el mundo imagina, y el límite se aprieta a medida que el test crece. En un reparto 50/50 con 10.000 visitantes en total, una diferencia de unos 258 visitantes entre las ramas (51,29% contra 48,71%) ya cruza el umbral del 1% en el valor p. Con 100.000 visitantes bastan unos 816 visitantes de diferencia, lo que da un reparto de 50,41% contra 49,59%. La diferencia absoluta crece más o menos con la raíz cuadrada de la muestra, así que la tolerancia porcentual solo se encoge. Por eso mirar el panel nunca funciona: a escala, un reparto que parece perfectamente equilibrado puede ser un SRM claro.
- ¿Puedo reequilibrar los grupos y analizar igualmente?
- No, y ese es el error más caro de todo el tema. Recortar el grupo mayor o reponderar los números asume que los visitantes que faltaron (o sobraron) eran una muestra aleatoria, y es exactamente esa suposición la que el SRM derriba. Los visitantes que desaparecieron normalmente desaparecieron por un motivo ligado al propio cambio: página más lenta, redirección que falla, filtro de bots que se comporta distinto entre variantes. Reequilibrar esconde el síntoma y mantiene el sesgo. El único camino seguro es encontrar la causa raíz, corregir y volver a correr.
- ¿El SRM es común en programas reales?
- Más común de lo que los equipos suponen. Fabijan, Gupchup, Gupta, Omhover, Qin, Vermeer y Dmitriev reportan que aproximadamente el 6% de los experimentos en Microsoft presentaron SRM en el periodo estudiado, y observan que un producto que corre diez mil experimentos al año puede esperar al menos un SRM por día. El mismo artículo cita trabajo en LinkedIn indicando que cerca del 10% de los análisis con disparo (triggered) tenían SRM. Si tu programa nunca ha saltado uno, la explicación más probable es que nadie está corriendo la verificación.
- ¿El SRM vale para repartos que no son 50/50?
- Vale, y los repartos desiguales merecen más atención, no menos. La prueba chi cuadrado de bondad de ajuste compara cada grupo con su conteo esperado, así que funciona para 90/10, 80/20 o cualquier número de ramas. Los diseños desiguales también son más frágiles: una rampa 90/10 que termina en 44.600 y 5.400 usuarios de un total de 50.000 parece cerca del objetivo, pero produce un chi cuadrado de cerca de 35,6 y un valor p cercano a 2,5 en mil millones, porque la rama pequeña es donde unos cientos de usuarios mal enrutados duelen más.
- ¿Cuáles son las causas más frecuentes de SRM?
- La taxonomía del KDD 2019 agrupa las causas por la etapa en la que aparecen: asignación, ejecución, procesamiento de logs, análisis e interferencia entre experimentos. En la práctica, los reincidentes son una redirección que pierde tráfico de un lado, una variante que carga más despacio y pierde telemetría de los usuarios más lentos, un filtro de bots que trata a las variantes de forma distinta, un filtro de análisis aplicado a un solo grupo, y un segundo experimento solapando el tuyo. La etapa importa porque es la que dice de quién es la corrección.
- ¿Debo comprobar el SRM durante el test o solo al final?
- Los dos, y la comprobación temprana es la que ahorra dinero. Córrela el primer día para pillar bugs de asignación y de despliegue mientras reiniciar todavía es barato, y córrela otra vez al final, antes de leer cualquier número de conversión. Comprobar el reparto a mitad de camino no es peeking: estás mirando el reparto de tráfico, no la métrica de resultado, así que eso no infla la tasa de falso positivo de la prueba de conversión. El peeking es mirar el resultado y decidir si paras, que es otro acto.