Como medir o churn no Chargebee

O churn parece um único número, mas no Chargebee está espalhado por vários estados, eventos e definições. Uma subscrição pode estar agendada para cancelar e continuar ativa. Pode estar em pausa e não pagar nada. Pode ser cancelada por falta de pagamento e não por escolha. A menos que decida à partida como conta cada caso, duas pessoas da sua equipa vão calcular duas taxas de churn diferentes a partir dos mesmos dados.

Este guia mostra como construir uma medição clara do churn a partir do Chargebee Billing: que estados e eventos usar, como separar o churn voluntário do involuntário e como tratar as pausas e as reativações. Baseia-se na documentação do Chargebee: Subscription Cancellation, a API Cancel a subscription, os tipos de eventos, as APIs List events e List subscriptions, Reason Codes e Pause Subscription (todos consultados em novembro de 2026).

Comece pelos relatórios do Chargebee

O Chargebee tem relatórios integrados, incluindo um relatório padrão de Subscriptions. Use-o primeiro, e leia nessa página como cada valor é definido antes de o comparar com outra coisa. Este guia centra-se em construir a sua própria medição a partir dos dados do Chargebee, de que precisa quando quer o churn cruzado com a utilização do produto, a origem da inscrição ou os motivos de cancelamento no seu próprio data warehouse.

Os estados que contam

Estado no Chargebee	Perdido?	Porquê
`in_trial`	Ainda não é um cliente pagante	Meça a conversão dos testes à parte
`active`	Não	A pagar
`non_renewing`	Ainda não	Cancelamento agendado para o fim do período; ainda ativa
`paused`	Não, mas não paga	Acompanhe à parte
`cancelled`	Sim	Terminada

A linha non_renewing é a que as equipas erram. Segundo a API Cancel a subscription, um cancelamento no fim do período passa a subscrição para non_renewing e define os ciclos de faturação restantes como 0. Ainda pode ser salva com “Remove scheduled cancellation”. Conte-a como churn na data em que passa a cancelled, não no dia em que o cliente clicou.

Os eventos que contam

Os tipos de eventos do Chargebee dão-lhe um registo com data e hora de cada transição:

Evento	Use-o para
`subscription_created`	Novas subscrições
`subscription_cancellation_scheduled`	Cancelamentos agendados (indicador antecipado)
`subscription_cancellation_reminder`	Enviado 6 dias antes de um cancelamento agendado
`subscription_cancelled`	Churn, na sua data efetiva
`subscription_reactivated`	Clientes que voltaram depois de cancelar
`subscription_paused`, `subscription_resumed`	Períodos de pausa
`subscription_pause_scheduled`	Pausas agendadas para mais tarde

Pode recebê-los como webhooks, ou ir buscar o histórico através da API List events. Para uma primeira análise, ir buscar os eventos dos últimos doze meses é muitas vezes a forma mais rápida de obter uma referência.

Uma nota sobre a grafia: a referência de eventos do Chargebee usa subscription_cancelled com dois L, enquanto algumas das suas outras páginas escrevem “canceled”. Use exatamente a string que vê nos seus próprios payloads.

Churn voluntário vs involuntário

Pedem soluções diferentes, por isso separe-os desde o primeiro dia.

Involuntário: a referência de tipos de eventos diz que subscription_cancelled traz um cancel_reason quando o cancelamento foi causado por falta de pagamento ou por falta de cartão. Essas são as suas perdas por pagamento falhado.
Voluntário: cancelamentos sem esse motivo de sistema, normalmente com um cancel_reason_code dos seus Reason Codes configurados.

Torne os códigos de motivo obrigatórios para cancelamentos a partir da app e do portal. Segundo a documentação do Chargebee, quando os códigos de motivo são obrigatórios, a API de cancelamento também tem de receber um cancel_reason_code. Assim, cada cancelamento voluntário tem um motivo, e pode reportar o churn por motivo sem adivinhar.

