Teste A/B em Apps Mobile: o Guia Completo (iOS + Android)

Teste A/B em app mobile é a mesma ideia central do teste A/B na web (dividir o público ao acaso entre duas versões e medir qual converte mais), mas a execução muda em pontos que decidem se o teste vai dar uma resposta confiável ou vai travar no meio do caminho. Não existe deploy instantâneo: toda mudança de UI ou fluxo passa por uma feature flag remota, porque publicar uma nova versão na loja para cada variação seria inviável e lento. A unidade de aleatorização normalmente é o dispositivo ou o usuário logado, não a sessão. E a base instalada nunca atualiza de uma vez, o que cria um jeito específico de poluir a amostra que quase nenhum guia genérico de teste A/B cobre.

Este guia é a matéria mãe do cluster de teste A/B em mobile deste blog: cobre o que muda de iOS e Android para a web, os três tipos de teste que às vezes se confundem (client-side, server-side e ASO na própria loja), o que testar em cada tela do app, a estatística aplicada com um exemplo trabalhado usando números reais, as ferramentas do mercado numa comparação neutra e os erros que mais derrubam testes mobile. Se você já conhece o básico de teste A/B, veja também o guia completo de teste A/B; se o seu foco é CRO de site, o guia de otimização de conversão (CRO) cobre o lado web em profundidade. Esta matéria vai ganhar posts filhos nas próximas semanas, cobrindo cada uma das telas do app em detalhe. O primeiro já está a caminho: veja o guia completo de teste A/B de onboarding mobile ->.

O que é teste A/B em app mobile, de forma direta

Um teste A/B em app mobile pega uma tela, um fluxo ou uma mensagem dentro do app (ou associada a ele, como um push notification) com um comportamento conhecido, e testa uma variação dela contra o que já existe, com usuários reais, ao mesmo tempo, exatamente como um teste A/B de site. A diferença não está no conceito estatístico, que é idêntico: está em como a variação chega até o usuário e em como você garante que a mesma pessoa sempre veja o mesmo lado, apesar de abrir o app dezenas de vezes ao longo de semanas em vez de carregar uma página uma vez.

Os termos específicos de mobile que você vai encontrar

• ID de instalação (device ID) ou ID de usuário autenticado: a chave estável usada para decidir de qual lado do teste um usuário está, em vez do cookie de sessão comum na web.
• Feature flag remota: um interruptor configurado no servidor que liga ou desliga um trecho de código já publicado no binário, sem exigir nova versão na loja.
• Remote Config: o serviço (Firebase Remote Config é um dos mais usados) que entrega os valores dessas flags para o app em tempo de execução.
• Rollout progressivo (staged rollout / phased release): um mecanismo da própria loja que libera uma nova versão de app para uma fatia crescente da base ao longo de dias, pensado para segurança de release, não para teste A/B propriamente dito; é fácil confundir os dois porque ambos “mostram coisas diferentes para pessoas diferentes”, mas o rollout progressivo não tem grupo de controle nem calcula significância, ele só reduz o raio de um problema até você confirmar que a versão está estável.
• Versão mínima elegível: a versão de binário a partir da qual o código da variação existe; usuários abaixo dela precisam ser excluídos do denominador do teste, não só da exposição.
• Cohort de instalação: o grupo de usuários que instalou o app dentro de uma mesma janela de tempo, útil para isolar o efeito de uma mudança de quem entrou depois dela ser lançada.

Em que teste A/B mobile difere do teste A/B web

Quatro diferenças mudam como você desenha, roda e lê um teste dentro de um app, comparado com um site:

