Como parar de se preocupar e começar a acreditar nos testes A / B

Quando você desenvolve um produto, cada nova iteração corre o risco de perder métricas e perder usuários. No entanto, às vezes, especialmente nos estágios iniciais, as empresas, sem saber, correm esse risco - elas mudam o produto, confiando apenas em seus instintos e hipóteses.

Nós no Badoo não confiamos em sentimentos, mas acreditamos em números. No total, nossos serviços têm mais de 500 milhões de usuários e escrevemos nossa estrutura de teste por um longo tempo. Em seis anos, 2962 testes passaram por ele, e os testes A / B provaram sua importância, confiabilidade e eficácia.



Mas neste artigo, não falarei sobre como nosso sistema funciona. Um artigo não é suficiente para isso. Além disso, muitas coisas são específicas da nossa empresa e não se adequam a outras. Hoje vou falar sobre a evolução de nossas idéias sobre os testes A / B: que tipo de rake entramos no processo e como verificamos a exatidão dos testes. Este artigo é para aqueles que ainda não começaram o teste, mas pense nisso, bem como para aqueles que não têm certeza sobre seu sistema de teste.

O que é um teste A / B?


Imagine uma situação: um novo recurso deve ser lançado e nosso gerente de produto não está pronto para arriscar uma renda pequena, mas estável, para o produto. Após alguma deliberação, ele sugere iniciar o recurso através do teste A / B e ver se ele decola e os usuários não vão para os concorrentes. 

Como não realizamos testes A / B antes, a primeira coisa que aprendemos é o que são. A Wikipedia diz: “O teste A / B é um método de pesquisa de mercado , cuja essência é que o grupo de elementos de controle é comparado com um conjunto de grupos de testes nos quais um ou mais indicadores foram alterados para descobrir quais Alterar melhorar alvo" Acontece que precisamos realizar um estudo no qual deve haver um grupo de controle, pelo menos um grupo de teste e um indicador de meta.

Para o grupo de teste, mostraremos uma versão alternativa da página de pagamento. Nele, queremos alterar o texto, destacar o desconto, substituir a imagem - e tudo isso para os usuários da Eurásia, para que comprem mais. E para usuários da América, não queremos mudar nada. 

Teremos alvos. Vamos dar os básicos:

  • ARPU (receita média por usuário) - o lucro que receberemos em média do usuário; 
  • número de cliques nos elementos da CTA (frase de chamariz) - botões e links na página de pagamento. 

Tarefa técnica


Está planejado alterar três elementos na página ao mesmo tempo: texto, botão e imagem com informações de desconto.



Será bastante difícil entender quais dessas mudanças influenciaram o resultado se testadas simultaneamente. Talvez o novo texto repulse os usuários e leve a uma diminuição no número de compras, mas destacar o desconto aumentará: como resultado, obtemos zero. Os recursos de desenvolvimento serão desperdiçados e a hipótese de trabalho será rejeitada. 

Portanto, não faremos isso. Deixaremos apenas uma alteração para teste - alocação de descontos. 


Primeiro teste


O plano é o seguinte: dividimos os usuários em dois grupos iguais e aguardamos o resultado. Quando o recebermos, compararemos os indicadores nos grupos de controle e teste. 

Tudo parece bem simples: dividimos os usuários em pares e ímpares e depois analisamos as estatísticas. 

Nós escrevemos o código:

if (userId % 2 == 1) {
    showNewAwesomeFeature();
}

Estamos ansiosos por algumas semanas: os resultados são incríveis! ARPU aumentado em 100%! As pessoas clicam, pagam, o gerente de produto pede para implementar rapidamente a alteração. 



Ativamos, mais duas semanas se passam, mas não há resultados. O lucro total não aumentou. 

O que estamos fazendo errado?

Selecionamos um grupo de teste


Simplesmente dividimos os usuários em dois grupos iguais e fizemos o teste, mas você não pode fazer isso. Afinal, algo mudou apenas para usuários da Eurásia. E temos muito menos deles do que usuários da América. Portanto, verificou-se que um aumento repentino na atividade dos usuários da América influenciou os resultados do nosso teste, embora na realidade eles não fossem os melhores.

Conclusão: sempre selecione no grupo de teste apenas os usuários para os quais as alterações foram implementadas.

Vamos corrigir o nosso código:

if (user.continent === ‘eurasia’ && userId % 2 == 1) {
    showNewAwesomeFeature();
}

Agora tudo deve funcionar como deveria! Execute o teste. Estamos aguardando algumas semanas.



Aconteceu! O ARPU aumentou 80%! Distribuir a alteração para todos os usuários. 

E ... após o mesmo período de tempo, os gráficos novamente parecem diferentes do que planejamos.