Um ponto prático da documentação de cancelamento: o cancel_reason_code pode não estar incluído quando obtém uma subscrição non-renewing, a menos que ative a definição correspondente ao nível do site. Ative-a, ou recolha o motivo a partir do evento subscription_cancellation_scheduled.

Pausas

A página Pause Subscription do Chargebee diz que as renovações param enquanto uma subscrição está em pausa. Um cliente em pausa não está a pagar e não saiu.

Escolha uma regra e mantenha-a:

Exclua as subscrições em pausa tanto da base inicial como do churn, e reporte o número de pausas ao lado da taxa de churn. É a escolha mais comum.
Se uma pausa terminar num cancelamento, conte o churn na data do cancelamento, como qualquer outro.

Seja qual for a escolha, não deixe que as pausas baixem silenciosamente a sua taxa de churn. Uma oferta de pausa que só adia o cancelamento deve acabar por aparecer como churn.

Reativações

Um cliente que cancela e mais tarde reativa (subscription_reactivated) continua a ser churn no mês em que saiu. Conte a reativação à parte, como clientes recuperados ou reativados, em vez de a subtrair ao churn passado. Reescrever meses passados torna as tendências impossíveis de ler.

Um cálculo mensal do churn

Com os estados e eventos acima, uma taxa de churn de clientes para um mês:

Base inicial: subscrições active ou non_renewing às 00:00 do primeiro dia do mês (exclua in_trial, e paused se for essa a sua regra). A API List subscriptions dá-lhe o estado atual; para uma data passada, reconstrua o estado a partir dos eventos.
Perdidas: subscrições dessa base com um evento subscription_cancelled durante o mês.
Taxa de churn de clientes: perdidas a dividir pela base inicial.
Divisão: o mesmo rácio para o involuntário (cancel_reason de sistema) e o voluntário (com cancel_reason_code), que somados dão o total.

As novas subscrições criadas durante o mês não estão na base inicial, por isso os seus cancelamentos dentro do mês são reportados à parte ou deixados de fora. Escreva qual das opções.

Para o churn de receita, substitua as contagens pelo valor recorrente mensal de cada subscrição no início do mês (planos anuais divididos por 12). Reporte a contração por downgrades separadamente dos cancelamentos.

Indicadores antecipados

O churn é um número com atraso. Estes mexem-se mais cedo:

Cancelamentos agendados (subscription_cancellation_scheduled) este mês, sobretudo em planos anuais.
Retenções de non-renewing: subscrições que saem de non_renewing sem serem canceladas.
Renovações falhadas que ainda não foram recuperadas.
Pausas iniciadas, e a proporção de pausas que terminam em cancelamento.

Erros comuns

Contar o churn no clique. A data de cancelamento é quando a subscrição passa a cancelled, não quando passou a non_renewing.
Misturar testes na base. Os testes que não convertem são um problema de conversão, não churn.
Um único número agregado. Sem a divisão entre voluntário e involuntário, não consegue saber se deve corrigir a sua recuperação de pagamentos ou o seu produto.
Pausas silenciosas. Excluir as subscrições em pausa sem as reportar esconde um grupo crescente de clientes que não estão a pagar.

Mantenha as definições estáveis

Escreva as suas definições: o que conta como base, quando é datado o churn, como são tratadas as pausas, os testes, as reativações e os períodos contratuais. Mude-as raramente e, quando o fizer, recalcule o histórico. Uma taxa de churn é sobretudo útil comparada consigo mesma.

Fazer isto com o NoChurn

As subscrições, os cancelamentos e os relatórios do próprio Chargebee ficam no Chargebee. O NoChurn lê os seus eventos do Chargebee, separa o churn voluntário do involuntário, regista o motivo a partir do seu fluxo de cancelamento (onde cancelar está sempre a um clique) e dá a cada cliente um score de churn de 0 a 100. Pode enviar os seus próprios dados de produto por API para ver que atributos estão correlacionados com o churn e, se ligar um helpdesk, as conversas de suporte são lidas para o score e os insights. Veja NoChurn + Chargebee.