• Unidade de aleatorização. Na web, muita ferramenta ainda pensa em sessão (o cookie do navegador). No app, a unidade quase sempre precisa ser o dispositivo (um ID de instalação estável) ou o usuário autenticado, porque o mesmo visitante pode abrir o app dezenas de vezes ao longo de semanas e precisa cair sempre no mesmo lado. Se a atribuição for por sessão de uso, o mesmo usuário pode alternar entre A e B em aberturas diferentes, e a conversão dele não pertence a lado nenhum.
• Ciclo de release da loja em vez de deploy instantâneo. Um site publica uma mudança em minutos. Um app precisa submeter uma nova versão para a App Store ou o Google Play, esperar a revisão (que pode levar de horas a poucos dias, variando por plataforma e época) e ainda esperar a base instalada atualizar organicamente, o que leva semanas. Por isso praticamente todo programa de teste mobile sério depende de um mecanismo de feature flag remota: a variação já existe dentro do binário publicado, e o servidor decide, em tempo real, qual parte do código cada usuário vê, sem precisar de uma nova versão para cada teste.
• Latência de propagação da mudança. Mesmo com feature flag, uma parcela da base está em modo avião, com o app fechado há dias, ou num dispositivo com política agressiva de economia de bateria que atrasa a sincronização com o servidor de configuração remota. O teste começa “ligado” para todo mundo, mas a exposição real se espalha ao longo de horas ou dias, não instantaneamente.
• Fragmentação de versão do app. Ao contrário da web, onde todo mundo carrega a versão mais nova da página a cada visita, o app tem várias versões de binário rodando ao vivo ao mesmo tempo: quem atualizou ontem, quem atualizou há um mês e quem não atualiza há seis meses porque desativou atualização automática. Se o seu teste depende de um código que só existe nas versões mais novas, usuários presos em versões antigas ficam de fora da randomização real mas ainda entram no denominador de alguma métrica de produto, distorcendo qualquer leitura que não isole isso corretamente.

Três tipos de teste que se confundem: client-side, server-side e ASO

“Teste A/B mobile” na verdade cobre três mecanismos bem diferentes, e é comum confundir os três porque todos comparam duas versões de alguma coisa relacionada ao app:

• Client-side (feature flag remota). A variação vive dentro do binário já publicado. Um SDK de feature flag (Firebase Remote Config, LaunchDarkly, Statsig e outros) busca a configuração do servidor quando o app abre ou sincroniza, e o próprio app decide o que renderizar com base nessa configuração. É o modelo mais comum para testar UI, textos, ordem de telas e pequenas variações de fluxo dentro do app.
• Server-side. A decisão de qual variação mostrar nasce no backend, e o app só pede “o que eu devo mostrar para este usuário” e renderiza o que volta. É o modelo mais robusto para regras de negócio (precificação, elegibilidade de oferta, lógica de recomendação) e para qualquer experimento que também precise ser consistente entre app, site e e-mail transacional, porque a mesma decisão de backend alimenta os três canais.
• Teste de ASO na própria loja. Tecnicamente não é um teste A/B “no seu app”: é um experimento rodado pela própria loja sobre a ficha de listagem, antes mesmo da instalação. A Google oferece isso como Store listing experiments no Google Play Console; a Apple, como Product Page Optimization no App Store Connect. Os dois testam ícone, screenshots e vídeo de preview com tráfego real de busca e navegação da loja; a Google também permite testar o texto da ficha (descrição curta e longa), o que o Product Page Optimization da Apple não cobre, ele fica restrito a ícone, screenshots e vídeo. O resultado que você lê, nos dois casos, é a taxa de conversão de visualização da ficha em instalação, não qualquer evento dentro do app.

Comparando os três lado a lado

Critério	Client-side	Server-side	ASO na loja
Onde a decisão nasce	Dentro do app, lendo uma flag remota	No backend, o app só renderiza	Dentro da própria loja (Google Play / App Store)
O que testa tipicamente	UI, texto, ordem de telas, pequenos fluxos	Preço, elegibilidade, regra de negócio, recomendação	Ícone, screenshots e vídeo de preview (Google e Apple); texto da ficha só no Google Play
Consistência entre canais	Só dentro do app	Alta (a mesma decisão pode alimentar app, site e e-mail)	Não se aplica, é só a ficha da loja
Quem opera a ferramenta	Time de produto/mobile, SDK de feature flag	Time de backend/growth	Google Play Console / App Store Connect (a própria plataforma)
Métrica típica	Conversão dentro do app (ativação, upgrade)	Conversão de negócio (receita, retenção)	Taxa de visualização da ficha em instalação
Depende de review de loja	Não, roda sobre um binário já aprovado	Não	Não é bem “review”, roda dentro do fluxo próprio da plataforma

