SaaS / Product: churn, retention and MRR
The standard for tracking subscription health: a model for churn, cohort retention and MRR, with the most common pitfalls.
- View typical SaaS sources
- Understand churn, retention and MRR modeling
- Have an end-to-end implementation checklist
Every SaaS lives or dies by the health of its subscription base. While marketing counts how many customers come in, what decides the The future of the business is what happens afterwards: how many stay, how much they pay per month and for how long. This playbook shows the standard that Nekt uses to transform billing, subscription and product data into reliable metrics churn, cohort retention and MRR, without the errors that inflate or distort these numbers.
1. Context: what a SaaS needs to measure
A handful of metrics guide virtually every decision in a SaaS. They answer different questions, but are based on the same basis of Well modeled data.
- MRR (monthly recurring revenue): how much revenue predictable basis generates per month. It is the metric that the board looks at first, and the basis for calculating almost all others.
- Churn: the proportion of customers (or revenue) that the base loses in one period. It's the bucket leaking. A high churn nullifies any acquisition effort.
- Retention by cohort: of each group that entered a same period, how many are still active months later. Shows whether the product is improving or worsening over time, something that general average hides.
- LTV (customer time value): as a customer generates, on average, throughout the relationship. It directly depends on the churn: the longer the customer stays, the higher the LTV.
- Expansion and contraction: revenue that grows (upgrade, more seats) or downgrade within the existing base. In Mature SaaS, expansion can offset churn and sustain growth.
These metrics guide the business because each one points to a different lever: MRR measures size, churn measures leakage, Cohort retention measures trend, and LTV connects it all to acquisition economics. The problem is that, without a modeled base, each The team calculates in their own way and no one trusts the number. It's exactly This is the work that modeling at Nekt solves.
2. Typical SaaS sources
Most SaaS have data spread across the billing, application banking and CRM. Each source delivers a piece of puzzle, and the value appears when they come together in a layer modeled.
- Payment/billing gateway (e.g. Stripe, Iugu). The source of truth about money: plans, amounts, charges paid, payment failures, refunds. This is where MRR comes from and the fact that payments.
-
Bank of application subscriptions and payments (tables
subscriptionsandpayments). The status of signatures in your own system: who signed what, when it started, when it canceled, current status. It often has product details that the gateway does not have. - CRM (e.g. HubSpot). The commercial context: how customer entered, acquisition channel, segment, account owner, reason declared cancellation. Enrich churn with “why”.
- Product/usage events. Logins, features used, access frequency. They are the antecedent sign of churn: a customer What you stopped using today is next month's churn. Feed alerts and health scores.
Gateway and application bank often have overlapping information about subscriptions. Define from the beginning what the source of truth for each field: normally the gateway controls amounts and charges paid, and the application bank send plan and product status. Documenting this avoids conflicts in modeling.
3. Modeling recommended at Gold
The objective is to reach a few tables in the layer Gold, each with a clear granularity and a question it answers. The raw sources billing and subscriptions enter the Bronze, cleaning and standardization takes place in Silver, and the business model final (the four tables we describe below) lives in the Gold. Four tables cover the most cases.
- Gateway charges and plans
- Application subscription and payment tables
- As it came, unedited
- Values and dates still as text
- Typed values, truth dates
- One table per entity
- Only charges confirmed in fact
- Source of truth defined by field
- Subscriptions, payments fact
- Monthly MRR with cutoff date
- Cohort retention
- This is where dashboard and MCP read from
Signatures (one line per signature)
The backbone of the model. Each line is a signature, with the customer, the plan, current status, and start and end dates cancellation. This is where churn and retention come from, because this table who knows who was active at each moment.
Payment fact (one line per charge paid)
Each line is a charge actually paid: customer, subscription, date and value. Filtered for confirmed payments, it is the basis for revenue carried out and to separate those who paid from those who just created a subscription and never paid (which matters a lot in churn, as we will see).
Monthly MRR (one line per customer per month)
The recurring revenue time series. Each line is a customer in a month, with the MRR recognized in that month. Allows you to add the total MRR of the business, look at the evolution month by month and derive expansion, contraction and revenue churn comparing consecutive months.
Cohort retention (grouped retention)
The table showing the trend. Group customers by month entry (the cohort) and, for each following month, calculates how many remain active. Can be cut by dimensions such as plan or coupon, to compare the quality of each gateway. When you draws this table on the screen, it becomes the classic retention heatmap: each row is a cohort, each column is a month since entry, and the color It instantly shows where the base holds and where it leaks.
| Entry cohort | M0 | M1 | M2 | M3 |
|---|---|---|---|---|
| Jan 2026 | 100% | 82% | 71% | 64% |
| Feb 2026 | 100% | 79% | 68% | 59% |
| Mar 2026 | 100% | 85% | 74% | 66% |
One line per customer per month, with recognized MRR and type of movement in relation to the previous month:
| month | client_id | plan | mrr | movement |
|---|---|---|---|---|
| 2026-01 | c_1042 | Pro | R$ 299 | new |
| 2026-02 | c_1042 | Pro | R$ 299 | maintained |
| 2026-03 | c_1042 | Business | R$599 | expansion |
| 2026-01 | c_1088 | Starter | R$ 99 | new |
| 2026-02 | c_1088 | Starter | R$0 | churn |
Adding the column mrr per month, you have the total MRR.
Comparing the movimento between months, you separate
new growth, expansion, contraction and revenue churn, all
from a single table.
Keep each table with a single granularity. The temptation is to create a "table" that answers everything, but it becomes difficult to maintain and to explain to the AI. One line per subscription, one per charge, one per customer/month: clean granularities make consumption and Semantic Layer become simple.
4. Traps
Two pitfalls appear in almost every SaaS metrics project. They don't break the pipeline, what's worse: they deliver numbers plausible but wrong. It's worth knowing both before modeling.
Churn must count only subscriptions that have had at least one payment. Trial cancellations that never paid are NOT churn: these people were never paying customers, so losing them is not losing revenue. If you count every cancellation as churn, the number inflates, often dramatically, and begins to measure the quality trial rather than customer retention. This is the most common error in SaaS metrics. The rule of thumb: only enter the churn denominator who appears in the fact of payments with at least one charge paid.
MRR needs a set cutoff date, or that is, from when you reliably recognize revenue. Old systems often have testing charges, poor migrations imported and inconsistent values in the first months of operation. If you add up everything since the beginning of time, this dirty history it distorts the series and no one trusts the graph. Choose a date to from which the data is complete (for example, when billing current one went into production) and recognize the MRR only from then on. Make the cutoff date explicit in the modeling and documented in the Layer Semantics.
5. Use case: cohort dashboard + AI agent
With the four tables in Gold, two consumptions appear almost free on the same model.
A cohort retention dashboard read directly from retention table: the classic triangle chart, with each cohort in a line and retention decreasing over the months. Cutting by plan or coupon, the team immediately sees which gateway brings customers who stay and which brings people who evaporate in the second month.
An AI agent, via MCP, answers questions in natural language on the same tables: "which cohort retains better", "which plan has the most churn", "how much MRR came from expansion in the last quarter". Instead of waiting for an analyst to put together the query, whoever needs the answer asks and receives the number instantly.
What makes the agent trustworthy is the
Semantic Layer describing these tables: what is
each column, that churn only counts those who paid, that the MRR starts on the date
cutoff value, which means each cutoff value movimento. Without
this description, the AI guesses and gets it wrong. With it, the AI responds with
same rules that the dashboard uses, and the two match. A modeling,
two consumptions that never contradict each other.
A gym management SaaS charged gyms a monthly fee customers via gateway, and had the signatures mirrored in the bank of the application. The reported churn seemed very high until we realized that he told every gym that created an account and disappeared in the test, without ever paying. When redoing the modeling counting churn only about who had at least one payment, and recognizing MRR from the date the current billing went live, the number became a metric the team finally trusted. On top of the same layer Gold, plugged in a dashboard cohort per plan and an agent who answers retention questions in the day to day.
6. Implementation checklist
The end-to-end path, in the order that usually makes sense. Each step is based on the previous one, so it's worth following it from top to bottom.