Teste A/B em Jogos: Como Decidir com Dado, Não com Achismo

Você mudou o tutorial do seu jogo porque achou que ficava mais claro. A retenção caiu, mas você não tem certeza se foi por causa disso ou por causa da atualização do fim de semana que também saiu junto. Esse tipo de dúvida é exatamente o buraco que o teste A/B em jogos existe pra tapar. Em vez de mudar tudo de uma vez e torcer, você mostra duas versões ao mesmo tempo pra grupos parecidos de jogadores e deixa o comportamento real decidir qual ganha. Não é sobre ter razão, é sobre parar de adivinhar.

Depois de mais de 20 anos construindo software que cliente paga pra usar, a lição que mais se repete é essa: a sua intuição de designer é uma boa geradora de hipóteses e uma péssima juíza de resultado. O que você acha óbvio muitas vezes o jogador ignora, e o detalhe que você achou irrelevante é o que segura ou espanta a pessoa. Teste A/B é o jeito de separar o que você acredita do que de fato acontece.

O que é teste A/B em jogos e quando usar

Teste A/B é um experimento controlado. Você pega um elemento do jogo, cria duas versões (a original, chamada de controle, e a variação, chamada de variante), e mostra cada uma pra uma parcela dos jogadores, ao acaso, no mesmo período. Depois compara uma métrica objetiva entre os dois grupos. Se a variante entrega mais do que você queria (mais gente terminando o tutorial, mais conversão, mais gente voltando no outro dia), ela ganha. Se não, você fica com o controle e aprendeu de graça.

A parte que muita gente pula é o "ao mesmo tempo" e o "ao acaso". Comparar a retenção deste mês com a do mês passado não é teste A/B, é comparar duas épocas diferentes com jogadores diferentes, promoções diferentes e talvez uma atualização de mercado no meio. Sem grupos paralelos e sorteados, você não está testando, está torcendo com gráfico bonito.

Teste A/B faz sentido depois do lançamento, quando o jogo já tem jogadores de verdade passando pelo fluxo. É uma ferramenta de operação contínua de um jogo já no ar, não de pré-lançamento. Os lugares onde ele rende mais são bem específicos:

• Onboarding e tutorial. Onde mais gente desiste é nos primeiros minutos. Testar uma versão mais curta do tutorial contra a atual costuma ser o experimento de maior retorno.
• Preço e ofertas. Valor de um pacote, desconto exibido, moeda mostrada primeiro. Pequenas mudanças de apresentação mexem na conversão. Antes de testar preço, vale entender os modelos de monetização de jogos pra saber o que faz sentido pro seu.
• Dificuldade e ritmo. Curva de dificuldade da fase inicial, tempo até a primeira recompensa, força do primeiro inimigo. Dá pra medir se afrouxar o começo segura mais gente.
• Layout de loja. Ordem dos itens, qual pacote aparece em destaque, texto do botão. É um dos testes mais baratos de montar e um dos que mais movem receita.

Repare que tudo isso é refino de algo que já existe. Teste A/B não inventa mecânica nova nem descobre se a sua ideia de jogo presta. Ele escolhe entre duas versões de uma decisão que você já tomou.

Como montar um teste honesto

Um teste mal montado é pior que nenhum teste, porque te dá confiança falsa. A estrutura honesta tem poucos passos, e todos importam.

Comece pela hipótese. Escreva uma frase no formato: "Se eu fizer X, então a métrica Y vai melhorar, porque Z". Por exemplo: "Se eu cortar o tutorial de oito passos pra quatro, a retenção D1 vai subir, porque a maioria desiste antes de terminar". A hipótese te obriga a escolher uma métrica antes de ver o resultado, o que impede a armadilha de olhar todos os números e escolher o que ficou bonito depois.

Controle contra variante. O grupo controle continua com a versão atual. O grupo variante recebe a mudança. Os dois rodam no mesmo período e os jogadores são sorteados pra cada grupo, sem você escolher quem vai pra onde. Divisão comum é metade e metade, mas se a mudança for arriscada, dá pra mandar uma fatia menor pra variante e proteger a maioria.

Uma variável por vez. Esse é o mandamento que quase todo mundo quebra. Se a variante muda o tutorial e o preço ao mesmo tempo e a conversão sobe, você não sabe qual dos dois causou. Pior: pode ser que o tutorial novo tenha ajudado e o preço novo tenha atrapalhado, e o efeito líquido escondeu isso. Uma mudança por variante. Se quiser testar duas coisas, rode dois testes.

Tamanho de amostra. Antes de começar, decida quantos jogadores precisam passar por cada grupo. Quanto menor a diferença que você quer detectar, maior a amostra necessária. Detectar um salto de dois pontos percentuais na conversão exige muito mais gente que detectar um salto de dez. Não precisa virar estatístico, mas precisa aceitar uma verdade dura: se o seu jogo recebe poucas centenas de pessoas por semana, testes de efeito sutil talvez nunca fechem. Melhor gastar essa energia em mudanças grandes o bastante pra aparecer.

