SaaS / Produto: churn, retenção e MRR
O padrão para acompanhar a saúde de assinaturas: um modelo para churn, retenção por cohort e MRR, com as armadilhas mais comuns.
- Ver as fontes típicas de um SaaS
- Entender a modelagem de churn, retenção e MRR
- Ter um checklist de implementação end-to-end
Todo SaaS vive ou morre pela saúde da sua base de assinaturas. Enquanto o marketing conta quantos clientes entram, o que decide o futuro do negócio é o que acontece depois: quantos ficam, quanto pagam por mês e por quanto tempo. Este playbook mostra o padrão que a Nekt usa para transformar dados de billing, assinaturas e produto em métricas confiáveis de churn, retenção por cohort e MRR, sem os erros que inflam ou distorcem esses números.
1. Contexto: o que um SaaS precisa medir
Um punhado de métricas guia praticamente toda decisão em um SaaS. Elas respondem perguntas diferentes, mas se sustentam sobre a mesma base de dados bem modelada.
- MRR (receita recorrente mensal): quanto de receita previsível a base gera por mês. É a métrica que o board olha primeiro, e a base para calcular quase todas as outras.
- Churn: a proporção de clientes (ou de receita) que a base perde num período. É o vazamento do balde. Um churn alto anula qualquer esforço de aquisição.
- Retenção por cohort: de cada grupo que entrou num mesmo período, quantos continuam ativos meses depois. Mostra se o produto está melhorando ou piorando ao longo do tempo, algo que a média geral esconde.
- LTV (valor do cliente no tempo): quanto um cliente gera, em média, durante toda a relação. Depende diretamente do churn: quanto mais tempo o cliente fica, maior o LTV.
- Expansão e contração: receita que cresce (upgrade, mais assentos) ou encolhe (downgrade) dentro da base existente. Em SaaS maduro, expansão pode compensar churn e sustentar o crescimento.
Essas métricas guiam o negócio porque cada uma aponta para uma alavanca diferente: o MRR mede o tamanho, o churn mede o vazamento, a retenção por cohort mede a tendência, e o LTV conecta tudo isso à economia de aquisição. O problema é que, sem uma base modelada, cada time calcula do seu jeito e ninguém confia no número. É exatamente esse trabalho que a modelagem na Nekt resolve.
2. Fontes típicas de um SaaS
A maioria dos SaaS tem os dados espalhados entre o sistema de cobrança, o banco da aplicação e o CRM. Cada fonte entrega uma peça do quebra-cabeça, e o valor aparece quando elas se juntam numa camada modelada.
- Gateway de pagamento / billing (ex: Stripe, Iugu). A fonte da verdade sobre dinheiro: planos, valores, cobranças pagas, falhas de pagamento, reembolsos. É de onde vem o MRR e o fato de pagamentos.
-
Banco de assinaturas e pagamentos da aplicação (tabelas
subscriptionsepayments). O estado das assinaturas no seu próprio sistema: quem assinou o quê, quando começou, quando cancelou, status atual. Muitas vezes tem detalhes de produto que o gateway não tem. - CRM (ex: HubSpot). O contexto comercial: como o cliente entrou, canal de aquisição, segmento, dono da conta, motivo declarado de cancelamento. Enriquece o churn com o "porquê".
- Eventos de produto / uso. Logins, features usadas, frequência de acesso. São o sinal antecedente de churn: um cliente que parou de usar hoje é o churn do mês que vem. Alimentam alertas e health scores.
Gateway e banco da aplicação costumam ter informação sobreposta sobre assinaturas. Defina desde o começo qual é a fonte da verdade para cada campo: normalmente o gateway manda em valores e cobranças pagas, e o banco da aplicação manda em plano e status do produto. Documentar isso evita conflitos na modelagem.
3. Modelagem recomendada na Gold
O objetivo é chegar a poucas tabelas na camada Gold, cada uma com uma granularidade clara e uma pergunta que ela responde. As fontes cruas de billing e assinaturas entram na Bronze, a limpeza e a padronização acontecem na Silver, e o modelo de negócio final (as quatro tabelas que descrevemos a seguir) vive na Gold. Quatro tabelas cobrem a maioria dos casos.
- Cobranças e planos do gateway
- Tabelas de assinaturas e pagamentos da aplicação
- Como veio, sem edição
- Valores e datas ainda como texto
- Valores tipados, datas de verdade
- Uma tabela por entidade
- Só cobranças confirmadas no fato
- Fonte da verdade definida por campo
- Assinaturas, fato de pagamentos
- MRR mensal com data de corte
- Retenção por cohort
- É daqui que dashboard e MCP leem
Assinaturas (uma linha por assinatura)
A espinha dorsal do modelo. Cada linha é uma assinatura, com o cliente, o plano, o status atual e as datas de início e de cancelamento. É daqui que saem churn e retenção, porque é esta tabela que sabe quem estava ativo em cada momento.
Fato de pagamentos (uma linha por cobrança paga)
Cada linha é uma cobrança efetivamente paga: cliente, assinatura, data e valor. Filtrada para pagamentos confirmados, é a base para receita realizada e para separar quem pagou de quem só criou uma assinatura e nunca pagou (o que importa muito no churn, como veremos).
MRR mensal (uma linha por cliente por mês)
A série temporal de receita recorrente. Cada linha é um cliente num mês, com o MRR reconhecido naquele mês. Permite somar o MRR total do negócio, olhar a evolução mês a mês e derivar expansão, contração e churn de receita comparando meses consecutivos.
Retenção por cohort (retenção agrupada)
A tabela que mostra a tendência. Agrupa os clientes pelo mês de entrada (o cohort) e, para cada mês seguinte, calcula quantos continuam ativos. Pode ser cortada por dimensões como plano ou cupom, para comparar a qualidade de cada porta de entrada. Quando você desenha essa tabela na tela, ela vira o clássico heatmap de retenção: cada linha é um cohort, cada coluna é um mês desde a entrada, e a cor mostra na hora onde a base segura e onde ela vaza.
| Cohort de entrada | M0 | M1 | M2 | M3 |
|---|---|---|---|---|
| Jan 2026 | 100% | 82% | 71% | 64% |
| Fev 2026 | 100% | 79% | 68% | 59% |
| Mar 2026 | 100% | 85% | 74% | 66% |
Uma linha por cliente por mês, com o MRR reconhecido e o tipo de movimento em relação ao mês anterior:
| mes | cliente_id | plano | mrr | movimento |
|---|---|---|---|---|
| 2026-01 | c_1042 | Pro | R$ 299 | novo |
| 2026-02 | c_1042 | Pro | R$ 299 | mantido |
| 2026-03 | c_1042 | Business | R$ 599 | expansão |
| 2026-01 | c_1088 | Starter | R$ 99 | novo |
| 2026-02 | c_1088 | Starter | R$ 0 | churn |
Somando a coluna mrr por mês, você tem o MRR total.
Comparando o movimento entre meses, você separa
crescimento novo, expansão, contração e churn de receita, tudo a
partir de uma única tabela.
Mantenha cada tabela com uma granularidade só. A tentação é criar uma "tabelona" que responde tudo, mas ela vira difícil de manter e de explicar para a IA. Uma linha por assinatura, uma por cobrança, uma por cliente/mês: granularidades limpas fazem o consumo e a Camada Semântica ficarem simples.
4. Armadilhas
Duas armadilhas aparecem em quase todo projeto de métricas de SaaS. Elas não quebram o pipeline, o que é pior: entregam números plausíveis, mas errados. Vale conhecer as duas antes de modelar.
Churn deve contar apenas assinaturas que tiveram ao menos um pagamento. Cancelamentos de trials que nunca pagaram NÃO são churn: essas pessoas nunca foram clientes pagantes, então perdê-las não é perder receita. Se você contar todo cancelamento como churn, o número infla, muitas vezes de forma dramática, e passa a medir a qualidade do trial em vez da retenção de clientes. Este é o erro mais comum em métricas de SaaS. A regra prática: só entra no denominador do churn quem aparece no fato de pagamentos com pelo menos uma cobrança paga.
O MRR precisa de uma data de corte definida, ou seja, a partir de quando você reconhece receita de forma confiável. Sistemas antigos costumam ter cobranças de teste, migrações mal importadas e valores inconsistentes nos primeiros meses de operação. Se você somar tudo desde o começo dos tempos, esse histórico sujo distorce a série e ninguém confia no gráfico. Escolha uma data a partir da qual os dados são íntegros (por exemplo, quando o billing atual entrou em produção) e reconheça o MRR só de lá para frente. Deixe a data de corte explícita na modelagem e documentada na Camada Semântica.
5. Use case: dashboard de cohort + agente de IA
Com as quatro tabelas na Gold, dois consumos aparecem quase de graça em cima do mesmo modelo.
Um dashboard de retenção por cohort lê direto da tabela de retenção: o clássico gráfico de triângulo, com cada cohort numa linha e a retenção decaindo ao longo dos meses. Cortando por plano ou cupom, o time enxerga na hora qual porta de entrada traz clientes que ficam e qual traz gente que evapora no segundo mês.
Um agente de IA, via MCP, responde perguntas em linguagem natural sobre as mesmas tabelas: "qual cohort retém melhor", "qual plano tem mais churn", "quanto de MRR veio de expansão no último trimestre". Em vez de esperar um analista montar a query, quem precisa da resposta pergunta e recebe o número na hora.
O que faz o agente ser confiável é a
Camada Semântica descrevendo essas tabelas: o que é
cada coluna, que o churn só conta quem pagou, que o MRR começa na data
de corte, o que significa cada valor de movimento. Sem
essa descrição, a IA adivinha e erra. Com ela, a IA responde com as
mesmas regras que o dashboard usa, e os dois batem. Uma modelagem,
dois consumos que nunca se contradizem.
Um SaaS de gestão de academias cobrava mensalidade das academias clientes via gateway, e tinha as assinaturas espelhadas no banco da aplicação. O churn reportado parecia altíssimo até percebermos que ele contava toda academia que criava conta e sumia no teste, sem nunca pagar. Ao refazer a modelagem contando churn só sobre quem tinha ao menos um pagamento, e reconhecendo MRR a partir da data em que o billing atual entrou no ar, o número virou uma métrica em que o time finalmente confiava. Em cima da mesma camada Gold, plugaram um dashboard de cohort por plano e um agente que responde perguntas de retenção no dia a dia.
6. Checklist de implementação
O caminho end-to-end, na ordem em que costuma fazer sentido. Cada passo se apoia no anterior, então vale seguir de cima para baixo.