MRR preserved: how to report save-flow revenue honestly#

MRR preserved - the monthly recurring revenue of subscriptions your cancel flow kept - is the number that decides whether the flow is worth running. But counted at the moment of save, it overstates reality: it ignores discounts you gave to get the save and counts subscribers who churn again three weeks later. Count a save as realized only when the subscriber pays the next renewal, survival-adjust the cohort at 90 days, and report both numbers side by side.

Save rate is the metric everyone quotes and the wrong one to optimize. This post is about the better metric, and about the three places it quietly inflates if you count it carelessly: timing, discounts, and re-churn.

Why MRR preserved, not save rate#

Save rate weights every subscriber equally; MRR preserved weights them by what they pay, which is what your P&L does. A flow that saves five $9 subscribers posts a better save rate than one that saves two $199 subscribers, while preserving $353 less revenue per month. If your store has any plan-price spread at all, the two metrics can move in opposite directions, and offer changes that look like wins on save rate can be losses in dollars.

This is not an argument against tracking save rate - it is the right numerator for flow-quality questions like survey design, and it is what public benchmarks report, including the ones we have collected for WooCommerce stores. It is an argument for making MRR preserved the number that goes in the monthly report, with save rate as a diagnostic underneath. The save-rate impact calculator does the translation: it turns a save-rate change into dollars using your subscriber count, churn, and average plan price, which is the units the decision actually gets made in.

Counted at save vs realized at next renewal#

"Counted at save" books the subscription's full monthly value the moment the customer accepts an offer. "Realized at next renewal" books it when the next invoice is actually paid. Use the second one for reporting; keep the first only as a leading indicator.

Counted-at-save numbers inflate in two ways. First, an accepted offer is not a completed save - a customer can accept a discount in the cancel flow and still churn before the next invoice, through a failed payment, a chargeback, or simply coming back to cancel properly. Second, the face value is wrong: a $49 subscriber saved with a 25% discount for three cycles renews at $36.75, not $49, so booking $49 overstates near-term preserved revenue by a third for the life of the discount.

There is precedent for the realized standard in the tooling itself. Churnkey's A/B testing framework tracks each test cohort for a fixed 30 days specifically to confirm that saved customers actually pay their next invoice and remain subscribed - the accept click alone does not count. Industry headline numbers, on the other hand, are usually the generous kind: Churnkey's 2025 State of Retention cites $250 million of revenue recovered without specifying whether that figure is adjusted for subscribers who later churned, and ProsperStack's reporting docs define save rate as the percentage of subscriptions saved in the period, which is a counted-at-save definition. None of this is dishonest - it is just measured at the most favorable moment, and you should not run your own store on numbers measured that way.

The survival adjustment#

A saved subscriber who churns next month was not really saved; they were rescheduled. The survival adjustment applies your saved cohort's actual retention to the headline number, and it is the difference between a flow that looks great and a flow that is great.

A worked example - hypothetical numbers, arithmetic real. Say July's flow saves 20 subscribers on a $49 monthly plan, all via a 20% discount for three cycles ($39.20 per renewal):

The honest 90-day figure is $510 - about half the $980 headline. That ratio is not a scandal; some decay is inevitable, because these are customers who by definition already tried to leave once. The scandal is only in reporting $980 and building payback math on it. For calibration on how fast unsaved cohorts decay, Stripe's cohort-retention documentation walks through the compounding: at a constant 10% monthly churn, a cohort is at 90% after one month and 59% after five. Your saved cohort will decay faster than your general base; how much faster is exactly what this table measures.

One caveat to keep you honest in the other direction: survival-adjusted MRR preserved still is not a true causal number. Some declined-offer customers come back on their own or through a winback sequence, so the counterfactual is not zero. Measuring the true lift takes a holdout group, and the A/B math shows most stores lack the cancel volume to run one. Survival adjustment gets you most of the honesty for none of the sample-size cost, which is why it is the practical standard.

Your billing dashboard will not compute this#

