Taxa de retenção de apps móveis: como calcular e ler referências

A taxa de retenção de uma app móvel é a parte dos utilizadores de uma coorte de instalação que volta à app num determinado dia após a instalação. Pegue nos utilizadores da coorte que voltam segundo a regra escolhida, divida pela dimensão original da coorte e multiplique por 100. Leia-a como uma curva com três marcos, Dia 1, Dia 7 e Dia 30, e não como um selo único que se ganha ou se perde.

Imagine uma app de fitness que ganha 84 novos membros em janeiro. No fim da segunda semana, 39 ainda a abrem. Na quarta semana, 22. Na oitava semana, 11. Esta sequência diz muito mais sobre o negócio do que qualquer número isolado. A maioria das equipas de apps aprende isto da forma mais difícil: abrem o painel de retenção, veem um valor de Dia 30 com um só algarismo e passam um trimestre a discutir se é “bom”. A discussão não acerta no essencial.

O que significa a taxa de retenção de uma app móvel?

Duas apps podem ambas indicar uma taxa de retenção de 8% no Dia 30 e querer dizer coisas diferentes. Uma conta qualquer pessoa que tenha aberto a app pelo menos uma vez a partir do dia 30. A outra conta apenas quem a abriu no próprio dia 30. Uma mistura iOS e Android, novas instalações e utilizadores antigos. O mesmo título, medições diferentes.

A fórmula é simples: utilizadores da coorte que voltam segundo a sua regra ÷ dimensão original da coorte × 100. O difícil é chegar a acordo sobre os dados de entrada antes de os números aparecerem.

A coorte é o que mantém a métrica honesta. Funciona como um livro de presenças: 84 alunos inscrevem-se na primeira aula e acompanha quantos voltam à segunda, quem ainda frequenta ao fim de uma semana e quem continua na avaliação das quatro semanas. Nunca juntaria os novos alunos desta semana às presenças do mês passado para dizer que a turma está estável. A mesma lógica aplica-se aos subscritores; veja taxa de retenção de clientes.

Para onde vai a curva?

A retenção cai mais depressa no início, e esse padrão é normal. Os Mobile App Benchmarks of 2024 da OneSignal situam a retenção média em 28,29% no Dia 1, 17,86% no Dia 7 e 7,88% no Dia 30, com resultados publicados para 12 categorias de apps. Menos de um em cada três utilizadores voltou no dia a seguir à instalação. Menos de um em cada cinco passou a primeira semana. Ao fim de um mês, restava menos de um em cada doze.

A mesma referência mostra as apps de negócios ainda mais abaixo: 25,38% no Dia 1, 16,85% no Dia 7 e 6,94% no Dia 30. A categoria muda o nível; a forma descendente mantém-se familiar.

Cada marco responde a uma pergunta diferente:

• O Dia 1 reflete o onboarding: se o utilizador chegou ao primeiro valor, se o canal de aquisição correspondia bem ao produto e se alguma coisa falhou na primeira sessão.
• O Dia 7 mostra se a app conquistou um lugar na rotina de curto prazo de alguém.
• O Dia 30 é o sinal precoce mais próximo de um envolvimento duradouro e, nas apps de subscrição, de que o produto consegue manter uma relação paga.

Por isso a pergunta útil raramente é “qual é a minha taxa de retenção?”. É onde a curva estabiliza, e o que acontece aos utilizadores que ainda lá estão nesse ponto.

A mudança prática: leia a inclinação de cada troço e depois dê nome ao problema. Uma queda do Dia 1 para o Dia 7 aponta para uma fraca criação de hábito. Uma queda do Dia 7 para o Dia 30 aponta para um valor contínuo pouco profundo. Precisam de soluções diferentes.

Nas apps de subscrição, a queda entre a instalação e o primeiro mês explica também porque é que a retenção de envolvimento e a retenção na faturação têm de ser lidas em conjunto. Um utilizador pode continuar a abrir a app enquanto um pagamento falhado, um cartão a expirar ou um cancelamento silencioso põem fim à relação de receita.

Como calcular a sua própria taxa de retenção?

1. 01 Fixar a coorte Um período de instalação, tamanho fixado antes da consulta
2. 02 Definir o regresso Uma abertura ou uma ação-chave, escolhida antes de olhar
3. 03 Escolher a janela Dia exato, intervalo de dias ou qualquer altura depois
4. 04 Dividir e repetir Utilizadores que voltaram ÷ tamanho da coorte × 100, no dia 1, 7 e 30

