Por que o vencedor do teste A/B some depois do rollout?

O teste terminou, a variante B venceu com significância e o time fez o rollout. Semanas depois, a métrica voltou ao que era. O ganho que estava no relatório não aparece no dashboard.

Esse é um dos problemas que mais frustram times de produto e growth. Ele não tem uma causa única, mas as causas mais comuns são conhecidas e dá para checá-las.

Resumo rápido: o vencedor pode ter sumido por quatro motivos: efeito de novidade, erro de medição, escolha do vencedor errado ou diferença entre o público do teste e o do rollout. Antes de ler o resultado, verifique se a divisão do tráfego saiu como planejada. Depois, olhe o efeito ao longo do tempo e continue medindo após o rollout.

Este texto usa apenas fontes públicas. Não traz resultados de testes de nenhuma empresa.

O que "sumir" pode significar

Quando alguém diz que o vencedor sumiu, podem ser coisas diferentes:

• o ganho nunca existiu, e o teste enganou o time;
• o ganho existiu no começo e diminuiu com o tempo;
• o ganho existiu para o público do teste, mas não para o do rollout.

Cada hipótese pede uma checagem diferente. Por isso vale separá-las antes de culpar a ferramenta ou o time.

Causa 1: o efeito de novidade

Pessoas reagem a algo novo. Um botão diferente ou uma tela redesenhada chama atenção por ser novo, e essa reação tende a passar.

Pesquisadores da Microsoft descrevem o fenômeno em um estudo sobre efeitos de novidade e primazia (Sadeghi e outros, 2021, consultado em 17/10/2026). Segundo eles, a novidade é o desejo de usar uma tecnologia nova, que tende a diminuir com o tempo. A primazia é o oposto: o engajamento cresce à medida que as pessoas adotam a mudança.

O artigo afirma que, como os experimentos são limitados em duração, o efeito observado nem sempre é estável. Isso pode levar a uma decisão errada se o efeito sustentado for diferente do observado. Os autores falam em experimentos de algumas semanas ou meses.

A consequência para o produto é direta. Um teste curto pode medir a reação à mudança, e não a preferência pelo novo desenho. Se a novidade inflou a variante, o ganho some quando as pessoas se acostumam.

Causa 2: o teste tinha erro de medição

Às vezes o ganho nunca foi real, porque a medição estava errada. O sinal mais barato de checar é a sample ratio mismatch, ou SRM, a divergência de proporção da amostra.

A documentação do Amplitude Experiment (consultada em 17/10/2026) define o problema assim: ocorre quando a divisão observada entre as variantes difere de forma significativa da planejada. O exemplo dela é um teste planejado em 50% e 50% que mostra 55% e 45%. A ferramenta detecta o caso com um teste qui-quadrado sequencial, com alfa de 0,01.

A orientação é clara: trate como suspeito o resultado de qualquer experimento com SRM, e investigue a causa antes de confiar nele. Entre as causas que a página lista como mais comuns:

• eventos de exposição enviados antes da atribuição da variante;
• pesos de distribuição alterados no meio do teste;
• janela de exposição diferente da janela de análise;
• usuários que mudam de variante, por exemplo quando o device ID é regenerado.

Todas são erros de instrumentação. O paralelo é o mesmo de Como montar um tracking plan antes da feature ir ao ar.

Causa 3: o vencedor errado

Mesmo com a medição correta, é possível escolher a variante errada. O trabalho de pesquisadores da Microsoft sobre armadilhas em experimentos na web, apresentado no KDD 2009 (consultado em 17/10/2026), cita duas relevantes aqui.

A primeira é o paradoxo de Simpson. Os autores o apontam como uma forma de identificar, de maneira incorreta, o tratamento vencedor. Em termos gerais, uma tendência que aparece em cada subgrupo pode se inverter quando os grupos são somados.

A segunda é ignorar robôs na análise, que a página descreve como um problema típico do ambiente online. Tráfego automatizado não se comporta como gente e pode distorcer a conversão.

Também cabe a pergunta de estatística básica: o teste foi encerrado no momento certo? Esse tema merece um texto próprio.

Causa 4: o público do teste não é o do rollout

Esta é uma hipótese minha, não um dado de fonte. Um teste mede o efeito sobre as pessoas que participaram dele, no período em que ele rodou. Se o rollout alcança outro público ou outra época, o resultado pode mudar.

Dois exemplos de como isso acontece:

• o teste rodou só em um canal de aquisição, e o rollout vale para todos;
• o teste rodou em um período com campanha ativa, e o rollout cai em um mês comum.

Antes do rollout, compare quem entrou no teste com quem vai receber a mudança. Se há diferenças grandes, o resultado pode não se transferir.

Como checar antes e depois do rollout

Os dois primeiros passos têm base nas fontes citadas. Os demais são práticas que recomendo, sem fonte específica.

1. Verifique a SRM antes de ler o resultado. Se a divisão saiu diferente do planejado, pare e investigue.
2. Olhe o efeito ao longo do tempo, não só o total. Se o ganho diminui semana a semana, suspeite de novidade.
3. Separe pessoas novas de recorrentes. Um ganho só entre os novos, ou só entre os recorrentes, indica que o efeito depende do contato prévio com o produto.
4. Defina uma métrica de proteção antes do teste. Uma métrica de guardrail é a que não pode piorar, como o tempo de carregamento ou o volume de chamados ao suporte. Defina o limite antes, não depois.
5. Mantenha um grupo de controle depois do rollout, quando for viável. Um pequeno grupo que continua na versão antiga mostra o efeito real de longo prazo.
6. Registre o resultado esperado e o observado. Com o tempo, você descobre quanto os seus testes tendem a prometer a mais, para o seu produto.

O que fazer agora

Pegue o último teste que foi para produção e desenhe o efeito dele por semana, desde o início do teste até hoje. Se a curva cai, você encontrou uma causa para investigar. Se o teste foi para todos sem nenhum grupo de comparação, o próximo passo é decidir como medir o que acontece daqui em diante.

Nota de IA: usei inteligência artificial na pesquisa e no rascunho deste texto. As fontes foram conferidas nas páginas citadas, e a revisão e as opiniões são minhas. Trabalho com Amplitude e tenho a certificação Amplitude Data Management, sem patrocínio nem parceria com Amplitude ou Google. Como escrevo.