SRM: divisão desigual de tráfego em teste A/B

SRM é uma diferença estatisticamente significativa entre a divisão de tráfego que você configurou e a que realmente aconteceu, e é a verificação que decide se o resto da sua análise significa alguma coisa. Se um teste 50/50 termina em 50,6 contra 49,4, isso não é detalhe de arredondamento. É evidência de que alguma coisa decidiu onde cada visitante caiu, e no momento em que algo além do randomizador está escolhendo, os dois grupos deixam de ser comparáveis e a diferença de conversão entre eles não é o efeito da sua mudança. Este guia cobre o que é a verificação, quão pequeno é o desvio que já reprova, como ler o resultado do qui-quadrado, de onde vêm os desvios e o que fazer quando você acha um. Ele faz parte do nosso guia completo de teste A/B e é a outra metade, junto de significância estatística em teste A/B, de um resultado confiável.

O que SRM significa de verdade

A aleatorização é o argumento inteiro de um teste A/B. É ela que permite afirmar que a única diferença sistemática entre controle e variação é a mudança que você subiu. A divisão de amostra é a evidência observável mais barata de que a aleatorização funcionou, porque você já sabe a resposta de antemão: configurou 50/50, espera algo perto de 50/50.

“Perto de” está fazendo trabalho pesado nessa frase, e o teste qui-quadrado de aderência é o que torna isso preciso. Ele faz uma pergunta só: se a atribuição fosse mesmo justa, com que frequência o acaso sozinho produziria uma diferença pelo menos deste tamanho? Quando essa probabilidade cai abaixo do limiar de alarme, o acaso deixa de ser uma explicação plausível.

A consequência é severa e vale dizer sem rodeio. Fabijan e colegas, escrevendo sobre experimentação na Microsoft, Booking.com, Outreach.io e Online Dialog, descrevem o SRM como uma condição que na maioria dos casos invalida completamente o resultado do experimento. Não é uma ressalva de rodapé. É placa de pare.

Quão pequeno é o desvio que já reprova

A parte desconfortável do SRM é que a tolerância encolhe conforme o teste cresce. A diferença absoluta que dispara o alarme cresce mais ou menos com a raiz quadrada da amostra total, então, como percentual do tráfego, ela vai ficando mais apertada. Uma divisão que você descreveria como “praticamente igual” muitas vezes já é um SRM.

Total de visitantes	Menor diferença que dispara	Divisão resultante
2.000	116 visitantes	52,90 / 47,10
10.000	258 visitantes	51,29 / 48,71
20.000	366 visitantes	50,91 / 49,09
50.000	576 visitantes	50,58 / 49,42
100.000	816 visitantes	50,41 / 49,59
200.000	1.152 visitantes	50,29 / 49,71

Números calculados com o mesmo teste qui-quadrado de aderência usado pela calculadora abaixo, com limiar de alarme de 1% e divisão esperada de 50/50. A coluna do meio é a diferença entre os dois braços.

Leia a última linha de novo. Com 200.000 visitantes, uma divisão de 50,29 contra 49,71 é SRM. Nenhum ser humano olhando um painel marcaria isso. Esse é o motivo inteiro de a verificação precisar ser automática e numérica, e não um olhar.

VariaçãoVisitantes observadosAlocação esperada

AVisitantes observadosAlocação esperada

BVisitantes observadosAlocação esperada

+ Adicionar variação

Preencha ao menos duas variações. A alocação esperada é o peso relativo do split (1 e 1 = 50/50, 9 e 1 = 90/10).

χ² (qui-quadrado)-

Graus de liberdade-

valor-p-

Variação	Visitantes observados	Esperado	% real

Teste qui-quadrado de aderência entre a divisão observada e a esperada. O alarme dispara quando o valor-p fica abaixo de 0,01: com esse split, um desvio desse tamanho é raro demais pra ser só acaso. SRM invalida o teste, investigue o motor de divisão antes de ler a conversão.

