Run a retention offer before renewal without paying customers who were staying anyway
Pre-renewal save offers on Stripe, sized by risk instead of by list membership.
The short answer
A pre-renewal retention offer is a discount or benefit shown to a subscriber shortly before their renewal date. It only creates value when it reaches customers who would otherwise have cancelled. Markin scores renewal risk per subscriber, excludes low-risk accounts, executes through Stripe, and reads the result against a randomised holdout.
Last reviewed 2026-09-10
Who this applies to, and who it must not reach
Eligible
- Active subscription renewing in the next 14 to 30 days.
- Modelled cancellation risk above the threshold where the offer pays for itself.
- No retention offer accepted in the previous two renewal cycles.
- Marketing or transactional consent valid for the channel used.
Excluded
- Subscribers already inside a committed term with no cancellation right in the window.
- Low-risk, high-tenure accounts: the offer is pure margin loss on them.
- Accounts in dunning or with a failed payment. That is a billing problem, not a retention problem.
- Anyone in the randomised holdout, and anyone who saw a save offer in the current cycle.
The minimum data, and where it normally comes from
| What is needed | Usual source |
|---|---|
| Subscription state and renewal date | Stripe subscriptions and invoices |
| Plan, price and discount history | Stripe prices, coupons and promotion codes |
| Usage or engagement in the last 30 days | Product events in the warehouse |
| Past cancellations and reactivations | Stripe cancellation events, warehouse history |
| Gross margin on the next unit | Finance, supplied once as an input |
| Consent and contact fatigue | CDP or engagement platform |
Step by step
How the decision runs
- 01Markin
Score renewal risk per subscriber
Risk is estimated on billing, usage and support signal for every subscription entering the renewal window, not on a segment rule written months ago.
- 02Markin
Size the offer against margin
Each candidate offer is valued as expected retained margin minus expected discount given to customers who would have renewed regardless. Offers that do not clear that bar are not proposed.
- 03Markin
Hold out a randomised control
A share of eligible subscribers is withheld before anything is sent, so the read is causal rather than a before-and-after comparison.
- 04Your stack
Apply the offer in Stripe
The chosen coupon or promotion code is attached to the subscription in Stripe, keeping billing, proration and tax exactly as your finance team already configured them.
- 05Your stack
Deliver the message on your channel
Braze, Klaviyo or your own email service sends the message. Markin supplies the decision and the reason; the channel keeps its own governance and frequency rules.
- 06Markin
Read the result and update the policy
Retention, revenue and margin are read against the holdout at the end of the window, and the eligibility threshold moves with the evidence.
Measurement
How you know whether it worked
- Holdout
- Randomised at the subscriber level before the first send, sized from the lift you need to detect rather than a fixed percentage.
- Window
- One full renewal cycle plus 30 days, so cancellations deferred rather than prevented are visible.
- Primary result
- Incremental retained gross margin per eligible subscriber.
Guardrails
- Discount cost per retained subscriber.
- Share of the offer taken by low-risk accounts.
- Downgrade rate, so retention is not bought by moving people to a cheaper plan.
- Repeat-offer dependency across cycles.
Illustrative only
A worked example
Illustrative arithmetic on made-up inputs, to show how the decision is evaluated. These are not Markin results.
| Subscribers entering the renewal window each month | 40,000 |
|---|---|
| Share above the risk threshold | 18% (7,200) |
| Offer | 20% off one cycle on a $30 plan |
| Assumed lift in renewal on the eligible group | 3.5 points |
| Gross margin on the next unit | 70% |
| Read | Retained margin from the incremental renewals, minus the discount paid to everyone who took the offer, including those who would have renewed |
The point of the exercise is the second half of that last line. Without a holdout you never see it.
Run it on your own numbers
The arithmetic, spelled out
Offer is worth making when p(cancel) x lift x margin per cycle > discount cost x p(take-up). Rearranged, the eligibility threshold is: p(cancel) > (discount x take-up rate) / (lift x margin per cycle).
| Input | Value |
|---|---|
| Plan price per cycle | $30.00 |
| Gross margin on the next cycle (70%) | $21.00 |
| Discount offered | 20% of $30.00 = $6.00 |
| Assumed take-up among those contacted | 45% |
| Expected discount cost per contacted subscriber | 0.45 x $6.00 = $2.70 |
| Assumed absolute lift in renewal on the eligible group | 3.5 points (0.035) |
| Expected retained margin per contacted subscriber | 0.035 x $21.00 = $0.735 |
| Net per contacted subscriber at these inputs | $0.735 - $2.70 = -$1.965 |
At a flat 20% discount and 45% take-up, a 3.5 point lift does not pay for itself: the programme loses about $1.97 per contacted subscriber. It only clears zero when the lift reaches 0.45 x $6.00 / $21.00 = 12.9 points, or when eligibility is tightened so that take-up concentrates on subscribers who would actually have cancelled.
This is why the threshold, not the creative, is the decision. The same offer is profitable on a 40% risk band and destructive on a 5% one. Inputs are illustrative; substitute your own price, margin and observed take-up.
Timeline
How long it takes to a first measured result
- 01Week 1
Read-only connection and data check
Stripe read access plus the warehouse tables. The output is a count of subscriptions entering the renewal window each month and how much of the required data is actually present.
- 02Weeks 2 to 3
Risk model and margin inputs
Renewal risk is fitted on historical cancellations, and finance supplies gross margin per plan. The break-even threshold above falls out of these two.
- 03Week 4
Offer set, exclusions and approval
The coupons or promotion codes that may be used are agreed, exclusions are signed off, and the holdout share is fixed before anything is sent.
- 04Week 5
First cohort live
The first eligible cohort enters the renewal window with the offer attached in Stripe and delivered on your existing channel.
- 05Week 9 to week 13
First causal read
One full renewal cycle plus 30 days after the first cohort. Monthly subscriptions read at roughly week 9; annual plans require a longer horizon and are read on a rolling monthly cohort instead.
Technical detail
What is read and written, field by field
Stripe
Read
- subscriptions: status, current_period_end, cancel_at_period_end, items.price
- invoices and invoice line items for realised revenue
- customers for identity mapping
- events: customer.subscription.deleted, updated, invoice.payment_failed
Written
- A pre-approved coupon or promotion_code attached to the subscription
- subscription.metadata.markin_decision_id and markin_reason
Read via webhook plus a nightly reconciliation; write at decision time.
Warehouse (BigQuery, Snowflake or equivalent)
Read
- Product or usage events for the last 30 days, keyed to the customer
- Support contacts and complaint history
- Historical cancellations for model fitting
Written
- A decision table: customer, decision_id, action, reason, holdout flag, timestamp
Daily batch.
Messaging platform (Braze, Klaviyo or your ESP)
Read
- Consent state, frequency caps and quiet hours
Written
- The decision as a profile attribute the existing journey branches on
At your sync interval, typically hourly to daily.
Effort
What it asks of your team
| Who | How much of their time |
|---|---|
| Data engineer | Around 2 days in week 1 for access and table mapping, then occasional. |
| Lifecycle or CRM manager | Half a day a week: offer set, message templates, journey branch. |
| Finance | One session to supply gross margin per plan and approve the discount ceiling. |
| Legal or privacy | One review of data scope and consent basis before the first send. |
| Executive sponsor | One decision: accepting that a holdout receives nothing for a full cycle. |
What normally goes wrong
Offering everyone in the renewal window
The largest cost in most save programmes is the discount handed to subscribers who were never going to leave. Eligibility has to be risk-based, and the holdout has to be able to expose that cost.
Reading retention instead of margin
A deep enough discount always improves retention. It regularly destroys margin at the same time. Retention is a guardrail; margin is the result.
Training the base to wait for the discount
Repeating the same offer every cycle converts a save into an expected price cut. Cap repeat exposure and watch the cohort across cycles, not only within one.
Reading the result at two weeks
Early reads flatter the programme because deferred cancellations have not happened yet. Wait for the full cycle.
Questions this playbook answers
- Who should get a save offer before renewal?
- How do I stop discounting customers who were going to renew anyway?
- How big should the holdout be for a retention offer?
- How do I apply a retention discount in Stripe without breaking proration?
- How long should a save-offer test run?
Frequently asked
- How far before renewal should the offer land?
- Close enough that the renewal decision is live, far enough that the customer has not already cancelled. Fourteen to thirty days is the usual window for monthly and annual subscriptions, and it is worth testing as a variable rather than fixing it by convention.
- Does this replace my cancellation flow?
- No. The in-cancellation flow catches people who have already decided. This playbook is about the customers who never reach that flow because they simply let the renewal lapse, which in most subscription bases is the larger group.
- Can the offer be something other than a discount?
- Yes, and it usually should be. Extra usage, a plan feature, a service credit or a pause option often retain at similar rates without permanently repricing the relationship. Markin treats each as a candidate action and lets the holdout decide.
- What does Markin need access to in Stripe?
- Read access to subscriptions, invoices, prices and cancellation events, plus the ability to attach an approved coupon or promotion code to a subscription. No changes to your billing model are required.
- How is this different from a churn prediction model?
- A prediction tells you who is at risk. This playbook decides what to do about it, executes it, and proves whether the action changed the outcome. Prediction without a measured intervention does not move revenue.
Where this connects
- PlaybookWin back lapsed customers with a silence window instead of a discount ladderReactivation timed on returning intent, not on days since last order.
- PlaybookAdd next best action to journeys you already run in BrazePer-customer arbitration written into the canvases your team already operates.
- PlaybookCross-sell a second product without cannibalising the plan the customer already pays forSecond-product offers valued on incremental margin, not on attach rate.
- SolutionRetention DecisioningChoose the right intervention before churn, not after the score
- SolutionCustomer DecisioningThe decision layer between your customer data and your channels
- ComparisonMarkin + Optimove: deciding what deserves a campaign at allOptimove orchestrates and prioritises retention campaigns. Markin decides which revenue opportunity deserves one, sizes it, and proves it against a holdout.