Teste A/B Mobile x Web: o que Realmente Muda

Teste A/B mobile e teste A/B web usam exatamente a mesma estatística e quase nada mais em comum. O teste de duas proporções, o valor-p, o intervalo de confiança e a fórmula de amostra são idênticos; o que muda é o ciclo de release, a unidade de randomização, o atraso entre atribuir uma variação e ela aparecer, o volume de tráfego disponível nas telas que importam e as métricas de guarda que só existem dentro de um app. Este artigo é filho do guia completo de teste A/B em apps mobile e trata de uma pergunta só: o que um time que já testa bem na web precisa desaprender antes de testar dentro de um aplicativo.

A versão curta: na web a parte difícil costuma ser decidir o que testar, porque publicar uma variação custa minutos. No mobile a parte difícil é a maquinaria em volta do teste, porque uma variação que não está atrás de uma flag remota pode levar semanas para alcançar todo mundo e não pode ser desligada quando dá errado.

Teste A/B mobile x web: as seis diferenças que mudam o resultado

Dimensão	Web	App mobile
Publicar uma variação	Imediato, um snippet ou um deploy	Depende de release, revisão da loja e adoção do usuário, a menos que esteja atrás de remote config
Matar uma variação ruim	Imediato, desligar a flag ou reverter	Imediato só com remote config; senão, nova submissão e novo ciclo de atualização
Unidade de randomização	Cookie ou storage do navegador, fácil de perder	Identificador de aparelho ou de instalação, às vezes a conta logada
Atraso entre atribuir e renderizar	Milissegundos	Segundos a dias, conforme a busca de configuração e a abertura do app
Tráfego na tela que decide	Muitas vezes dezenas de milhares por semana	Muitas vezes alguns milhares por semana
Métricas de guarda extras	Tempo de carregamento, taxa de erro	Crash, nota da loja, tamanho do app, bateria e consumo de dados

Cada linha dessa tabela tem a mesma consequência prática: no mobile você tem menos experimentos, mais lentos e mais caros, então cada um precisa ser escolhido e dimensionado com mais critério que o equivalente na web.

Diferença 1: publicar e matar uma variação

Na web, uma variação é um deploy ou uma regra de snippet, e reverter é outro deploy. No mobile, uma variação embutida no binário precisa passar pela revisão da loja e depois esperar os usuários atualizarem, o que faz a população do teste crescer devagar e de forma desigual. Pior: ela não pode ser interrompida. Uma variação que derruba a conversão ou quebra uma tela numa família específica de aparelho segue rodando até uma nova versão sair e ser adotada.

É por isso que configuração remota não é um luxo no mobile, é a pré-condição para testar. A variação viaja dentro do binário mas nasce inativa; uma flag no servidor decide quem vê, e a mesma flag desliga em minutos. O Firebase Remote Config e a camada de A/B Testing em cima dele são a implementação mais comum nas duas plataformas, e toda alternativa séria funciona do mesmo jeito.

Uma consequência a planejar: a flag é buscada, cacheada e aplicada no ritmo do app, não no seu.

Diferença 2: latência entre atribuição e renderização

Na web, atribuição e renderização acontecem no mesmo carregamento de página. No mobile existe uma lacuna. O app busca a configuração remota, guarda em cache e muitas vezes aplica o valor novo só na abertura seguinte, então um usuário pode estar atribuído à variação B e continuar vendo a variação A por horas ou dias. Aparelhos em modo agressivo de economia de bateria, ou apps deixados em segundo plano por uma semana, esticam isso ainda mais.

Duas regras práticas saem daí. Primeira: trate os dias iniciais de um teste mobile como janela de propagação, não como amostra válida; se a sua plataforma permitir, conte a exposição a partir do primeiro evento que prova que a variação de fato renderizou, e não a partir da atribuição. Segunda: nunca compare o número do primeiro dia de um teste mobile com o do primeiro dia de um teste web, porque o do mobile inclui uma mistura de gente que ainda não recebeu a mudança.

Diferença 3: a unidade de randomização

Um teste web randomiza por cookie ou chave de storage do navegador, o que é frágil: storage limpo, janela anônima e um segundo aparelho produzem uma identidade nova para a mesma pessoa. Um teste mobile randomiza por identificador de aparelho ou de instalação, bem mais estável dentro de um aparelho e igualmente instável entre aparelhos: a mesma pessoa no celular e no tablet pode ficar dos dois lados do experimento.