Lendo o qui-quadrado sem cerimônia

A estatística é simples o bastante para calcular na mão, e vale fazer isso uma vez para o número parar de parecer caixa-preta. Para cada grupo você pega a distância ao quadrado entre observado e esperado, divide pelo esperado, e soma tudo.

Com 48.005 visitantes no total e divisão configurada em 50/50, cada grupo esperava receber 24.002,5. O controle recebeu 24.301, a variação recebeu 23.704, então cada um está a 298,5 da sua expectativa.

qui-quadrado = (24.301 - 24.002,5)^2 / 24.002,5
             + (23.704 - 24.002,5)^2 / 24.002,5
             = 89.102,25 / 24.002,5  x  2
             = 7,42   (1 grau de liberdade)

valor-p      = 0,0064

Grau de liberdade é o número de grupos menos um, então um teste de dois braços tem um. O valor-p responde a única pergunta que importa: uma moeda honesta produziria uma diferença deste tamanho ou maior cerca de 6 vezes em 1.000. Não é impossível, mas é uma aposta ruim quando a explicação alternativa é um bug que você pode ir procurar.

Duas observações que evitam discussão. Primeira: o limiar do SRM é deliberadamente mais rígido que o 0,05 que você usa para conversão, porque cada teste que você roda é mais uma chance de disparar alarme falso, e o custo de investigar um é de algumas horas enquanto o custo de deixar passar um é uma decisão errada. Um limiar de 1% é um padrão de trabalho comum e é o que a calculadora acima usa. Segunda: o valor-p do SRM não mede o tamanho do viés. Ele só diz o quanto você pode confiar que o desequilíbrio é real. Um viés sistemático minúsculo e real num teste enorme produz um valor-p aterrorizante e talvez mal mexa na sua métrica, enquanto um viés grande num teste pequeno pode passar raspando. Use como gatilho de investigação, nunca como nota de gravidade.

Exemplo trabalhado: a vencedora que não existia

Um time de e-commerce testa um checkout reconstruído. O teste é configurado 50/50 e roda até 48.005 visitantes. Este é o placar que eles levam para a reunião.

• Controle: 24.301 visitantes, 1.094 compras, 4,502%
• Variação: 23.704 visitantes, 1.156 compras, 4,877%

Rode esses números e você obtém z = 1,943, valor-p = 0,0520, melhora relativa de +8,33% e intervalo de confiança sobre a diferença de -0,003 a +0,753 ponto percentual. Fora da significância por pouco, na direção positiva, e grande o bastante para importar comercialmente. O instinto da sala é rodar mais dois dias.

Controle (A)

VisitantesConversões

Variação (B)

VisitantesConversões

Confiança90%95%99%

Controle (A) · Taxa-

Variação (B) · Taxa-

Melhora relativa-

valor-p-

IC 95% da diferença-

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.

O instinto está errado, e não por causa do valor-p. A divisão é 50,62 / 49,38, que, como calculamos acima, é SRM com p = 0,0064. Os 597 visitantes que nunca chegaram à variação são a história, e ninguém na sala sabe quem eles eram.

Eis por que reequilibrar não salva isso. Suponha que a gente pergunte qual teria sido o resultado se aqueles 597 visitantes tivessem aparecido. Dois cenários honestos de contorno:

Se eles tivessem se comportado exatamente como o controle e convertido a 4,502%, a variação mostraria 24.301 visitantes e cerca de 1.183 compras. Resultado: p = 0,0561, ganho +8,14%, intervalo de -0,009 a +0,742 ponto percentual.

Se eles fossem visitantes que não conseguiram concluir e tivessem convertido a zero, a variação mostraria 24.301 visitantes e 1.156 compras, uma taxa de 4,757%. Resultado: p = 0,1808, ganho +5,67%, intervalo de -0,118 a +0,629 ponto percentual.

