A ideia por trás do teste A/B é comparar e contrastar variantes semelhantes de usuários, mas fornecendo otimizações diferentes em cada variante para determinar quais alterações devem ser feitas no futuro. Idealmente, o teste A/B é usado para comparar duas ou mais versões de um experimento para ver qual delas tem melhor desempenho.

Ao comparar as duas variantes, elas são comumente chamadas de variante A e variante B. Os usuários são atribuídos aleatoriamente a cada variante para evitar qualquer tipo de viés que possa distorcer os dados.

Isso pode incluir vieses pré-teste com base em variáveis que podem afetar os resultados do teste, como uma campanha de mídia social que premia os usuários com moedas para experimentar o jogo logo antes do início do experimento. Esse grupo de usuários pode afetar seu teste e fornecer resultados distorcidos.

Os testes A/B permitem que você tome decisões fundamentadas com base em dados e não em palpites. Ser capaz de fornecer dados às evidências é essencial para fazer as alterações necessárias com confiança para otimizar melhor seu aplicativo.

Dependendo do tamanho do seu teste, você poderá testar mais do que apenas uma variante A e B. Os testes podem ser ajustados para incluir mais variantes. No entanto, dividir o público em mais variantes exige que você estenda a duração do teste para obter significância estatística, caso contrário, você corre o risco de os dados serem diluídos por falta de amostras.

As causas mais comuns para a utilização de testes A/B são:

• Maximizar o comportamento específico do jogador (hábitos de gastos, hábitos de jogo, retenção, etc.)
• Teste de recursos novos e existentes para otimizar o desempenho e as taxas de adoção pelos usuários
• Melhoria de fluxos de usuários específicos (FTUE, fluxo de usuários da loja, progressão de nível, ritmo de recompensas etc.)

Definir suas metas para cada teste A/B é importante para utilizar seus dados e seu tempo adequadamente. Certifique-se de que a meta comercial de cada experimento esteja clara para que você possa medir os KPIs que fornecem dados valiosos para impulsionar as iniciativas de otimização do seu aplicativo.

Um exemplo de um teste A/B no aplicativo seria testar o saldo inicial de moeda de um novo jogador. Seu experimento poderia ser algo semelhante a:

Público: Novos usuários Variante A (ativada): 100 ouro Variante B (controle): 0 gold KPIs para medir: Taxa de retenção (D1, D3, D7, D30), ARPDAU e taxa de conversão

Uma variante de controle é um subconjunto de usuários que correspondem aos critérios de público do teste, mas não são afetados pelo tratamento. A importância desse grupo é garantir que sua equipe possa ver claramente quaisquer elevações ou quedas medidas usando as variantes A e B. Os KPIs definidos antes do teste ajudarão a determinar essas alterações.

É importante observar que, ao comparar a mudança de um grupo de teste ao longo do tempo com a métrica da variante de controle, podemos isolar os impactos nos KPIs causados por fatores externos que podem afetar seus resultados.

O Unity Gaming Services tem a capacidade de criar campanhas de teste A/B usando nosso sistema Game Overrides. Você pode ver nosso guia passo a passo aqui. Não deixe de conferir esta página, pois adicionaremos mais dicas nos próximos meses.

Depois de executar esse teste, podemos analisar os dados para ver como cada um dos comportamentos dessas variantes é afetado pelo equilíbrio inicial variável e seu impacto nos KPIs que desejamos medir.

Com base em nosso exemplo acima, queremos ver se a variante A teve impactos positivos (ou negativos) em nossos KPIs. Algumas perguntas que você pode fazer a si mesmo ao analisar os resultados são:

• A variante A oferece maior taxa de retenção em comparação com o controle devido ao fato de os usuários terem mais moeda para gastar para ajudar no progresso do jogo?
• Fornecer aos usuários um saldo inicial maior incentiva-os a gastar mais dinheiro?
• Os usuários estão sendo convertidos em gastadores a uma taxa maior quando têm um saldo inicial mais alto?

Fazer essas perguntas e entender o impacto que o tratamento tem sobre os usuários é essencial para entender o comportamento desses jogadores e como você pode otimizar a experiência desses usuários.

