Teste A/B: A única certeza do que fazer na incerteza
Dentro de todos os modelos ágeis que estão na moda atualmente, principalmente quando falamos de produtos digitais com modelos SAAS, APPs, Portais, e-commerce, etc, ouvimos com frequência o lema:
“Erre rápido para corrigir rápido”
Quando vejo isso, penso que falta uma peça, algo que conecta o erro à solução. Será que falta uma ideia? Não exatamente. Acredito que o mais correto seria dizer que falta uma hipótese.
Os testes AB ganharam mais notoriedade e acessibilidade no ambiente digital, impulsionados pela popularização dos softwares de analytics e aplicações para segmentar o público, algoritmos de distribuição de amostras e todo o aparato que vem com a hiper digitalização.
Mas testes e hipóteses fazem parte de toda a base científica e de construção de conhecimento da humanidade, se estamos aqui é porque muitos testes falharam.
Em geral, mais de 70% dos testes falham!
Mas é justamente por meio das falhas que a chance de errar diminui. E assim o ciclo se renova com mais conhecimento e novas hipóteses.
EUREKA! Afinal o que é uma hipótese?
Hipótese é mais do que ter uma ideia, é entender todos os aspectos que estão por trás de como validar essa ideia e se assegurar que ela é a melhor resposta para o problema que está tentando resolver.
Alguns elementos para se ter uma boa hipótese são:
- Ter claro o problema;
- Entender que a sua hipóteses está alinhada com o problema;
- Conseguir mensurar o KPI determinado;
- Assegurar que tem volumetria necessária para a amostra
RODANDO SEUS TESTES
HIPÓTESE
Como já falamos, a hipótese vai além da ideia e alguns pontos precisam ser observados para que ela seja uma hipótese válida. Porém, um dos aspectos mais interessantes em formular hipóteses não é simplesmente receber um ideia vinda como uma luz divina e que junta os seus neurônios formulando uma solução imbatível que com 100% de certeza vai resolver o seu problema.
Uma hipótese bem estruturada e com chances maiores de estar certa não vem de um evento milagroso ou de um top down do diretor ou cliente.
Ela é “garimpada”, na rocha BRUTA do seu analytics, na voz ou comportamento dos seus clientes.
Ou seja:
- Analisada e identificada a partir dos seus números de analytics;
- Validada ou encontrada a partir de gravações de comportamento com ferramentas como https://www.hotjar.com ;
- Avaliada com base em perguntas em entrevistas ouvindo a voz do seu cliente em um canal ativo ou receptivo, como um atendimento ou ouvidoria.
INDICADORES
O problema definido e o indício de como resolvê-lo são os elementos necessários para fechar a hipótese. O próximo passo é definir um indicador (conversão, vendas, clicks, tempo de página) de como vai testá-la e se tem volume de amostra para realizar o teste de forma quantitativa.
Uma dica, principalmente no início, é evitar escolher um indicador (métrica) contínuo. Prefira os unitários, como por exemplo: em um e-commerce, prefira pedidos a receita, porque geralmente a receita é volátil e depende do ticket médio; os pedidos são unitários e a comparação é mais simples.
Se estiver trabalhando com métrica contínuas, evite fazer a média, prefira as medianas, porque elas diminuem o efeito de “outliers” (picos), normalizando melhor a sua amostra.
TAMANHO DA AMOSTRA
Para entender quanto de volume de dados precisamos para realizar o teste como ele foi idealizado, vamos precisar de:
- Volume ou conversão desse indicador atual em nosso analytics;
- Média de visitantes únicos dentro do teste por dia.
Para fazer esse cálculo, indicamos a calculadora do site Bookingcom, conhecido pelo seu modelo data driven e pelos muitos testes que rodam na plataforma continuamente :
Os dados 1 e 2 devem ser preenchidos na calculadora e ela vai te dar o número de dias necessários para rodar o teste.
Um abordagem diferente para ter certeza dos resultados de um teste é aplicar um teste AAB, que consiste em ter duas versões iguais. A diferença entre os dois indicadores de testes A é a margem de segurança que você pode considerar. Quanto mais próximo for o indicador envolvido entre as 2 versões iguais, mais confiável será a diferença apresentada em B.
Exemplo:
Experiência | Indicador | Variação |
Teste A 1 2 | 2 | Média: 3.5 Vemos que a diferença de 2 para 5 é muito alta, o que dá uma baixa confiabilidade do resultado. Pode ser necessário deixar o teste rodando mais tempo, até que a amostra se normalize. |
Teste A 2 | 5 | |
Teste B (hipótese) | 4 | Considerando a média, temos um incremento de 0.5 da hipótese B. |
DOCUMENTAÇÃO
Documentar o que você está testando, como vai ser e todos os detalhes, é primordial para que no futuro você e todos os que venham a trabalhar no projeto possam saber o que já foi feito.
Além disso, evita dúvidas sobre onde seguir e não repetir os mesmos testes.
A documentação pode ser feita de várias formas. Uma plataforma gratuita que faz isso de maneira simples e eficiente é a https://grows.growthtribe.io. Ela organiza as suas hipóteses, o que já está pronto para ser testado, o que está rodando e os resultados.
Esse processo pode também ser feito em documento de texto ou qualquer outra plataforma. De maneira geral, a documentação do teste deve responder a algumas perguntas:
- Datas de início e fim?
- Tipo de abordagem (qual o objetivo de negócio do teste)?
- Qual o indicador principal que será impactado?
- Volumetria e número de variações? ABCD? (lembre-se: quanto mais hipóteses, mais tempo será necessário para que seu teste termine)
Como um questionário a Growthtribe faz essa documentação com 4 perguntas:
- Nós acreditamos que?
- Responda com uma afirmação simples que não seja ambígua e testável.
- Para verificar isso nós vamos?
- Descreva em detalhes qual é o seu experimento.
- E vamos medir?
- Descreva o indicador que vamos usar
- Nós estaremos certos se?
- Qual é a expectativa de melhoria, como base pode se colocar 2% de melhora.
Além disso é importante colocar bloqueios e ferramentas necessárias para realizar o teste. Outro passo antes de partir para a implementação do teste, é alinhar com o time questões de layout e técnicas para fazer o teste.
Implementação
Em quase todos os cenários, o time técnico faz a implementação do teste dentro do ambiente/plataforma, e a sua ferramenta de teste faz a gestão da audiência que pode ver uma versão ou outra.
Entre as ferramentas mais usadas no mercado temos o Google Optimize e o Optimizely.
Cada teste vai demandar um tipo de abordagem do time técnico. O importante é garantir que o seu indicador não seja impactado pela forma da abordagem técnica, sempre valide o teste em cenários de desktop, mobile, captura de eventos e qualquer dado necessário para realizá-lo.
Fechamento e aprendizado
Depois que teste for ao ar é importante acompanhar diariamente os resultados, principalmente nos primeiros dias, para garantir que tudo está correto.
Alguns pontos de atenção:
- Se o resultado estiver muito abaixo do esperado – desligue o teste.
- Se a distribuição das amostras não estiver igual entre as variações do teste – desligue o teste.
Após o término do volume de usuários dentro do seu teste, você já tem a relevância estatística para fazer um fechamento e voltar à documentação colocando os seus aprendizados.
Nesse momento é importante se manter neutro e atento ao problema, evitando qualquer influência de métricas de vaidade (são métricas que podem ter melhorado mas no final do dia elas não resolvem o problema).
Muitas pessoas estão tão conectadas à solução delas que quando recebem a informação que a sua grande ideia não foi a vencedora, num primeiro momento, elas vão questionar toda a execução do teste. Por isso, esteja preparado!
Após documentar os resultados, uma boa prática é documentar também o que foi aprendido e qual será o próximo passo. Antes de passar para o próximo teste, é importante implementar essas melhorias dentro do sistema, pois você pode contar com elas dentro da experiência padrão do ambiente testado.
Mas assim que uma melhoria for publicada, acompanhe os indicadores para ver se eles se mantêm dentro do mesmo patamar.
Teste tudo
Aqui não existe bala de prata, fórmula mágica e nem garantia que um comportamento já observado se repetirá. Então toda e qualquer hipótese deve ser testada, até o bom e velho botão verde deve ser questionado.
A única lição que vale para todos os cenários é:
Nunca se apaixone pela solução, mas sim pelo problema.
Quem escreveu este artigo foi o Marcelo Gorzoni, coordenador de Growth Marketing, com amplo conhecimento wm SEO, CRO e experiência do cliente na Serasa Experian.
Com mais de 20 anos de experiência, tem alto conhecimento em SEO, além de buscar constantemente a melhor experiência para o cliente final, sabe como ninguém trabalhar com linhas e linhas de código de programação.
Compartilha com a gente, o que achou desse artigo? Lembre-se estamos aqui para te ajudar!