¿Cómo se diagnostica el Sample Ratio Mismatch en una prueba A/B?

Enunciado y contexto aplicable

Un experimento de producto utiliza una asignación aleatoria estable por usuario con una división configurada de 50/50. Después de 100,000 usuarios elegibles, el análisis contiene 51,000 usuarios de control y 49,000 usuarios de tratamiento. La conversión del tratamiento es un 1.8% superior y la prueba de efecto ordinaria reporta un valor p inferior a 0.01. Decida si el resultado es confiable y diseñe un proceso para detectar, diagnosticar, reparar y prevenir el Sample Ratio Mismatch, o SRM.

Esta pregunta se aplica a roles de ciencia de datos, analítica de producto, inteligencia de negocios y plataformas de experimentación. La guía actual de entrevistas para roles de datos de Amazon exige explícitamente conocimientos de estadística, trabajar con datos ambiguos y transformar el análisis en decisiones ejecutables. La investigación en experimentación de Microsoft trata al SRM como una señal fundamental de confiabilidad. La categoría principal es data: la tarea central es la prueba estadística y el diagnóstico del linaje de datos, no el diseño de la plataforma de experimentación completa.

Los valores 100,000, 51,000, 49,000 y 1.8% son supuestos de entrevista, no puntos de referencia de la industria. La solución asume que el usuario es la unidad de aleatorización y que cada usuario debe aparecer exactamente en una variante. Un experimento real aleatorizado por dispositivo, cuenta, espacio de trabajo, hogar o región debe probar la unidad correspondiente.

Qué evalúa el entrevistador

La primera señal es si el candidato comprueba la integridad del experimento antes de interpretar el impacto de negocio. Una respuesta débil ve “un incremento del 1.8% con p inferior a 0.01” y recomienda el lanzamiento. Una respuesta sólida primero verifica que la población observada coincida con la asignación configurada. La prueba de efecto puede indicar que dos resultados observados difieren; no puede probar que los usuarios que permanecen en esos grupos sigan formando muestras aleatorizadas comparables.

La segunda señal es si una diferencia de proporción visible se transforma en una prueba estadística. La misma división 51/49 significa algo muy diferente con 1,000 usuarios que con 100,000 usuarios. Una prueba de SRM compara los recuentos de variantes observados con los recuentos implícitos según la asignación configurada. Más datos hacen que las desviaciones sistemáticas pequeñas sean más fáciles de distinguir del azar.

La tercera señal es la cobertura diagnóstica. El SRM puede originarse por la configuración de asignación, identidades inestables, ejecución de variantes, telemetría faltante, filtrado de bots, combinaciones de datos (joins) o una condición de análisis definida después del tratamiento. Calificar cada SRM como “mala aleatoriedad” pasa por alto muchas fallas comunes de ejecución y procesamiento de datos.

Por último, el entrevistador busca disciplina en la toma de decisiones. El SRM es un síntoma, no ruido inofensivo que la ponderación elimine automáticamente. En un caso publicado, el tratamiento cambió el engagement lo suficiente como para que un filtro de bots eliminara a más usuarios de alto engagement; la conclusión del negocio se invirtió después de que se corrigió el defecto. Hasta que se comprenda la causa raíz, congele la decisión de lanzamiento en lugar de buscar otra métrica que siga siendo significativa.

Preguntas para clarificar antes de responder

• ¿50/50 describe la asignación, la exposición, la activación (triggering) o la población de análisis final? La asignación puede estar limpia mientras que la exposición, la elegibilidad o el análisis posterior desarrollan SRM. Pruebe cada etapa.
• ¿Cuál es la unidad de aleatorización? Si la asignación es por espacio de trabajo, los recuentos de miembros pueden diferir de forma natural. Pruebe primero los recuentos de espacios de trabajo y analice los resultados con métodos apropiados para asignación por conglomerados (clustered assignment).
• ¿Es la identidad estable y mutuamente excluyente? El inicio de sesión en múltiples dispositivos, la eliminación de cookies, la fusión de anónimo a cuenta y la migración de ID pueden reasignar o duplicar a una persona.
• ¿Cambió la asignación durante la ejecución? Un incremento gradual (ramp) de 10/90 a 50/50 requiere recuentos esperados de cada intervalo, no la división final aplicada a todo el experimento.
• ¿Cómo se define un “usuario elegible”? Una condición afectada por el tratamiento, como hacer clic en un botón nuevo exclusivo del tratamiento, es una selección post-tratamiento y puede destruir la comparabilidad.
• ¿Puede una variante redirigir, fallar o registrar logs de manera diferente? Cargas más lentas, caídas de la aplicación (crashes) y telemetría específica de la versión pueden eliminar usuarios durante la ejecución y la recolección.
• ¿Qué pipelines producen el recuento final? Separe la asignación, la exposición, la recolección de eventos, la desduplicación, el filtrado de bots, las combinaciones de dimensiones y las ventanas de métricas.
• ¿Se puede volver a ejecutar el experimento? Si la reconstrucción sin sesgos a partir de los registros sin procesar es imposible, corregir el defecto y volver a ejecutarlo es más defendible que forzar una conclusión a partir de la muestra actual.

