Uma função compartilhada no layout raiz do site transformou um contador de exposição de teste A/B em um contador de visualizações de página, inflando o tamanho da amostra e tornando as taxas de conversão sem sentido. O teste, uma divisão de 50/50 da página inicial, relatou 178 acessos para uma variante e 57 para a outra — longe da divisão equilibrada esperada.
Como o erro passou pelo randomizador
O desenvolvedor primeiro verificou o randomizador que atribui os visitantes a uma variante. Ele leu o middleware, inspecionou a lógica de cookies e executou um script que chamou a função de atribuição 10.000 vezes; o resultado foi uma divisão perfeita de 50/50. O randomizador em si funcionava; o problema era como a exposição era registrada.
Uma única função realizava dois trabalhos:
- Definir a variante – é executada em cada carregamento de página para manter a experiência do visitante consistente.
- Registrar o evento de exposição – deve ser disparado apenas uma vez por visitante, no momento em que a variante aparece pela primeira vez.
A função residia no layout raiz, um componente renderizado em cada navegação. Como o código de registro de exposição era executado toda vez que o layout era renderizado, cada visualização de página contava como uma nova exposição. As duas variantes da página inicial usavam árvores de layout ligeiramente diferentes, então suas taxas de visualização de página divergiram, criando a ilusão de um randomizador quebrado.
Por que a contagem incorreta importava
Os números de conversão — cliques, cadastros, compras — foram registrados corretamente. Mas o denominador (o número de exposições) estava errado. As taxas de conversão calculadas pareciam muito menores do que a realidade, e quaisquer decisões baseadas nessas taxas eram pouco confiáveis.
O teste durou duas semanas antes que a discrepância surgisse, forçando a equipe a descartar todo o conjunto de dados.
A correção
A solução foi direta: dividir as responsabilidades em funções separadas. O código de registro de exposição agora verifica se o visitante já foi contado, disparando apenas uma vez por usuário. O código de definição de variante permanece onde está, continuando a ser executado em cada navegação.
Três lições para quem realiza experimentos
- Separe a definição de estado de eventos únicos. Uma função que tanto atribui uma variante quanto registra uma exposição entrará em conflito, pois a primeira se repete, enquanto a segunda não deve repetir.
- Evite lógica de execução única em um layout raiz. Qualquer coisa colocada em um componente que é renderizado em cada carregamento de página será executada repetidamente, transformando "uma vez por visitante" em "uma vez por visualização de página".
- Quando a divisão observada contradisser o randomizador, audite o contador primeiro. Desenvolvedores frequentemente testam a imparcialidade do randomizador, mas raramente verificam se o mecanismo de contagem é preciso.
O que observar a seguir
Qualquer experimento que dependa de um único contador para exposição deve ser auditado para verificar onde esse contador reside na árvore de componentes. Se o contador estiver em um layout global, adicione uma verificação que vincule o evento a um identificador persistente — como um cookie ou uma flag no local-storage. As equipes também devem construir uma verificação de sanidade em seus dashboards: se a distribuição de variantes observada desviar além de uma pequena margem estatística, sinalize o teste para uma auditoria de contador antes de assumir que o randomizador está quebrado.
Em resumo, um randomizador que funciona bem é inútil sem uma contagem de exposição confiável. Dividir responsabilidades e colocar eventos únicos fora de componentes que são sempre renderizados mantém os testes A/B honestos e economiza semanas de análises desperdiçadas.