Quanto tempo rodar. Defina o fim antes do começo: até atingir a amostra planejada e cobrir pelo menos um ciclo semanal inteiro. Fim de semana e dia útil têm comportamentos diferentes; se o teste pega só a quinta e a sexta, o resultado está enviesado. E se a métrica é retenção D7, o teste tem que rodar tempo suficiente pros primeiros jogadores completarem sete dias antes de você olhar.

Métricas que fazem sentido medir

A métrica errada faz um teste bom mentir. A regra é escolher uma métrica primária, ligada direto à hipótese, e olhar o resto só como contexto.

Retenção é a rainha na maioria dos testes de onboarding e dificuldade. Se a mudança é pra segurar o jogador, meça se ele volta. Vale entender bem o que significam retenção D1, D7 e D30 e como cada uma se comporta antes de escolher qual delas é o alvo do teste, porque testar contra a errada te leva pra decisão errada.

Conversão é o alvo natural de testes de preço e loja. Pode ser conversão de instalação pra primeira compra, de tela de oferta pra compra, ou de visita à loja pra clique. Escolha a que corresponde ao ponto que você mexeu, não a conversão geral do jogo inteiro, que é lenta demais pra reagir a uma mudança pontual.

Tempo de sessão ajuda em testes de ritmo e engajamento, mas exige cuidado. Sessão mais longa nem sempre é vitória: pode ser que a fase ficou confusa e a pessoa passou mais tempo perdida. Sempre leia tempo de sessão junto com retenção, nunca sozinho.

O perigo é olhar dez métricas e comemorar a que subiu. Se você mede tudo, alguma coisa vai parecer melhor por puro acaso. Escolha a primária na hipótese, trate as outras como sinais de alerta (pra garantir que a variante não quebrou nada), e resista a trocar de alvo no meio do caminho.

Erros comuns que estragam o resultado

Parar cedo. O mais comum e o mais caro. A variante abre na frente nos primeiros dias, você comemora e encerra. Só que com pouca gente, essa diferença pode ser sorte. Resultado que oscila muito no começo é normal; ele estabiliza com volume. Definir o fim antes de começar existe justamente pra você não ceder à tentação de parar no pico.

Testar coisa demais. Rodar cinco variantes com dez mudanças cada, sem estrutura, gera um monte de número que não ensina nada. Você não consegue atribuir causa, a amostra se dilui entre grupos e nenhum atinge significância. Menos testes, mais limpos, valem mais que muitos testes bagunçados.

Ignorar significância. Significância estatística é o jeito de perguntar "essa diferença é real ou é sorte?". Uma variante que converte 12% contra 11% do controle pode ser vitória real ou pode ser ruído, dependendo de quantos jogadores passaram por cada lado. Sem checar isso, você toma decisão baseada em barulho. Não precisa dominar a matemática, mas precisa desconfiar de diferença pequena com pouca gente, e existem calculadoras simples que fazem essa conta pra você.

Contaminar os grupos. Se o mesmo jogador vê as duas versões (porque trocou de aparelho, porque o sorteio falhou, porque você mudou a versão no meio), o teste apodrece. Cada pessoa fica num grupo só, do começo ao fim.

Teste A/B não substitui playtest

Esse é o ponto que fecha tudo. Teste A/B te diz qual versão ganha. Ele não te diz por quê. Você vê a retenção da variante subir, mas o número não explica o que passou pela cabeça do jogador.

Quem explica o porquê é o playtest qualitativo. Sentar do lado de poucas pessoas, ver onde elas travam, ouvir o que resmungam, notar a cara de confusão que nenhuma métrica captura. O playtest gera as hipóteses que valem a pena testar; o teste A/B decide entre elas com volume. Se você tenta usar teste A/B pra descobrir problema novo, vai testar no escuro, porque nem sabe o que procurar. E se tenta usar playtest pra decidir preço com cinco pessoas, vai generalizar demais a partir de pouca gente.

A ordem prática costuma ser: playtest revela um problema e sugere uma solução, você transforma essa solução numa hipótese, e o teste A/B confirma se ela funciona na escala real. Vale investir em playtesting qualitativo e iteração com feedback de usuários mesmo depois do jogo lançado, porque ele continua sendo a fonte das melhores perguntas. O teste A/B só responde bem perguntas boas.

Ferramentas existem, mas o método vem primeiro

Sim, tem plataforma pronta pra dividir jogadores em grupos, servir versões diferentes e calcular significância. Elas ajudam e economizam tempo. Mas ferramenta nenhuma salva um teste com hipótese vaga, duas variáveis misturadas e amostra pela metade. O contrário também vale: dá pra rodar um teste A/B decente com um sorteio simples no código, um evento de analytics e uma planilha, desde que o método esteja certo.

Comece pelo experimento mais barato e de maior impacto que você tiver, quase sempre o onboarding ou a loja. Escreva a hipótese numa frase. Mude uma coisa. Defina a amostra e o prazo antes de rodar. Escolha uma métrica primária. Espere o teste terminar de verdade. E, ganhando ou perdendo, você sai com uma certeza a mais e um achismo a menos. Num jogo que vive de operação contínua, é assim que a soma de pequenas decisões honestas separa o que cresce do que definha.