Marco de respuesta de 30 segundos

“No haría el lanzamiento. Con una asignación 50/50, los recuentos esperados son 50,000 por grupo. El estadístico de chi-cuadrada es (51,000 - 50,000)² / 50,000 + (49,000 - 50,000)² / 50,000 = 40; con un grado de libertad, p es aproximadamente 2.54 × 10^-10. Por lo tanto, la población final tiene un desajuste severo en la proporción de la muestra, por lo que el valor p del efecto de negocio no es evidencia suficiente para el lanzamiento. Compararía los recuentos en las etapas de asignación, exposición, activación, procesamiento de logs y análisis final; luego segmentaría por tiempo, plataforma, versión y tipo de identidad para encontrar la primera divergencia. Después de reparar la causa, volvería a ejecutar las comprobaciones de SRM, telemetría y A/A; si la muestra no se puede reconstruir sin sesgos, volvería a ejecutar el experimento”.

Respuesta detallada paso a paso

Comience con un punto de control de decisión explícito: un experimento debe superar las comprobaciones de aleatorización, integridad de datos y efecto de negocio. Ejecute el SRM antes del análisis de efecto y muéstrelo de forma destacada en la plataforma de experimentación. La práctica publicada por Microsoft utiliza p < 0.0005 como un umbral de alerta conservador para reducir los falsos positivos a escala de plataforma. Ese es un ejemplo documentado, no una constante universal. Un equipo debe elegir su umbral de calidad con anticipación en lugar de hacerlo después de ver los resultados.

Paso 1: Calcular el SRM correctamente.

Para dos variantes configuradas en 50/50 con 100,000 usuarios en total, cada recuento esperado es 50,000. El estadístico de bondad de ajuste de chi-cuadrada es:

χ² = Σ (observed - expected)² / expected = 40

Con dos grupos y ningún parámetro estimado adicional, hay un grado de libertad, lo que da un valor p de aproximadamente 2.54 × 10^-10. Esto está muy por debajo de un umbral de integridad conservador y no es plausiblemente ruido de asignación ordinario. La aproximación de chi-cuadrada necesita recuentos esperados adecuados; una regla común del NIST es aproximadamente cinco observaciones esperadas por grupo. Muestras muy pequeñas, asignaciones raras o muchas variantes dispersas exigen una prueba binomial o multinomial exacta.

La proporción debe interpretarse junto con su tamaño de muestra. Si el total fuera 1,000 y los recuentos fueran 510/490, los recuentos esperados serían 500/500, χ² = 0.4, y p sería aproximadamente 0.527. La proporción visible de 51/49 es idéntica, pero la evidencia no lo es.

Paso 2: Encontrar la primera etapa donde divergen los recuentos.

Construya un embudo de etapas que preserve los recuentos únicos de unidades de aleatorización por variante:

Si la asignación ya está desbalanceada, inspeccione la configuración del experimento, el código de partición en cubetas (bucketing) y los IDs de aleatorización. Si la asignación está limpia pero la exposición diverge, inspeccione fallas de carga específicas de la variante, caídas de la aplicación y redirecciones. Si la población no activada está limpia pero los “usuarios que visitaron el checkout” no lo están, determine si la activación está afectada por el tratamiento o si falta en el control. Si solo diverge la tabla de hechos final, concéntrese en el filtrado, la desduplicación y los joins.

