Paradoxo de Simpson em Teste A/B: segmento x total
Por que todo segmento pode perder enquanto o total vence, o que causa o paradoxo de Simpson em teste A/B e como corrigir o experimento.
📚 Este artigo faz parte do guia Significância Estatística em Teste A/B: O Guia.
O paradoxo de Simpson é quando o seu teste A/B reporta um vencedor claro no total enquanto cada segmento dentro dele reporta o contrário. A aritmética não está quebrada: o agregado é uma média ponderada, e quando os dois braços carregam misturas diferentes de usuários, o total pode apontar para um lugar que nenhum segmento aponta. Este guia cobre um exemplo trabalhado com números reais, as causas que produzem isso em experimento online, a única checagem que pega o problema antes de enganar alguém, e como consertar um teste que já caiu nele. Faz parte do nosso guia completo de teste A/B e depende do diagnóstico de SRM, divisão desigual de tráfego.
Um exemplo trabalhado em que todo segmento perde e o total vence
Um teste na página de preços roda por duas semanas e termina com 30.000 visitantes em cada braço, uma divisão de topo perfeitamente equilibrada. O painel diz que a variação venceu com folga. Este é o teste inteiro, aberto por dispositivo.
| Segmento | Visitantes controle | Conversões controle | Taxa controle | Visitantes variação | Conversões variação | Taxa variação | Vencedor |
|---|---|---|---|---|---|---|---|
| Desktop | 10.000 | 600 | 6,00% | 20.000 | 1.160 | 5,80% | Controle, por 3,33% relativos |
| Mobile | 20.000 | 400 | 2,00% | 10.000 | 190 | 1,90% | Controle, por 5,00% relativos |
| Total | 30.000 | 1.000 | 3,333% | 30.000 | 1.350 | 4,500% | Variação, por 35,0% relativos |
Todo número dessa tabela está correto. Confira você mesmo:
Teste z bilateral de duas proporções. "Sem significância" quase sempre quer dizer que falta amostra, não que as versões são iguais.
A comparação agregada dá z = 7,37 e valor-p de cerca de 0,0000000000002, ganho de +35,0%, intervalo de confiança de +0,86 a +1,48 ponto percentual. Se um resultado desses caísse no seu painel, você subiria sem hesitar.
Agora os segmentos. Desktop: 6,00% contra 5,80%, z = -0,69, valor-p 0,4871, controle na frente. Mobile: 2,00% contra 1,90%, z = -0,59, valor-p 0,5565, controle na frente de novo. Nenhum é significativo sozinho, mas os dois apontam para o mesmo lado, e essa direção é o oposto da do total.
Por que o paradoxo de Simpson acontece: o total é média ponderada
Olhe a mistura de segmentos dentro de cada braço, e não as taxas de conversão.
- Controle: 10.000 de desktop e 20.000 de mobile, ou seja 33,3% desktop e 66,7% mobile.
- Variação: 20.000 de desktop e 10.000 de mobile, ou seja 66,7% desktop e 33,3% mobile.
Desktop converte três vezes melhor que mobile. A variação recebeu o dobro do segmento bom, e isso vale muito mais que a pequena penalidade que ela carrega dentro de cada segmento. Crook e colegas, na Microsoft, escrevendo sobre armadilhas de experimentação em 2009, colocam a álgebra de forma direta: é perfeitamente possível uma fração ser menor que outra, e uma segunda fração também ser menor que a sua correspondente, enquanto a soma dos numeradores sobre a soma dos denominadores inverte a comparação.
O exemplo deles é uma rampa de tráfego, e vale reproduzir porque é o caso que a maioria dos times vai encontrar de verdade. Um site com um milhão de visitantes por dia roda um experimento com divisão 99 para 1 na sexta-feira e sobe o tratamento para 50% no sábado. O tratamento converte melhor na sexta (2,30% contra 2,02%) e melhor no sábado (1,20% contra 1,00%), e mesmo assim combinar os dois dias faz o tratamento parecer pior: 1,20% contra 1,68%. A direção do paradoxo inverteu em relação ao nosso exemplo de dispositivo, mas o mecanismo é idêntico. O sábado foi um dia pior no geral, e ele compôs metade dos dados do tratamento e só um terço dos do controle.
A única checagem que pega: verificação de divisão por segmento
O paradoxo de Simpson precisa de alocação desigual para existir. Uma verificação de SRM mede alocação desigual diretamente, então rodá-la dentro de cada segmento é o diagnóstico.
No nosso exemplo os números são gritantes. O total do experimento é 30.000 contra 30.000, o que dá qui-quadrado de 0,00 e valor-p de 1,00: aprovação impecável no nível de topo. Dentro do desktop a divisão é 10.000 contra 20.000, o que dá qui-quadrado de 3.333,33 com um grau de liberdade e valor-p indistinguível de zero. O mobile é a imagem espelhada, qui-quadrado de 3.333,33 na outra direção. Um teste pode passar na checagem de divisão do topo e ainda assim ser feito de duas metades completamente desbalanceadas.
Dmitriev e colegas transformam isso em regra explícita, e acrescentam o caso que a maioria dos times não vê chegando: a definição do segmento não pode ser afetada pelo tratamento. Eles descrevem um experimento de ranqueamento no Bing em que tanto os usuários que viram um certo link extra quanto os que não viram mostraram aumento significativo em sessões por usuário, enquanto a população combinada não mostrou mudança nenhuma. O experimento não tinha movido sessões por usuário. Ele tinha movido quem caía em qual segmento, e os usuários menos ativos que saíram do primeiro grupo elevaram a média dele e também a média do grupo em que entraram. A recomendação é direta: teste SRM em cada grupo de segmento, e quando a proporção diferir de forma significativa, os resultados daquele grupo, e normalmente de todos os grupos daquele segmento, são inválidos e devem ser ignorados.
Há uma segunda disciplina na mesma seção. Fatiar a população recursivamente até algo alcançar significância é um erro separado que também convida o paradoxo, e a aritmética é ingrata: com grupos de segmento independentes lidos a um limiar de 5%, cerca de 1 em 20 vai parecer significativo só por acaso. Declare antes de subir quais segmentos você pretende reportar, ou aplique uma correção como Bonferroni ao analisá-los depois. A mecânica dessa correção está em teste A/B/n com várias variações.
Como consertar um teste que já caiu nisso
Crook e colegas listam três remédios, e são francos sobre qual deles de fato usam.
| Remédio | Como funciona | Quando serve |
|---|---|---|
| Descartar os dados da rampa | Analisar só o período em que a alocação ficou estável | O preferido deles, porque a rampa costuma ser curta em relação ao teste inteiro |
| Parear dentro de períodos estáveis | Comparar controle e tratamento dentro de cada janela em que as proporções não mudaram, e depois combinar | Quando a alocação mudou mais de uma vez e os trechos estáveis são longos o bastante |
| Combinação ponderada | Repesar cada segmento pela sua fatia real de tráfego antes de fazer a média | Quando o desequilíbrio é entre segmentos, e não ao longo do tempo |
O terceiro aplicado ao nosso exemplo é instrutivo. Desktop e mobile respondem por 30.000 dos 60.000 visitantes cada, então ponderá-los igualmente dá uma estimativa corrigida de 4,000% para o controle (metade de 6,00 mais metade de 2,00) e 3,850% para a variação (metade de 5,80 mais metade de 1,90). O aparente ganho de +35,0% vira uma perda de 3,75%, que é a direção para a qual os dois segmentos apontavam desde o começo.
O jeito mais limpo de ver o que o teste teria dito é rodá-lo de novo com a mistura equilibrada. Dê a cada braço 15.000 visitantes de desktop e 15.000 de mobile, exatamente com as mesmas taxas por segmento, e o controle termina com 1.200 conversões em 30.000 visitantes (4,000%) contra 1.155 da variação (3,850%). Essa comparação dá z = -0,95, valor-p 0,3441, intervalo de confiança de -0,46 a +0,16 ponto percentual. Não é vencedora de 35%. Também não é perdedora provada. Inconclusivo, levemente negativo, que é uma frase muito diferente da que estava no painel original.
De onde vem o desequilíbrio por trás do paradoxo de Simpson
| Causa | Como aparece | Prevenção |
|---|---|---|
| Rampa dentro da janela de análise | A alocação começa em 5% ou 10% e é aumentada no meio do teste, e tudo é analisado junto | Descartar o período de rampa, ou travar a alocação antes de abrir a janela de medição |
| Alocação diferente por região ou plataforma | Um país ou versão do app roda uma divisão diferente porque um time local dimensionou por conta | Analisar por região e nunca juntar braços com divisões diferentes |
| Segmento limitado | Clientes de alto valor deliberadamente restritos a uma fatia pequena do tratamento | Reportar esse segmento em separado e nunca dobrá-lo dentro do número de manchete |
| Amostragem não uniforme | Alguns navegadores ou classes de dispositivo amostrados a taxa maior por questão de cobertura | Repesar pela fatia real da população antes de combinar |
| Segmento que o próprio tratamento move | Pertencer ao segmento depende de algo que a mudança torna mais ou menos provável | Rodar a checagem de divisão por segmento; reprovar significa que todo grupo daquele segmento é ilegível |
| Falha de redirect ou de carregamento num braço | Uma variação perde em silêncio uma fatia de um segmento porque é mais lenta ou quebra em algum ponto | Isso é divisão desigual de tráfego (SRM) puro, e a correção é causa raiz mais reteste |
Repare que só a última linha é um defeito. As outras são escolhas operacionais comuns e sensatas, que só ficam perigosas no momento em que alguém junta os braços num único número sem checar se juntar era legítimo.
Erros comuns com segmento e total
| Erro | O que produz |
|---|---|
| Ler só o total | Um artefato de média ponderada sobe como vitória de 35% |
| Ler só os segmentos | O artefato oposto, mais um problema de comparações múltiplas que ninguém corrigiu |
| Rodar a checagem de divisão só no topo | A checagem que pegaria o problema passa perfeitamente, como no exemplo acima |
| Fatiar até algo dar significativo | Cerca de 1 em 20 fatias independentes parece significativa por acaso, e o paradoxo fica mais provável quanto mais fundo se vai |
| Segmentar por algo que o tratamento muda | Todo grupo daquele segmento fica ilegível, por mais limpos que os números pareçam |
| Chamar de efeito heterogêneo | Leva a subir a mudança para uma classe de dispositivo quando o problema real era um bug de alocação |
| Repesar e declarar vitória | Recupera a direção, mas não a precisão; teste muito contaminado deve ser refeito |
Se os segmentos de fato discordam entre si num teste cuja alocação estava limpa dentro de cada um, aí é outra situação, bem mais interessante: um efeito heterogêneo de verdade, que nosso guia de erros comuns em teste A/B trata ao lado das ameaças de validade com que ele costuma ser confundido.
Faça isso automático na Donnu
O paradoxo de Simpson sobrevive num painel que mostra um número agregado e esconde a divisão por trás dele. A Donnu A/B roda a verificação de proporção dentro de cada segmento reportado, além do total do experimento, sinaliza segmento cuja alocação não bate com a divisão configurada antes de mostrar os números de conversão dele, e mantém a mistura de segmentos de cada braço visível ao lado do resultado de manchete. Quando o total e os segmentos apontam em direções opostas, essa contradição aparece como aviso, em vez de ficar esperando alguém reparar durante uma reunião.
Comece um teste grátis de 14 dias e cheque a divisão dentro dos seus próprios segmentos antes de ler qualquer taxa de conversão.
Referências
- Crook, T., Frasca, B., Kohavi, R. e Longbotham, R. Seven Pitfalls to Avoid when Running Controlled Experiments on the Web. KDD 2009. Fonte do exemplo de rampa com as divisões de sexta e sábado, das quatro situações que produzem o paradoxo em experimento online, e dos três remédios, incluindo descartar o período de rampa. É também de onde vem a atribuição do nome a Simpson (1951). exp-platform.com.
- Dmitriev, P., Gupta, S., Kim, D. W. e Vaz, G. A Dirty Dozen: Twelve Common Metric Interpretation Pitfalls in Online Controlled Experiments. KDD 2017. Fonte do caso de ranqueamento no Bing em que os dois segmentos se moveram e o total não, da regra de que a definição do segmento não pode ser afetada pelo tratamento, da recomendação de rodar SRM por grupo de segmento, e da aritmética de 1 em 20 para segmentação recursiva. exp-platform.com.
- Kohavi, R., Deng, A., Frasca, B., Walker, T., Xu, Y. e Pohlmann, N. Online Controlled Experiments at Large Scale. KDD 2013. Sobre rampa de alocação e monitoramento automático de qualidade de dados numa plataforma grande de experimentação. exp-platform.com.
- Kohavi, R., Tang, D. e Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020. Capítulos sobre confiabilidade do experimento, segmentação e rampa. Material complementar em experimentguide.com.
Leia também: SRM: divisão desigual de tráfego · Significância estatística em teste A/B · Teste A/B/n com várias variações · Erros comuns em teste A/B · Verificador de SRM grátis · Read in English
Perguntas frequentes
- O que é o paradoxo de Simpson em teste A/B?
- O paradoxo de Simpson é quando o resultado agregado do teste aponta para um lado enquanto cada segmento individual aponta para o outro. Não é erro de conta: é matematicamente possível uma variação perder no desktop, perder no mobile e ainda assim vencer no total, porque o agregado é uma média ponderada e os dois braços podem carregar pesos diferentes. Em experimento online a causa usual é que a divisão de tráfego não foi idêntica dentro de cada segmento, o que acontece em rampa de tráfego, em alocação por país ou quando um segmento foi limitado de propósito.
- Como uma variação vence no total e perde em todos os segmentos?
- Porque os braços não foram feitos da mesma mistura de usuários. Pegue um teste em que o controle recebeu 10.000 visitantes de desktop e 20.000 de mobile enquanto a variação recebeu 20.000 de desktop e 10.000 de mobile. Desktop converte a 6% e mobile a 2%, e a variação é um pouco pior nos dois. Os totais ainda saem 3,333% para o controle e 4,500% para a variação, um ganho aparente de 35%, porque a variação foi alimentada com mais do segmento que converte melhor. Nada na mudança testada causou essa distância.
- Como detectar o paradoxo de Simpson antes de ser enganado por ele?
- Rode uma verificação de SRM dentro de cada segmento que você pretende reportar, não só no total do experimento. É essa checagem que pega o problema, porque o paradoxo precisa de alocação desigual para existir e o teste de SRM mede exatamente isso. No exemplo acima, a divisão geral é um 30.000 contra 30.000 perfeito, com qui-quadrado 0 e valor-p 1, então a checagem de topo passa limpa, enquanto a divisão dentro do desktop, de 10.000 contra 20.000, dá qui-quadrado 3.333 e valor-p indistinguível de zero.
- O que causa o paradoxo de Simpson em experimentos online?
- Crook e colegas (KDD 2009) listam a rampa de tráfego como causa mais comum: um experimento que roda a 1% de alocação num dia e 50% no dia seguinte, e depois é analisado juntando os dois dias, mistura duas ponderações diferentes. Os outros exemplos deles são amostragem não uniforme por navegador, alocações diferentes por país e um segmento de clientes valiosos limitado de propósito a uma fatia pequena. Dmitriev e colegas (KDD 2017) acrescentam um caso mais sutil: um segmento cuja própria composição é alterada pelo tratamento, como ter visto ou não uma funcionalidade que o tratamento mostra menos.
- Posso simplesmente reportar os segmentos em vez do total?
- Só se a definição do segmento não tiver sido afetada pelo tratamento e você tiver resolvido o problema de comparações múltiplas. Segmento é a unidade certa quando a alocação diferiu por segmento, mas fatiar recursivamente até algo dar significativo é uma falha separada e muito comum: com grupos de segmento independentes a um limiar de 5%, cerca de 1 em 20 vai parecer significativo só por acaso. Declare antes de subir quais segmentos você vai reportar, ou aplique uma correção como Bonferroni ao analisá-los depois.
- Qual é a correção depois que o paradoxo de Simpson já aconteceu?
- A correção mais simples, e a que o time de experimentação da Microsoft diz usar, é descartar os dados do período de rampa, que normalmente é curto em relação ao teste inteiro. As alternativas que eles listam são parear controle e tratamento dentro de janelas em que as proporções ficaram estáveis, e usar combinações ponderadas que repesam cada segmento pela fatia real de tráfego. No exemplo trabalhado, ponderar os dois segmentos igualmente transforma um ganho aparente de 35% numa perda de 3,75%.
- Paradoxo de Simpson é a mesma coisa que efeito heterogêneo?
- Não, e confundir os dois leva à ação errada. Efeito heterogêneo é real: a mudança de fato ajuda o usuário de mobile e prejudica o de desktop, e a resposta certa é decidir para quem subir. O paradoxo de Simpson é artefato de ponderação desigual, e a resposta certa é corrigir a alocação e reler o teste. A pergunta que separa os dois é se a proporção da divisão foi a mesma dentro de cada segmento, e é por isso que a checagem de SRM por segmento vem antes de qualquer interpretação.