Errores comunes en tests A/B y amenazas a la validez
Seis errores en tests A/B que invalidan resultados en silencio: peeking, SRM, efectos de novedad, paradoja de Simpson, señal de alerta y corrección.
📚 Este artículo es parte de la guía ¿Qué es un test A/B? La guía completa (2026).
Los errores en tests A/B rara vez se anuncian a sí mismos. Un test puede correr limpiamente, producir un valor p de aspecto prolijo, y aun así estar equivocado, porque la amenaza a su validez estaba en cómo se recolectaron o leyeron los datos, no en las matemáticas aplicadas después. Esta guía recorre los seis errores y amenazas a la validez que aparecen con más frecuencia en programas de experimentación reales, cada uno con la señal de alerta que lo delata y la corrección concreta.
Esta es la versión panorámica de dos guías más profundas: nuestra guía completa de significancia estadística en tests A/B cubre las matemáticas que estos errores corrompen, y nuestra guía dedicada al problema del peeking profundiza en el error #1 de abajo con un ejemplo completo resuelto paso a paso. Para el proceso de punta a punta que estos errores suelen descarrilar, mira cómo hacer un test A/B paso a paso.
Los estadísticos llaman a esto “amenazas a la validez” en lugar de simples errores porque eso es exactamente lo que son: no hacen que tus matemáticas estén mal, hacen que los datos sobre los que se aplican esas matemáticas sean poco confiables. Una prueba z de dos proporciones calculada correctamente sobre datos corrompidos por SRM sigue produciendo un valor p real y bien formado, solo que es un valor p que responde una pregunta que en realidad no hiciste, porque los grupos que compara no son la división aleatoria limpia que crees que son. Eso es lo que hace peligrosas a estas amenazas: nada en el resultado marca que algo salió mal, tienes que saber que hay que revisarlo.
1. Peeking: detenerse en cuanto parece significativo
Revisar el panel de tu test repetidamente y terminarlo la primera vez que el resultado cruza tu umbral de significancia es la amenaza a la validez más común de todas, precisamente porque no requiere ningún bug, solo un hábito comprensible. Cada mirada adicional es una nueva oportunidad para que el ruido aleatorio por sí solo cruce la línea, y el análisis ampliamente citado de Evan Miller de 2010 mostró que el monitoreo continuo puede llevar una tasa nominal de falsos positivos del 5% a aproximadamente un 26% en la práctica (Miller, 2010).
Señal de alerta: “Dio significativo el día 3, vamos a publicarlo”, dicho antes de alcanzar el tamaño de muestra o la duración planeados.
Corrección: Decide tu tamaño de muestra y duración de antemano, usando una tasa base, un efecto mínimo detectable, un nivel de significancia y un poder, y trata el panel intermedio como solo informativo. Nuestra guía dedicada al problema del peeking recorre las matemáticas completas y las reglas de parada que sí se sostienen.
2. Sample Ratio Mismatch (SRM)
El SRM ocurre cuando tu división de tráfico observada, digamos 60/40, no coincide con tu división configurada, digamos 50/50, más de lo que el azar explicaría. A diferencia de la mayoría de los puntos de esta lista, el SRM no es una sutileza estadística, es una señal de que algo en tu aleatorización, seguimiento o lógica de redirección está activamente roto. Fabijan et al. (2019), basándose en datos de cuatro empresas y cientos de millones de usuarios, encontraron que el SRM aparece en la práctica con más frecuencia de lo que la mayoría de los equipos asume, y lo rastrearon a causas que van desde tráfico de bots y bugs de caché hasta lógica de redirección asimétrica entre variaciones.
Señal de alerta: Tu división prevista de 50/50 termina en algo notablemente distinto, sin explicación, y una simple prueba de significancia sobre la división misma (visitantes en A frente a visitantes en B, tratada como su propia prueba de dos proporciones) da significativa.
Corrección: Verifica tu proporción de tráfico cada vez que revises los resultados. Si hay SRM presente, los datos de todo el test están comprometidos, por bien que se vea la métrica principal, y necesita una corrección de causa raíz (bots, caché, asimetría de redirección, unidad de aleatorización defectuosa) antes de volver a correrlo.
3. Efectos de novedad (y de primacía)
Un efecto de novedad es un aumento o caída temporal en una métrica que ocurre simplemente porque una variación es nueva, no porque sea genuinamente mejor. Los visitantes recurrentes en particular pueden explorar una página rediseñada por curiosidad, inflando las métricas de interacción tempranas que se desvanecen una vez que la nueva versión se vuelve familiar. La imagen espejo, un efecto de primacía, ocurre cuando un cambio rinde peor al principio porque los visitantes no están familiarizados con él, y luego se recupera a medida que se adaptan.
Señal de alerta: Un efecto fuerte en los primeros días que se reduce constantemente a medida que avanza el test, especialmente cuando es más pronunciado entre visitantes recurrentes que entre nuevos.
Corrección: Segmenta tus resultados por visitante nuevo frente a recurrente y por día, en lugar de leer solo el total acumulado. Si el efecto se concentra al principio y entre visitantes recurrentes, extiende el test más allá de la ventana de novedad (comúnmente una a dos semanas) y toma la decisión sobre los datos estabilizados del período posterior.
4. Paradoja de Simpson
La paradoja de Simpson ocurre cuando una tendencia que se mantiene en cada subgrupo de tus datos se revierte al combinar los subgrupos en un único número general (Stanford Encyclopedia of Philosophy). En los tests A/B, suele aparecer cuando una variación pierde en cada segmento individual, móvil, escritorio, cada canal de tráfico, pero parece ganar en el total combinado, porque los segmentos estaban ponderados de forma desigual entre A y B.
Una ilustración simplificada: supongamos que móvil convierte a una tasa base menor que escritorio, y que la variación B recibió por casualidad una mayor proporción de tráfico de escritorio que la variación A (quizás por una particularidad de un lanzamiento específico de canal). B puede entonces parecer la ganadora agregada únicamente porque recibió más del segmento que convierte mejor, incluso si A en realidad convierte mejor dentro de móvil y dentro de escritorio individualmente.
| Segmento | Conversiones / visitantes de A | Tasa de A | Conversiones / visitantes de B | Tasa de B |
|---|---|---|---|---|
| Móvil | 40 / 1.000 | 4,0% | 18 / 500 | 3,6% |
| Escritorio | 30 / 500 | 6,0% | 57 / 1.000 | 5,7% |
| Combinado | 70 / 1.500 | 4,7% | 75 / 1.500 | 5,0% |
En esta tabla, A gana dentro de móvil (4,0% frente a 3,6%) y dentro de escritorio (6,0% frente a 5,7%), pero el total combinado muestra a B adelante (5,0% frente a 4,7%), únicamente porque la mezcla de tráfico de B se inclinó más hacia el segmento de escritorio, que convierte mejor.
Señal de alerta: Los resultados segmentados de un test no coinciden con su resultado agregado, especialmente cuando las proporciones de tráfico por segmento difieren notablemente entre A y B.
Corrección: Verifica si la composición del tráfico (dispositivo, canal, geografía) estaba equilibrada entre variaciones antes de confiar en un número agregado, y reporta tanto el agregado como los segmentos clave en lugar de elegir el que cuenta la historia que esperabas.
5. Probar demasiadas cosas a la vez
Cambiar el titular, el color del CTA, la imagen hero y la visualización del precio, todo en una sola variación, significa que si el test gana, no sabes qué cambio movió la métrica, y si pierde, no sabes qué cambio (si acaso alguno) fue realmente perjudicial.
Señal de alerta: Una variación agrupa varios cambios no relacionados, y el equipo no puede articular una única hipótesis que explique por qué debería rendir de forma distinta.
Corrección: Aísla una sola variable por test siempre que sea posible. Cuando genuinamente necesites probar varios elementos juntos, usa un test multivariado diseñado para estimar la contribución de cada elemento, en lugar de un test A/B que solo te dice el efecto neto del conjunto.
6. El problema de las comparaciones múltiples
Correr muchos tests simultáneos, o dividir los resultados de un test en muchos segmentos y buscar cualquiera que sea significativo, infla tu probabilidad de un falso positivo de la misma forma que el peeking, solo que a través de tests o segmentos en lugar de a través del tiempo. Si revisas 20 segmentos independientes con un umbral de significancia del 5%, esperarías que aproximadamente uno de ellos parezca significativo puramente por azar, incluso sin ningún efecto real en ninguna parte.
Señal de alerta: “No fue significativo en general, pero sí fue significativo para usuarios de Safari por la tarde”, reportado después de los hechos, sin ningún segmento definido de antemano.
Corrección: Define de antemano cualquier segmento que planees analizar antes de que empiece el test, y si genuinamente estás corriendo muchas comparaciones, aplica una corrección (como un umbral de significancia más estricto por comparación) para que tu tasa general de falsos positivos a través de todas ellas se mantenga donde la planeaste.
Una ilustración rápida de la escala del problema: con un umbral del 5% sin corrección, revisar 5 segmentos independientes conlleva aproximadamente un 23% de probabilidad de que al menos uno resulte significativo puramente por azar, y eso sube por encima del 40% con 10 segmentos. Una corrección común y simple (Bonferroni) divide tu umbral de significancia entre el número de comparaciones, así que 5 segmentos necesitarían cada uno superar aproximadamente 0,01 en lugar de 0,05 para contar. Es una corrección conservadora, pero mucho mejor que reportar el único segmento que resultó verse bien y quedarse callado sobre los diecinueve que no lo hicieron.
Revisa tu propio test contra estas amenazas
Dos de las verificaciones anteriores, detectar un resultado inflado por peeking y confirmar la significancia de tu métrica principal, empiezan ambas con el mismo cálculo: una prueba de significancia de dos proporciones. Pega tus conteos de visitantes y conversiones abajo para obtener el valor p, el aumento y el intervalo de confianza sobre los que debería construirse tu investigación:
Test z bilateral de dos proporciones. "Sin significancia" casi siempre significa que falta muestra, no que las versiones sean iguales.
Los seis, uno al lado del otro
| Error | Señal de alerta | Corrección |
|---|---|---|
| Peeking | “Es significativo el día 3, publíquenlo” | Fija el tamaño de muestra y la duración de antemano; decide solo en el punto final |
| Sample Ratio Mismatch | La división de tráfico se aleja notablemente de la proporción configurada | Prueba la significancia de la división misma; encuentra y corrige la causa raíz antes de confiar en cualquier métrica |
| Efecto de novedad / primacía | Efecto inicial fuerte que se desvanece en 1 a 2 semanas | Segmenta por día y por visitante nuevo frente a recurrente; decide sobre los datos estabilizados del período tardío |
| Paradoja de Simpson | Los resultados segmentados no coinciden con el resultado agregado | Verifica el equilibrio de la composición de tráfico entre variaciones; reporta los segmentos junto al agregado |
| Probar demasiado a la vez | La variación agrupa varios cambios no relacionados | Aísla una variable por test, o usa un diseño multivariado adecuado |
| Comparaciones múltiples | Un segmento resultó significativo solo después de los hechos, sin plan de revisarlo | Define los segmentos de antemano; aplica un umbral más estricto al revisar muchas comparaciones |
Hazlo automático en Donnu
Cada error de arriba se puede evitar con proceso, no con más conocimiento de estadística: un tamaño de muestra comprometido de antemano, una verificación de SRM y un reporte honesto de segmentos capturan casi todos. Donnu integra por defecto en la plataforma el bloqueo del tamaño de muestra, el monitoreo de SRM y el reporte de significancia bayesiano, de modo que una amenaza a la validez se marca antes de que se convierta silenciosamente en una decisión equivocada.
Empieza una prueba gratis de 14 días y corre tu próximo experimento sobre una base que detecta esto automáticamente. Para la mirada más profunda al error #1, mira nuestra guía del problema del peeking, y para el proceso completo que estos errores suelen descarrilar, mira cómo hacer un test A/B paso a paso.
Referencias
- Miller, E. How Not To Run an A/B Test. 2010. evanmiller.org.
- Fabijan, A. et al. Diagnosing Sample Ratio Mismatch in Online Controlled Experiments: A Taxonomy and Rules of Thumb for Practitioners. KDD 2019. microsoft.com/research.
- Simpson’s Paradox. Stanford Encyclopedia of Philosophy. plato.stanford.edu.
- Kohavi, R., Tang, D. & Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020. Sitio de apoyo en experimentguide.com.
Preguntas frecuentes
- ¿Cuál es el error más común en los tests A/B?
- El peeking, revisar los resultados repetidamente y detener el test en cuanto parece significativo, es considerado en general la amenaza a la validez más común de todas, porque no requiere ningún bug ni mala configuración, solo un hábito comprensible pero estadísticamente dañino de mirar el panel con demasiada frecuencia.
- ¿Qué es el Sample Ratio Mismatch (SRM) y por qué importa?
- El SRM ocurre cuando la división de tráfico que realmente observas (por ejemplo, 60/40) no coincide con la división que configuraste (por ejemplo, 50/50) más de lo que el azar explicaría. Se trata como una parada obligatoria porque indica que algo en tu aleatorización, seguimiento o lógica de redirección está roto, lo que significa que ninguna métrica de ese test, por bien que se vea, puede ser confiable.
- ¿Qué es un efecto de novedad en un test A/B?
- Un efecto de novedad es un aumento (o caída) temporal en una métrica que ocurre simplemente porque una variación es nueva y los visitantes recurrentes interactúan con ella de forma distinta, no porque el cambio sea genuinamente mejor. Suele desvanecerse en una o dos semanas, a medida que los visitantes se familiarizan con la nueva versión, y por eso segmentar los resultados entre visitantes nuevos y recurrentes a lo largo del tiempo es la forma estándar de detectarlo.
- ¿Qué es la paradoja de Simpson y cómo aparece en los tests A/B?
- La paradoja de Simpson ocurre cuando una tendencia que se mantiene dentro de cada subgrupo de tus datos se revierte al combinar los subgrupos en un total general, generalmente porque los subgrupos tienen tamaños o tasas base muy distintas. En los tests A/B suele aparecer cuando una variación pierde en cada segmento de tráfico individual (móvil, escritorio, cada canal) pero gana en el agregado, debido a cómo se distribuyeron de forma desigual los visitantes entre esos segmentos entre A y B.
- ¿Puedo corregir un test que tiene uno de estos problemas, o tengo que reiniciarlo?
- Depende del problema. El peeking se corrige hacia adelante, comprometiéndote con la duración planeada restante e ignorando la lectura intermedia. El SRM y los bugs de instrumentación generalmente exigen reiniciar el test una vez corregida la causa raíz, porque los datos recolectados no son confiables. Los efectos de novedad se diagnostican segmentando los datos existentes en lugar de reiniciar, y las comparaciones múltiples se corrigen ajustando el umbral de significancia en lugar de volver a correr nada.