Tests A/B: cómo los usuarios excluidos sesgan los resultados

El experimento termina y la variante nueva convierte mejor. El equipo tiene una cifra defendible, una presentación casi lista y ganas de cerrar la discusión. Antes de hacerlo, conviene mirar un dato mucho menos vistoso: cuántas personas han llegado realmente al análisis en cada grupo.

Si una variante pierde observaciones de forma selectiva, podemos acabar comparando poblaciones diferentes después de haberlas asignado correctamente al principio. El resultado puede parecer preciso y estar respondiendo a otra pregunta. Para quienes construimos plataformas de datos, esta es una frontera importante: la calidad de la medición participa directamente en la decisión de producto.

¿Qué significa detectar Sample Ratio Mismatch?

Significa que la proporción observada de usuarios difiere de la prevista de una forma estadísticamente relevante y necesita investigación. Es una señal de posible problema de integridad; no demuestra por sí sola la causa ni permite confiar en el efecto estimado. Su ausencia tampoco certifica todo el experimento.

Un carrusel de MSN que parecía empeorar el producto

Microsoft publicó en 2020 un caso de su plataforma de experimentación en el que MSN amplió un carrusel de doce a dieciséis tarjetas. El análisis inicial mostraba una caída de interacción. Al investigar una discrepancia entre el reparto esperado y los usuarios observados, encontraron que la mayor actividad de ciertos usuarios los hacía parecer bots: el filtro los excluía.

Corregido el problema, la dirección del resultado cambió. La variante nueva aumentaba la interacción. La misma publicación indicaba que aproximadamente el 6 % de los experimentos A/B de Microsoft presentaba una discrepancia de proporciones en el análisis citado. Es una cifra histórica de aquella organización, no una tasa universal ni una estimación del error de todos los experimentos actuales.

El caso resulta especialmente interesante porque el fallo no consistía simplemente en olvidar un evento. Había una regla que cumplía una función razonable —filtrar actividad automatizada— y que interactuó con el comportamiento que se estaba intentando medir. Podemos tener componentes sensatos y, aun así, producir una conclusión equivocada cuando los combinamos.

Qué nos dice una discrepancia de proporciones

El nombre habitual es Sample Ratio Mismatch, o SRM: una diferencia estadísticamente relevante entre las proporciones de usuarios previstas y las observadas en las variantes. La documentación de experimentación de PlayFab lo trata como una comprobación de calidad de los datos.

No cualquier reparto distinto de la proporción prevista demuestra un fallo. La asignación aleatoria admite fluctuaciones y su interpretación depende del tamaño de la muestra. Tampoco superar esta comprobación demuestra que el experimento entero sea válido: puede haber errores de medición que afecten por igual a ambos grupos o problemas en la métrica elegida.

Un control de integridad permite detectar una familia de problemas; no certifica por sí solo una conclusión causal. La diferencia importa cuando convertimos una señal verde en permiso para dejar de pensar.

Cómo fabricar una mejora sin mejorar nada

Este ejemplo es hipotético y solo ilustra la aritmética. Supongamos que cada variante recibe 10.000 usuarios y que en ambas compran 500. La conversión real de cada grupo es del 5 %. En la variante nueva, un fallo deja fuera del registro a 1.000 usuarios que no compraron; las 500 compras siguen registradas.

El informe calcularía entonces 500 compras entre 9.000 usuarios: un 5,56 % aproximadamente. Frente al 5 % del grupo de control, aparecería una mejora relativa cercana al 11,1 %, sin una sola compra adicional. La subida absoluta sería de unos 0,56 puntos porcentuales. Son dos maneras diferentes de expresar el mismo artefacto; ninguna lo convierte en una mejora real.

La condición decisiva del ejemplo es que las observaciones perdidas pertenecen a personas que no compraron. No podemos aplicar ese resultado a cualquier pérdida de eventos. Si desaparecen otros usuarios o también se pierden compras, el sesgo puede cambiar de dirección. Precisamente por eso hace falta comprender quién falta y por qué antes de corregir una cifra.

Eliminar usuarios del grupo contrario para igualar los tamaños no reconstruye automáticamente a los ausentes. Podríamos obtener una tabla visualmente equilibrada y conservar el problema de selección. El análisis necesita una población comparable, no dos columnas con el mismo número de filas.

Filtro de decisión para experimentos

El filtro de decisión para experimentos organiza tres preguntas antes de convertir una comparación en un lanzamiento. Es una síntesis propia apoyada en los problemas descritos; no sustituye el diseño estadístico ni los controles específicos del experimento.

Integridad: Qué usuarios debían aparecer, quiénes faltan y qué controles se han superado.
Interpretación: Qué comportamiento representa la métrica y qué explicaciones alternativas permanecen.
Decisión: Qué acción admite la evidencia, con qué incertidumbre y qué criterio de freno.

En el ejemplo de las compras, la variante nueva no supera la pregunta de integridad: faltan selectivamente usuarios que no compraron. La aparente mejora no autoriza avanzar hacia una conclusión de producto. Cuando esa causa se resuelva, todavía habrá que interpretar la métrica y valorar la incertidumbre; pasar un control no equivale a completar todo el filtro.

Mejora observada ≠ efecto causal demostrado. Ausencia de SRM ≠ experimento válido. Puede haber fallos compartidos por ambos grupos o una métrica que represente mal el objetivo.

El control de calidad debe poder frenar una decisión

En su artículo sobre alertas de la plataforma ExP, Microsoft explica cómo supervisa tanto problemas de calidad como deterioros de métricas durante los experimentos. Esa distinción es útil: una alerta puede advertir de que el producto está perjudicando a los usuarios o de que los datos todavía no permiten valorar el efecto. Las respuestas no tienen por qué ser las mismas.

Desde el punto de vista de organización, eso exige dejar espacio para un resultado incómodo: «aún no sabemos». Si cada prueba tiene que entregar un ganador para justificar el esfuerzo, el equipo recibe un incentivo para ignorar lo que dificulte cerrar la historia. Una investigación que descubre una medición sesgada puede ahorrar decisiones equivocadas aunque no produzca un lanzamiento.

También cambia la conversación entre ingeniería, analítica y producto. Una incidencia de identidad o telemetría ya no es un detalle que pueda quedar aparcado porque el dashboard carga correctamente. Puede invalidar la comparación que sostiene una inversión. La gravedad viene del uso de los datos, no de lo llamativo del error.

Esto conecta con la reflexión sobre entregar software sin comprobar su utilidad. Experimentar aporta una oportunidad de aprender, pero ese aprendizaje depende de que el sistema permita refutar la historia que queríamos contar.

Cuando alguien presente la próxima variante ganadora, podemos pedir algo más que el porcentaje de mejora: qué población representa, qué controles de integridad superó y qué incertidumbre permanece. Si esas respuestas cambian la decisión, el trabajo de datos ha cumplido su función antes de que una mala conclusión llegue a producción.