Teste A / B de dispositivos móveis: sete grandes erros e equívocos que você precisa evitar

Não é nenhum segredo que o marketing em geral se baseia principalmente em dados. O mesmo se aplica ao marketing móvel e à aquisição de usuários. Nesse domínio, escolher os elementos certos da página do produto para a App Store e o Google Play pode fazer uma diferença crucial para o sucesso de um aplicativo ou jogo móvel. O teste A / B móvel é uma ferramenta que ajuda a fazer essa escolha com base nos dados.

No entanto, quantas vezes ouvimos o argumento de que o teste A / B não traz os resultados desejados ou que alguém não tem certeza de que está realizando experimentos móveis corretamente? Isso geralmente acontece devido a alguns erros comuns e má interpretação dos dados. Neste post, vou cobrir os maiores erros e conclusões enganosas em testes A / B de aplicativos móveis, cujo conhecimento o ajudará a alcançar o sucesso.

1. Concluir uma experiência antes de obter a quantidade certa de tráfego

Este é um dos erros mais comuns em testes A / B de dispositivos móveis. Caso você seja um adepto do teste A / B clássico, terminar um experimento antes de obter a quantidade necessária de tráfego - tamanho da amostra - apresenta o risco de obter resultados estatisticamente não confiáveis .

Para obter evidências confiáveis, você precisa esperar até que a quantidade necessária de tráfego seja alcançada para as variações A e B.

Se você está procurando uma alternativa à opção clássica, recorra aos testes A / B sequenciais. Você precisará começar especificando a taxa de conversão de linha de base (taxa de conversão de sua variação atual), poder estatístico (80% por padrão), nível de significância e o efeito mínimo detectável (MDE) - isso o ajudará a determinar o tamanho da amostra.

O nível de significância é 5% por padrão, o que significa que a margem de erro não excederá 5%. Você pode personalizar esse valor junto com o MDE - o aumento mínimo da taxa de conversão esperada que você gostaria de ver . Nota: não altere o nível de significância, MDE ou poder estatístico depois de iniciar um experimento.

Com o teste A / B sequencial, o algoritmo verificará constantemente suas variações no nível de significância e a quantidade de tráfego restante até a conclusão do experimento. É assim que funciona em nossa plataforma de teste A / B SplitMetrics.

Lição aprendida: se você executar testes A / B clássicos, não termine um experimento até que a quantidade certa de tráfego seja alcançada. Ou então, tente o teste A / B sequencial e você poderá verificar os resultados a qualquer momento.

2. Concluir um experimento antes de decorridos 7 dias

Por que você tem que esperar pelo menos sete dias? Bem, vários aplicativos e jogos para dispositivos móveis apresentam picos de atividade em dias diferentes durante a semana . Por exemplo, os aplicativos de negócios assistem a picos de atividade às segundas-feiras, enquanto os jogos são mais populares entre os usuários nos finais de semana.

Para obter resultados confiáveis ​​de experimentos de teste A / B móveis, você deve capturar os dias de pico do seu aplicativo durante um experimento. Caso contrário, você corre o risco de tirar conclusões precipitadas.

Por exemplo, você executa testes para um aplicativo de gerenciamento de tarefas. Você começa uma experiência na quarta-feira e a termina no sábado. Mas a maior parte do seu público-alvo está utilizando seu aplicativo às segundas-feiras, então você simplesmente perderá o ponto, já que o pico de atividade ainda não entrou no período experimental. Ou vice-versa, você está executando testes A / B para o seu jogo de corrida de sexta a domingo: nos dias de pico do jogo. Nesse caso, os resultados também serão inadequados.

Portanto, mesmo que você tenha evitado o erro número um e já tenha obtido a quantidade necessária de tráfego no primeiro dia, não interrompa a experiência antes de sete dias.

Lição aprendida: devido a picos fracos de atividade que variam para cada jogo ou aplicativo para dispositivos móveis, não conclua um experimento antes que o ciclo completo (sete dias) tenha passado.

3. Teste de mudanças muito pequenas no design

Outro erro comum em testes A / B móveis é comparar variações que parecem quase iguais devido a pequenas diferenças no design.

Se a única diferença entre os ícones do aplicativo móvel que você está testando é uma cor de fundo azul em vez do azul claro, ou se você adicionou um pequeno detalhe a outra variação da captura de tela, você está definitivamente em apuros. Os usuários simplesmente não percebem essas pequenas mudanças.

Nesse caso, ambas as variações mostrarão o mesmo resultado, e isso é perfeitamente normal. Portanto, se você já tentou executar os testes A / B da app store, mas desistiu deles, já que as variações tiveram desempenho igual, é hora de refletir sobre o que deu errado. Talvez suas variações parecessem praticamente as mesmas.