Calcular a significância estatística


O teste não pode ser interrompido simplesmente "após algumas semanas": os resultados obtidos podem ser imprecisos. Quanto menos a métrica que seguimos for alterada, e quanto menos pessoas participarem do teste, maior será a probabilidade de ele ser aleatório.  

Essa probabilidade pode ser calculada. O valor que indica isso é chamado valor-p. Eu vou te dizer como isso funciona.

Ao realizar qualquer teste, há uma chance de obter resultados aleatórios. Por exemplo, os usuários que visitaram o site podem ser distribuídos de maneira desigual - e todo o público pagante se enquadra em um dos grupos. Em testes reais, a diferença nas métricas geralmente não é tão grande: é difícil ou mesmo impossível perceber o problema nos gráficos, e os testes estatísticos não podem ser dispensados. Em particular, precisamos corrigir a probabilidadeerros do primeiro e do segundo tipo - em outras palavras, a probabilidade de encontrar mudanças onde elas não existem e, inversamente, de não encontrá-las, se existirem. Dependendo do valor da métrica e das probabilidades estabelecidas, precisaremos de um número diferente de usuários.

Você pode calculá-lo usando a calculadora on - line : especifique os valores atuais e de destino das métricas monitoradas - você obtém o número necessário de usuários para o teste e vice-versa.


Cálculo para conversão em 10% e alterações em 0,2% em relação ao valor atual

Agora recebemos todos os dados necessários e entendemos quando parar o teste. Não há mais obstáculos.

Vamos executar o teste A / B e ver os resultados.



Desta vez, os resultados são mais parecidos com a verdade, mas ainda excelentes: crescimento do ARPU em 55%. 

Paramos o teste, aplicamos o grupo de teste. E ... as métricas estão caindo novamente. Por quê? 

Verifique o número de usuários


Vamos descobrir quantos usuários realmente visitaram nosso site enquanto o teste estava em andamento. A julgar pelos logs, apenas 10% dos nossos grupos de teste, mas não levamos isso em consideração. 

Se sua DAU (o número de usuários únicos por dia) for de 1000 pessoas, isso não significa que em dez dias você terá 10.000 usuários no teste. Sempre registre ocorrências reais no teste (ocorrências de teste) e conte apenas elas.

Implementamos lógica simples. Para cada usuário que visita o site, enviamos uma solicitação ao servidor com os nomes do grupo de teste e controle A / B. Graças a isso, saberemos exatamente quantos usuários nos visitaram e não nos enganaremos mais.

Iniciamos o teste A / B.

Os resultados são excelentes. Ganhamos mais dinheiro novamente! Ativamos nosso teste para todos - e algo dá errado de novo: depois de algumas semanas, as métricas estão novamente abaixo do previsto. 

Lembre-se, começamos a enviar hits para todos os usuários que visitaram o site? Nunca faça isso. Os hits devem ser enviados apenas aos usuários que interagiram com a parte testada do recurso. E quanto mais precisamente você os definir, melhor. 

Felizmente, isso é fácil de verificar. Para fazer isso, você pode realizar um teste A / A / B. Parece um teste A / B, mas neste caso você tem dois grupos de controle e um grupo de teste. Por que isso é necessário? Se o momento para o envio de uma ocorrência foi escolhido incorretamente, os usuários que não interagiram com a parte testada do site serão submetidos ao teste. Nesse caso, haverá grandes diferenças nas métricas nos grupos A e A e você poderá entender imediatamente que algo está errado. 

Iniciamos o teste A / A / B. 

No grupo B, deixe 50% dos usuários e divida os 50% restantes igualmente entre os grupos A e A (nós os chamamos de controle e verificação de controle). Sim, os resultados terão que esperar mais, mas, se os resultados dos grupos A e A convergirem, você entenderá se o resultado foi enviado corretamente.



Os resultados são modestos (crescimento de apenas 20%), mas realistas. Vamos rolar a mudança. 

Tudo funciona perfeitamente! 

Mas depois de um mês, as métricas caíram novamente.

Testando o que podemos controlar


Acontece que nosso faturamento de terceiros também realizou seu teste A / B, o que afetou diretamente nossos resultados. Portanto, sempre siga os resultados da produção e tente testar o que você controla por completo.

Total


Os testes A / B podem ajudar o produto a crescer. Mas, para confiar nos testes, é importante conduzi-los corretamente e sempre verificar os resultados. Essa abordagem permite testar qualitativamente seu produto e testar hipóteses antes que elas descartem todas as métricas.

  • Sempre verifique o grupo-alvo.
  • Enviar hits.
  • Envie os hits certos.
  • Teste o que você controla por completo.
  • /-!

All Articles