Paso 3: Localizar la causa con tiempo y segmentos.

Grafique los recuentos acumulados observados y esperados por hora y localice cuándo comienza la brecha. Una discontinuidad repentina apunta hacia un cambio de configuración, despliegue o pipeline. Una desviación constante desde el inicio del experimento es más consistente con un defecto de bucketing o de activación. Segmente por plataforma, navegador, versión de la aplicación, geografía, estado de inicio de sesión, tipo de identidad y fuente de tráfico, mostrando el tamaño del segmento, la dirección y el primer momento anómalo.

La segmentación es una herramienta de diagnóstico, no una búsqueda de un subgrupo que casualmente apruebe el SRM. Muchos cortes producen naturalmente algunos valores p pequeños. Un corte útil respalda un mecanismo. Si el SRM se concentra en una versión antigua de iOS y faltan los logs de exposición al tratamiento en esa versión, inspeccione la entrega del cliente y la telemetría; no excluya simplemente a iOS declarando que el resto del experimento es confiable.

Paso 4: Verificar la aleatorización y la semántica de identidad.

El bucketing debe ser una función determinista de un ID de aleatorización estable, un ID de experimento y un salt fijo. La misma unidad debe permanecer en una sola variante durante todo el experimento. Verifique:

1. Si una unidad de aleatorización aparece en múltiples variantes.
2. Si los IDs anónimos se reasignan cuando se fusionan con los IDs de cuenta.
3. Si el borrado de cookies o el uso multidispositivo crea “nuevos usuarios” repetidos.
4. Si las reglas de empleados, bots y exclusión se aplican de manera consistente en torno a la asignación.
5. Si cada configuración de incremento gradual (ramp) tiene una marca de tiempo de entrada en vigor auditable.

Para la aleatorización por espacio de trabajo u hogar, pruebe primero los recuentos de conglomerados. Una variante de tratamiento puede recibir aleatoriamente varios espacios de trabajo grandes y mostrar una proporción de filas de miembros de 51/49 sin que exista un defecto de bucketing. Tratar las filas de miembros como muestras aleatorizadas independientes crearía una falsa alarma.

Paso 5: Auditar la selección post-tratamiento y los datos faltantes.

Un trigger válido debe determinarse a partir de información disponible antes del tratamiento siempre que sea posible. “Llegó al checkout” puede definirse mediante la exposición de una página registrada en ambas variantes. “Hizo clic en el nuevo botón de cupón del tratamiento” no tiene una observación equivalente en el control y naturalmente selecciona más usuarios del tratamiento. El rendimiento del tratamiento también puede alterar la completitud de la telemetría; los filtros de bots, tiempos de espera y errores pueden eliminar a los usuarios más afectados por el cambio.

No asuma que los usuarios faltantes son aleatorios. Compare los logs de asignación inmutables con cada tabla posterior, tome muestras de IDs faltantes e inspeccione su plataforma, hora, versión y comportamiento. Si el tratamiento afecta la probabilidad de que un usuario ingrese a la tabla de análisis, la diferencia de conversión observada incluye sesgo de selección.

Paso 6: Elegir entre reparación, reconstrucción o reinicio.

• Asignación incorrecta o usuarios en múltiples variantes: detenga, repare la asignación, aleatorice de nuevo y vuelva a ejecutar.
• Asignación y exposición completas con una pérdida reversible en el ETL: repare el job, reconstruya a partir de eventos sin procesar no sesgados y vuelva a ejecutar el SRM.
• Trigger dependiente del tratamiento: utilice una condición previa al tratamiento o regrese a la población por intención de tratar (intent-to-treat) no activada.
• Telemetría requerida faltante en una versión de cliente sin posibilidad de backfill: corrija la instrumentación y vuelva a ejecutar para esa población objetivo.
• Incrementos de asignación planificados: sume los recuentos esperados de cada intervalo de configuración y preserve el historial de configuración.

La ponderación solo es defendible cuando el mecanismo de selección es conocido, estimable y validado de forma independiente. La mayoría de los SRM señalan que el mecanismo de pérdida de datos es desconocido. Multiplicar 49,000 usuarios de tratamiento por una ponderación hasta que el total se parezca a 50,000 no restaura el comportamiento de los usuarios faltantes ni recupera la aleatorización.