Do not expect MRR preserved to appear in Stripe, or in any general-purpose billing analytics, because a save is invisible to MRR accounting. Stripe's Billing docs define MRR as the monthly-normalized value of all active and past_due subscriptions; a subscriber who enters the cancel flow, takes an offer, and stays was active before and active after. Nothing churned, nothing reactivated, no MRR event fired. The flow's entire contribution is a counterfactual, and dashboards do not chart counterfactuals.

Worse, two save mechanics actively distort the dashboard numbers:

• Retention discounts may not show up at all. Stripe's MRR settings make subtracting discounts optional - the docs describe subtracting them as the more conservative approach that more closely reflects the present value of these customers. If that toggle is off, a book full of save-flow discounts reads as full-price MRR, and your MRR quietly overstates collectible revenue by your aggregate discount depth.
• Paused subscribers can still look like revenue. Stripe's pause-payment-collection mechanism leaves the subscription active with invoices generating and only collection stopped, so a paused-to-avoid-cancel subscriber continues to count toward MRR while paying nothing. In WooCommerce Subscriptions the equivalent on-hold status does leave MRR, which is the opposite distortion - a paused subscriber who will probably return counts as zero.

The practical consequence: MRR preserved has to be computed from save-flow events joined to subsequent renewal payments - flow data plus billing data, not billing data alone. Wherever you compute it, define it as: subscribers saved in the cohort window, still subscribed at the checkpoint, times what they actually pay now.

What counted-at-save is still good for#

Keep the counted-at-save number - just demote it to a leading indicator. It has three legitimate jobs.

It is available immediately. Realized numbers lag by a full billing cycle at minimum and 90 days for the settled figure, which is too slow for spotting operational breakage. If counted-at-save MRR drops by half this week, something changed in the flow today - a broken offer, a routing bug, a price change upstream - and you want the alarm now, not in October.

It is the right numerator for within-flow comparisons made in the same period. When two offers run side by side against similar cohorts, their counted-at-save gap is a fair early read on relative performance, because both inflate the same way. The absolute level lies; the comparison mostly does not, though the final call should still wait for realized numbers, since offers can differ exactly in how well their saves stick.

And it bounds the realized number from above. If the headline is $980, you know September's settled figure will land somewhere below it; a forecast that assumes more is wrong on arrival.

The one thing never to do with either number is annualize it. "July preserved $510/month, so the flow is worth $6,120 a year" assumes zero decay for twelve months from a cohort you just watched lose a third of its members in three. Preserved MRR times remaining expected lifetime is an LTV question, and it needs your cohort's actual retention curve, not a multiplication by 12.

Reporting windows#

Report monthly save cohorts, each evaluated at a fixed 90 days, plus a counted-at-save column as the leading indicator. The window choices that work:

• Cohort by save month. July saves are one row forever. Never report a blended "MRR preserved to date" across all history - it mixes cohorts that have had twelve months to decay with cohorts that have had one, and the blend drifts upward as you grow.
• Realize at the next renewal (30 days for monthly plans). This is the earliest defensible number and matches the 30-day convention Churnkey's testing uses. Expect it to be the biggest single drop from headline.
• Settle at 90 days. Three renewal cycles catches most re-churn, including customers whose discount just ended, while keeping the number recent enough to act on. Freeze the cohort's reported figure there; further decay is ordinary churn, not save-flow failure.
• Annual plans need annual patience. A saved annual subscriber cannot be realized until the renewal, up to a year out. Report those cohorts separately as counted-at-save with the realization date attached, rather than blending unrealizable annual MRR into monthly numbers.

The honest report#

The monthly save-flow report is five columns and a rule:

The rules that keep it honest:

1. The 90-day column is the number. It is what the flow is worth. Quote it in payback math, pricing decisions, and any argument about whether the save flow earns its keep.
2. Watch the ratio, not just the level. Realized-at-90 divided by counted-at-save is your inflation factor. If it sinks over time, your offers are buying accepts, not retention - typically a discount that is too deep or a pause routed to price-reason customers.
3. Never let the headline number travel alone. The moment "$980 saved in July" leaves the dashboard without its $510 companion, it becomes the official number, and every decision downstream of it inherits the overstatement.

The pattern in one sentence: count saves when the money arrives, not when the button is clicked - the same discipline, applied one metric later, that separates an accepted offer from a saved subscriber.