O que testar em cada tela do app

Nem toda tela do app merece o mesmo esforço de teste. As que mais concentram ganho, em ordem típica de impacto:

Tela / momento	O que costuma se testar	Cuidado específico
Onboarding / tutorial	Número de telas, pular ou não pular, pedir permissão antes ou depois de mostrar valor	É a maior alavanca de ativação; abandono aqui nunca mais volta a aparecer no funil
Paywall / upgrade	Posição do preço, âncora de plano, gatilho de exibição (por tempo, por feature, por uso)	Rege receita direto; sensível a versão do app e a app store rules sobre pagamento
Push notification	Horário de envio, copy, segmentação por comportamento	Cuidado com fuso horário de base global; teste closer ao envio, não ao clique isolado
Navegação / IA	Tab bar x menu lateral, ordem de itens, nomeação de seções	Mudança estrutural, difícil de reverter sem confundir usuário recorrente
Precificação	Planos, período de trial, desconto de entrada	Mesma cautela de qualquer teste de preço: efeito de longo prazo (LTV) nem sempre aparece rápido
Checkout in-app	Fluxo de pagamento, número de etapas, métodos aceitos	Compra dentro do app segue regras da Apple e do Google sobre comissão e sistema de pagamento próprio da loja, que mudam com frequência por decisão regulatória e de plataforma; confirme a regra vigente antes de desenhar o teste, em vez de assumir o que valia há um ano

Sobre o último ponto: as políticas de compra dentro do app (in-app purchase) da Apple e do Google já passaram por mudanças relevantes de comissão e de obrigatoriedade de sistema de pagamento próprio em diferentes mercados e períodos, por decisão das próprias plataformas ou por pressão regulatória. Trate isso como algo que muda, não como uma regra fixa: confira a documentação oficial vigente da App Store Connect e do Google Play Console antes de desenhar qualquer teste de checkout in-app, em vez de replicar o que valia numa época anterior.

Push notification tem uma relação próxima com e-mail marketing (o mesmo raciocínio de teste de assunto e horário de envio se aplica), mas o foco deste guia é o comportamento dentro do app; se seu programa de mensagens cobre e-mail também, trate os dois canais com a mesma disciplina estatística, cada um com sua própria amostra.

Como escrever uma hipótese de teste mobile

A mesma disciplina de hipótese que vale para qualquer teste A/B vale aqui, só que a “observação” que origina a hipótese costuma vir de analytics de produto (evento instrumentado no app), não de heatmap de site. O formato continua o mesmo: porque observei [dado do produto], acredito que [mudança na tela/flag] vai gerar [efeito], medido por [métrica de produto].

Um exemplo concreto de mobile: “porque 38% dos usuários abandonam o onboarding na tela de pedido de permissão de notificação (dado do funil de ativação instrumentado no app), acredito que mover esse pedido para depois do usuário completar a primeira ação de valor vai reduzir o abandono, medido pela taxa de conclusão do onboarding em D1”. Repare que essa frase já entrega a métrica primária (conclusão do onboarding em D1), a direção esperada (subir) e a origem (um evento de produto real, não um palpite de time). Hipóteses fracas em mobile costumam soar como “e se a gente deixasse o app mais bonito”, sem métrica nem direção; descarte esse formato antes de gastar um ciclo de desenvolvimento nele.

Métrica primária e guardrails específicos de mobile

Toda a lógica de métrica primária, secundária e de guarda do teste A/B clássico se aplica sem alteração, mas mobile adiciona guardrails que praticamente não existem (ou importam muito menos) num teste de site:

Guardrail	Por que monitorar em mobile	Sinal de alerta
Taxa de crash	Uma variação pode converter melhor e ainda assim derrubar o app com mais frequência num dispositivo ou versão de sistema operacional específica	Crash rate sobe de forma isolada numa das variações
Nota e sentimento na loja	Uma mudança agressiva de fluxo (paywall cedo demais, permissão insistente) pode melhorar uma métrica de curto prazo e piorar a avaliação pública do app	Queda na nota média ou aumento de reviews negativas mencionando a mudança testada
Taxa de desinstalação	Ganho de conversão que vem à custa de fricção percebida tende a aparecer primeiro aqui, antes de aparecer em churn de assinatura	Desinstalação sobe na variação “vencedora”
Tempo de carregamento / cold start	Qualquer SDK de feature flag ou remote config adiciona uma chamada de rede; se mal implementado, atrasa a primeira tela	Tempo até a primeira tela interativa piora na variação com a flag