Seis passos, cada um para evitar um erro específico.

1. Fixe a coorte de instalação. Escolha um grupo com um início comum, como todos os que instalaram na primeira semana de março, e bloqueie a sua dimensão antes de consultar o que quer que seja. Sem um denominador fixo, o número desvia-se à medida que chegam novos utilizadores.
2. Defina o evento de regresso antes de olhar para os dados. Abrir a app é a escolha habitual, mas para alguns produtos uma ação principal é melhor: registar um treino, enviar uma fatura, ligar uma conta bancária. Escolher a definição depois de ver os números é como as equipas acabam com uma métrica que só pode subir.
3. Escolha uma regra de janela. A retenção ao dia exato só conta um utilizador se ele abrir a app no próprio dia 7. Uma janela conta as aberturas em qualquer momento entre os dias 6 e 8. Uma regra de qualquer momento conta quem abriu pelo menos uma vez a partir do dia 7. Não dão o mesmo valor, por isso anote sempre qual usou.
4. Conte as correspondências em cada marco. Dia 1, Dia 7 e Dia 30, mesma coorte, mesma regra.
5. Divida pela dimensão original da coorte e multiplique por 100. Exemplo (números hipotéticos): 1000 instalações, 260 abrem no Dia 1, portanto 26%. No Dia 7 conta 130: 13%. No Dia 30 conta 45: 4,5%. Três números, uma coorte, uma história.
6. Compare com o período anterior da mesma coorte, não com uma média do setor. A comparação que reflete o seu trabalho é a sua própria curva a mexer-se, coorte após coorte.

Que dois erros estragam o número?

O primeiro é uma coorte com fugas. Se os utilizadores que instalaram em março, abril e maio caem todos no mesmo grupo, o denominador não para de crescer enquanto o numerador mistura versões do produto. A retenção parece estável quando está a piorar.

O segundo é um desencontro de ferramentas. Se o número de instalações vem de um fornecedor de atribuição e o número de sessões de um SDK de análise do produto, os dois podem discordar sobre a identidade do dispositivo, o fuso horário ou o que conta como sessão. Uma taxa de Dia 1 acima de 100% vem quase sempre daqui. Escolha uma única fonte de verdade para cada lado da fração e mantenha-a.

Acertar na coorte é a base de tudo o resto, e o mesmo trabalho de fundo de que precisa para a análise de retenção por coortes.

Porque divergem as referências de retenção?

A definição por trás de um valor de retenção pode mexer mais no resultado do que a qualidade da app. Um utilizador que tem de abrir a app exatamente no dia 7 enfrenta um teste mais exigente do que um que a pode abrir em qualquer momento entre o dia 6 e o dia 8, ou em qualquer momento depois do dia 7. O mesmo comportamento, três veredictos diferentes.

Dar nome aos métodos: a versão mais exigente é a retenção clássica, em que o utilizador tem de voltar nesse dia específico. A mais permissiva é a retenção contínua (rolling retention), em que conta qualquer regresso a partir do dia 7. Quando um número de retenção vem sem o método, pergunte antes de comparar.

Definição	Conta como retido quando	Efeito na taxa indicada
Dia exato	O utilizador abre a app no próprio dia 7	Valor mais baixo, teste mais exigente
Janela temporal	O utilizador abre-a em qualquer momento entre os dias 6 e 8	Mais alto, depende da largura da janela
Qualquer momento depois	O utilizador abre-a pelo menos uma vez a partir do dia 7	O mais alto, esconde o abandono

A retenção contínua é a mais lisonjeira e a menos informativa: um utilizador que voltou uma vez no primeiro mês e nunca mais continua a contar como retido.

A definição não é a única variável. O guia da Adjust sobre referências de retenção divide os resultados por região, e a categoria alarga ainda mais a dispersão, porque as apps construídas à volta de hábitos diários tendem a manter os utilizadores mais tempo do que as ferramentas abertas só quando são precisas.

O que deve verificar antes de comparar com uma referência?

• Definição: clássica, janela ou contínua.
• Largura da janela: dia exato ou um intervalo de dias.
• Mistura de plataformas: iOS e Android indicados em separado ou em conjunto.
• Geografia: que mercados o conjunto de dados abrange.
• Canal de aquisição: pago, orgânico e por recomendação misturados ou separados.
• Categoria: a sua subcategoria, não a média de todas as apps.