Situação	Unidade recomendada	Por quê
App sem login, um aparelho por usuário	Identificador de aparelho ou instalação	Estável, simples, não exige identidade
Produto com login usado em vários aparelhos	Identificador da conta	Mantém a mesma pessoa na mesma variação em todo lugar
Teste que muda algo antes do login	Identificador de aparelho, com usuários logados analisados à parte	Misturar as duas unidades numa leitura só contamina a divisão
Teste cujo efeito só aparece depois do login	Identificador da conta, excluindo sessões deslogadas	Incluir sessões que não podiam converter dilui o efeito e infla a amostra necessária

A regra de bolso: escolha a unidade que corresponde ao nível em que o efeito acontece, e nunca misture duas unidades na mesma leitura. Isso se conecta direto com SRM, porque trocar de unidade no meio do teste aparece como uma proporção de divisão que muda ao longo do tempo.

Diferença 4: amostra e a aritmética da paciência

Aqui a diferença deixa de ser conceitual e passa a custar semanas. A fórmula não muda, só o denominador. Ajuste os números abaixo para a sua base e o seu tráfego:

Taxa de conversão atual%Efeito mínimo detectávelrelativo (%)absoluto (pp)Confiança909599%Poder8090%Visitantes por semana (total)Testebilateralunilateral

-Visitantes por variação

-Total (2 variações)

-Duração estimada

Cálculo por aproximação normal de duas proporções, 2 variações (50/50). Mexa nos campos e veja o impacto ao vivo.

O mesmo teste, duas plataformas

Pegue uma taxa de conversão de 3% na tela que decide e um alvo de detectar uma melhora relativa de 10% (de 3,0% para 3,3%), a 95% de confiança e 80% de poder. A matemática devolve 53.211 usuários por variação, na web e dentro do app igualmente, porque a estatística não se importa com onde o usuário está.

O que muda é quanto tempo leva para acumular isso:

• Web, 40.000 visitantes por semana na página testada: cerca de 19 dias.
• App, 6.000 usuários por semana chegando na tela testada: cerca de 125 dias, mais de quatro meses, o que não é um teste, é uma estação do ano.

A resposta honesta no mobile não é rodar assim mesmo e espiar. É mudar a pergunta: mire numa melhora relativa de 20% (de 3,0% para 3,6%) e o requisito cai para 13.914 por variação, que aos mesmos 6.000 usuários por semana leva cerca de 33 dias. Efeito maior exige mudança maior, o que na prática significa testar uma tela redesenhada em vez de um botão reescrito.

Diferença 5: o que dá e o que não dá para testar

Alguns experimentos simplesmente não existem do outro lado da divisa.

• Só na web: qualquer coisa que dependa de publicação instantânea, como testar várias versões de título na mesma semana, e qualquer coisa movida por tráfego de busca ou indicação que cai direto na página testada.
• Só no app: testes de ficha da loja (Product Page Optimization da Apple, experimentos de ficha do Google Play), testes de notificação push e qualquer coisa amarrada a pedidos nativos de permissão, como o momento de pedir permissão de notificação ou de rastreamento.
• Nos dois, com regras diferentes: preço. Na web você controla o checkout e a exibição do preço. No app, os requisitos da Apple para assinaturas renováveis exigem que o valor a ser cobrado seja o elemento de preço mais proeminente do layout na tela de compra, com preço equivalente ou economia exibidos em posição e tamanho subordinados, o que elimina toda uma família de layouts de ancoragem que passariam num paywall web. O guia de teste A/B de paywall mobile cobre esses limites em detalhe.

Diferença 6: métricas de guarda que só existem num app

Um teste web acompanha tempo de carregamento e taxa de erro. Um teste mobile precisa acompanhar mais três, e as três conseguem transformar um vencedor estatístico numa perda de negócio.

• Taxa de crash e de app não responsivo por variação. Uma variação que carrega uma tela mais pesada pode quebrar em aparelhos antigos enquanto converte melhor nos novos. Leia estabilidade por variação e, quando o volume permitir, por faixa de aparelho.
• Nota da loja e sentimento das avaliações. Uma mudança de monetização pode vencer em conversão e custar uma fração de estrela, e a nota alimenta o volume de instalação. É uma perda lenta e composta que nenhum painel de conversão mostra.
• Tamanho do app, bateria e consumo de dados. Usuário de aparelho de entrada e de plano de dados limitado vai embora em silêncio. A ausência dele não aparece como conversão menor, aparece como denominador menor, exatamente o tipo de perda que uma leitura agregada esconde.

O erro de somar mobile e web num resultado só