Ignorar esses guardrails é como comemorar um teste A/B de site que melhorou conversão mas também disparou o cancelamento: o número que decide o teste subiu, mas o negócio, no agregado, piorou.

A estatística aplicada a mobile: por que a amostra demora mais

A matemática por trás de um teste A/B mobile é exatamente a mesma de um teste A/B web (a mesma aproximação normal de duas proporções), mas três fatores tornam a conta mais dura na prática:

1. Tráfego elegível menor. Um site de marketing pode ter dezenas de milhares de visitantes por semana numa página só. Um app costuma ter um volume de instalações novas ou de usuários ativos numa tela profunda do funil (paywall, checkout) que é uma fração disso, porque o público já passou por um filtro de instalação antes de chegar ali.
2. Ciclos de atualização do app. Se o teste depende de uma versão nova do binário, uma parte do seu público-alvo simplesmente não está elegível ainda, porque não atualizou. O denominador “todo mundo que deveria entrar no teste” cresce devagar, ao ritmo da atualização orgânica.
3. Contaminação por versão antiga. Usuários numa versão antiga do app, que não têm o código da variação nem da flag, continuam gerando eventos de produto (aberturas, conversões) que podem acabar entrando numa métrica agregada se o pipeline de análise não filtrar por versão mínima elegível, distorcendo a leitura sem que ninguém perceba a tempo.

Calcule a amostra do seu teste mobile

Ajuste a taxa de conversão da tela, o efeito mínimo que você quer detectar e o volume semanal real do seu app (não o tráfego do site, o volume de usuários elegíveis daquela tela específica):

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.

Um exemplo trabalhado com números reais

Vamos usar um cenário comum de app mobile: uma tela de ativação (o usuário completa a ação central nos primeiros 7 dias, o “D7”) com taxa base de 22%, testando uma mudança no onboarding que a equipe espera melhorar em +15% relativo (de 22% para cerca de 25,3%). Com 95% de confiança e 80% de poder (os mesmos padrões usados em toda calculadora deste blog), a fórmula de tamanho de amostra devolve 2.602 usuários por variação.

Se o app tem 2.500 novas instalações elegíveis por semana (um volume realista para um app de porte médio, bem abaixo do tráfego de uma landing page de marketing), a duração do teste fica em 15 dias para fechar as duas variações, cerca de duas semanas de espera, mesmo com um efeito relativamente generoso de +15%. É exatamente esse tipo de conta que explica por que testes mobile em telas profundas do funil demoram mais que testes de landing page: não é falta de rigor, é volume elegível menor por padrão.

Agora repare no que acontece se a equipe fica ansiosa e decide olhar o resultado com só 900 usuários por variação (um terço do necessário), com a mesma proporção observada de conversão (22% no controle contra 25,7% na variação, a mesma melhora de +16,7% relativo que apareceria no teste completo):

	Amostra completa (2.602 por variação)	Amostra parcial (900 por variação)
Taxa A (controle)	22,0%	22,0%
Taxa B (variação)	25,6%	25,7%
Melhora relativa observada	+16,6%	+16,7%
Valor-p	0,00199	0,0679
Intervalo de confiança da diferença	+1,3 a +6,0 pontos	−0,3 a +7,6 pontos
Veredito	Significativo, B vence	Inconclusivo

A melhora observada é quase a mesma nos dois casos (a variação realmente parece ~16% melhor), mas o veredito muda por completo: com a amostra completa, o valor-p fica em 0,00199 e o intervalo de confiança da diferença não cruza zero (fica entre +1,3 e +6,0 pontos), um resultado sólido. Com um terço da amostra, o mesmo efeito real produz um valor-p de 0,068, acima do limiar de 0,05, e o intervalo de confiança cruza zero (vai de −0,3 a +7,6 pontos), ou seja, ainda é plausível que não haja diferença nenhuma. Isso não quer dizer que o teste parcial “deu errado”: quer dizer que faltou amostra para o mesmo efeito real virar evidência estatística, exatamente o motivo de calcular o N antes de rodar, e não decidir “de olho no painel” no meio do caminho.

