Fazer teste A/B em uma landing page é um problema resolvido. Você muda o título, espera alguns dias e conta os cadastros. A métrica chega em segundos, o tráfego é grande e o resultado de cada visitante independe do resultado de todos os outros.
O onboarding quebra essas três premissas. O resultado que importa chega dias depois de a mudança ter sido vista. O seu volume de cadastros é uma fração do seu volume de visitantes. E cada usuário passa pelo fluxo exatamente uma vez, o que significa que você não consegue repetir o momento que fez diferença.
Nada disso torna impossível experimentar no onboarding. Só faz dele uma disciplina diferente, em que o valor vem de testar mudanças em menor número e maiores contra métricas mais lentas e melhores. Este guia mostra o que testar, o que medir, de quanto tráfego você realmente precisa e o que fazer quando não tem esse tráfego.
Principais conclusões
- Meça ativação, não cliques. Uma variante pode aumentar a conclusão do tour e ao mesmo tempo reduzir o número de usuários que tiram algum proveito do produto. É otimizando a métrica substituta que isso acontece.
- Teste coisas grandes. Mudanças pequenas exigem um tráfego que a maioria dos produtos SaaS não tem. Checklist versus nenhum checklist dá para testar; mudar a cor de um botão, não.
- A métrica de resultado é atrasada. Se a ativação costuma levar uma semana, quem se cadastrou ontem não pode ter ativado. Incluir essas pessoas corrompe o resultado.
- Defina o tamanho da amostra antes de lançar. As métricas de onboarding oscilam muito no começo, e quase sempre existe um momento em que a sua variante preferida está ganhando.
- Uma variável por teste. Mude três coisas e um resultado positivo não diz nada sobre qual delas manter.
- Falta de tráfego não é desculpa para chutar. Cinco sessões de usabilidade, uma comparação de cohorts antes e depois ou um teste de porta pintada valem mais do que um experimento sem poder estatístico.
O que é teste A/B no onboarding?
Definição: fazer teste A/B no onboarding significa dividir aleatoriamente os novos usuários entre duas versões da experiência de onboarding e compará-las em um resultado posterior, geralmente a taxa de ativação. Um grupo recebe o fluxo atual (o controle), o outro recebe uma única mudança deliberada (a variante). Cada usuário é atribuído uma vez e permanece nessa variante durante todo o teste.
A mecânica é a de sempre. O que não é comum é a distância entre causa e efeito. Em uma landing page, o que você mudou e o que você mede estão a segundos de distância. No onboarding, você muda algo que o usuário vê no segundo minuto e mede se ele obteve valor até o sétimo dia, com toda uma experiência de produto no meio.
É nessa distância que a maioria dos experimentos de onboarding dá errado, e é por isso que o restante deste guia dedica mais tempo à medição do que à mecânica.
Por que testes A/B de onboarding são mais difíceis
-
A métrica é atrasada
A ativação pode levar uma hora ou duas semanas. Até que todos os usuários da amostra tenham tido a janela completa para ativar, as duas variantes ficam subestimadas, e não necessariamente na mesma proporção, que é como uma métrica atrasada consegue inverter um resultado.
-
A população é pequena
Você testa com cadastros, não com visitantes. Um site com 50.000 visitantes por mês e taxa de cadastro de 3% tem 1.500 usuários por mês para dividir, ou seja, mais ou menos um teste com poder estatístico adequado por trimestre, se você estiver testando algo relevante.
-
Cada usuário vê uma vez só
Não existe segunda impressão. Uma variante confusa não apenas perde o teste: ela custa para sempre os usuários que a receberam, o que é um argumento real para fazer pesquisa qualitativa antes e testar só as ideias que sobrevivem a ela.
-
Segmentos se comportam de formas diferentes
Uma mudança que ajuda usuários técnicos pode prejudicar os não técnicos, e o saldo dá "nenhum efeito". Resultados agregados de onboarding escondem mais do que os de landing page, então planeje as quebras por segmento antes de lançar.
A consequência prática: você tem um punhado de experimentos reais de onboarding por ano, não dezenas. Use-os em mudanças estruturais com um mecanismo plausível por trás (ideias que surgiram de gravações de sessão, dados de abandono ou testes de usabilidade), e não em uma fila de variações cosméticas.
O que medir: ativação, não cliques
A forma mais comum de obter uma resposta errada de um teste bem executado é medir a coisa errada.
| Métrica | Use como | Por quê |
|---|---|---|
| Taxa de ativação | Métrica principal de sucesso | O único número que significa que o usuário conseguiu o que veio buscar |
| Tempo até o primeiro valor | Métrica secundária de sucesso | Identifica variantes que ativam a mesma parcela de usuários, só que mais rápido |
| Retenção no dia 30 | Juiz final, se você puder esperar | A única métrica que não pode ser manipulada por uma primeira sessão persuasiva |
| Taxa de conclusão de etapas | Apenas diagnóstico | Explica por que uma variante ganhou ou perdeu; péssimo critério de sucesso |
| Conclusão do tour / checklist | Apenas diagnóstico | Sobe facilmente se você encurtar o tour, o que pode não ajudar ninguém |
| Tempo no onboarding | Métrica de proteção | Ambígua sozinha: pode ser engajamento ou pode ser confusão |
| Tickets de suporte | Métrica de proteção | Uma variante que ganha em ativação e dobra os tickets não ganhou |
A armadilha da métrica substituta merece ser explicada em detalhe, porque é muito fácil cair nela. Suponha que a variante B encurte o tour de produto de oito etapas para três. A conclusão do tour salta de 34% para 71% e o teste é declarado um sucesso. Mas, se as cinco etapas removidas eram justamente as que mostravam aos usuários como fazer aquilo que vieram fazer, a ativação pode ter caído enquanto a sua métrica de destaque dobrava.
Escolha o evento de ativação antes do teste, defina-o como um evento de valor concreto e não o mude no meio do caminho. Nossos guias sobre o momento aha e sobre métricas de onboarding explicam como escolhê-lo.
8 testes A/B de onboarding que valem a pena
Ordenados mais ou menos pelo tamanho de efeito esperado, que, dadas as limitações de tráfego acima, é a ordem que importa.
1. Checklist versus nenhum checklist
Mostre um checklist de onboarding para metade dos novos usuários e o produto sem nada para a outra metade. Essa costuma ser a maior alavanca isolada disponível, porque um checklist transforma um "se vira" sem fim em uma lista curta e finita, com um final visível.
Hipótese: tornar o caminho explícito e finito aumenta a ativação. Meça: taxa de ativação e tempo até o valor.
2. Menos campos no cadastro
Reduza o formulário a e-mail e senha e colete todo o resto depois. Acompanhe as duas metades do funil: a taxa de cadastro e a taxa de ativação. A falha que este teste existe para detectar é uma mudança no formulário que aumenta os cadastros e reduz a ativação, porque os campos removidos faziam um trabalho útil de direcionamento, a tensão de que tratam nossos guias sobre fluxos de cadastro e perfilamento progressivo.
3. Dados de exemplo versus estado vazio
Preencha as contas novas com um projeto de exemplo realista em vez de uma tela vazia. É estrutural, barato de construir e muitas vezes um dos testes que mais movem o ponteiro: uma conta vazia pede ao usuário que faça a parte mais difícil do trabalho com o mínimo de contexto. Veja nosso guia sobre estados vazios.
Métrica de proteção: fique atento a usuários que confundem os dados de demonstração com os próprios dados, o que aparece como tickets de suporte e não como uma métrica.
4. Tour inicial versus orientação contextual
Controle: um tour de boas-vindas no primeiro login. Variante: nenhum tour inicial e tooltips curtos acionados quando o usuário chega pela primeira vez a cada área relevante.
Este é o teste mais informativo da lista, porque as duas filosofias produzem produtos de fato diferentes. A orientação contextual costuma ganhar em ativação; os tours iniciais às vezes ganham em descoberta de funcionalidades. Saber qual se aplica a você vale o tráfego de um trimestre. Nosso guia sobre tours de produto que convertem cobre os dois padrões.
5. Caminho personalizado versus fluxo único para todos
Faça uma pergunta de múltipla escolha, "o que traz você aqui?", e ramifique a primeira sessão de acordo com a resposta. O controle recebe o mesmo fluxo para todo mundo.
Note que isso testa duas coisas ao mesmo tempo: o custo da pergunta e o benefício da ramificação. Aqui isso é aceitável, porque você nunca lançaria a pergunta sem a ramificação, mas seja honesto: um resultado negativo não diz qual das duas metades falhou. Relacionado: onboarding personalizado.
6. Indicador de progresso versus nenhum
Adicione uma barra de progresso a um setup de várias etapas. É barato de implementar e aproveita um efeito comportamental confiável: as pessoas tendem mais a terminar algo que está visivelmente perto do fim.
Fique atento a: uma barra de progresso que faz um setup longo parecer mais longo. Mostrar "etapa 2 de 9" pode ser pior do que não mostrar nada.
7. Exigência de valor adiada versus imediata
O controle pede que o usuário importe os dados reais antes de ver qualquer coisa. A variante deixa o usuário explorar primeiro e importar depois. Testa se o custo do setup está sendo cobrado antes de o usuário ter qualquer motivo para pagá-lo.
8. Microcopy na etapa com maior abandono
Reescreva o rótulo, o texto de ajuda e o botão da etapa em que o seu funil mais perde gente. O escopo é pequeno, mas concentrado exatamente no lugar onde a perda acontece. Veja nosso guia de microcopy UX.
Ressalva: mudanças de texto costumam produzir efeitos pequenos, então este teste precisa de mais tráfego do que a sua simplicidade sugere.
Tamanho da amostra e duração: a versão honesta
Esta é a seção que a maioria dos conselhos sobre testes de onboarding pula, e pulá-la é o motivo de tantas equipes rodarem testes que nunca poderiam ter chegado a uma conclusão.
O que importa é a relação: reduzir pela metade o efeito que você quer detectar multiplica por quatro, aproximadamente, o tráfego necessário. Esse único fato define toda a sua estratégia de experimentação.
Três regras para encerrar um teste
- Atinja o tamanho de amostra calculado antes. Decidido antes do lançamento, por escrito, e não revisado porque o gráfico parece promissor no quarto dia.
- Rode por pelo menos duas semanas completas. Cadastros de dias úteis e de fim de semana se comportam de forma diferente, e uma semana é uma única amostra de um ciclo semanal.
- Deixe a métrica amadurecer. Se a ativação leva até sete dias, os cadastros dos últimos sete dias ainda não tiveram tempo de ativar. Exclua esses usuários ou espere.
Espiar o resultado não é um pecado pequeno. Verificar a significância repetidas vezes e parar assim que ela aparece infla muito a sua taxa de falsos positivos: na prática, você roda vários testes e reporta o mais lisonjeiro. Com os dados iniciais ruidosos do onboarding, uma variante "claramente ganhando" no terceiro dia é a regra, não o sinal. Defina a condição de término antes de lançar e respeite-a.
Como rodar um teste A/B de onboarding em 6 etapas
Encontre o vazamento no seu funil
Diagnostique de forma qualitativa antes de desenhar uma variante
Escreva uma hipótese refutável com uma única variável
Calcule o tamanho da amostra e a data de término
Construa as duas variantes e verifique a divisão
Analise por segmento e depois lance ou descarte
1. Encontre o vazamento
Monte o funil de onboarding do cadastro até a ativação e encontre a etapa com a pior conversão, o diagnóstico que está no centro do framework de pirate metrics. Teste onde está a perda, não onde está a ideia.
2. Diagnostique antes de desenhar
A análise de dados diz onde. Nunca diz por quê. Antes de construir uma variante, assista a cinco gravações de sessão de usuários que abandonaram naquela etapa ou faça um teste de usabilidade rápido no fluxo.
É esta etapa que separa um teste com chance real de ganhar de um cara ou coroa. Uma variante desenhada a partir de uma causa observada tem um mecanismo por trás; uma variante desenhada a partir de um brainstorm tem uma esperança.
3. Escreva uma hipótese refutável
O formato que mantém as equipes honestas:
Como [o que observamos], acreditamos que [a mudança] vai [efeito esperado na métrica principal]. Saberemos que estamos certos quando [limite específico].
Preenchido: como quatro de cinco participantes do teste abandonaram na etapa de importação de dados e disseram que não tinham um arquivo pronto, acreditamos que oferecer um conjunto de dados de exemplo vai aumentar a ativação em 7 dias. Saberemos que estamos certos quando a taxa de ativação da variante superar a do controle em pelo menos 20% relativos, com 1.300 usuários por braço.
Mude exatamente uma variável. Não o texto e o layout e o gatilho: uma vitória vinda de um pacote de mudanças não pode ser atribuída, e você vai acabar mantendo as três para sempre.
4. Calcule primeiro o tamanho da amostra e a data de término
Pegue a sua taxa de ativação de base, decida qual é a menor melhoria que vale a pena lançar e calcule os usuários necessários por braço. Depois divida pelo seu volume semanal de cadastros para obter a duração. Se essa duração passar de oito semanas, o teste não é viável: teste algo maior ou use uma das alternativas abaixo.
5. Construa as duas variantes e verifique a divisão
Atribua cada usuário uma única vez, com base em um identificador estável, e mantenha-o nessa variante durante todo o teste. Depois verifique: confira a divisão após os primeiros cinquenta usuários e confirme que ela está perto de 50/50 e que as duas variantes aparecem corretamente para uma conta real.
Variantes quebradas ou mal atribuídas são a principal causa de testes de onboarding desperdiçados, e o estrago fica invisível até a análise. Como os tours, os checklists e os tooltips do Kompassify são direcionados por segmento e configurados em vez de programados, você consegue montar os dois braços sem um release, o que também significa que uma variante perdedora pode ser desligada em minutos.
6. Analise por segmento e depois decida
Olhe primeiro o agregado e depois quebre por canal de aquisição, plano e qualquer atributo da primeira sessão que você colete. Um "nenhum efeito" no agregado muitas vezes esconde um resultado fortemente positivo em um segmento e negativo em outro, o que é uma decisão de lançamento (liberar para um segmento) e não um descarte.
E então decida de verdade. Um teste que termina com "interessante, vamos deixar rodando" custou tráfego e não trouxe nada.
O que fazer quando você não tem tráfego
A maioria dos produtos SaaS não consegue rodar testes A/B válidos no onboarding, e fingir o contrário gera testes sem poder estatístico cujos falsos negativos bloqueiam mudanças realmente boas. As alternativas não são prêmios de consolação; para equipes pequenas, costumam ser as ferramentas melhores.
| Método | O que você precisa | O que ele entrega | Ideal para |
|---|---|---|---|
| Teste de usabilidade | 5 participantes | A causa do abandono, observada diretamente | Qualquer abandono que você não consegue explicar |
| Cohorts antes / depois | Dois meses comparáveis | Evidência direcional, distorcida pela sazonalidade | Apenas mudanças estruturais grandes |
| Teste de porta pintada | Um link e uma mensagem | Evidência de demanda antes de construir | Decidir se algo sequer vale a pena ser construído |
| Pesquisa in-app no ponto de abandono | Uma pergunta | Motivos declarados, nas palavras do usuário | Gerar hipóteses a baixo custo |
| Gravações de sessão | 10–20 sessões | Hesitação e cliques de frustração observados | Encontrar atritos que você nem sabia que existiam |
A política pragmática para uma equipe pequena: use métodos qualitativos para decidir o que mudar, lance a mudança para todo mundo e use uma comparação de cohorts antes e depois para confirmar que nada piorou. Reserve testes A/B de verdade para as duas ou três decisões por ano que são caras, reversíveis e realmente incertas. Uma causa clara observada em cinco sessões vale mais do que um teste sem poder estatístico que não conclui nada.
Erros comuns em testes A/B de onboarding
✅ Faça
- Defina o evento de ativação antes de lançar
- Mude exatamente uma variável
- Fixe com antecedência o tamanho da amostra e a data de término
- Rode por pelo menos duas semanas completas
- Deixe a métrica de resultado amadurecer antes de analisar
- Quebre os resultados por segmento
- Mantenha métricas de proteção para tickets de suporte e retenção
- Lance ou descarte; nunca deixe um teste rodando indefinidamente
❌ Não faça
- Otimizar a conclusão do tour ou do checklist como objetivo
- Parar no momento em que a significância aparece pela primeira vez
- Juntar várias mudanças em uma única variante
- Incluir usuários que ainda não tiveram tempo de ativar
- Testar mudanças cosméticas com pouco tráfego
- Deixar usuários trocarem de variante entre sessões
- Rodar testes sobrepostos no mesmo fluxo
- Tratar um resultado nulo como prova de que a ideia estava errada
O erro mais caro: testar a coisa errada com todo o cuidado. Um teste rigorosamente executado sobre a cor de um botão, em um fluxo cujo problema real é que os novos usuários caem em uma tela vazia sem ideia do que fazer, vai produzir um resultado limpo, confiável e totalmente inútil, consumindo um trimestre de tráfego que você poderia ter gastado na pergunta que importava.
Rode experimentos de onboarding sem precisar de um release
Com o Kompassify, você cria tours de produto, checklists de onboarding, tooltips e barras de progresso, direciona cada um para segmentos específicos de usuários e mede a ativação com a análise de produto integrada, tudo sem código. Grátis até 100 usuários ativos por mês, em conformidade com o GDPR e hospedado na UE.
Comece grátis →Perguntas frequentes
O que é teste A/B no onboarding de usuários?
Fazer teste A/B no onboarding significa dividir aleatoriamente os novos usuários entre duas versões de uma experiência de onboarding e compará-las em um resultado posterior, geralmente a taxa de ativação. Um grupo recebe o fluxo atual, o outro recebe uma única mudança deliberada, e cada usuário é atribuído uma vez e permanece nessa variante durante todo o teste. A principal diferença em relação ao teste de landing page está no que você mede: o resultado relevante chega dias depois de a mudança ter sido vista, não segundos.
O que medir em um teste A/B de onboarding?
A taxa de ativação, definida como a porcentagem de usuários de cada variante que chegam a um evento de valor concreto, como enviar a primeira fatura ou publicar a primeira página. Taxas de conclusão de etapas e de cliques são úteis como diagnóstico, mas perigosas como critério de sucesso, porque uma variante pode facilmente aumentar a conclusão do tour enquanto reduz o número de usuários que realmente tiram algum proveito do produto. Quando você pode esperar, a retenção no dia 30 é um juiz final melhor do que a ativação.
Quanto tráfego é preciso para fazer teste A/B no onboarding?
Como referência aproximada, detectar uma melhoria relativa de 20% sobre uma taxa de ativação de base de cerca de 25% exige algo entre 1.000 e 1.500 usuários por variante. Efeitos menores exigem muito mais: reduzir pela metade o tamanho do efeito que você quer detectar multiplica por quatro, aproximadamente, a amostra necessária. A maioria dos produtos SaaS com menos de alguns milhares de cadastros por mês não consegue rodar testes A/B de onboarding válidos com mudanças pequenas, o que é um argumento para testar mudanças maiores, e não para deixar de testar.
Por quanto tempo um teste A/B de onboarding deve rodar?
O suficiente para atingir o tamanho de amostra necessário, no mínimo duas semanas completas para cobrir a sazonalidade semanal, e o suficiente para que a métrica de resultado tenha amadurecido para todos os usuários da amostra. É esse último ponto que as equipes esquecem: se a ativação costuma levar sete dias, quem se cadastrou ontem ainda não teve chance de ativar, então incluir essas pessoas subestima as duas variantes e pode inverter o resultado. Encerre com base em um tamanho de amostra definido antes, não quando o gráfico parecer bom.
Quais são os melhores testes A/B de onboarding para começar?
Comece pelos experimentos estruturais, e não pelos cosméticos, porque mudanças pequenas exigem um tráfego que você provavelmente não tem. Os primeiros testes de maior valor costumam ser: adicionar um checklist de onboarding versus não ter checklist, adiar campos do cadastro para mais tarde na jornada, preencher uma conta nova com dados de exemplo em vez de um estado vazio e substituir um tour de produto inicial por orientação contextual acionada onde os usuários travam.
Dá para fazer teste A/B no onboarding sem tráfego suficiente?
Dá, e você deveria fazer algo. Com volume baixo, as opções honestas são testes de usabilidade qualitativos com cinco participantes para encontrar a causa de um ponto de abandono, comparação de cohorts antes e depois para mudanças estruturais grandes e testes de porta pintada (painted door), que medem a demanda antes de qualquer coisa ser construída. Eles trazem menos certeza estatística do que um teste A/B, mas uma causa clara observada em cinco sessões vale mais do que um experimento sem poder estatístico que gera um falso negativo e bloqueia uma boa mudança.
Qual é o erro mais comum em testes A/B de onboarding?
Declarar o resultado cedo demais. As métricas de onboarding oscilam muito nos primeiros dias de um teste, e quase sempre é possível encontrar um momento em que a variante preferida está na frente. Somado a uma métrica de resultado atrasada, isso produz conclusões confiantes a partir de ruído. Defina o tamanho da amostra e a data de término antes de lançar, e não olhe a significância até que os dois tenham sido atingidos. Em segundo lugar, bem perto, vem mudar várias coisas ao mesmo tempo, o que garante que você não conseguirá atribuir o resultado.