A significância estatística é o nível de confiança de que um teste A/B está fornecendo dados precisos e não é influenciado por fatores externos. A primeira etapa para o cálculo da significância estatística é a elaboração de suas hipóteses nula e alternativa.

• Hipótese nula (H0): Uma declaração de que a alteração não teve efeito sobre o grupo de amostra e é considerada verdadeira.
• Hipótese alternativa (Ha): Uma previsão que seu tratamento terá sobre a amostra fornecida.

Uma vez escolhidas as hipóteses, você pode escolher o nível de significância (α), que é a probabilidade de rejeitar a hipótese nula. O nível de significância padrão que deve ser buscado é 0,05, o que significa que seus resultados têm menos de 5% de probabilidade de que a hipótese nula seja verdadeira.

A próxima etapa seria encontrar seu valor de probabilidade (valor p), que determina a probabilidade de que seus dados ocorram dentro da hipótese nula. Quanto menor for o valor p, mais significativos serão os resultados estatisticamente.

Se o valor p for maior que o nível de significância, a probabilidade é muito alta para rejeitar a hipótese nula e, portanto, seus resultados não são estatisticamente significativos.

Se seu nível p for menor que o nível de significância, então há evidência suficiente para rejeitar a hipótese nula e aceitar a hipótese alternativa, o que significa que nossos resultados são estatisticamente significativos.

Um teste A/B com significância estatística indica que nosso experimento foi bem-sucedido e que você pode fazer alterações com confiança com base em nosso teste para otimizar o aplicativo.

Um experimento de teste A/B muito comum a ser realizado no início da vida útil dos jogos é testar diferentes experiências de usuário na primeira vez (FTUEs) para aumentar a retenção inicial entre os jogadores (D1, D3, D7). O FTUE de um jogo é importante para integrar os usuários e fazer com que eles se interessem pelo seu aplicativo.

Público: Novos usuários Variante A (variante): FTUE normal (10 etapas) Variante B (controle): KPIs curtos de FTUE (5 etapas) para medir: Taxa de retenção (D1, D3, D7)

Muitos jogos e aplicativos de serviço ao vivo têm compras no aplicativo (IAPs) disponíveis para os usuários para ajudar a distribuir conteúdo e receita para o desenvolvedor. Um exemplo comum é testar diferentes pontos de preço para um pacote de IAP, como um pacote de itens (pacote de US$ 5 vs. pacote de US$ 20). Como alternativa, você pode ter a mesma faixa de preço, mas conteúdos diferentes no pacote.

Público: Variante A do Spender (ativada): Pacote de US$ 5 Variante B (controle): Pacote de US$ 20 KPIs para medir: ARPDAU (receita média por usuário médio diário), LTV (valor de longo prazo)

DO:

Sempre tenha um teste A/B em execução. Você deve sempre ter pelo menos um teste A/B em execução, para não perder tempo e encontrar novas maneiras de otimizar seu aplicativo.

Realizar testes em várias métricas. Ao fazer experimentos, certifique-se sempre de testar diferentes variáveis que possam ser otimizadas, usando testes A/B separados para cada uma delas. Isso pode variar de dificuldade, recompensas de anúncios, tempo de notificação por push, entre outros.

Certifique-se de que seus grupos de variáveis tenham tamanhos de amostra semelhantes. Se os tamanhos das amostras entre os grupos forem muito diferentes, você terá resultados imprecisos. Qualquer tratamento executado nessas amostras pode não ser adequado.

NÃO FAÇA ISSO:

Testar muitas variáveis ao mesmo tempo. A realização de muitos testes A/B ao mesmo tempo atrapalhará seus resultados, pois diferentes testes podem influenciar diretamente uns aos outros.

Executar seus testes em um período muito curto. Um erro comum é interromper um teste muito cedo, quando os dados não são suficientes e podem ser afetados por uma grande variedade de fatores. Um evento no jogo que ocorre no meio do seu experimento pode influenciar muito os resultados, levando a uma baixa significância estatística e a dados menos confiáveis.

Tenha medo de ser mais detalhista em seus experimentos. Reduzir seu público-alvo a um nível mais refinado pode ser muito eficaz, desde que você tenha uma hipótese bem elaborada e um tamanho de amostra grande o suficiente para fornecer resultados precisos.