SRM em mobile: a versão antiga do app como suspeita principal

O SRM (Sample Ratio Mismatch, divergência na proporção de amostra) acontece quando o split observado entre variações se afasta do configurado por um problema de coleta, não por acaso. Em mobile, duas causas dominam a lista de suspeitos:

• Bug de atualização forçada. Uma tela de “atualize para continuar” que só aparece para uma variação empurra desproporcionalmente usuários de versões antigas para o outro lado, porque quem atualiza primeiro tende a ter um perfil de engajamento diferente de quem demora.
• Crash isolado numa variação. Se a variação B tem um bug que derruba o app antes de registrar o evento de exposição, o app “some” da contagem de B sem sequer contar como abandono, inflando artificialmente a participação de A no total observado.

Um exemplo com números reais: um teste configurado para 50/50 registra, ao final, 7.150 usuários na variação A contra 4.850 na B, de um total de 12.000. O checador de qui-quadrado de aderência (a mesma matemática usada na calculadora de SRM deste blog) devolve um valor-p praticamente zero para essa divergência, bem abaixo do limiar de alerta de 1%, ou seja, uma divisão dessa magnitude é estatisticamente impossível de acontecer por acaso num split configurado 50/50. Qualquer resultado de conversão medido nesse teste é suspeito até a causa da divergência ser encontrada e corrigida, mesmo que a diferença entre A e B pareça favorável e “limpa” à primeira vista.

Quanto tempo deixar um teste mobile rodando

A regra geral não muda: rode por pelo menos uma a duas semanas inteiras, mesmo que a amostra calculada seja atingida antes, para cobrir um ciclo completo de dias úteis e fim de semana. Em mobile, dois fatores adicionais alongam esse prazo na prática. O primeiro é a propagação da própria feature flag: se o teste depende de uma versão nova do app, o prazo real de “amostra elegível suficiente” só começa a contar depois que uma fatia relevante da base atualizou, não no dia em que você configurou o experimento no painel. O segundo é o comportamento cíclico específico de app: uso de fim de semana em apps de consumo (jogos, entretenimento, redes sociais) costuma diferir bastante do uso em dias úteis de apps de produtividade ou financeiros, e encerrar um teste mobile em três ou quatro dias captura uma fatia enviesada da sua base tanto quanto encerraria num site.

Se o teste envolve push notification, o cuidado de fuso horário já discutido antes também afeta a duração: um teste que “roda 14 dias” no relógio do servidor pode, na prática, expor uma parte da base a menos ciclos de envio completos, se o disparo é sempre no mesmo horário de servidor e uma fatia da audiência está em fusos onde esse horário cai de madrugada.

Checklist antes de ligar um teste mobile (ativo copiável)

Antes de virar a chave de um teste em produção, confirme cada item abaixo. É a versão mobile do teste A/A e dos cuidados de execução que qualquer teste A/B honesto exige, adaptada para os pontos que só existem em app:

Item	Confirmar antes de ligar
Unidade de aleatorização	Device ID ou user ID estável, nunca sessão de uso
Versão mínima elegível	Usuários abaixo dela estão excluídos do denominador, não só da exposição
Feature flag testada em ambos os SOs	A flag renderiza corretamente em iOS e Android antes do teste ir ao ar
SRM por plataforma configurado	O checador de qui-quadrado roda separado para iOS e Android, além do agregado
Guardrails instrumentados	Crash rate, desinstalação e (quando aplicável) nota da loja monitorados desde o dia 1
Amostra e duração calculadas antes	N por variação e prazo definidos com a calculadora deste guia, não “vamos ver como vai”
Fuso horário tratado (se houver push)	Envio e leitura de resultado segmentados por fuso do usuário, não por horário do servidor
Teste A/A prévio (se for a primeira vez na ferramenta)	Duas variações idênticas não acusam diferença significativa nem SRM, confirmando que a coleta está limpa