O resultado observado fica entre “quase lá” e “claramente nada”, e os dados não conseguem dizer qual dos dois é. Essa é a definição de experimento inválido. Neste caso a causa raiz era um redirecionamento que estourava o tempo em conexões móveis lentas, o que significa que o segundo cenário está mais perto da verdade: os visitantes que sumiram eram desproporcionalmente os menos propensos a comprar, e a ausência deles inflou a taxa da variação. Depois de corrigir o redirecionamento e rodar de novo, a divisão voltou em 24.102 / 24.088 (qui-quadrado 0,004, p = 0,949) e o resultado foi 4,502% contra 4,583%: p = 0,6675, ganho +1,81%, intervalo de -0,290 a +0,453 ponto percentual. Inconclusivo, e honesto.

De onde vêm os desvios

A taxonomia do KDD 2019 é útil justamente porque organiza as causas pelo estágio em que aparecem, que é também como você decide de quem é a correção. O artigo identifica 25 causas distintas agrupadas em cinco estágios.

Estágio	O que dá errado	Sintoma típico
Atribuição	O randomizador não é independente: semente compartilhada, balde herdado de um teste anterior, regra de exclusão que pega um braço só	Desvio presente desde a primeira hora, estável no tamanho, visível num teste A/A
Execução	Uma variação carrega mais devagar, um redirecionamento falha, a flag chega atrasada, a telemetria nunca dispara para parte dos usuários	Desvio aparece só em certos aparelhos ou conexões, e as métricas de performance pioram do mesmo lado
Processamento de log	Filtro de bot, deduplicação ou um join que descarta linhas de forma desigual entre as variações	Desvio aparece no data warehouse mas não nos logs brutos de atribuição
Análise	Gatilho ou filtro aplicado a um grupo só, segmento definido depois do fato, recorte de datas que corta um braço	Desvio presente no relatório filtrado e ausente no relatório cheio
Interferência	Outro experimento rodando junto, com segmentação correlacionada à sua	Desvio aparece só enquanto o outro teste está no ar

A distinção entre o estágio de análise e os outros é a que economiza mais tempo. Se a divisão está boa na população cheia e quebrada só na sua visão filtrada, o experimento provavelmente está saudável e a sua consulta não está.

A ordem de diagnóstico que acha mais rápido

Fabijan e colegas publicam dez regras práticas para estreitar a causa. Condensadas na ordem que resolve a maioria dos casos rápido:

1. Compare o relatório filtrado com o relatório cheio. Se o desvio só existe na visão filtrada, a condição de gatilho está errada, não o experimento. Relaxe o filtro por etapas até ele desaparecer.
2. Segmente por atributo de usuário. Um desvio confinado a um navegador, uma versão de app ou um país é causa localizada, normalmente um recurso que a variação assume e aquele segmento não tem.
3. Segmente por tempo. Evidência mais forte no primeiro dia e que some depois aponta para cache, rollout atrasado da variação ou início escalonado, não para randomizador quebrado.
4. Olhe as métricas de performance do lado que perdeu gente. Uma variação que aumentou o tempo de carregamento perde telemetria dos usuários mais lentos, e isso produz o desvio e a métrica pior pela mesma causa raiz.
5. Olhe o engajamento. Se o engajamento médio por usuário está maior no braço que perdeu usuários, a causa está atingindo mais os usuários menos engajados, e vice-versa.
6. Conte quantos experimentos foram afetados. Vários testes sem relação acusando ao mesmo tempo significa causa sistêmica, que mora na plataforma e não em nenhum teste específico.
7. Rode um teste A/A. Desvio num A/A é problema de plataforma por definição, e a calculadora de teste A/A é a forma mais barata de manter essa linha de base honesta.

A regra 7 merece destaque porque inverte o clima da sala. Quando um teste acusa SRM, a discussão é sempre sobre se aquele teste específico está quebrado. Um A/A resolve isso sem nenhuma dessas políticas, porque não existe resultado ao qual alguém esteja apegado.

