Paradoja de Simpson en Test A/B: segmento y total
Por qué todo segmento puede perder mientras el total gana, qué causa la paradoja de Simpson en un test A/B y cómo corregir el experimento.
📚 Este artículo es parte de la guía Significancia Estadística en Tests A/B: La Guía.
La paradoja de Simpson es cuando tu test A/B reporta un ganador claro en el total mientras cada segmento dentro de él reporta lo contrario. La aritmética no está rota: el agregado es un promedio ponderado, y cuando los dos brazos cargan mezclas diferentes de usuarios, el total puede apuntar a un lugar al que ningún segmento apunta. Esta guía cubre un ejemplo trabajado con números reales, las causas que producen esto en un experimento online, la única comprobación que atrapa el problema antes de engañar a alguien, y cómo arreglar un test que ya cayó en ella. Forma parte de nuestra guía completa de test A/B y depende del diagnóstico de SRM, reparto desigual de tráfico.
Un ejemplo trabajado en el que todo segmento pierde y el total gana
Un test en la página de precios corre durante dos semanas y termina con 30.000 visitantes en cada brazo, un reparto general perfectamente equilibrado. El panel dice que la variación ganó con holgura. Este es el test entero, abierto por dispositivo.
| Segmento | Visitantes control | Conversiones control | Tasa control | Visitantes variación | Conversiones variación | Tasa variación | Ganador |
|---|---|---|---|---|---|---|---|
| Escritorio | 10.000 | 600 | 6,00% | 20.000 | 1.160 | 5,80% | Control, por 3,33% relativo |
| Móvil | 20.000 | 400 | 2,00% | 10.000 | 190 | 1,90% | Control, por 5,00% relativo |
| Total | 30.000 | 1.000 | 3,333% | 30.000 | 1.350 | 4,500% | Variación, por 35,0% relativo |
Todo número de esa tabla es correcto. Compruébalo tú mismo:
Test z bilateral de dos proporciones. "Sin significancia" casi siempre significa que falta muestra, no que las versiones sean iguales.
La comparación agregada da z = 7,37 y valor p de cerca de 0,0000000000002, ganancia de +35,0%, intervalo de confianza de +0,86 a +1,48 puntos porcentuales. Si un resultado así cayera en tu panel, lo lanzarías sin dudar.
Ahora los segmentos. Escritorio: 6,00% contra 5,80%, z = -0,69, valor p 0,4871, control por delante. Móvil: 2,00% contra 1,90%, z = -0,59, valor p 0,5565, control por delante otra vez. Ninguno es significativo por sí solo, pero los dos apuntan hacia el mismo lado, y esa dirección es la opuesta a la del total.
Por qué ocurre la paradoja de Simpson: el total es un promedio ponderado
Mira la mezcla de segmentos dentro de cada brazo, y no las tasas de conversión.
- Control: 10.000 de escritorio y 20.000 de móvil, es decir 33,3% escritorio y 66,7% móvil.
- Variación: 20.000 de escritorio y 10.000 de móvil, es decir 66,7% escritorio y 33,3% móvil.
Escritorio convierte tres veces mejor que móvil. La variación recibió el doble del segmento bueno, y eso vale mucho más que la pequeña penalización que carga dentro de cada segmento. Crook y colegas, en Microsoft, escribiendo sobre trampas de experimentación en 2009, plantean el álgebra de forma directa: es perfectamente posible que una fracción sea menor que otra, y que una segunda fracción también sea menor que su correspondiente, mientras la suma de los numeradores sobre la suma de los denominadores invierte la comparación.
Su ejemplo es una rampa de tráfico, y vale la pena reproducirlo porque es el caso que la mayoría de los equipos va a encontrar de verdad. Un sitio con un millón de visitantes por día corre un experimento con reparto 99 a 1 el viernes y sube el tratamiento al 50% el sábado. El tratamiento convierte mejor el viernes (2,30% contra 2,02%) y mejor el sábado (1,20% contra 1,00%), y aun así combinar los dos días hace que el tratamiento parezca peor: 1,20% contra 1,68%. La dirección de la paradoja se invirtió respecto a nuestro ejemplo de dispositivo, pero el mecanismo es idéntico. El sábado fue un día peor en general, y compuso la mitad de los datos del tratamiento y solo un tercio de los del control.
La única comprobación que atrapa: verificación de reparto por segmento
La paradoja de Simpson necesita asignación desigual para existir. Una verificación de SRM mide la asignación desigual directamente, así que correrla dentro de cada segmento es el diagnóstico.
En nuestro ejemplo los números son escandalosos. El total del experimento es 30.000 contra 30.000, lo que da chi cuadrado de 0,00 y valor p de 1,00: aprobación impecable en el nivel general. Dentro de escritorio el reparto es 10.000 contra 20.000, lo que da chi cuadrado de 3.333,33 con un grado de libertad y valor p indistinguible de cero. Móvil es la imagen especular, chi cuadrado de 3.333,33 en la otra dirección. Un test puede pasar la comprobación de reparto general y aun así estar hecho de dos mitades completamente desbalanceadas.
Dmitriev y colegas convierten esto en regla explícita, y añaden el caso que la mayoría de los equipos no ve venir: la definición del segmento no puede ser afectada por el tratamiento. Ellos describen un experimento de ranking en Bing en el que tanto los usuarios que vieron cierto enlace extra como los que no lo vieron mostraron un aumento significativo en sesiones por usuario, mientras la población combinada no mostró ningún cambio. El experimento no había movido las sesiones por usuario. Había movido quién caía en cuál segmento, y los usuarios menos activos que salieron del primer grupo elevaron su promedio y también el promedio del grupo al que entraron. La recomendación es directa: prueba SRM en cada grupo de segmento, y cuando la proporción difiera de forma significativa, los resultados de ese grupo, y normalmente de todos los grupos de ese segmento, son inválidos y deben ignorarse.
Hay una segunda disciplina en la misma sección. Rebanar la población recursivamente hasta que algo alcance significancia es un error separado que también invita a la paradoja, y la aritmética es ingrata: con grupos de segmento independientes leídos a un umbral del 5%, cerca de 1 de cada 20 va a parecer significativo solo por azar. Declara antes de lanzar qué segmentos pretendes reportar, o aplica una corrección como Bonferroni al analizarlos después. La mecánica de esa corrección está en test A/B/n con varias variantes.
Cómo arreglar un test que ya cayó en esto
Crook y colegas listan tres remedios, y son francos sobre cuál de ellos de hecho usan.
| Remedio | Cómo funciona | Cuándo sirve |
|---|---|---|
| Descartar los datos de la rampa | Analizar solo el período en que la asignación se mantuvo estable | El que ellos prefieren, porque la rampa suele ser corta en relación con el test entero |
| Emparejar dentro de períodos estables | Comparar control y tratamiento dentro de cada ventana en que las proporciones no cambiaron, y después combinar | Cuando la asignación cambió más de una vez y los tramos estables son lo bastante largos |
| Combinación ponderada | Repesar cada segmento por su porción real de tráfico antes de promediar | Cuando el desequilibrio es entre segmentos, y no a lo largo del tiempo |
El tercero aplicado a nuestro ejemplo es instructivo. Escritorio y móvil responden por 30.000 de los 60.000 visitantes cada uno, así que ponderarlos por igual da una estimación corregida de 4,000% para el control (la mitad de 6,00 más la mitad de 2,00) y 3,850% para la variación (la mitad de 5,80 más la mitad de 1,90). La aparente ganancia de +35,0% se convierte en una pérdida del 3,75%, que es la dirección a la que los dos segmentos apuntaban desde el principio.
La forma más limpia de ver lo que el test habría dicho es correrlo de nuevo con la mezcla equilibrada. Dale a cada brazo 15.000 visitantes de escritorio y 15.000 de móvil, exactamente con las mismas tasas por segmento, y el control termina con 1.200 conversiones en 30.000 visitantes (4,000%) contra 1.155 de la variación (3,850%). Esa comparación da z = -0,95, valor p 0,3441, intervalo de confianza de -0,46 a +0,16 puntos porcentuales. No es una ganadora del 35%. Tampoco es una perdedora probada. Inconcluso, levemente negativo, que es una frase muy diferente de la que estaba en el panel original.
De dónde viene el desequilibrio detrás de la paradoja de Simpson
| Causa | Cómo aparece | Prevención |
|---|---|---|
| Rampa dentro de la ventana de análisis | La asignación empieza en 5% o 10% y se aumenta a mitad del test, y todo se analiza junto | Descartar el período de rampa, o fijar la asignación antes de abrir la ventana de medición |
| Asignación diferente por región o plataforma | Un país o versión de la app corre un reparto diferente porque un equipo local lo dimensionó por su cuenta | Analizar por región y nunca juntar brazos con repartos diferentes |
| Segmento limitado | Clientes de alto valor deliberadamente restringidos a una porción pequeña del tratamiento | Reportar ese segmento por separado y nunca plegarlo dentro del número de titular |
| Muestreo no uniforme | Algunos navegadores o clases de dispositivo muestreados a mayor tasa por cuestión de cobertura | Repesar por la porción real de la población antes de combinar |
| Segmento que el propio tratamiento mueve | Pertenecer al segmento depende de algo que el cambio hace más o menos probable | Correr la comprobación de reparto por segmento; reprobar significa que todo grupo de ese segmento es ilegible |
| Falla de redirección o de carga en un brazo | Una variación pierde en silencio una porción de un segmento porque es más lenta o se rompe en algún punto | Eso es reparto desigual de tráfico (SRM) puro, y la corrección es causa raíz más repetir el test |
Fíjate en que solo la última fila es un defecto. Las otras son decisiones operativas comunes y sensatas, que solo se vuelven peligrosas en el momento en que alguien junta los brazos en un único número sin comprobar si juntarlos era legítimo.
Errores comunes con segmento y total
| Error | Qué produce |
|---|---|
| Leer solo el total | Un artefacto de promedio ponderado se lanza como victoria del 35% |
| Leer solo los segmentos | El artefacto opuesto, más un problema de comparaciones múltiples que nadie corrigió |
| Correr la comprobación de reparto solo en el total | La comprobación que atraparía el problema pasa perfectamente, como en el ejemplo de arriba |
| Rebanar hasta que algo salga significativo | Cerca de 1 de cada 20 rebanadas independientes parece significativa por azar, y la paradoja se vuelve más probable cuanto más hondo se va |
| Segmentar por algo que el tratamiento cambia | Todo grupo de ese segmento queda ilegible, por más limpios que parezcan los números |
| Llamarlo efecto heterogéneo | Lleva a lanzar el cambio para una clase de dispositivo cuando el problema real era un bug de asignación |
| Repesar y declarar victoria | Recupera la dirección, pero no la precisión; un test muy contaminado debe rehacerse |
Si los segmentos de hecho discrepan entre sí en un test cuya asignación estaba limpia dentro de cada uno, entonces es otra situación, bastante más interesante: un efecto heterogéneo de verdad, que nuestra guía de errores comunes en tests A/B trata junto a las amenazas de validez con las que suele confundirse.
Hazlo automático en Donnu
La paradoja de Simpson sobrevive en un panel que muestra un número agregado y esconde el reparto detrás de él. Donnu A/B corre la verificación de proporción dentro de cada segmento reportado, además del total del experimento, señala el segmento cuya asignación no coincide con el reparto configurado antes de mostrar sus números de conversión, y mantiene la mezcla de segmentos de cada brazo visible al lado del resultado de titular. Cuando el total y los segmentos apuntan en direcciones opuestas, esa contradicción aparece como aviso, en vez de quedarse esperando a que alguien lo note durante una reunión.
Empieza una prueba gratis de 14 días y comprueba el reparto dentro de tus propios segmentos antes de leer cualquier tasa de conversión.
Referencias
- Crook, T., Frasca, B., Kohavi, R. y Longbotham, R. Seven Pitfalls to Avoid when Running Controlled Experiments on the Web. KDD 2009. Fuente del ejemplo de rampa con los repartos del viernes y el sábado, de las cuatro situaciones que producen la paradoja en un experimento online, y de los tres remedios, incluyendo descartar el período de rampa. Es también de donde viene la atribución del nombre a Simpson (1951). exp-platform.com.
- Dmitriev, P., Gupta, S., Kim, D. W. y Vaz, G. A Dirty Dozen: Twelve Common Metric Interpretation Pitfalls in Online Controlled Experiments. KDD 2017. Fuente del caso de ranking en Bing en el que los dos segmentos se movieron y el total no, de la regla de que la definición del segmento no puede ser afectada por el tratamiento, de la recomendación de correr SRM por grupo de segmento, y de la aritmética de 1 de cada 20 para segmentación recursiva. exp-platform.com.
- Kohavi, R., Deng, A., Frasca, B., Walker, T., Xu, Y. y Pohlmann, N. Online Controlled Experiments at Large Scale. KDD 2013. Sobre rampa de asignación y monitoreo automático de calidad de datos en una plataforma grande de experimentación. exp-platform.com.
- Kohavi, R., Tang, D. y Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020. Capítulos sobre confiabilidad del experimento, segmentación y rampa. Material complementario en experimentguide.com.
Lee también: SRM: reparto desigual de tráfico · Significancia estadística en test A/B · Test A/B/n con varias variantes · Errores comunes en tests A/B · Verificador de SRM gratis · Leia em português · Read in English
Preguntas frecuentes
- ¿Qué es la paradoja de Simpson en un test A/B?
- La paradoja de Simpson es cuando el resultado agregado del test apunta hacia un lado mientras cada segmento individual apunta hacia el otro. No es un error de cuentas: es matemáticamente posible que una variación pierda en escritorio, pierda en móvil y aun así gane en el total, porque el agregado es un promedio ponderado y los dos brazos pueden cargar pesos diferentes. En un experimento online la causa habitual es que el reparto de tráfico no fue idéntico dentro de cada segmento, lo que pasa en una rampa de tráfico, en asignaciones por país o cuando un segmento fue limitado a propósito.
- ¿Cómo gana una variación en el total y pierde en todos los segmentos?
- Porque los brazos no se hicieron con la misma mezcla de usuarios. Toma un test en el que el control recibió 10.000 visitantes de escritorio y 20.000 de móvil mientras la variación recibió 20.000 de escritorio y 10.000 de móvil. Escritorio convierte al 6% y móvil al 2%, y la variación es un poco peor en ambos. Los totales aun así salen 3,333% para el control y 4,500% para la variación, una ganancia aparente del 35%, porque la variación fue alimentada con más del segmento que convierte mejor. Nada en el cambio probado causó esa distancia.
- ¿Cómo detectar la paradoja de Simpson antes de ser engañado por ella?
- Corre una verificación de SRM dentro de cada segmento que pretendes reportar, no solo en el total del experimento. Es esa comprobación la que atrapa el problema, porque la paradoja necesita asignación desigual para existir y el test de SRM mide exactamente eso. En el ejemplo de arriba, el reparto general es un 30.000 contra 30.000 perfecto, con chi cuadrado 0 y valor p 1, así que la comprobación de arriba pasa limpia, mientras que el reparto dentro de escritorio, de 10.000 contra 20.000, da chi cuadrado 3.333 y valor p indistinguible de cero.
- ¿Qué causa la paradoja de Simpson en experimentos online?
- Crook y colegas (KDD 2009) listan la rampa de tráfico como la causa más común: un experimento que corre al 1% de asignación un día y al 50% al día siguiente, y después se analiza juntando los dos días, mezcla dos ponderaciones diferentes. Sus otros ejemplos son muestreo no uniforme por navegador, asignaciones diferentes por país y un segmento de clientes valiosos limitado a propósito a una porción pequeña. Dmitriev y colegas (KDD 2017) añaden un caso más sutil: un segmento cuya propia composición es alterada por el tratamiento, como haber visto o no una funcionalidad que el tratamiento muestra menos.
- ¿Puedo simplemente reportar los segmentos en vez del total?
- Solo si la definición del segmento no fue afectada por el tratamiento y has resuelto el problema de comparaciones múltiples. El segmento es la unidad correcta cuando la asignación difirió por segmento, pero rebanar recursivamente hasta que algo salga significativo es una falla separada y muy común: con grupos de segmento independientes a un umbral del 5%, cerca de 1 de cada 20 va a parecer significativo solo por azar. Declara antes de lanzar qué segmentos vas a reportar, o aplica una corrección como Bonferroni al analizarlos después.
- ¿Cuál es la corrección después de que la paradoja de Simpson ya ocurrió?
- La corrección más simple, y la que el equipo de experimentación de Microsoft dice usar, es descartar los datos del período de rampa, que normalmente es corto en relación con el test entero. Las alternativas que ellos listan son emparejar control y tratamiento dentro de ventanas en que las proporciones se mantuvieron estables, y usar combinaciones ponderadas que repesan cada segmento por la porción real de tráfico. En el ejemplo trabajado, ponderar los dos segmentos por igual convierte una ganancia aparente del 35% en una pérdida del 3,75%.
- ¿La paradoja de Simpson es lo mismo que un efecto heterogéneo?
- No, y confundir los dos lleva a la acción equivocada. Un efecto heterogéneo es real: el cambio de hecho ayuda al usuario de móvil y perjudica al de escritorio, y la respuesta correcta es decidir para quién lanzar. La paradoja de Simpson es un artefacto de ponderación desigual, y la respuesta correcta es corregir la asignación y releer el test. La pregunta que separa a los dos es si la proporción del reparto fue la misma dentro de cada segmento, y por eso la comprobación de SRM por segmento viene antes de cualquier interpretación.