O que um teste A/B realmente consegue responder
A pergunta que um experimento responde é bem mais estreita do que a que as pessoas fazem quando pedem um teste. Entender esse limite é o que separa experimentação de teatro.
Um teste A/B responde exatamente uma pergunta:
Nesta população, neste período, esta variação mudou esta métrica?
Só isso. Todo o resto que as pessoas esperam de um experimento está fora do que ele consegue entregar, e boa parte da frustração com CRO vem de pedir ao método uma resposta que ele nunca prometeu dar.
Vale destrinchar cada pedaço dessa frase, porque cada um esconde uma limitação real.
#"Nesta população"
O resultado vale para quem participou do teste. Se você rodou em desktop, não sabe o que acontece no app. Se rodou em tráfego pago, não sabe o que acontece com quem chega por busca orgânica com outra intenção.
Isso não é preciosismo estatístico. Uma mudança em página de produto pode funcionar muito bem para quem já conhece a marca e muito mal para quem está chegando pela primeira vez. Se os dois grupos estão misturados no teste, o resultado é uma média que não descreve nenhum dos dois.
Quando dá, vale olhar o efeito por segmento depois. Mas com uma ressalva importante: quanto mais recortes você faz, mais chance de achar um "vencedor" que é só ruído. Recorte planejado antes do teste é análise. Recorte procurado depois que o resultado veio chato é pescaria.
#"Neste período"
Experimento é uma fotografia de uma janela de tempo. Duas coisas atrapalham essa fotografia.
A primeira é o efeito de novidade. Usuário recorrente reage ao que mudou, não necessariamente ao que ficou melhor. Um botão diferente chama atenção na primeira semana simplesmente por ser diferente. Se o teste dura pouco, você mede a novidade e chama de melhoria.
A segunda é sazonalidade. Semana com Black Friday, campanha grande no ar, feriado, folha de pagamento. Rodar menos que ciclos semanais inteiros faz o resultado carregar o dia da semana junto. Eu prefiro sempre fechar semanas completas, mesmo que a significância tenha chegado antes.
#"Esta variação"
O teste compara duas experiências inteiras. Se a variante mudou foto, título e posição do botão ao mesmo tempo, você aprendeu que o conjunto funciona. Não aprendeu qual parte funcionou, e não pode aplicar as partes separadamente confiando no mesmo resultado.
Isso não quer dizer que teste com muitas mudanças seja errado. Às vezes é a única forma de mover a agulha com o tráfego que você tem. Mas o aprendizado é sobre o pacote, e é honesto registrar assim.
#"Mudou esta métrica"
Aqui mora a limitação mais dura, e é matemática.
Todo teste tem um efeito mínimo detectável, que é o menor tamanho de diferença que ele consegue distinguir de ruído com o volume disponível. Esse número depende do tráfego, da taxa base e do tempo. Se você tem 2 mil sessões por semana e conversão de 1,5%, não vai detectar uma melhoria de 3% em conversão. Não porque a melhoria não exista, mas porque ela é menor que a sua régua.
Isso tem uma consequência que quase ninguém tira: calcular o efeito mínimo detectável antes de subir o teste é o que decide se vale rodar. Se o cálculo diz que você só detecta ganhos acima de 20%, e a mudança que você vai testar é o raio de borda de um card, o teste não vai responder nada. Você vai gastar três semanas para terminar com "inconclusivo".
E "inconclusivo" não significa "não teve efeito" nem prova que o efeito era pequeno. Significa que, com aquela amostra e aquele método, a evidência não foi suficiente para distinguir o resultado de ruído. São coisas diferentes, embora essa distinção seja menos interessante de apresentar.
#As armadilhas que invalidam o resultado
Três coisas quebram um teste silenciosamente, sem dar erro em lugar nenhum.
Espiar e parar quando ficou bom. Se você olha o resultado todo dia e para no momento em que a significância aparece, a taxa real de falso positivo é muito maior que os 5% que você acha que está usando. O teste virou uma máquina de encontrar ruído favorável. Ou você define a duração antes e respeita, ou usa um método desenhado para leitura contínua, sabendo que ele tem outras exigências.
SRM. Se a divisão deveria ser 50/50 e chegou 52/48 com volume grande, alguma coisa está errada no sorteio, no disparo ou na coleta. Isso invalida a comparação inteira, porque os grupos deixaram de ser equivalentes. Checar SRM deveria ser a primeira coisa a olhar em qualquer resultado, antes até de olhar quem ganhou. É um teste de qui-quadrado de trinta segundos que evita decisões erradas caríssimas.
Contaminação. A mesma pessoa vendo as duas versões, em dispositivos diferentes ou depois de limpar cookie, mistura os grupos e empurra o resultado para o meio.
#Frequentista ou bayesiano
Essa discussão costuma ocupar mais espaço do que merece. As duas abordagens respondem perguntas diferentes e as duas servem.
O frequentista responde: se não houvesse diferença nenhuma, qual a chance de eu ver um resultado tão extremo quanto este? O bayesiano responde: dada a evidência, qual a probabilidade de B ser melhor que A, e quanto eu perco se escolher errado?
A segunda formulação costuma conversar melhor com quem decide, porque "87% de chance de ser melhor, com perda esperada de 0,3%" é uma frase que um time de produto consegue usar. Mas nenhuma das duas cria informação que o volume de dados não tem. Se o tráfego é baixo, os dois métodos vão dizer que você não sabe, cada um com o seu vocabulário.
#Então para que serve
Depois de toda essa lista de limitações, vale dizer o que sobra, porque o que sobra é muito.
Um experimento obriga você a transformar opinião em uma afirmação falsificável, com um número, um prazo e um critério de decisão combinados antes de ver o resultado. Esse ritual é o produto principal. Ele impede que a pessoa mais convincente da sala ganhe a discussão por ser a mais convincente.
E ele produz a coisa mais rara em otimização: um registro honesto do que não funcionou. A maior parte das ideias boas não funciona. Saber disso, com evidência, vale mais que a próxima ideia boa.