Customer Success Metrics Reveal Hidden Churn
A customer success dashboard can look healthy just before a difficult renewal meeting. Net revenue retention is above 100%, product activity is rising, and most accounts carry a green health score. Then a customer explains that its team still cannot complete the job it bought the product to do. The dashboard has recorded a growing subscription and frequent use, but neither answers the customer’s question: is this product worth keeping?

That gap is why customer success metrics need to be read together. Revenue retention describes what happened to the starting customer base. Product activity shows what people did inside the product. A customer outcome describes what that work accomplished. Relationship signals add what the people paying for and using the product are saying. Each answers a different question, and each can mislead when asked to stand in for the others. The useful starting point is a small set of measures tied to a specific decision: where revenue is leaking, which accounts need a conversation, and whether customers are reaching the result they expected.
Fix the starting group before calculating retention
Gross revenue retention, or GRR, asks how much recurring revenue remained from customers present at the beginning of a period, before any expansion. Net revenue retention, or NRR, adds expansion from those same customers. Both calculations exclude customers acquired during the period. ChartMogul’s definitions and formulas make that starting group central: without it, a growing new-business line can be mistaken for successful retention.
Choose the period and revenue unit before reading either rate. Monthly recurring revenue at the start of a year should be compared with monthly recurring revenue from those same accounts at the end of that year. If one report includes one-time services and another includes only subscriptions, their rates do not answer the same question. Record how cancellations, downgrades, upgrades, and any pricing changes enter the calculation. The choice matters less than applying it consistently and making it visible to the people using the number.
Consider an illustrative starting group of 100 customers paying a total of $100,000 in monthly recurring revenue. Over the next year, ten customers cancel, removing $8,000 of monthly revenue. Continuing customers reduce subscriptions by another $4,000 and expand them by $15,000. No new customer enters these calculations. GRR is ($100,000 − $8,000 − $4,000) ÷ $100,000, or 88%. NRR is ($100,000 − $8,000 − $4,000 + $15,000) ÷ $100,000, or 103%. The cohort ends at $103,000 in monthly recurring revenue, yet it has lost customers and $12,000 of its original revenue before expansion.
The two percentages are both correct. They call for different decisions. The 103% NRR says expansion more than replaced revenue lost from the starting group. The 88% GRR says a meaningful portion of that group’s original spend disappeared. A team celebrating NRR alone could miss the cancellations and downgrades. A team looking only at GRR could miss that some continuing customers found enough reason to buy more. For a renewal discussion, put the two figures side by side and show the underlying amounts; the rate alone conceals the scale and source of the change.
Time matters as much as the denominator. A monthly view can show a sudden change, while a year can cover a full renewal cycle; ChartMogul notes that its retention charts can be read by month, quarter, or year. Its discussion of retention periods is a reason to label every chart with its window. Do not compare a one-month NRR with a twelve-month GRR as if the difference described customer behavior. Pick the window that matches the decision, and keep it fixed when comparing periods.
Customer retention shows a loss that revenue can cover up
In the same illustration, ten of the 100 starting customers cancel. Customer-count retention is therefore 90%: 90 continuing customers divided by 100 starting customers. Revenue retention uses the $100,000 starting revenue instead. ChartMogul defines revenue retention using starting MRR; customer-count retention instead uses the starting number of customers. The distinction is especially important when accounts have very different subscription sizes.
Suppose the $15,000 expansion in the illustration came from one continuing account. NRR would still be 103%, even though ten other customers had left. That does not establish that the expanding account is unusually healthy, or that the departing accounts were poor fits. It does show why an aggregate rate cannot settle an account-level question. Read customer-count retention alongside GRR and NRR, then inspect the particular accounts behind each change. Which customers left entirely? Which reduced seats or capabilities? Which expanded, and what part of the subscription changed? The answer determines whether to investigate a common obstacle, a pricing issue, or a pattern limited to a few accounts.
Segmenting is useful when the segments describe materially different customers. ChartMogul allows retention views by plan, industry, and company size, among other filters. That segmentation guidance supports a practical choice: compare customers on similar plans or at similar stages before declaring that an overall average describes them all. A single large expansion can dominate revenue-weighted results while many smaller accounts leave. Conversely, a count of small cancellations may look alarming while the revenue effect is modest. Neither denominator is the true one in every setting; the decision determines which loss matters, and the other denominator provides a check.
Do not turn this into a contest for the highest percentage. A retention rate is an outcome of past account decisions. To change the next one, the team needs earlier signs of what customers can and cannot accomplish. That moves the discussion from a cohort total to the work happening inside individual accounts.
Product use should point to a question, not supply the answer
Product activity is valuable because it appears before a cancellation is booked. Pendo recommends looking at breadth, depth, and frequency when incorporating usage into customer health: how many users at an account are active, whether important features are used, and how often people return. Pendo’s customer health guidance also calls for goals based on historical patterns and customer outcomes rather than a universal activity threshold.
Start by defining the capability whose adoption matters. “Feature adoption” is incomplete without a feature, an eligible population, a time window, and an event that represents meaningful use. If only 40 accounts have access to a reporting capability, then 20 accounts using it means 20 of 40 eligible accounts, or 50%, in an illustrative calculation. It is not 20 divided by every customer in the company. Counting clicks on the menu might show discovery; counting a completed report might better reflect actual use. The team should choose the event that matches the customer’s intended task and explain why.
Breadth and frequency need the same care. Ten active users out of ten licensed users tells a different story from ten out of 500. Thirty logins in a month may mean a team has made the product part of its work, or that one person repeatedly retries a difficult task. Pendo distinguishes active visitors, days active, time in the app, and engagement with high-value events in its account reports. Those example measures are most useful as a prompt to inspect behavior, not as automatic proof of value.
Use a usage drop to decide which question to ask. If the account stopped using a capability after its primary user left, the response may be to help a new owner get started. If users are active but never complete the intended workflow, the response may concern setup, usability, or whether the capability fits their job. If usage is low because a customer’s work occurs only once a quarter, a weekly activity target could wrongly mark a healthy account as at risk. The missing fact is the customer’s expected pattern of use. A usage metric cannot supply that context by itself.
Pendo also describes retention views that identify accounts that have stopped returning. Its retention guidance makes a useful distinction between identifying an account and deciding what to do with it. An in-app prompt may help a user who needs instruction; it will not resolve an unmet business goal simply because it raises activity. Before sending an intervention, learn which user stopped, which task they were trying to complete, and whether anyone in the account still needs that task done.
Ask whether the customer achieved the result behind the activity
A customer can use a product often and still be dissatisfied with its result. Gainsight’s account of redesigning a health score for its own product warns against treating adoption alone as customer health. It describes deployment, stakeholder engagement, adoption, business impact, support tickets, and customer sentiment as different inputs. Gainsight’s account is an example of one operator’s approach, not a claim that every product needs the same score.
For each account, write down the result that justified buying or renewing the product, then decide how the customer would recognize progress toward it. A reporting product might be used to produce a weekly report, but opening the reporting screen is only an activity. The result could be a completed report that the customer actually uses in a decision. This is an illustrative distinction, not a claim about a particular vendor’s customers. It forces the metric to follow the customer’s work rather than the product’s event counter.
The result may be difficult to observe from software logs. In that case, pair a precise usage measure with a customer conversation, an agreed milestone, or the customer’s own record of the outcome. Record what was expected, what happened, and who at the customer confirmed it. A statement from one enthusiastic user may not represent the budget holder’s view, while a budget holder’s renewal may not mean every user can do the job. Relationship measures and economic measures belong next to the outcome, because each captures a part the others can miss. Gainsight includes surveys, sentiment, and support volume among its experience inputs. Its description of those inputs also shows why a support count needs interpretation: a contact may be a request for help with real engagement or a sign of persistent difficulty.
When the account reports success but its usage data is thin, ask whether the product is being used in a way the instrumentation cannot see, or whether success came from another source. When activity is high but the customer reports no progress, investigate the workflow before asking for more logins. These are different situations and should lead to different conversations. The cost is time spent learning the customer’s definition of success. It is time better spent than treating a rising event total as a completed outcome.
Make a health score explain the account, not replace it
A health score can combine account signals, but a single color is only useful if the team can see what created it. Gainsight describes choosing features for its score, assigning weights under different scenarios, and including both quantitative and customer-facing input. Its score-design account makes the trade-off clear: a composite can help prioritize work, while its weighting choices can change which account appears most urgent.
A sensible first version would keep the components visible: retention or renewal status, adoption of the capability the customer bought, progress toward the customer’s stated result, and relationship or support context. Define the period and data source for each. If a component has no current observation, show it as unknown rather than silently treating the account as healthy. If a score falls because usage fell, the account owner should see which users or workflows changed. If it falls because a customer reported an unmet outcome, the owner should see that reason instead. Two accounts with the same score can require different help.
Weights should reflect the score’s intended use. A score meant to prompt onboarding help may give more attention to setup and early use. A score meant to prepare a renewal conversation may put more attention on whether the customer achieved the promised result and whether the people responsible for renewing recognize it. Gainsight says its own score changed as its product and customers matured, and that goals differ between onboarding and later adoption. That account-specific experience is a useful warning against copying someone else’s weights without copying their customers, product, and decision.
Treat a score as a way to choose the next conversation, not as a verdict about the customer or the customer success manager. A green score cannot cancel an explicit complaint; a red score cannot prove that the customer will leave. Inspect the underlying signals and the account’s stated goal before assigning an action. If changing one weight reverses the priority of many accounts, the team needs to understand which assumption caused the reversal before staffing its response around the ranking.
Put the numbers where they change a decision
An effective customer success review can be compact. Start with GRR, NRR, and customer-count retention for the same starting group and period. Show the dollars and accounts behind churn, contraction, and expansion. Then move to account-level exceptions: a customer whose key workflow stopped, one whose activity increased without an agreed result, or one whose support pattern changed. End each account discussion with the next question or action and the person responsible for it. This sequence moves from a company-level result to the customer work that might change the next result.
The resulting dashboard is smaller than a catalogue of every available metric. A number earns a place when it can change a decision. GRR can direct attention to losses masked by expansion. NRR can show whether continuing customers are increasing spend. Customer-count retention can expose a pattern of departures that revenue totals conceal. Adoption can identify a stalled capability, provided the eligible accounts and meaningful action are clear. An outcome record can show whether product use delivered what the customer expected. A health score can order conversations, provided its reasons remain visible.
The trade-off is that the most useful measures require definitions and account context. It is easier to publish a single retention percentage or count every click than to preserve a starting cohort, identify eligible users, and ask a customer what changed in its work. Choose that extra precision. When the measures disagree, the disagreement is often the most useful thing on the page: it tells the team exactly which customer question the dashboard has not answered yet.