Paso 7: Integrar la prevención en la plataforma de experimentación.

Conserve registros de asignación inmutables, proporciones configuradas y marcas de tiempo de vigencia. Calcule el SRM por separado para las poblaciones de asignación, exposición, activadas y analizadas. Los resultados de negocio no deben impulsar una decisión de lanzamiento hasta que se superen las comprobaciones de integridad. Ejecute pruebas A/A periódicas para verificar que el bucketing, la telemetría y el análisis permanezcan limpios cuando no exista ninguna diferencia en el producto.

Una alerta debe incluir el tamaño total, los recuentos observados y esperados, el valor p, la dirección, el primer momento anómalo y los segmentos principales. Aumente la rigurosidad tras cambios en el despliegue, la identidad, la detección de bots o el ETL. Conserve suficiente linaje después de que termine un experimento para reproducir los recuentos esperados a partir de la configuración histórica en lugar de preservar únicamente una imagen del panel.

Ejemplo de respuesta de alta calidad

“No lanzaría la variante porque el incremento reportado del 1.8% asume muestras aleatorizadas comparables. Bajo la división configurada de 50/50, 51,000 usuarios de control y 49,000 de tratamiento tienen recuentos esperados de 50,000 cada uno. El estadístico de chi-cuadrada es 40 con un grado de libertad, por lo que p es aproximadamente 2.54 × 10^-10. El experimento presenta SRM y congelaría la conclusión de negocio.

Primero verificaría que el usuario sea la unidad de aleatorización real y que la división 50/50 se haya aplicado durante toda la ejecución. Luego compararía los recuentos a través de la asignación, la exposición real, la elegibilidad de activación, la inclusión en la tabla de hechos de eventos y el análisis final. La primera etapa divergente determina la investigación. Un SRM en la asignación apunta a la configuración, IDs estables, salts o membresía en múltiples variantes. Una asignación limpia pero una exposición desbalanceada apunta al despliegue, rendimiento, caídas de la aplicación o redirecciones. Un SRM exclusivo de la activación apunta a una condición dependiente del tratamiento. Un SRM en la tabla final apunta a telemetría, filtrado de bots, desduplicación o joins.

Segmentaría por tiempo, plataforma, versión de la app, geografía, estado de inicio de sesión y tipo de ID para encontrar evidencia de un mecanismo concreto, no para seleccionar convenientemente un subgrupo limpio. Si los eventos sin procesar no sesgados pueden reconstruir la población, repararía el pipeline y volvería a ejecutar cada comprobación de integridad. Si los usuarios cruzaron variantes, el trigger depende del tratamiento o la telemetría requerida no se puede recuperar, repararía el sistema y volvería a ejecutar el experimento.

Para la prevención, la plataforma debería ejecutar SRM antes de revelar los resultados de negocio, conservar un historial inmutable de asignaciones y configuraciones, y monitorear los recuentos de asignación, exposición, activación y análisis por separado. Las pruebas A/A, el bucketing estable y los triggers previos al tratamiento verifican la ruta. Solo después de que se explique la causa raíz y la población reparada apruebe el SRM, reconsideraría el incremento del 1.8% y sus métricas de control (guardrails)”.

Errores comunes

• Lanzar a producción porque el valor p del resultado es pequeño → La inferencia del efecto asume muestras comparables → Supere primero las comprobaciones de SRM y de integridad de datos.
• Fijarse únicamente en el porcentaje 51/49 → La misma proporción aporta distinta evidencia con diferentes tamaños de muestra → Utilice recuentos esperados y una prueba estadística.
• Tratar el SRM únicamente como un problema de números aleatorios → La ejecución, los logs y los filtros también eliminan usuarios → Rastree la primera divergencia a lo largo de toda la ruta.
• Esperar a que los recuentos se acerquen más → Más datos sesgados no restauran la aleatorización → Congele la decisión y diagnostique de inmediato.
• Reponderar directamente a 50/50 → Las ponderaciones no recuperan el comportamiento sistemáticamente ausente → Corrija únicamente bajo un modelo validado de datos faltantes.
• Comprobar solo la tabla de análisis final → Oculta si falló la asignación o el procesamiento posterior → Conserve recuentos en cada etapa.
• Activar (triggering) ante un comportamiento exclusivo del tratamiento → El grupo de control carece de una oportunidad equitativa de entrar en la muestra → Utilice una condición simétrica previa al tratamiento.
• Evaluar filas de miembros en un experimento por conglomerados → La variación en el tamaño de los conglomerados genera falsos SRM → Pruebe primero la unidad de aleatorización real.
• Descartar una plataforma problemática después de ver los resultados → La selección post-hoc de la población añade sesgo → Utilice cortes para el diagnóstico y vuelva a ejecutar sobre la población planificada.
• Reutilizar el informe de efecto anterior después de la reparación → Se calculó a partir de la muestra defectuosa → Regenere los análisis de integridad, efecto y guardrails.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Qué pasa si la división sigue siendo 51/49 pero la muestra total es de solo 1,000?

