O teste A / B é frequentemente classificado como uma maneira científica de validar decisões de design. Ocasionalmente referido como teste de divisão, o teste A / B é um processo simples que aparentemente promete resultados concretos:
Crie duas variações em um elemento de design, troque-as aleatoriamente em seu site e registre como seus usuários reagem, compare os resultados e implemente a variação que tiver melhor desempenho. Faz sentido.
O exemplo clássico é: um botão vermelho contra um botão verde, que será aproveitado mais? No entanto, a questão mais interessante é: um botão verde contra o mesmo botão verde, que será aproveitado mais?
O que acontece quando nós A / B testamos duas variações idênticas? Um teste A / A, se você quiser.
Para testar a validade de qualquer teste A / B, precisamos de um teste que tenha uma resposta 'correta'. Precisamos de uma resposta correta, porque queremos saber, sendo todas as coisas iguais, qual a probabilidade de o teste A / B produzir o resultado esperado e, para isso, precisamos saber qual resultado esperar.
Se nós A / B testarmos dois botões idênticos, o resultado deve ser um calor morto
Então, vamos supor que estamos testando um botão verde versus o mesmo botão verde, e que o botão é tão atraente que 100% dos usuários irão tocá-lo.
(A porcentagem não importa realmente, pode ser 14,872%. O que importa é que, como os botões são idênticos, a taxa de toque também deve ser idêntica.)
Se nós A / B testarmos dois botões idênticos, o resultado deve ser um empate.
Atirar uma moeda. Qual lado vai surgir, cara ou coroa? Sabemos que existem dois lados, ambos idênticos, então é uma chance de 50%.
Se jogarmos a nossa moeda duas vezes, sabemos que existem três resultados possíveis: 2 cabeças, 2 caudas ou 1 cabeça e 1 coroa. E assim por diante…
Vamos dizer que o sorteio é o nosso teste A / A; as probabilidades de o lado da cabeça surgir são idênticas às probabilidades do lado da cauda emergir, tal como as probabilidades de os nossos botões verdes serem iguais são iguais.
Então, vamos escrever um script rápido no navegador (porque a maioria dos testes A / B acontece no navegador) para simular os usuários tocando um botão ou outro, dependendo de qual deles é apresentado.
Lembre-se: estamos testando duas variações idênticas de um botão, e a maneira como sabemos que são idênticas é que estamos tratando a probabilidade de elas serem chamadas como idênticas. Tudo o que procuramos é um resultado consistente (e, portanto, correto).
Em primeiro lugar, precisamos de uma tabela HTML para registrar nossos resultados, a tabela ficará assim:
# Heads Tails Difference Margin of Error
Na primeira coluna, vamos registrar o número do teste (todos os bons testes A / B são repetidos para verificar os resultados, por isso vamos repetir o teste algumas vezes). Em seguida, registramos o número de resultados do Heads e , em seguida, o número de resultados do Tails . A coluna depois disso será a diferença entre os dois resultados (que deve ser zero). Então vamos registrar a margem de erro (que, novamente, deve ser 0%). Abaixo da tabela, vamos imprimir um resumo, a média de todos os resultados e o pior resultado.
Aqui está o script:
var bestOf = 12, // the number of times we want to run the testtestRepeat = 12, // the number of times we’d like to repeat the testtestCount = 0, // the number of the current testtestInterval = setInterval(performCoinToss, 100), // call the coin toss functiontotalDifference = 0, // used for calculating the average differenceworstDifference = 0; // the worst casefunction performCoinToss(){testCount++; // increment the current testvar testCounter = bestOf, // the current iteration of the testheadsCounter = 0, // the total number of times the script came up with "heads"tailsCounter = 0; // the total number of times the script came up with "tails"while(testCounter--) // loop 'testCounter' times{Math.round(Math.random()) ? headsCounter++ : tailsCounter++; // finds 0 or 1 randomly, if 1 increments headsCounter, otherwise increments tailsCounter}var difference = Math.abs(headsCounter - tailsCounter), // the difference between the twoerror = (difference / bestOf) * 100; // the error percentagedocument.getElementById("results").innerHTML += "" + testCount + " " + headsCounter + " " + tailsCounter + " " + difference + " " + error + "% Average difference: " + averageDifference + "
Average margin of error: " + averageError + "%
Worst Case: " + worstDifference + "
"; // write summary to pageclearInterval(testInterval); // if the test has been repeated enough times, clear the interval}}O código é comentado, então aqui estão apenas os destaques:
Em primeiro lugar, configuramos algumas variáveis, incluindo o número de vezes que queremos jogar a moeda (bestof) e o número de vezes que queremos repetir o teste (testRepeat).
Alerta de spoiler: entraremos em alguns loops razoavelmente altos, então, para evitar quebrar o navegador de qualquer pessoa, estamos executando o teste em um intervalo a cada 100 ms.
Dentro da função performCoinToss , fazemos o loop do número de vezes necessário, cada iteração do loop usamos a função aleatória do JavaScript para gerar um 1 ou um 0, que por sua vez incrementa o headsCounter ou o tailsCounter .
Em seguida, escrevemos o resultado desse teste na tabela.
Por fim, se o teste tiver sido repetido quantas vezes quisermos, encontraremos as médias e, no pior dos casos, as escreveremos no resumo e limparemos o intervalo.
Aqui está o resultado . Como você pode ver a diferença média é, bem, será diferente para você, mas como eu estou escrevendo isso a diferença média é 2.8333333333333335, o erro médio é, portanto, 23.611111111111114%.
Mais de 23% de erros não inspiram confiança, especialmente porque sabemos que a diferença deve ser de 0%. O pior é que meu pior resultado é 8, que é 10-2 em favor dos caras.
Ok, então esse teste não foi justo. Um teste A / B real nunca afirmaria encontrar um resultado conclusivo de apenas 12 usuários.
O teste A / B usa algo chamado "significância estatística", o que significa que o teste precisa ser executado o suficiente para obter um resultado acionável.
Então, vamos dobrar a variável bestOf e ver até onde precisamos ir para alcançar uma margem de erro, de menos de 1% - o equivalente a 99% de confiança.
Na melhor das 24 (no momento da escrita), a diferença média é de 3.1666666666666665, que é 13.194444444444445%. Um passo na direção certa! Experimente você mesmo (seus resultados irão variar).
Vamos dobrar novamente. Desta vez, minha diferença média 6,6666666666666667, com uma margem de erro de 13,888888888888889%. Pior ainda, o pior caso é 16, isso é um erro de 33.33333333333333%! Você pode tente aquele para você também.
Na verdade, não há prêmios para adivinhar que podemos continuar: melhor de 96 , melhor de 192 , melhor de 384 , melhor de 768 , melhor de 1536 , melhor de 3072 , melhor de 6144 , melhor de 12288 , melhor de 24576 , melhor de 49152 , melhor de 98304 .
Finalmente, no melhor dos 98304, o pior cenário cai abaixo de 1%. Em outras palavras, podemos ter 99% de certeza de que o teste é preciso.
Assim, em um teste A / A, cujo resultado soubemos de antemão, foi necessário um tamanho de amostra de 98.304 para atingir uma margem de erro aceitável.
Sempre que um teste A / B é discutido, alguém se lembra de um amigo de um amigo, que A / B testou um único botão em seu site, e imediatamente obteve algum lucro improvável (o valor real do botão aumenta cada vez que ouço o história).
Nesses contos, os botões geralmente são testados para micro-cópias, “Download my ebook” vs. “Download my free ebook”. Não deveria ser uma surpresa que o último vença. É uma melhoria que qualquer bom redator faria. Um teste A / B mais apropriado seria “Faça o download do meu ebook” vs. “Faça o download do ebook” (meu dinheiro é sobre o último).
Se você se encontrar com um resultado muito pesado em relação a uma das opções, isso sugere que algo está muito errado em uma de suas variações. Mais frequentemente, um bom resultado será uma melhoria de menos de 5%, o que representa um problema se você estiver testando com cerca de 1.000 usuários (a margem de erro é de cerca de 5%).
Quanto mais útil for um teste, mais estreita será a margem de vitória para uma variação ou outra. No entanto, quanto mais apertada for a margem de vitória, maior será o tamanho da amostra para fornecer uma margem de erro aceitavelmente pequena.
Mark Twain, possivelmente citando Disraeli, já usou a frase: mentiras, mentiras e estatísticas. Por que ele quis dizer que algo provado pelas estatísticas, não é necessariamente verdade. Estatísticas podem ser usadas para provar qualquer coisa que você queira.
O teste A / B fornecerá um resultado, mas é um resultado que diz mais sobre você e sobre o que você esperava encontrar do que sobre seus clientes
A coisa mais perigosa sobre o teste A / B é que ele pode provar qualquer coisa que você queira; pode produzir falsos positivos e nos permite discernir padrões que não são adequadamente suportados.
Além disso, um teste A / B pode indicar que um botão verde supera um botão vermelho, mas que tal um botão azul? Até mesmo o teste A / B bem-sucedido nos permite validar nossas decisões de projeto dentro do contexto do próprio teste.
Para um teste A / B funcionar como pretendido, precisamos que duas condições opostas sejam verdadeiras:
Infelizmente, a maioria dos sites não tem um tamanho de amostra grande o suficiente para atingir uma margem de erro suficientemente pequena. E como não podemos aumentar nosso tamanho de amostra (o faríamos se pudéssemos), nossa única opção é aumentar a variação das opções para produzir um resultado claro, distorcendo o teste por nossas preferências.
O teste A / B fornecerá um resultado, mas é um resultado que dirá mais sobre você e sobre o que você esperava encontrar do que sobre seus clientes. Quando se trata de tomar decisões de design em qualquer site que não seja aquele com volumes muito altos de tráfego, podemos também jogar uma moeda, como teste A / B.
Imagem em destaque, imagem de lance de moeda via Shutterstock.