O erro mais caro de quem roda as duas superfícies é tratá-las como um experimento só com uma amostra só. As duas populações têm taxas base diferentes, chegam por canais diferentes e convertem em prazos diferentes. Somar cria as condições clássicas do paradoxo de Simpson, em que cada grupo aponta para um lado e o agregado aponta para o outro. Rode dois experimentos, dimensione cada um com a sua própria base e o seu próprio tráfego, e compare as duas leituras como duas evidências independentes. Se concordam, a sua confiança no mecanismo sobe. Se discordam, você aprendeu algo específico sobre a superfície, o que é mais útil que um número misturado que não descreve nenhuma das duas.

A mesma disciplina vale para SRM. Um teste de 10.000 usuários que deveria dividir 50/50 e observa 5.300 contra 4.700 produz um qui-quadrado de aderência de 36 com 1 grau de liberdade, muito acima do limiar de 6,63 a 1%, com valor-p da ordem de dois em um bilhão. Na web isso normalmente significa um redirecionamento ou um filtro de bot. No mobile normalmente significa uma versão do app ou um cache de configuração, e invalida a leitura nos dois casos até a causa ser encontrada.

Um exemplo trabalhado: lendo um resultado web com honestidade

Um checkout web converte a 3,00%. O time publica um novo layout da etapa de pagamento e roda o teste até 26.000 visitantes por variação, encerrando com 780 pedidos no controle e 866 na variação (3,33%). Passando esses quatro números pela mesma matemática de duas proporções que este blog usa em todo lugar: z = 2,15, valor-p ≈ 0,0312, com intervalo de confiança de 95% da diferença entre +0,03 e +0,63 ponto percentual, e ganho relativo observado de +11,0%.

O resultado é significativo, e o intervalo é um bom lembrete de quão impreciso um resultado significativo pode ser: o ganho verdadeiro pode ser tão pequeno quanto 0,03 ponto, que é quase nada, ou tão grande quanto 0,63 ponto. Na web, rodar mais tempo para estreitar esse intervalo custa alguns dias. Dentro de um app com 6.000 usuários semanais na mesma tela, estreitar o mesmo intervalo custaria meses, e essa é a razão real pela qual programas mobile deveriam preferir poucos experimentos ousados a muitos experimentos marginais. O guia de significância estatística explica como ler cada um desses números.

Faça isso automático na Donnu

Se o seu produto vive nas duas superfícies, a divisão honesta do trabalho é esta: dentro do app, você precisa de remote config, randomização por aparelho e métricas de guarda de estabilidade; na web, você precisa de um snippet que não atrase a página, dimensionamento automático de amostra e estatística que não inventa certeza.

A Donnu cobre a metade web e client-side desse quadro: snippet leve, dimensionamento automático e estatística bayesiana honesta, sem entregar framework para o visitante. Ela não roda experimentos dentro de um binário nativo iOS ou Android, e este guia não finge o contrário. Se a sua jornada inclui uma landing page, um checkout web ou uma área logada acessível pelo navegador, comece um teste grátis de 14 dias e aplique o mesmo rigor a essa metade.

---

Leia também: Teste A/B em Apps Mobile: o Guia Completo · Teste A/B de Paywall Mobile · Teste A/B Client-Side x Server-Side · Read in English

Referências

• Firebase. A/B Testing with Firebase Remote Config. Documentação oficial sobre configuração remota, atribuição de variante e rollout em iOS e Android. firebase.google.com/docs/ab-testing.
• Apple Developer. Auto-renewable Subscriptions. Requisito oficial de que o valor a ser cobrado seja o elemento de preço mais proeminente do layout na tela de compra. developer.apple.com/app-store/subscriptions.
• Apple Developer. App Review Guidelines (seção 3.1.2, Subscriptions). Regras de revisão para assinaturas, que remetem aos requisitos acima. developer.apple.com/app-store/review/guidelines.
• Apple. Product Page Optimization. Teste de ficha de loja no App Store Connect, um tipo de experimento sem equivalente na web. developer.apple.com/app-store/product-page-optimization.
• Google Play Console. Store listing experiments. Teste A/B nativo de ficha de loja, incluindo texto além de imagens. play.google.com/console/about/store-listing-experiments.
• Google Play Console Ajuda. Release app updates with staged rollouts. Documentação oficial sobre adoção escalonada de versão, que é o que faz uma variação amarrada à versão alcançar os usuários de forma desigual. support.google.com/googleplay/android-developer/answer/6346149.
• Kohavi, R., Tang, D. e Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020. Material de apoio em experimentguide.com.