Los recuentos esperados son 500 cada uno y los recuentos observados son 510 y 490. El estadístico de chi-cuadrada es (510 - 500)² / 500 + (490 - 500)² / 500 = 0.4, lo que da un valor p de aproximadamente 0.527 con un grado de libertad. Esa es evidencia insuficiente para declarar SRM. Por esto, una regla fija de “más de un punto porcentual” no puede reemplazar una prueba estadística, aunque un defecto de ingeniería conocido aún deba investigarse.

Pregunta de seguimiento 2: La asignación general pasa el SRM, pero los usuarios de iOS no. ¿Se puede seguir utilizando el experimento?

Considere el número de cortes, el tamaño de la muestra de iOS y si un mecanismo explica la anomalía. Si el SRM se concentra en una versión de iOS material y preespecificada, y la pérdida de exposición lo explica, el resultado de esa población no es confiable. Si otras poblaciones siguen siendo utilizables depende del plan de análisis y del verdadero aislamiento de la causa. No descarte iOS solo después de ver los resultados; reparar el cliente y volver a ejecutar la prueba sobre la población objetivo planificada es más seguro.

Pregunta de seguimiento 3: La población no activada está limpia, pero el análisis de la población activada tiene SRM. ¿Qué es lo más probable que esté mal?

Inspeccione primero el trigger. Puede que se registre solo en una variante o que dependa de un comportamiento causado por el tratamiento. Reemplácelo con una condición que ambos grupos puedan cumplir antes del tratamiento, como llegar a una página en lugar de hacer clic en un nuevo componente. Compare también la cobertura de la telemetría del trigger. Los recuentos limpios no activados sugieren que la asignación base puede ser sólida, pero no validan el análisis del efecto activado.

Pregunta de seguimiento 4: ¿Por qué no reponderar los grupos según sus tamaños observados?

El SRM no identifica quién falta. Si el tratamiento perdió a los usuarios más activos, con mayor conversión o más propensos a caídas del sistema, una ponderación de recuentos restaura solo el total, no la distribución de su comportamiento. La corrección puede ser posible cuando la probabilidad de selección se explica completamente mediante variables previas al tratamiento y el modelo está validado, pero ese es un supuesto adicional, no el remedio predeterminado.

Pregunta de seguimiento 5: Los espacios de trabajo se aleatorizaron 50/50, pero los recuentos de usuarios son 55/45. ¿Es eso un SRM?

Compruebe primero los recuentos de espacios de trabajo. Si la asignación de espacios de trabajo es 50/50 pero el tratamiento recibió aleatoriamente varios espacios de trabajo grandes, el desbalance de miembros puede ser una variación ordinaria del tamaño de los conglomerados y no una falla de bucketing. El análisis de resultados también debe considerar la dependencia dentro del espacio de trabajo. Si se requiere un tráfico de miembros equilibrado, utilice estratificación por tamaño o aleatorización emparejada en el diseño del experimento en lugar de tratar las filas de miembros como asignaciones independientes a posteriori.

Pregunta de seguimiento 6: El experimento aumentó gradualmente de 10/90 a 50/50. ¿Cómo se calculan los recuentos esperados?

Calcule los recuentos esperados dentro de cada intervalo de asignación y súmelos. Si 20,000 usuarios llegaron bajo 10/90 y 80,000 bajo 50/50, los recuentos esperados totales son 42,000 y 58,000, no 50,000 cada uno. Utilice la configuración y la hora efectiva que estaban activas al momento de la asignación; nunca aplique la división final de forma retroactiva a toda la ejecución.