Teste A/B de Onboarding Mobile: o que Melhora a Retenção
Teste a/b onboarding mobile: qual métrica de ativação usar, o efeito real das permissões do sistema e o erro estatístico que engana a maioria dos apps.
📚 Este artigo faz parte do guia Teste A/B em Apps Mobile: o Guia Completo (iOS + Android).
Testar A/B o onboarding de um app mobile só produz uma resposta confiável quando a métrica que decide o teste é a ativação de verdade, a conclusão de uma ação-chave específica dentro de uma janela fixa de dias, e não uma métrica de vaidade como “telas do tutorial vistas”. Este artigo faz parte do guia completo de teste A/B em apps mobile (iOS + Android) e cobre o experimento mais comum e mais mal medido do mobile: o onboarding. Você vai ver qual métrica usar, o que a tela pequena e as permissões do sistema mudam na conversão, o viés que infla resultados sem ninguém perceber e a armadilha estatística exclusiva de apps com versões diferentes em campo.
A métrica real de ativação: D1/D7/D30 e a ação-chave, não telas do tutorial
A armadilha mais comum de quem testa onboarding mobile é otimizar o que é fácil de contar (telas vistas, botões tocados, porcentagem do tour concluída) em vez do que de fato prevê se aquele usuário vai voltar. A prática recomendada de growth mobile trabalha com uma curva de retenção em três marcos: D1 (o usuário abre o app de novo no dia seguinte), D7 (ele volta e repete a ação central dentro de uma semana) e D30 (o hábito se consolidou). Nenhum desses três marcos é “viu o tutorial inteiro”. Cada produto tem a sua própria ação-chave: para um app de finanças pode ser conectar uma conta; para um de fitness, registrar o primeiro treino; para um de mensagens, trocar a primeira conversa real. Defina a sua antes de testar qualquer coisa no fluxo de boas-vindas.
Benchmarks de mercado ajudam a calibrar expectativa, nunca a definir meta. O levantamento de retenção mobile da UXCam reporta estas faixas para os apps de melhor desempenho, o percentil 75 de cada categoria:
| Categoria | D1 | D7 | D30 |
|---|---|---|---|
| Social | 50% a 60% | 25% a 30% | 15% a 20% |
| Fintech | 35% a 45% | 18% a 25% | 10% a 15% |
| Produtividade | 40% a 50% | 22% a 28% | 12% a 18% |
| Jogos | 40% a 50% | 12% a 18% | 5% a 8% |
| E-commerce | 25% a 30% | 8% a 12% | 3% a 6% |
Leia essas faixas como o quartil superior, não como a média. Segundo o mesmo levantamento da UXCam, a D30 abaixo de 5% é a norma na maioria das categorias, não a exceção, com a mediana em torno de 4%. Se o seu app converte acima disso, o problema não é a curva geral, é o quanto o seu onboarding empurra gente pra cima ou pra baixo dela, e isso só um teste A/B com a métrica certa consegue medir.
Tela pequena, decisões grandes: o que muda do onboarding web para o mobile
No onboarding web, o usuário tem uma tela grande, várias janelas abertas e a chance de voltar depois. No mobile, cada elemento da tela compete por uma atenção muito mais escassa: o espaço físico é menor, a sessão é mais curta e a distração (uma notificação de outro app, uma ligação) está a um toque de distância. Isso muda o que vale a pena testar:
- Um elemento por tela pesa mais. Um formulário de cadastro inteiro numa tela mobile costuma converter pior do que o mesmo formulário dividido em passos curtos, porque cada campo extra visível compete diretamente pelo polegar do usuário.
- A permissão do sistema operacional entra no meio do fluxo. É a diferença mais concreta e mais mensurável entre onboarding mobile e web: pedir push, localização ou câmera é uma interrupção nativa do sistema que o navegador não tem, e o momento em que ela aparece afeta diretamente quantas pessoas terminam o onboarding.
- Atualização de app não é instantânea. Na web, publicar uma mudança afeta todo mundo na próxima carga de página. No mobile, uma variação nova de onboarding só chega a quem está numa versão do app que a suporta, e isso cria uma armadilha estatística própria, que vamos ver mais à frente.
O ponto que mais derruba a conclusão: quando pedir permissão do sistema
Pedir push, localização ou câmera logo na primeira tela do onboarding é o erro de UX mais repetido em apps mobile, e o custo dele é mensurável, não apenas uma sensação de “atrito”. A documentação oficial da Android sobre boas práticas de permissão recomenda pedir a permissão no contexto do uso, no momento em que o usuário está prestes a usar a funcionalidade que precisa dela, e não de forma genérica no início do app: o usuário aceita mais quando entende por que está sendo perguntado, e recusa mais quando o pedido chega sem contexto. O mesmo padrão aparece do lado do iOS: telas de priming (uma explicação do valor antes do prompt oficial do sistema) tendem a elevar a taxa de aceitação, enquanto empurrar o prompt logo no primeiro acesso tende a reduzir a aceitação.
O funil abaixo marca onde esse pedido costuma entrar num onboarding self-serve típico, e o tamanho da queda que aparece exatamente ali:
Trate o momento do pedido de permissão como qualquer outra variável testável: variação A pede no primeiro acesso, variação B pede só quando o usuário toca numa funcionalidade que exige aquela permissão. Meça o efeito na conclusão do onboarding e na ativação real, porque a permissão em si não é o objetivo, é só um meio.
O viés de sobrevivência ataca o onboarding mobile do mesmo jeito
O mesmo erro estatístico que invalida testes de onboarding em SaaS web aparece aqui, e o artigo irmão sobre teste A/B de onboarding em SaaS já descreve a lógica geral: comparar a ativação só entre quem terminou o onboarding, ignorando quem abandonou no meio, é comparar dois grupos que já foram filtrados de formas diferentes. No mobile isso costuma ser mais severo, porque a tela de permissão e a tela pequena juntas produzem mais abandono precoce do que a maioria dos fluxos web.
Reaproveitando os números do funil anterior: 1.000 pessoas instalaram o app, 640 completaram o onboarding e 220 realizaram a ação-chave dentro de 7 dias. Se você medir a ativação só entre quem terminou o onboarding (o erro comum), o número parece ótimo. Se você medir contra todo mundo que entrou, o número honesto é bem menor:
Na prática, defina a janela de ativação (D7, por exemplo) contada a partir da instalação, e conte cada instalação que entrou no teste no denominador, mesmo a que nunca abriu o app de novo. É mais desconfortável de olhar, mas é o único número que representa o que de fato aconteceu.
A armadilha exclusiva do mobile: preso numa versão antiga, e o SRM que ninguém detecta
Existe um problema estatístico que praticamente não existe na web e que é comum no mobile: parte dos seus usuários fica presa numa versão antiga do app, porque a mudança de onboarding só existe a partir de uma versão nova publicada na loja, ou porque o dispositivo ainda não buscou a configuração atualizada de um remote config. Segundo a documentação do Firebase Remote Config, o intervalo mínimo padrão de busca em produção é de 12 horas: um app pode ficar rodando com a configuração antiga em cache por até meio dia depois de você publicar a mudança, e um usuário que não abre o app com frequência pode ficar preso na versão antiga por muito mais tempo que isso.
O efeito prático: se a divisão do teste depende de o dispositivo já ter recebido a variação nova, quem está preso na versão antiga nunca entra no experimento do jeito que deveria, e o tráfego que sobra para cada lado deixa de bater com o 50/50 que você configurou. Isso é exatamente o que o SRM (Sample Ratio Mismatch) detecta: um teste de aderência entre a divisão observada e a esperada. A pesquisa da Microsoft sobre diagnóstico de SRM em testes A/B trata esse problema como sério o bastante para travar a leitura de qualquer teste até ser descartado, e o usuário preso numa versão antiga do app é o caso mobile mais comum desse mesmo defeito: parte do público nunca teve chance real de cair no lado esperado.
Veja como isso aparece nos números. Um teste configurado para 50/50 (6.000 esperados de cada lado, de um total de 12.000) mas com uma fatia de usuários presa na versão antiga produz uma divisão bem diferente da esperada:
A correção prática: segmente o verificador de SRM por versão do app, não só pelo total agregado. Se o desequilíbrio desaparece ao excluir versões antigas do cálculo, o problema é confirmado e a solução é forçar atualização (ou excluir versões incompatíveis da divisão), nunca só “ignorar e olhar o resultado de ativação mesmo assim”.
Onboarding mobile e onboarding SaaS web: mesma disciplina, detalhes diferentes
A estatística por trás de um teste A/B de onboarding é a mesma em qualquer canal: amostra dimensionada antes de rodar, denominador cheio contra o viés de sobrevivência, e nenhuma leitura de significância sem checar a saúde da divisão. O teste A/B de onboarding em SaaS cobre exatamente essa disciplina para produtos web, e vale a leitura complementar. O que muda no mobile são os detalhes de execução: a variação depende de qual versão do app o usuário tem instalada (a web não tem esse conceito, toda visita já carrega o código mais recente), e a entrega de uma mudança via remote config tem uma latência real de propagação até o dispositivo buscar a configuração nova, em vez de acontecer instantaneamente como na próxima carga de uma página web. Ignorar essas duas diferenças é o jeito mais comum de importar um teste A/B “de livro” da web e ele falhar silenciosamente no mobile.
Tour guiado, sandbox livre ou progressive onboarding: sem vencedor universal
As três estruturas mais comuns de onboarding mobile resolvem problemas diferentes, e nenhuma delas vence sempre:
A tabela resume o que testar em cada estágio do onboarding mobile e onde mora o risco de se enganar:
| Estágio | O que testar | Hipótese comum | Risco de se enganar |
|---|---|---|---|
| Permissão do sistema | Momento de pedir push, localização ou câmera (logo no 1º acesso vs. depois de uma ação de valor) | Pedir com contexto aumenta a aceitação | Medir só a taxa de opt-in infla a permissão como sucesso; meça o efeito na ativação, não só no aceite |
| Estrutura do fluxo | Tour guiado vs. sandbox livre vs. progressive onboarding | Menos carga cognitiva na tela pequena aumenta a conclusão | Concluir o tour não é ativar; meça a ação-chave, não telas vistas |
| Densidade da tela | Quantos elementos por tela (um CTA vs. vários) | Telas mais “vazias” reduzem o abandono | Uma tela vazia demais pode esconder informação que faltava, e isso só aparece na retenção, não na conclusão da tela |
| Push de reengajamento | Notificação pós-instalação (timing e gatilho) para quem não voltou sozinho | Lembrete no momento certo recupera uso | Só alcança quem aceitou push; comparar sem ajustar o denominador reintroduz o viés de sobrevivência |
| Entrega da variação | Rollout via nova versão de loja vs. via remote config | Remote config chega mais rápido a todo mundo | Cache local e usuários presos em versão antiga distorcem a divisão 50/50 (checar SRM por versão) |
Dimensionando o teste: quantos novos usuários você precisa
Suponha que o seu app ativa hoje 22% dos novos cadastros dentro de 7 dias (a ação-chave já validada, na janela de D7) e você quer detectar uma melhora relativa de 15% trazida por um novo posicionamento da tela de permissão, ou seja, levar a ativação para cerca de 25,3%. Com 95% de confiança e 80% de poder, os parâmetros padrão de mercado, ajuste a calculadora abaixo para o seu próprio cenário:
Cálculo por aproximação normal de duas proporções, 2 variações (50/50). Mexa nos campos e veja o impacto ao vivo.
Rodando esses números na mesma matemática da calculadora (sampleSizePerVariant), o resultado é 2.602 cadastros por variação (5.204 no total). Com um volume de 2.500 novas instalações por semana, o teste leva cerca de 15 dias para reunir essa amostra, tempo suficiente para cobrir pelo menos duas semanas cheias de comportamento, incluindo fins de semana.
Veja por que ignorar essa conta é o jeito mais comum de descartar uma boa ideia de onboarding. Simulando o mesmo efeito real usado na conta acima (22% contra 25,3%, usando significance()) em dois volumes de amostra diferentes:
| Cenário | N por variação | Ativados (A / B) | Valor-p | Veredito |
|---|---|---|---|---|
| Amostra dimensionada | 2.602 | 572 / 658 | ≈ 0,0050 | Significativo, B vence |
| Amostra insuficiente | 900 | 198 / 228 | ≈ 0,0962 | Inconclusivo, mesmo efeito real |
A diferença entre “deu certo” e “não deu certo” não veio de o efeito real ter mudado, é o mesmo ganho de ativação nos dois casos. A única coisa que mudou foi o tamanho da amostra. Times de onboarding mobile early-stage, com poucas centenas de instalações por semana, são especialmente vulneráveis a essa armadilha: rodam o teste por 10 dias, leem “não deu significativo” e descartam uma ideia que na verdade funcionava, só faltou amostra.
Antes de rodar qualquer teste de onboarding, escreva a hipótese primeiro: o guia de como escrever uma hipótese de teste A/B tem o formato exato e evita que você saia “descobrindo” um vencedor entre dezenas de métricas secundárias só por acaso.
Faça isso automático na Donnu
Declarar um vencedor de onboarding mobile sem corrigir o viés de sobrevivência ou sem checar SRM por versão de app é a forma mais comum de comemorar um resultado que não existe. A Donnu A/B aplica o mesmo motor de significância deste artigo a cada variação, sempre contra o denominador cheio de quem entrou no teste, e o snippet leve nunca trava o fluxo de onboarding do seu produto. Antes de declarar qualquer vencedor, dimensione o teste com a calculadora acima e confirme a saúde da divisão segmentada por versão do app, não só no agregado.
Comece um teste grátis de 14 dias e dimensione o próximo teste de onboarding com o rigor certo, não com o volume que “parece suficiente”.
Leia também: Teste A/B em Apps Mobile: o Guia Completo (iOS + Android) · Teste A/B de Onboarding em SaaS: o Que Move a Ativação · Como escrever uma hipótese de teste A/B
Referências
- Android Developers. App permissions best practices (timing e contexto do pedido de permissão). developer.android.com/training/permissions/usage-notes.
- UXCam. Mobile App Retention Benchmarks by Industry. uxcam.com/blog/mobile-app-retention-benchmarks.
- AppsFlyer. 5 ways to increase your ATT opt-in rates (priming antes do prompt do sistema). appsflyer.com/blog/tips-strategy/apps-boost-att-opt-in.
- Microsoft Research. Diagnosing Sample Ratio Mismatch in A/B Testing. microsoft.com/en-us/research/articles/diagnosing-sample-ratio-mismatch-in-a-b-testing.
- Firebase. Get started with Remote Config on Android (intervalo padrão de busca/cache). firebase.google.com/docs/remote-config/android/get-started.
Perguntas frequentes
- Qual é a métrica real de ativação num onboarding mobile?
- É a conclusão de uma ação-chave específica do seu produto (o core action) dentro de uma janela fixa de dias, como D7 ou D30, contada a partir da instalação, não a partir do fim do tutorial. "Telas do onboarding vistas" ou "tour concluído" são métricas de vaidade: descrevem se o usuário passou pela introdução, não se ele voltou a usar o app. Valide a ação-chave cruzando quem a fez com quem realmente segue ativo em D7/D30, antes de testar qualquer variação de onboarding.
- Pedir permissão de push, localização ou câmera durante o onboarding derruba a conversão?
- Sim, e o efeito é mensurável, não só uma impressão. A documentação da Android sobre boas práticas de permissão recomenda pedir a permissão no contexto do uso, não no início do app, porque o usuário aceita mais quando entende por que está sendo perguntado. O padrão relatado por fornecedores de mensuração de apps sobre opt-in de ATT no iOS aponta na mesma direção: uma tela de priming antes do prompt oficial do sistema, mostrando o valor primeiro, tende a aumentar a aceitação, enquanto empurrar o pedido logo no primeiro acesso tende a reduzi-la. O timing exato é testável: trate-o como mais uma variação do seu teste A/B de onboarding, não como um detalhe técnico fixo.
- Por que meu teste de onboarding mobile pode "dar significativo" e ainda estar errado?
- O motivo mais comum é o viés de sobrevivência: medir a ativação só entre quem terminou o onboarding, e não entre todo mundo que entrou no teste. Se uma variação afasta mais gente cedo (uma tela de permissão mal posicionada, por exemplo), quem sobra tende a ser um público mais engajado por natureza, e a taxa "entre quem terminou" fica artificialmente melhor mesmo que a ativação real, olhando todo mundo, seja pior ou igual. A comparação correta sempre usa o denominador cheio: todos que instalaram e entraram no teste.
- O que quebra a divisão 50/50 quando eu testo onboarding num app mobile?
- O caso mais específico do mobile é o usuário preso numa versão antiga do app que nunca recebe a nova variação, porque a mudança só existe a partir de uma versão nova publicada na loja (ou porque o cache local do remote config ainda não buscou a configuração atualizada). Isso empurra tráfego desproporcional para o lado antigo e quebra a divisão que você configurou como 50/50. Rode o verificador de SRM (Sample Ratio Mismatch) segmentado por versão do app antes de confiar em qualquer resultado de ativação.
- Tour guiado, sandbox livre ou progressive onboarding: qual converte mais?
- Não existe vencedor universal, e é por isso que esse é um teste, não uma escolha de design feita de ouvido. Produtos com um caminho único e óbvio até o valor central tendem a ganhar com um tour guiado. Produtos cujo valor depende do contexto específico do usuário (dados próprios, integrações, casos de uso variados) tendem a ganhar com um sandbox livre ou com um progressive onboarding, que só pergunta o que é preciso conforme o uso avança. Meça pela ativação real na janela fixa de dias, não pela taxa de conclusão do fluxo.