Diagnostique una discrepancia en la proporción de muestras en cinco ramas antes de desechar la prueba.

Alrededor del 6% de los experimentos en Microsoft muestran una discrepancia en la proporción de muestras, lo que en un producto que ejecuta 10,000 experimentos al año equivale aproximadamente a una detección al día (Fabijan y otros, KDD 2019Los equipos que realizan muchas menos pruebas rara vez ven esa cifra, porque la comprobación que ejecuta su plataforma no puede alcanzar significancia estadística con su volumen de tráfico. La prueba parece correcta, reporta un aumento del 4%, pero de todos modos es errónea.

Esta guía está dirigida a la persona que interpreta los resultados del experimento y debe decidir si se envía o no. Al finalizar, podrá determinar si su prueba es lo suficientemente amplia como para que la verificación de discrepancias tenga algún significado, ejecutar cinco ramas de diagnóstico en el orden que permita encontrar la causa más rápidamente y diferenciar un desequilibrio que invalida los resultados de uno que puede segmentar y conservar.

Lo que realmente te indica una alarma SRM

Una discrepancia en la proporción de la muestra es una diferencia entre la división que configuraste y la división que observas: configuraste 50/50 y obtuviste 50.8/49.2. La verificación estándar es la prueba de bondad de ajuste chi-cuadrado de Pearson sobre los recuentos de exposición, con un grado de libertad para una prueba de dos grupos.

Es importante porque el mecanismo que provoca la pérdida de usuarios casi nunca es neutral con respecto a la métrica. Si una redirección elimina las conexiones lentas de la variante, los usuarios que sobreviven son aquellos con mejores conexiones y, por lo tanto, convierten mejor. El aumento es real en los datos, pero inexistente en la realidad.

Aquí está el primer error que cometen la mayoría de los equipos: no existe un umbral estándar en la industria. Las plataformas difieren en más de un orden de magnitud.

Dos consecuencias. Una prueba marcada en una plataforma pasa en otra con datos idénticos, por lo que "nuestra herramienta no nos advirtió" no es evidencia de una división limpia. Y un umbral de 0.01 marca una de cada cien pruebas correctas. Si se observa el valor p diariamente durante una prueba de tres semanas, el límite ingenuo de pico independiente para una falsa alarma es del 19 %; la cifra real es menor porque los días consecutivos están fuertemente correlacionados, pero no es del 1 %. Por eso AB Tasty ejecuta un procedimiento secuencial. Si su plataforma ejecuta una prueba chi-cuadrado de horizonte fijo, observe una sola vez, al final, los recuentos acumulados.

Comprueba si tu prueba puede detectar algún desequilibrio.

Para una división 50/50, el estadístico chi-cuadrado se simplifica a 4n(p̂−0.5)², donde n es el total de exposiciones. Inviértalo y obtendrá el desequilibrio más pequeño que su verificación puede detectar:

Léalo como un límite, no como una licencia. Con 10,000 exposiciones, cualquier desequilibrio menor a 1.3 puntos es invisible para la verificación, y un efecto de selección de 1.3 puntos es más que suficiente para generar un pequeño aumento en la conversión. Ese es el problema estructural en la mayor parte de la región. Turquía registró alrededor de 6 millones de transacciones de comercio electrónico en aproximadamente 634,000 empresas en 2025 (Ministerio de Comercio, 12 de mayo de 2026), un promedio cercano a 9,500 al año cada uno, y ese promedio se ve fuertemente impulsado por un puñado de mercados. Una tienda mediana que prueba un paso de pago trabaja con decenas de miles de exposiciones, no con millones, por lo que su verificación SRM detecta roturas graves y nada más sutil.

Con ese volumen, no confíe en la alarma. Obtenga usted mismo los recuentos de exposición brutos por día y por segmento, y trate una deriva persistente en la misma dirección como sospechosa incluso cuando el valor p no sea destacable. Si no está seguro de dónde su plataforma expone esos recuentos, Documentación de SRM Checker Los asigna por herramienta.

Las cinco ramas, en el orden que encuentra la causa más rápidamente.

La taxonomía KDD clasifica las causas de SRM según la etapa del ciclo de vida: asignación, ejecución, procesamiento de registros, análisis e interferencia. Diagnostímelas en un orden diferente, comenzando por las más económicas y comunes.

1. Análisis y activación. Síntoma: la división es correcta en el registro de exposición sin procesar, pero incorrecta en el cuadro de mando. Verificación: recalcule la proporción sin la condición de activación, el filtro de fecha ni las uniones a nivel de métrica. Confirme si la proporción vuelve a lo esperado. Solución: evalúe la activación de forma idéntica en ambos grupos, antes de que cualquier comportamiento específico de la variante pueda modificar la elegibilidad. Es la falsa alarma más común; se puede descartar en diez minutos.
2. Procesamiento de registros. Síntoma: los recuentos de exposición difieren entre dos pipelines, o la brecha aparece después del paso ETL. Verificación: compare el recuento del lado del SDK, el recuento del almacén y el recuento de informes para la misma ventana, luego compare las tasas de exclusión del filtro de bots por brazo. Confirma si los brazos son iguales aguas arriba y desiguales aguas abajo. Solución: filtre de forma determinista e idéntica. El tráfico automatizado alcanzó el 53% del tráfico web en 2026, frente al 51% en 2024 (Informe sobre bots maliciosos de Imperva, 29 de abril de 2026), por lo que un filtro heurístico basado en el tiempo de carga o el comportamiento del agente de usuario puede excluir a diferentes tasas por variante. La pérdida basada en el consentimiento también se encuentra aquí: cuando ad_storage Si se deniega, la plataforma de etiquetas de Google deja de establecer cookies publicitarias (Documentos de consentimiento de la plataforma de etiquetas de Google), por lo que si las tasas de denegación difieren entre las distintas zonas geográficas en una prueba, cualquier asignación que dependa de esos identificadores provoca una pérdida desigual de usuarios.
3. Ejecución. Síntoma: el desequilibrio aumenta con el peso de la página, empeora en dispositivos móviles o comienza en el despliegue. Verificación: divida la proporción por dispositivo, navegador, tipo de conexión y día; compare el tiempo de exposición entre los brazos. Confirme si el déficit se concentra en segmentos lentos o en un navegador específico. Solución: aquí es donde fallan las pruebas de redirección. Una redirección agrega una navegación completa a un solo brazo, y todos los que abandonan durante ella representan una pérdida selectiva. Renderice ambas variantes en el servidor en una sola URL o acepte que los brazos no son comparables.
4. Asignación. Síntoma: la proporción se desvía desde la primera hora y permanece desviada por un factor constante. Verificación: ejecute una prueba A/A en la misma asignación y compruebe que la sal hash no se haya reutilizado de un experimento anterior en esta población. Esto se confirma si la prueba A/A también muestra el desequilibrio. Solución: reasigne con una sal nueva y reinicie. El arrastre de una prueba anterior es la versión silenciosa de este problema, y ​​solo la prueba A/A lo revela.
5. Interferencia. Síntoma: el desequilibrio se concentra en un pequeño número de identificadores de alta actividad o en rangos de IP internos. Verificación: la distribución del recuento de exposición por usuario y el 1 % superior de identificadores por volumen de eventos. Confirme si al eliminarlos se restablece la proporción. Solución: excluya el tráfico interno y el generado por scripts mediante una regla documentada, no manualmente, para que la exclusión sea idéntica la próxima vez.

Un recorrido guiado paso a paso.

Los números a continuación son ilustrativos, no datos del cliente. Una prueba de checkout informa 61,480 exposiciones de control y 58,520 de variantes: 51.2/48.8 en 120,000 usuarios, chi-cuadrado p por debajo de 0.001. Rama 1: eliminar la condición de activación devuelve 60,020 / 59,980, por lo que la asignación es correcta y la pérdida ocurre después de la exposición. Rama 2: los recuentos de canalización coinciden, exclusiones de bots 0.9% en ambos brazos. Rama 3: escritorio se sitúa en 50.1/49.9, móvil en 52.4/47.6, y el tiempo medio de exposición de la variante es 900 ms mayor en móvil. Diagnóstico: la variante envía una solicitud adicional que bloquea la renderización, los usuarios móviles abandonan durante ella, los supervivientes tienen mejores conexiones. La lectura es nula. La corrección es una corrección de rendimiento, y la prueba se vuelve a ejecutar, no se reinterpreta.

Lo que se puede salvar y lo que no.

• Anular la lectura cuando el mecanismo de pérdida pueda correlacionarse plausiblemente con la métrica. Cada causa de ejecución y asignación califica por defecto.
• Recuperación por segmento Solo cuando el desequilibrio se limita a un segmento que se puede excluir claramente, ese segmento se definió antes de analizar la métrica y el resto supera su propia verificación SRM. Dos de tres no son suficientes.
• Conserva la prueba Cuando la causa radicaba únicamente en el análisis y el cuadro de mando corregido es satisfactorio. Estás releyendo los mismos datos con un filtro fijo, no buscando información errónea.
• Regístrelo de cualquier manera. Registra la categoría de la causa en el experimento. La taxonomía resulta rentable de forma acumulativa: si tres de tus últimas diez pruebas fallaron en la rama 3, el problema no es la experimentación, sino la entrega del front-end. [DATOS INTERNOS NECESARIOS: porcentaje de experimentos ejecutados por Switas en los últimos 24 meses que fallaron una verificación SRM, desglosado por rama de taxonomía, para reemplazar el valor de referencia del 6 % de Microsoft con una cifra de este mercado].

Aquí es donde se produce el fallo

Este árbol presupone una prueba de dos brazos con una asignación fija y conocida y aleatorización a nivel de usuario. No abarca pruebas de múltiples brazos, que requieren la prueba chi-cuadrado completa en todos los brazos más un seguimiento para determinar qué par está fuera, ni asignaciones escalonadas, donde la proporción esperada cambia durante la prueba y una prueba chi-cuadrado acumulativa es directamente incorrecta. No se aplica a diseños aleatorios por conglomerados o geoaleatorizados, donde la unidad no es el usuario y el desequilibrio relevante reside en las características del conglomerado. No indica si la definición de su métrica es correcta. Y no puede ayudar cuando las exposiciones no se registran y usted infiere la asignación a partir de un evento métrico, lo cual no es una verificación de división sino una suposición.

Preguntas Frecuentes

¿Una división 51/49 siempre supone un problema? Depende completamente de n. Con 5,000 exposiciones, se trata de ruido ordinario; con 500 000, es un defecto casi seguro. Compare la relación con la tabla de detectabilidad, no con una regla general de porcentaje fijo.

¿Puedo simplemente recalcular el peso de los brazos estadísticamente en lugar de volver a ejecutar la prueba? No. El reajuste de ponderación corrige los recuentos y mantiene la selección intacta. Los usuarios que perdiste ya no están, y no constituían una muestra aleatoria del grupo.

¿Con qué frecuencia debo consultar el valor p de SRM? Una sola vez, al final, en recuentos acumulativos, a menos que su plataforma ejecute un procedimiento secuencial. Consultar diariamente una prueba chi-cuadrado de horizonte fijo aumenta considerablemente las falsas alarmas.

¿SRM también invalida las métricas de protección? Sí, por la misma razón. Si las poblaciones involucradas son diferentes, una línea de control plana no es más confiable que una métrica primaria variable.

¿Qué ocurre si una prueba A/A también muestra una discrepancia? Entonces, el problema reside en la asignación o en el proceso de registro, no en el tratamiento. Solucione esto antes de ejecutar cualquier otra cosa, ya que está contaminando todas las pruebas en esa plataforma.

¿Las pruebas de redirección siempre provocan SRM? No siempre, pero conllevan un riesgo estructural que ningún otro diseño presenta, ya que la navegación adicional se encuentra en un solo brazo. Si necesita usar uno, verifique la relación según la velocidad de conexión y el dispositivo antes de interpretar cualquier métrica.

Mi tráfico es demasiado bajo como para que la verificación tenga algún sentido. ¿Qué hago entonces? Supervise los recuentos diarios de exposición sin procesar para detectar desviaciones persistentes, ejecute una verificación automática periódica en la capa de asignación y registre previamente una lista más extensa de comprobaciones de coherencia. Está sustituyendo el poder estadístico por el proceso.

¿El filtrado de bots debe realizarse antes o después de la asignación? Tras el registro de la exposición, antes del análisis, se utilizan reglas deterministas aplicadas de forma idéntica a ambos brazos. El filtrado heurístico dentro del SDK es lo que provoca que el filtro en sí mismo genere la discrepancia.

Ejecuta la comprobación en tu propio programa experimental.

Si desea una segunda opinión sobre el estado de las pruebas que está ejecutando actualmente, o una revisión de la asignación y la capa de registro de las que dependen, eso es lo que nuestro Servicio de CRO y experimentación hace.

Fuentes

• Fabijan, Gupchup, Gupta, Omhover, Vermeer, Dmitriev, "Diagnóstico de la discrepancia en la proporción de muestras en experimentos controlados en línea: una taxonomía y reglas prácticas para profesionales", KDD 2019
• Documentación de AB Tasty, desajuste de la relación de muestras (S-SRM secuencial, umbral 0.01)
• Statsig, "Guía rápida para la discrepancia en la proporción de muestras", 31 de agosto de 2023 (chi-cuadrado, umbral 0.01)
• Documentación de GrowthBook, Experimentación (chi-cuadrado, advertencia por debajo de 0.001)
• Imperva, "Informe sobre bots maliciosos 2026: Bots en la era de los agentes", 29 de abril de 2026
• Ministerio de Comercio de la República de Turquía, cifras de comercio electrónico de 2025, 12 de mayo de 2026
• Plataforma de etiquetas de Google, modo de consentimiento y comportamiento de almacenamiento
• Documentación y preguntas frecuentes de SRM Checker, Lukas Vermeer