Trate essa lista como um gate de qualidade, não como burocracia: cada linha existe porque alguma das causas de teste mobile invalidado (peeking à parte) já apareceu em algum programa de experimentação real.

Ferramentas de teste A/B mobile (visão neutra)

Não existe uma ferramenta certa para todo mundo. O critério que decide é sempre o mesmo: client-side ou server-side, custo por evento/usuário e integração com o analytics mobile que você já usa (Firebase Analytics, Amplitude, Mixpanel e afins).

Ferramenta	Modelo	Ponto forte	Considere quando
Firebase A/B Testing + Remote Config	Client-side	Gratuito até um volume alto, integração nativa com Firebase Analytics e Cloud Messaging	Seu app já usa o ecossistema Firebase e o teste é de UI/fluxo dentro do app
Optimizely Full Stack	Client-side e server-side	Maduro, suporta múltiplos SDKs (mobile, servidor, web) sob o mesmo experimento	Você precisa do mesmo experimento coordenado entre mobile e backend
LaunchDarkly	Client-side e server-side (feature flag primeiro)	Foco forte em flag de release/rollout progressivo, com experimentação como camada adicional	O objetivo principal é controle de release seguro, e o teste A/B é um bônus sobre isso
Statsig	Client-side e server-side	Estatística e feature flag integradas desde o início, bom suporte a métricas de produto	Você quer experimentação e analytics de produto na mesma ferramenta
PostHog	Client-side e server-side (open-source)	Analytics de produto, feature flags e experimentos numa suíte só, com opção self-hosted	Você já usa PostHog para analytics e quer unificar com experimentação
VWO Mobile	Client-side	Vem do mundo de CRO web, curva de uso familiar para quem já testa landing pages	Seu time de marketing já usa VWO na web e quer o mesmo modelo mental no app
AB Tasty App	Client-side	Editor visual pensado para marketing, menos dependente de engenharia para variações simples	O time que cria os testes é de marketing/produto, não só engenharia

Vale um critério final, além dos da tabela: custo cresce com volume de eventos ou de usuários únicos, não com número de testes rodando, na maioria dessas ferramentas. Um app com poucos milhões de eventos por mês costuma caber em planos gratuitos ou de entrada de Firebase, Statsig ou PostHog; volume alto de eventos é onde a conversa de custo muda de patamar entre as opções, e vale pedir cotação real antes de decidir, em vez de assumir pelo tier público do site.

A Donnu A/B hoje é uma ferramenta focada no lado web e client-side: snippet leve, sem travar a página, estatística bayesiana honesta. Ainda não cobre app mobile nativo (iOS/Android), e este guia não afirma o contrário. Se o seu produto é um app híbrido ou tem uma camada web relevante (onboarding via web view, checkout web, landing page que alimenta a instalação), a Donnu já resolve essa fatia com o mesmo rigor estatístico que este guia defende para o app inteiro.

Erros comuns específicos de mobile

• Testar com populações de dispositivo desbalanceadas sem checar SRM por plataforma. iOS e Android costumam ter perfis de usuário, comportamento e taxa de conversão diferentes. Rodar o checador de SRM só no agregado pode esconder um desbalanceamento que existe dentro de uma plataforma específica.
• Ignorar diferença de comportamento entre iOS e Android. Um ganho forte no agregado pode ser puxado inteiramente por uma plataforma, escondendo uma perda na outra. Sempre que o volume permitir, leia o resultado segmentado por plataforma antes de generalizar a decisão para o app inteiro.
• Não considerar fuso horário em testes de push notification. Uma base global não está toda acordada ao mesmo tempo. Enviar (e medir) push num horário fixo de servidor, sem ajustar por fuso do usuário, mistura gente em pico de atenção com gente dormindo, distorcendo tanto o teste quanto a experiência.
• Ignorar a versão desatualizada do app como fonte de ruído. Como já cobrimos na seção de estatística, usuários presos numa versão antiga sem o código da variação continuam gerando eventos que podem contaminar métricas agregadas se o pipeline de análise não filtrar por versão mínima elegível.
• Rodar o teste só com a métrica de conversão, sem guardrail. Um paywall mais agressivo pode elevar a conversão de upgrade no curto prazo e, ao mesmo tempo, aumentar cancelamento e reviews negativas semanas depois. Sem guardrail instrumentado desde o início, esse efeito só aparece tarde demais para reverter com facilidade.
• Confiar em amostra pequena por pressa de lançamento. É tentador declarar vencedor assim que o painel mostra qualquer melhora, principalmente quando a equipe já quer avançar para a próxima feature. O exemplo trabalhado deste guia mostra como o mesmo efeito real pode parecer “inconclusivo” ou “significativo” dependendo só do tamanho da amostra, não da qualidade da ideia testada.

