Funis de onboarding e paywall: o que acompanhar

Nesta página
Na maioria dos apps de assinatura, os primeiros minutos decidem quase tudo. Alguém instala, passa pelo onboarding, encontra um paywall e começa um teste grátis ou vai embora. Se você consegue ver onde as pessoas saem dessa sequência, sabe o que corrigir em seguida. Se não consegue, está chutando, e o chute de sempre (mudar o preço do paywall) muitas vezes é o errado.
Este post é uma lista prática do que acompanhar entre a instalação e a compra, como dar nome a cada coisa, quais números observar e os erros que fazem os funis mentirem.
O funil, etapa por etapa
Um funil típico de app de assinatura tem cinco etapas:
- Instalação: o app foi aberto pela primeira vez.
- Onboarding concluído: a pessoa passou pelas suas telas de introdução e perguntas.
- Paywall visto: a sua oferta foi exibida.
- Teste grátis iniciado (se você oferece um).
- Pagamento: uma primeira compra, ou um teste grátis que converteu.
- Instalação1.000
- Concluíram o onboarding640−36%
- Viram o paywall560−13%
- Iniciaram um teste grátis120−79%(maior queda)
- Pagaram48−60%
Maior queda: Iniciaram um teste grátis
Alguns apps adicionam criou uma conta entre a 2 e a 3, ou colocam o paywall no meio do onboarding. Tudo bem. O funil deve seguir o seu app, não um modelo. Só mantenha o funil curto: cinco ou seis etapas sobre as quais você vai agir valem mais que vinte que você nunca vai ler.
Os eventos
Cada etapa é um evento que o seu app envia num momento específico. O momento importa mais que o nome.
| Recurso | Envie quando | O que ele diz |
|---|---|---|
| Tela de onboarding | Cada tela de onboarding aparece (não quando o botão dela é tocado), com o nome da tela | Em qual tela as pessoas saem, e quanto tempo cada uma leva |
| Onboarding pulado | Alguém toca em Pular, com a tela de onde pulou | Se Pular é um atalho ou uma fuga |
| Onboarding concluído | A última tela do onboarding termina, antes de qualquer paywall ou cadastro que venha depois | A sua taxa de conclusão do onboarding |
| Paywall visto | Toda vez que um paywall aparece, com onde ele apareceu (onboarding, feature_gate, settings) | O alcance do paywall, e qual posicionamento converte |
| Paywall pulado | Alguém fecha o paywall sem comprar | Se as pessoas o dispensam ou nunca o veem |
| Cadastro / login | Uma conta nova é criada / alguém entra numa conta que já tinha | Usuários novos versus os que voltam, para que reinstalações não pareçam cadastros novos |
| Teste grátis iniciado, compra | A loja confirma | A conversão, e o dinheiro |
Algumas regras tornam esses eventos confiáveis:
- Nomes fixos e curtos para as telas, como
goal,notifications,plan. Não “Tela 3”, que muda de sentido no dia em que você reordena o onboarding. - Um posicionamento em cada paywall. O paywall no fim do onboarding e o que fica atrás de um recurso bloqueado são ofertas diferentes para pessoas diferentes. Misture os dois e ambos os números perdem o sentido.
- Cadastro só para contas novas. Se usuários que voltam e entram num celular novo também enviam
sign_up, a sua taxa de cadastro sobe toda vez que alguém reinstala. - Compras vindas da fonte da verdade. Uma compra enviada pelo app não enxerga renovações, reembolsos nem testes grátis que convertem com o app fechado. Se você usa o RevenueCat ou um servidor, deixe que ele informe as compras.
Nunca coloque respostas ou dados pessoais em eventos
Os números para observar
Transforme os eventos em algumas taxas e olhe para elas toda semana.
- Conclusão do onboarding: onboarding concluído ÷ instalações. Está baixa? Olhe as desistências tela por tela.
- Maior queda isolada: a tela em que mais gente sai. Corrija essa primeiro; quase sempre é um pedido de permissão mostrado cedo demais, um formulário longo ou uma tela lenta.
- Alcance do paywall: paywall visto ÷ instalações. Se for baixo, o problema não é o paywall: as pessoas nunca chegam lá.
- Conversão do paywall: teste grátis ou compra ÷ paywall visto, por posicionamento.
- Teste grátis para pago: pagamento ÷ teste grátis iniciado, medido só em testes antigos o bastante para já terem terminado.
- Tempo até pagar: quantos dias depois da instalação as pessoas pagam pela primeira vez. Isso diz quanto esperar antes de julgar as instalações de uma semana.
Olhe para eles por origem também. Quem veio do vídeo de um criador muitas vezes se comporta de um jeito bem diferente de quem veio de um anúncio de busca, e uma média das duas esconde o que cada uma precisa.
Erros que fazem os funis mentirem
Contar pela data do evento em vez da data de instalação
Se você compara “pagamentos desta semana” com “instalações desta semana”, um teste grátis iniciado na semana passada que converte na terça cai na coorte errada. Escolha as pessoas pela data em que instalaram, e depois conte tudo o que elas fizeram, não importa quando. Espere que os números da semana passada subam conforme chegam os pagamentos tardios; isso está certo, não é um bug.
Exigir uma ordem rígida quando o seu app não tem uma
Se alguém pode ver o paywall antes de terminar o onboarding (um botão “ver planos”, por exemplo), um funil com ordem rígida deixa essa pessoa de fora. Conte cada etapa para qualquer pessoa que a fez, a qualquer momento, e use uma ordem rígida só quando a sua pergunta for sobre a sequência.
Dar as pessoas como “perdidas” cedo demais
Alguém que não terminou o onboarding depois de dez minutos pode estar fazendo o jantar. Espere um dia antes de chamar isso de desistência.
Dispositivos de teste nos seus números
Os seus próprios builds de depuração, instalações do TestFlight e compras de sandbox inflam todas as etapas. Deixe-os de fora automaticamente, não dependendo de lembrar de filtrar.
Gente de menos
Com 40 instalações, uma compra a mais move a conversão em mais de dois pontos. Antes de comparar duas versões, espere até que cada uma tenha gente suficiente para que a diferença não seja ruído.
Como fazer isso com o Unolink
Montar tudo isso à mão significa uma ferramenta de análise, um construtor de funis, um feed de compras e uma planilha para juntar tudo. O SDK do Unolink (plano Pro ou superior, US$ 19 por mês) faz isso num só lugar. É uma biblioteca pequena para iOS, Android, React Native e Flutter, com um evento pronto para cada etapa acima, então você adiciona uma linha por momento e pula as discussões sobre nomes. A referência de eventos lista todos eles.
- Onboarding mostra o alcance de cada tela, quantos saíram ali, quantos pularam e quanto tempo levou. Os eventos de tela são gratuitos: não contam para a franquia mensal de eventos do seu plano. Veja Encontre a tela do onboarding em que as pessoas desistem.
- Funil conta as pessoas pela data de instalação e inclui os pagamentos tardios. As etapas contam a qualquer momento, com a opção “Contar etapas só nesta ordem”. Divida por link, UTM, plataforma, país, tela de onboarding ou posicionamento do paywall.
- Jornadas mostram cada instalação do clique à compra: o caminho, onde saiu do onboarding e quando pagou.
- Relatório aponta vazamentos, picos e quanto tempo as pessoas levam para pagar, com regras fixas sobre os seus próprios números, sem IA.
- Usuários novos e os que voltam são separados, para que reinstalações não pareçam cadastros novos.
- RevenueCat se conecta com uma linha, e então testes grátis, compras, renovações e reembolsos chegam sozinhos, sem nada contado duas vezes. Veja Atribuição no RevenueCat.
- Dispositivos de teste ficam de fora automaticamente.
Como o Unolink também sabe qual link trouxe cada instalação, o mesmo funil se divide por post, criador ou anúncio. É assim que você descobre que o criador com menos instalações trouxe, na verdade, mais usuários pagantes.
Compartilhe este artigo


