Churn Analysis: A Worked Example for Better Retention Decisions

Churn analysis examines which customers leave, when they leave, and what the evidence suggests you should investigate next. Start with a consistent definition, compare customers with similar time to renew, and separate changes in customer mix from changes in retention within each group.

Imagine a monthly review where customer churn falls from 9% to 8%. The headline looks encouraging. But the rate has risen in both customer segments. A shift toward the lower-churn segment has hidden the deterioration.

This guide works through that problem, then shows how to connect the result to a retention decision. The data is synthetic, and the arithmetic is independently reproducible from the counts below. It is an analytical example, not a customer result or an Orion product benchmark.

What should churn analysis help you decide?

A useful analysis separates three questions:

• What happened? Establish the number of customers lost, the revenue affected, and the period being measured.
• Where should the team investigate? Identify the customer groups, lifecycle stages, or renewal events behind the movement.
• What should happen next? Choose a specific investigation or retention experiment, with an owner and a way to assess it.

A cancellation rate answers the first question. A breakdown can help with the second. Neither proves that a particular product change, price increase, or support experience caused someone to leave.

For a broader explanation of contribution and causation, see the guide to investigating metric changes. Here, the focus is the customer population and timing that make churn calculations meaningful.

Define the customer and the churn event first

For the worked example, a customer is a paying account with at least one active paid subscription at the start of the period. An account counts as churned if it has no active paid subscriptions at the end. New accounts acquired during the period are outside that starting population. An account that cancels and returns before period-end is retained under this definition.

The calculation is:

Customer churn rate = starting accounts no longer paying at period-end ÷ paying accounts at period-start.

Your finance or billing definition may differ. For example, ChartMogul documents a customer churn calculation that accounts for same-period acquisition and reactivation, plus a configurable point at which churn is recognized. Reconcile the definition before comparing reports.

Write down these choices alongside the result:

• The account identifier, including how multiple workspaces or subscriptions map to one customer.
• The recognition date: a cancellation request, the end of paid access, or a failed renewal after an agreed grace period.
• The reporting period and time zone, with both comparison periods complete.
• The treatment of trials, pauses, nonpayment, reactivation, and customers who join and leave in the same period.

Customer churn and revenue loss answer different questions. Losing a small account and losing a large account each count as one customer. Keep a separate revenue view using the approved definitions of cancellation, contraction, expansion, and reactivation. A customer-count improvement can coexist with worsening revenue retention.

Worked example: why did churn improve while both segments worsened?

The fictional company has Starter and Scale customers. Each account belongs to exactly one segment, recorded at the start of each period. The two periods have different starting populations; this is not a claim that the same 100 accounts remained in place.

Starter churn rose from 10% to 15%. Scale churn rose from 5% to 6.25%. Yet overall churn fell because Scale customers, the lower-churn segment in both periods, grew from 20% to 80% of the starting population.

Calculate each overall rate from total losses divided by total starting accounts. Averaging the two segment percentages would give the wrong answer whenever the groups have different sizes.

To check the effect of mix, hold Period A's weights constant and apply Period B's rates:

Period B churn at Period A mix = (80% × 15%) + (20% × 6.25%) = 13.25%.

With the earlier mix, the later segment rates would produce 13.25% churn, compared with Period A's 9%. That is a 4.25 percentage-point deterioration within segments under this weighting convention. The move from 13.25% to the observed 8% reflects a 5.25 percentage-point improvement from mix under the same convention. Together, +4.25 and −5.25 reconcile to the observed −1 percentage-point change.

This is a descriptive calculation. It is not a prediction, an expected count of lost customers, or proof that moving accounts into Scale causes better retention. A different order of changing weights and rates allocates the components differently; record the convention rather than treating one allocation as unique.

For the business review, the finding is specific: the overall rate improved because the starting population changed, while both segment rates worsened. Investigate how the population changed and examine the losses within each segment before declaring the retention program successful. With only one to eight losses per segment-period, these observations also need more history before being treated as a stable trend.

Compare cohorts at the same age

Segment mix is one explanation. Unequal time to churn is another.

A customer who joined ten days ago has not had the same opportunity to cancel as someone who joined six months ago. Compare acquisition cohorts at a common age, such as day 90, and leave cohorts blank until they have reached that age. Decide whether day zero means signup, first payment, or activation.

For example, a day-90 retention calculation can use customers from one acquisition cohort still paying at day 90 divided by the original paying cohort. That denominator differs from a monthly churn rate based on customers active at the start of each month. Label the measure so readers do not compare them as if they were interchangeable.