O que fazer quando você acha um

As regras aqui são curtas, e uma delas é impopular.

Não reequilibre. Cortar o braço maior ou reponderar as contagens assume que os visitantes que sobraram ou faltaram eram sorteio aleatório. O desvio é a evidência de que não eram. O que você fizer depois herda o viés.

Não reporte o resultado com uma ressalva. Um teste que acusou não é um resultado mais fraco, é um resultado desconhecido, e um número num slide sobrevive a todo asterisco pregado nele.

Ache o estágio primeiro, a causa depois. A tabela acima transforma uma caçada vaga em três ou quatro verificações dirigidas, e a maioria dos desvios se resolve nas duas primeiras regras da lista de diagnóstico.

Guarde o teste reprovado no acervo. Um desvio que você diagnosticou é uma melhoria permanente na plataforma e pertence ao repositório de experimentos exatamente como uma vencedora que subiu. Programas que apagam os testes inválidos redescobrem o mesmo bug todo trimestre.

Cheque cedo e no fim. Rodar a verificação no primeiro dia pega bug de atribuição e de rollout enquanto reiniciar ainda é barato. Rodar de novo no fim pega problema de processamento de log e de análise, que só aparece depois que o dado é agregado. Nenhuma das duas é peeking, porque você está olhando a divisão de tráfego e não a métrica de resultado. O problema do peeking vale para olhar o resultado e decidir se para, que é um ato completamente diferente.

Erros comuns com SRM

Erro	O que produz
Nunca rodar a verificação	Todo viés desse tipo sobe em silêncio, e o programa não distingue vitória real de divisão quebrada
Olhar a divisão em vez de testá-la	Em escala, um desvio que importa parece perfeitamente equilibrado num painel
Tratar o valor-p do SRM como nota de gravidade	Testes enormes acusam vieses reais minúsculos com valores-p assustadores; testes pequenos escondem vieses grandes
Reequilibrar ou reponderar os braços	Preserva o viés e remove a evidência dele
Checar só o relatório filtrado	Confunde consulta de análise quebrada com experimento quebrado
Reiniciar sem achar a causa	O mesmo desvio volta, normalmente no teste que mais importava
Usar limiar de 0,05	Alarme falso demais num programa movimentado, o que treina o time a ignorar a verificação

Faça isso automático na Donnu

Uma verificação de SRM só protege o programa se ela roda em todo teste sem ninguém precisar lembrar de pedir. A Donnu A/B compara a divisão observada com a configurada de forma contínua, acusa o desvio antes de os números de conversão serem apresentados e não depois, e segura o veredito em vez de mostrar um ganho que a divisão já invalidou. A divisão, as contagens esperadas e o resultado do qui-quadrado ficam ao lado do resultado, então a primeira pergunta da reunião já está respondida antes de alguém abrir a discussão.

Comece um teste grátis de 14 dias e rode a verificação contra a sua própria divisão de tráfego.

Referências

• Fabijan, A., Gupchup, J., Gupta, S., Omhover, J., Qin, W., Vermeer, L. e Dmitriev, P. Diagnosing Sample Ratio Mismatch in Online Controlled Experiments: A Taxonomy and Rules of Thumb for Practitioners. KDD 2019. Fonte da taxonomia de cinco estágios, das dez regras práticas, da taxa de aproximadamente 6% de SRM na Microsoft e do número do LinkedIn sobre análises com gatilho. exp-platform.com.
• Kohavi, R., Deng, A., Longbotham, R. e Xu, Y. Seven Rules of Thumb for Web Site Experimenters. KDD 2014. Sobre verificações de qualidade de dados e por que o objeto de um experimento é o efeito sustentado, não o número do primeiro olhar. 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 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. Material complementar em experimentguide.com.

Leia também: O que é teste A/B · Significância estatística em teste A/B · O problema do peeking · Erros comuns em teste A/B · Verificador de SRM grátis · Read in English