Para ter certeza de que você está testando A / B uma mudança significativa, mostre as duas versões para sua família ou amigos. Deixe seu colega olhar para cada variação por 3-5 segundos. Se eles não sabem a diferença, é melhor você redesenhar seus ativos visuais.

Lição aprendida: no caso de você testar variações com mudanças muito pequenas no design, você deve esperar que elas mostrem o mesmo resultado. Essas mudanças são muito insignificantes para os usuários, por isso é melhor testar ícones de aplicativos e capturas de tela que diferem muito entre si.

4. Seus anúncios de banner têm o mesmo design de um dos ativos visuais da loja de aplicativos

Se você usa uma ferramenta de teste A / B móvel de terceiros, como, por exemplo, SplitMetrics, você compra tráfego e coloca banners em redes de anúncios. A questão é que esse banner não deve se parecer com um dos recursos visuais que você está testando , seja uma captura de tela ou os mesmos elementos em um ícone.

Por exemplo, você executa experimentos para seu aplicativo educacional. Você projeta um banner que tem o mesmo elemento, como o ícone da variação A, enquanto a variação B é completamente outro ícone. A variação A mostrará a maior taxa de conversão, uma vez que tem o mesmo design que o banner que os usuários inicialmente viram e clicaram.

Estudos mostram que, se as pessoas veem algo repetidamente, seu cérebro processa as informações com mais rapidez, o que lhes dá uma sensação de simpatia. Você pode ler mais sobre isso aqui. Assim, os usuários tendem a tocar inconscientemente nas imagens já familiares.

Lição aprendida: ao trabalhar em banners, faça o design o mais neutro possível. O design do banner não deve coincidir com o design do ícone do seu aplicativo ou variações das capturas de tela.

5. Testar várias hipóteses de uma vez

Não faz sentido fazer várias alterações e testá-las no mesmo experimento. Alguns profissionais de marketing móvel tiram conclusões erradas após a execução de um teste, uma vez que fizeram várias alterações e, de fato, não podem saber exatamente o que afetou o resultado.

Se você decidiu alterar a cor das capturas de tela da página do produto da app store, crie uma ou algumas variações com outra cor de fundo e execute um teste. Não mude a cor, a ordem e o texto nas capturas de tela ao mesmo tempo. Caso contrário, você verá a variação vencedora (seja a variação B) e não terá ideia se foi a mudança de cor que realmente funcionou.

Lição aprendida: se você testar várias hipóteses ao mesmo tempo, não será capaz de entender qual delas é a correta.

6. Interpretar mal a situação quando duas variações são iguais, mas você obtém um vencedor

Ao executar testes A / A, você pode ficar confuso quando uma ferramenta de teste A / B está mostrando a variação vencedora entre dois ativos idênticos. Em particular, isso é comum para a ferramenta integrada da Google Play Store para a execução de experimentos.

Na plataforma SplitMetrics, ao nível de 5% de significância, nesse caso, você verá que o resultado é insignificante.

Pequenas diferenças entre duas variações exatamente iguais são pura coincidência. Diferentes usuários reagiram de maneira um pouco diferente. É como jogar uma moeda: há uma chance de 50-50 de você obter cara ou coroa, e há uma chance de 50-50 de uma das variações mostrar um resultado melhor.

Para obter um resultado estatisticamente significativo em uma situação como essa, você deve obter resultados de absolutamente todos os usuários, o que é impossível.

Lições aprendidas: se você obtiver a variação vencedora ao testar ativos idênticos, não há nada de errado com sua ferramenta de teste A / B, é apenas uma coincidência. No entanto, com o teste A / B sequencial, você verá que o resultado é insignificante.

7. Ficar chateado quando uma nova variação perde para a atual

Alguns profissionais de marketing móvel e gerentes de aquisição de usuários ficam desapontados quando um experimento mostra que a variação atual vence, o que eles não esperavam, e começam a desperdiçar um orçamento em mais tráfego pago na esperança de que a nova variação acabe vencendo.

Não há razão para se sentir mal se sua hipótese não foi confirmada. Se você tivesse alterado algo em sua página de produto da app store sem testar, você teria perdido parte de seus clientes em potencial e, conseqüentemente, dinheiro. Ao mesmo tempo, tendo gasto dinheiro neste experimento, você pagou pelo conhecimento . Agora você sabe o que funciona e o que não funciona com seu aplicativo.

Lição aprendida: tudo acontece por um motivo, e você não deve se arrepender se seu teste A / B não tiver confirmado sua hipótese. Agora você tem uma visão clara de quais ativos têm melhor desempenho para seu jogo ou aplicativo.