Keep the original acquisition cohort fixed when an account upgrades, downgrades, or returns. Analyze those events separately. ChartMogul's cohort documentation explains subscription cohorts, lifecycle intervals, and weighted aggregation; check the exact interval convention in the tool you use.

For annual contracts, renewal eligibility also matters. A month with many accounts approaching renewal can look worse than one where few contracts can expire. Inspect renewal-eligible accounts and their outcomes separately from the overall monthly population.

Build a customer-level record you can reconcile

The aggregate table is a starting point. To investigate it, retain one row per account and reporting period, with the starting status, ending status, starting segment, subscription dates, and the source records supporting those fields.

Join usage, support, and CRM data only after confirming the account mapping. A one-to-many join between subscriptions and support tickets can multiply accounts and inflate losses. Aggregate those systems to the required grain before joining, then reconcile both starting accounts and lost accounts to billing.

Record missing usage separately from zero usage. Check whether an event rename, migration, delayed load, or broken identity mapping changed what was recorded. A tracking failure can create an apparent engagement decline without a change in customer behavior.

Use attributes available at the time of the decision. If you are asking what was knowable before cancellation, an account's final cancellation reason or a later support escalation cannot be an input to that earlier risk assessment.

Turn the finding into an investigation

Return to Period B. Starter lost three of 20 accounts and Scale lost five of 80. The higher rate and the larger number of losses point to different priorities; add revenue exposure and the team's ability to help before choosing an action.

For Starter, inspect onboarding completion, tenure, payment failures, and cancellation feedback. For Scale, inspect the affected renewals, account-level usage, and relationship history. Those are proposed branches to test, not explanations established by the table.

A usage decline can help prioritize that review. Suppose an account's completed core actions fall from 100 to 40 across two equal, complete windows. That is a 60% decline in the defined activity, not a 60% probability of churn. Confirm instrumentation and context—such as seat reductions, seasonality, or a workflow migration—before interpreting it as lost value.

Assess a proposed signal against historical outcomes using information available before those outcomes. Track how many flagged accounts actually churned, how many churned accounts were missed, and whether the team can act on the warning. Do not call an untested threshold a prediction model.

Choose an action the evidence can support. Payment failures may warrant a billing review; an onboarding pattern may warrant an onboarding experiment. Record the intervention and subsequent outcome. A before-and-after improvement alone cannot establish that the intervention caused it; an appropriate randomized holdout can help when feasible.

Where Orion, Hex, and your existing analytics fit

You can do this analysis in a spreadsheet, a warehouse query, or an analytics product. Keep an existing billing report when it already answers the question correctly. Use an event analytics tool when the main task is exploring recorded product behavior, and evaluate a modeling environment when you need to develop and maintain a predictive model.

Hex's churn guide demonstrates a notebook workflow using a public telecom dataset, segmentation, and predictive modeling. Hex is a relevant choice for analysts who want to own that Python and SQL work. Its Threads documentation also describes conversational analysis over semantic models and warehouse tables, so natural-language access alone is not a reason to switch.

Orion by Gravity is worth evaluating when business users and data teams want to investigate churn together and preserve the analysis for later review. Orion's analysis documentation describes plain-language questions, queries against connected data, charts and tables, and reusable notebooks. Its Context pages can hold the agreed churn definition and analytical instructions.

A proposed starting question is: “Using our approved customer-churn definition, show starting accounts, losses, and rates by starting plan for the last two complete months. Reconcile to billing, then recalculate the later rate using the earlier plan mix. Show the calculation and unresolved data gaps.”

Review the returned work against the reference calculation before reusing it. If dbt owns the metric logic, preserve that definition and verify the actual execution path; importing metadata is not proof that an agent always executes through the dbt Semantic Layer.

The worked example here was checked independently, not run as a demonstrated Orion workflow. A product trial should reproduce the counts, identify the mix reversal, expose the underlying work, and respect the intended user's access. Compare Orion and Hex on that same task if both are on the shortlist; no comparative accuracy or retention outcome is established here. The Orion–Hex comparison covers the broader buying decision.

What belongs in the retention review?

Bring the reconciled metric and definition, the segment and cohort results, the account records supporting the finding, and the next action with an owner. State which observations are arithmetic, which are associations, and which explanations remain untested.

In this example, the next decision is to investigate worsening segment retention and the changing account population. The lower headline rate is real. It is insufficient evidence that the customer experience improved.