Se algum destes pontos diferir, os dois números não são diretamente comparáveis, e uma diferença entre eles não lhe diz nada sobre a sua app.

Os negócios de subscrição precisam também de uma segunda distinção: a retenção comportamental de um lado, e do outro a retenção paga, as renovações, o churn involuntário e a reativação. Um utilizador pode deixar de abrir a sua app e continuar a ser cobrado todos os meses; outro pode continuar a abri-la todos os dias depois de uma falha de pagamento. Para o lado do churn, veja referências de taxa de churn.

Quais são as referências típicas de Dia 1, Dia 7 e Dia 30?

A forma é a mesma em todos os conjuntos de dados: uma queda acentuada na primeira semana, um declínio mais lento depois disso. Os valores diferem consoante a fonte.

Referência	Dia 1	Dia 7	Dia 30
OneSignal 2024, todas as categorias publicadas	28,29%	17,86%	7,88%
OneSignal 2024, apps de negócios	25,38%	16,85%	6,94%
Mediana global Adjust 2024, citada pela RapidNative	26%	13%	7%

Os valores da Adjust vêm do playbook de retenção de apps móveis da RapidNative, que os descreve como “a referência global de 2024 da Adjust” de retenção mediana. A OneSignal indica médias; a Adjust, tal como citada, indica medianas. Só isso basta para que as duas linhas difiram, e é essa a lição: citar “a média do setor” sem nomear a fonte e o método é como dar uma temperatura sem dizer em que cidade foi medida.

Faça corresponder a linha à sua situação. Uma equipa que lança uma ferramenta B2B deve ler a linha das apps de negócios da OneSignal (6,94% no Dia 30) e não a linha de todas as categorias (7,88%). A diferença é pequena aqui, mas o hábito protege-o de perseguir uma média construída a partir de apps que não se parecem nada com a sua. Depois verifique se a fonte usou a mesma regra de janela que você.

Mais um limite: todas as linhas acima contam um utilizador como retido quando ele volta a abrir a app. Nenhuma diz se esse utilizador ainda está a pagar.

Em que difere a retenção de envolvimento da retenção de subscrição?

1. 01 Retenção de utilização Utilizadores de uma coorte de instalação que voltam a abrir a app. Fonte: analítica de produto.
2. 02 Retenção da subscrição Utilizadores que ainda pagam: renovações, pagamentos falhados, cancelamentos, reconquistas. Fonte: faturação, App Store ou Google Play.

Pense numa app de subscrição com uma utilização estável: as aberturas semanais mantêm-se em 40% da base, mês após mês. Depois a receita recorrente mensal começa a descer, e ninguém consegue explicar porquê, porque o envolvimento parece estar bem.

A explicação está normalmente no sistema de faturação, não no produto. Um cartão expira. Uma renovação é recusada. Um subscritor toca em cancelar e nunca lhe diz nada. As métricas de utilização não veem nada disto.

As referências públicas de apps contam um utilizador como retido quando ele volta à app. A economia das subscrições depende da conversão dos testes, do momento das renovações, da duração dos planos, das falhas de pagamento, dos cancelamentos e das reconquistas. O resumo da Deck do State of Subscription Apps 2025 da RevenueCat é um sítio onde ver como o churn e a retenção variam com a duração e o preço do plano. Uma app pode ter uma retenção de utilização modesta e gerar receita duradoura, ou uma utilização forte e perder subscritores em cada data de faturação.

Na App Store e no Google Play, as renovações falhadas passam pelos próprios períodos de novas tentativas e de tolerância das lojas; veja novas tentativas de faturação e período de tolerância da App Store e período de tolerância e suspensão de conta do Google Play.

Como combinar coortes de comportamento e de faturação?

Junte os sinais de envolvimento aos estados de faturação. Seis coortes cobrem a maioria dos casos:

