Platform
Resources
Una guía rápida sobre la discrepancia en la proporción de la muestra (SRM)
Nota: Esta es una traducción al español de un blog publicado originalmente en inglés, que puedes encontrar aquí: https://statsig.com/blog/sample-ratio-mismatch
"Decidamos con un lanzamiento de moneda: el primero en llegar a 50 gana."
Imagina que estamos lanzando una moneda justa varias veces y obtenemos 8 caras y 2 cruces. (Una moneda justa es una moneda equilibrada, y nunca ha sido utilizada en un truco de magia.)
Aunque esperaríamos obtener mitad caras y mitad cruces, podríamos haber obtenido resultados extraños. Si seguimos lanzando la moneda durante 100 intentos y obtenemos 80 caras y 20 cruces, sospecharemos mucho más sobre la "justicia" de esta moneda.
Si estamos usando este lanzamiento de moneda para asignar aleatoriamente usuarios al grupo de prueba o control de un experimento, la falta de "justicia" se llama desajuste de proporción de muestra o SRM.
Evaluamos esta falta de justicia con una prueba chi-cuadrado comparando los resultados 80/20 que estamos viendo con los resultados 50/50 que esperaríamos de una moneda justa. El valor p de esta prueba chi-cuadrado es la tasa de resultados tan o más extremos que lo que observamos que esperaríamos ver en ensayos repetidos con una moneda verdaderamente justa.
La intuición se corresponde con el valor p del SRM
La intuición de nuestros experimentos de lanzamiento de moneda se refleja en el valor p de las pruebas chi-cuadrado para cada uno de estos casos. Ver resultados del 80% de caras en un experimento de 10 lanzamientos tiene un valor p de 0.058, mientras que obtener 80% de caras en un experimento de 100 lanzamientos tiene un valor p de esencialmente 0.
¿Por qué es malo el SRM?
El desajuste de proporción de muestra es evidencia de sesgo de selección
Una de las suposiciones fundamentales de los experimentos aleatorios es que hay una asignación aleatoria de individuos al grupo de control o prueba. De lo contrario, podría haber otras variables que no son independientes de la asignación que podrían ser la verdadera causa de cualquier diferencia entre tratamiento y control que observemos.
Señala un problema de implementación
El hecho de que haya SRM probablemente significa que hay algún problema en la implementación de la experimentación, pero podría ocurrir tanto en la forma en que los usuarios son asignados a su grupo de tratamiento como en cómo se miden o procesan los datos después del hecho. Si estás usando Statsig, ¡también hay muchas de estas causas potenciales que probablemente podemos descartar!
Algunas causas para investigar:
Algunos usuarios no son elegibles para algunas variantes: tal vez el código para tu nueva función súper genial también inadvertidamente fuerza a cierto segmento de usuarios a un grupo de tratamiento específico.
Esto no sucederá si estás usando Statsig porque nuestro SDK filtra a los usuarios no elegibles de manera uniforme en todos los grupos del experimento
La inscripción está desacoplada de la exposición: Quizás los usuarios se inscriben en un experimento en cierta página web pero solo están expuestos a su grupo de tratamiento si llegan a la experiencia relevante. Sin embargo, si la exposición del grupo de control ocurre en la parte superior de la página pero el grupo de prueba necesita desplazarse, este es un mecanismo que podría causar SRM.
El SDK de Statsig acopla automáticamente la asignación y la exposición registrando las exposiciones automáticamente para ti de forma predeterminada, pero esto también puede desacoplarse cuando sea necesario.
El procedimiento de aleatorización no está aleatorizando: la función que estás usando para asignar usuarios 'aleatoriamente' a un tratamiento no es realmente aleatoria y potencialmente está introduciendo sesgo.
Esto no sucederá si estás usando Statsig: usamos el algoritmo de hash SHA256 para asignar determinísticamente grupos de tratamiento dado un ID de unidad y un ID de experimento
Diferencias en la tasa de fallos entre los grupos de Prueba y Control: Si el nuevo código introduce o resuelve fallos, esto podría resultar en SRM. Si el grupo de prueba tiene más fallos, esto resultaría en que más usuarios en el grupo de prueba no puedan enviar exposiciones, causando SRM.
Problemas de procesamiento de datos: puede haber algún proceso por el cual estos datos se están eliminando o duplicando solo para la variante de control o prueba.
Si estás enviando todos tus datos a través de Statsig, nosotros hacemos el procesamiento de datos y no debería haber SRM proveniente del procesamiento de datos
¿Simplemente tuviste muy mala suerte?
Probablemente no.
Esto es lo que está cuantificando el valor p: la tasa de resultados donde los grupos están divididos al menos tan extremadamente como lo que observamos que esperaríamos ver en ensayos repetidos realizados de la misma manera. Esto es realmente improbable pero podría ser lo que está sucediendo.
SRM en la Consola de Statsig
En Statsig verificamos automáticamente el SRM para cada experimento. En Diagnósticos, bajo Verificaciones de Salud del Experimento, si ves que las Exposiciones están Equilibradas está en verde, eso significa que no detectamos ningún SRM.
Consideramos que las exposiciones están desequilibradas si el valor p del SRM está por debajo de 0.01.
Si no estás usando Statsig, y quieres verificar si tu experimento tiene SRM, probablemente no quieras hacer una prueba chi-cuadrado a mano. He usado esta calculadora de SRM antes y la usé para calcular los valores p para nuestros ejemplos (8, 2) y (80, 20) anteriores.
Statsig rastrea automáticamente tu valor p de SRM a lo largo del tiempo, lo que te permite identificar si/cuándo ves evidencia de SRM. Cualquier valor p de SRM por debajo de 0.01 significará que el experimento falla la verificación de salud de Exposiciones Equilibradas.
Esto significa que también hay un punto de partida para depurar problemas que pueden haber causado el SRM.
Si se detecta SRM y se encuentra la causa raíz, puedes abandonar fácilmente el experimento y reasignar. Este nuevo experimento con el mismo diseño también tendrá una "sal" diferente utilizada para aleatorizar el grupo de un usuario, lo que significa que los usuarios son asignados aleatoriamente a un grupo independientemente de su grupo en la iteración anterior de este experimento. Esto es importante, porque asegura que el nuevo resultado no se vea afectado por una experiencia negativa o positiva en la ejecución anterior.
¿Tengo que descartar mis resultados porque tengo SRM?
No queremos tomar a la ligera la existencia de SRM en un experimento. Indica que muy probablemente hay algo metodológicamente incorrecto en tu experimento. Sin embargo, puede que no queramos descartar completamente el experimento que acabamos de ejecutar.
Es importante que necesito conocer la causa raíz del SRM al tomar estas decisiones. Sin este conocimiento crucial, es imposible considerar las fuentes potenciales de sesgo experimental y de qué maneras nos sentimos cómodos usando los resultados.
Hay algunos factores que considero cuando estoy mirando un experimento con SRM para determinar si puedo obtener alguna información direccional del experimento:
¿Qué tan diferente es el grupo de usuarios que causa SRM de otros usuarios?
p.ej. en nuestro experimento, los nuevos usuarios están todos en el grupo de prueba, y los nuevos usuarios se comportan muy diferente de los usuarios veteranos, así que descarto completamente los resultados del experimento y reinicio el experimento.
¿Podría la diferencia entre usuarios que está causando SRM también impactar el tratamiento?
p.ej. en nuestro experimento, tengo entradas duplicadas para todos los usuarios de Internet Explorer para quienes mi nueva función causa mayor latencia. Esto parece estar impulsando los resultados negativos que veo en general, mientras que los usuarios con otros navegadores parecen tener un pequeño impacto positivo de la nueva función. Esto puede llevarme a iterar en mi producto para reducir la latencia en todos los navegadores web antes de ejecutar otro experimento.
Al final del día, es una decisión de criterio.
Si bien puede haber desventajas en reiniciar un experimento y no tomar ningún aprendizaje de la versión anterior donde el SRM estaba presente (toma de decisiones retrasada, servir una experiencia inferior a los usuarios), el enfoque más científicamente riguroso sería siempre volver a ejecutar estos experimentos tal como fueron diseñados una vez que se encuentre el problema que causa el SRM.
Si quieres considerar los resultados de un experimento a pesar de la existencia de SRM, controlar el sesgo pre-experimento usando CUPED puede ayudar a abordar el sesgo.