Quando NÃO vale a pena rodar um teste A/B mobile

Teste A/B mobile é a ferramenta errada em alguns cenários específicos, e forçar um teste que nunca vai fechar é pior do que não testar:

Cenário	Por que não vale	O que fazer em vez disso
App com poucas centenas de instalações novas por semana	O cálculo de amostra facilmente pede meses para fechar numa tela de conversão rara	Aplique heurísticas conhecidas de UX mobile e correções de atrito óbvio, sem exigir significância estatística; veja também o conceito de baixo tráfego no guia de CRO, que vale igual para app
Correção óbvia e sem risco	Um crash, um botão que não responde, um texto errado: são bugs, não hipóteses	Corrija direto, sem rodar teste para “confirmar” o óbvio
A pergunta é “por quê”, não “quanto”	Teste A/B mede o efeito de uma mudança, não explica o motivo do comportamento atual	Use pesquisa qualitativa (entrevista com usuário, gravação de sessão, teste de usabilidade)
A mudança depende de uma nova versão de binário que a maior parte da base ainda não tem	Enquanto a atualização não se propaga, a amostra elegível fica pequena demais para qualquer leitura confiável	Espere a propagação atingir um piso razoável da base, ou use feature flag para não depender de nova versão nesse teste específico

Faça isso automático na Donnu

Este guia mostrou o que muda de verdade quando o teste A/B sai do navegador e entra no app: unidade de aleatorização por dispositivo, feature flag remota no lugar de deploy instantâneo, amostra que demora mais para fechar e um SRM que costuma nascer de bug de atualização ou de versão antiga em campo. É o mesmo rigor estatístico que este blog defende em toda matéria, só que aplicado a um terreno com mais fricção operacional.

A Donnu hoje resolve a parte web e client-side dessa disciplina: snippet leve que nunca trava a página, dimensionamento de amostra automático e estatística bayesiana honesta, sem achismo. Se o seu produto já mistura app e web (uma landing page que alimenta instalação, um checkout ou onboarding em web view, uma área logada acessada tanto pelo navegador quanto pelo app), o próximo passo natural é levar essa mesma disciplina estatística para o seu site com um teste grátis de 14 dias, enquanto o cluster de mobile deste blog cresce com os posts filhos que cobrem cada tela do app em detalhe, começando pelo guia de teste A/B de onboarding mobile.

Referências

• Firebase. A/B Testing. Documentação oficial do Google sobre como testar mudanças de UI, features e campanhas com Remote Config e Cloud Messaging. firebase.google.com/docs/ab-testing.
• Firebase. Remote Config. Documentação oficial sobre o serviço de configuração remota que permite mudar comportamento e aparência do app sem exigir atualização de versão. firebase.google.com/docs/remote-config.
• Google Play Console. Store listing experiments. Página oficial sobre o teste A/B nativo da ficha de listagem no Google Play, com tráfego real da loja. play.google.com/console/about/store-listing-experiments.
• Apple. Product Page Optimization. Documentação oficial sobre o recurso do App Store Connect que testa até três variações de ícone, screenshots e vídeo de preview contra a ficha original. developer.apple.com/app-store/product-page-optimization.
• Sensor Tower. App Store Optimization: visibility and conversions. Conteúdo da Sensor Tower sobre práticas de ASO, incluindo teste de elementos visuais da ficha da loja para elevar conversão. sensortower.com/blog/app-store-optimization-visibility-conversions.