Coorte	Sinal de envolvimento	Sinal de faturação	Ação provável
Ativo mas sem pagar	Abre todas as semanas	Pagamento falhado	Pedido de atualização do pagamento e novas tentativas programadas
Paga mas inativo	Sem aberturas há 14 dias	Renovação a aproximar-se	Lembrete do valor antes da renovação
Teste perto da conversão	Abre todos os dias	O teste termina dentro de 3 dias	Pedido de conversão com um benefício claro
Renovação falhada	Continua a abrir a app	Cartão recusado	Novas tentativas de recuperação e um link de atualização
Cancelou recentemente	Deixa de abrir	Cancelado	Mensagens de reconquista aos 30, 60 e 90 dias
Cliente antigo, pouca utilização	Abre uma vez por mês	Preço completo, plano anual	Contacto sobre a utilização antes da data de renovação

A atividade de Dia 1, Dia 7 e Dia 30, por si só, não distingue um envolvimento fraco de uma sensibilidade ao preço, de um cartão a expirar ou de um cancelamento deliberado. Cada um precisa de uma resposta diferente, e enviar um desconto a alguém cujo cartão simplesmente expirou desperdiça margem.

Um cartão retirado antes da renovação é um dos sinais de alerta mais claros. O NoChurn dá a cada novo cliente um score de churn de 0 a 100 no registo, com base no método de pagamento, na origem do registo e nos dados próprios que envia, e sobe-o quando um cartão é retirado antes da data de renovação, para que possa agir antes de o pagamento falhar.

Uma precaução sobre amostras pequenas: com uma base de clientes modesta, as comparações de atributos são observações sobre amostras pequenas. Trate um padrão de 40 clientes como uma hipótese a testar, não como uma prova.

Pode enviar os seus próprios atributos, como a data de registo, a origem do registo, os lugares, a utilização, o progresso no onboarding ou o NPS, numa única chamada à API, e comparar os clientes que saíram com os que ficaram para ver que atributos acompanham o churn (dados próprios e IA). A visão de receita do mesmo problema é a retenção líquida de receita: se a base pagante cresce ou encolhe depois de upgrades, downgrades e cancelamentos.

Como definir a sua própria referência?

As referências dizem-lhe se está mais ou menos dentro do normal. Só a sua própria tendência, coorte após coorte, lhe diz se está a melhorar.

1. Construa a referência a partir das suas três últimas coortes de instalação. Meça o Dia 1, o Dia 7 e o Dia 30 de cada uma, separados por plataforma e canal de aquisição, com a regra de janela que escolheu. Um Dia 1 estável de 20% diz-lhe menos do que um de 24% que desceu para 17% em duas coortes.
2. Compare com a linha de referência mais próxima, não com a média global. Se a maioria dos seus utilizadores está no Android numa categoria de nicho, o valor misturado é o espelho errado.
3. Acrescente uma camada de faturação se vende subscrições. Para cada coorte, conte os utilizadores do Dia 30 que ainda pagam, os que estão em estado de pagamento falhado ou cancelado e os que voltaram através da reconquista.
4. Dê à revisão um ritmo e uma nota de rodapé. As revisões mensais de coortes funcionam. Ao lado de cada valor, escreva a definição, a plataforma, o canal e o intervalo de datas, para que a comparação se mantenha honesta quando alguém a ler daqui a seis meses.
5. Teste uma alteração por coorte. Mensagens de reconquista aos 30, 60 e 90 dias após o cancelamento são um teste limpo de uma única variável. Uma alteração por janela de coorte, ou não saberá o que mexeu no número.

Antes da próxima revisão, responda a uma pergunta: que coorte está a perder mais valor, e qual é a primeira alteração que vai testar nela?

Como o NoChurn ajuda

Se a sua curva de retenção parece estar bem enquanto a receita se desvia, a diferença está normalmente na faturação e não no comportamento, e é nessa camada que o NoChurn trabalha. Liga-se ao Stripe com um clique e funciona com o Chargebee, o Recurly, o Paddle, a App Store, o Google Play e outros, ou com qualquer faturação pela API. Na faturação web, recupera pagamentos falhados com novas tentativas inteligentes e emails escritos pela IA, gere um fluxo de cancelamento com ofertas adaptadas ao motivo e o cancelamento com um clique sempre visível, e envia mensagens de reconquista aos 30, 60 e 90 dias com base no motivo do cancelamento. Na App Store e no Google Play, as novas tentativas de faturação e o botão de cancelamento ficam com a Apple e a Google; o NoChurn lê os eventos de subscrição e trata do score e da reconquista. O preço depende apenas do MRR, grátis até 300 $ de MRR e sem comissão (um domínio de envio próprio exige um plano pago, desde 9 $).