Win Back Lost Subscribers
Win back churned and cancelled subscribers with an automated push + promo-offer screen. Strategy, setup, and ready-to-use campaign recipes.
Win Back Lost Subscribers is a Rules template that automatically re-engages users the moment they cancel — sending a push notification and presenting an in-app screen with a personalized promotional offer (discount) to keep them subscribed.
It targets the cheapest revenue you can grow: people who already know your product. Reactivating a churned subscriber costs nothing in acquisition — you're recovering revenue you already earned once.
Find it under Templates on the Rules page → Win back lost subscribers.
Why win-back works
- A cancellation isn't a goodbye — yet. When a user turns off auto-renew, their subscription stays active until the end of the period. That gap is your window to intervene while they still have access to lose.
- Loss aversion is on your side. Reminding someone what they're about to lose, paired with a discount, converts better than a cold "we miss you" weeks later.
- It's near-zero cost. No ad spend, no new install.
Promotional offers are the right tool hereA win-back discount is delivered as an Apple promotional offer (iOS 12.2+), which is eligible only for users with a current or past active subscription — exactly your cancellers and lapsed users. Set up your offers in App Store Connect first, then attach the offer screen to the rule. See Promo Offers.
Pick the right trigger
A cancellation reaches Apphud as a specific event, and which one tells you whether the user was on a trial or paying — so you can tailor the offer.
| Event | Who it is | Use it for |
|---|---|---|
trial_canceled | Cancelled during a free trial (never paid) | Trial rescue — usually price anxiety or "haven't seen the value yet" |
subscription_canceled | A paying subscriber turned off auto-renew | Paid win-back — more deliberate; respond with a discount or a better-value plan |
Triggering on these two events is the recommended setup — they split trial vs. paying cancellers for you, and they're where cancellation volume actually flows.
autorenew_disabledis the legacy triggerThe template historically defaults to
autorenew_disabled, which fires for both trial and paid cancellations. It's deprecated (and now fires for only a small fraction of cancellations) — prefertrial_canceled/subscription_canceled. If you do useautorenew_disabled, split the groups with an audience (see below).
Splitting trial vs. paying cancellers
The cleanest split is the trigger event itself — trial_canceled (never paid) vs. subscription_canceled (paying). Use those two and you don't need anything else.
If you trigger on the broad autorenew_disabled instead, separate the groups with a custom audience (built on the Users & Audiences page) and run the rule on it. Audiences can be defined by criteria such as:
- Is Customer =
Yes→ the user has at least one payment (paying canceller);No→ trial-only. - Subscription status — e.g. trial vs. a paid status.
- Autorenewal =
Disabled— they just turned it off.
These are audience criteria, not rule filtersAn event-triggered rule's own + Add filter only offers Permission Group and Product ID. The trial/paid criteria above live in the audience definition — you build the audience, then target the rule at it. (Scheduled rules have no inline filters either; they simply sweep their audience.)
How the template works
| Piece | Default |
|---|---|
| Trigger | A cancel event (use trial_canceled / subscription_canceled). |
| Timing | Immediate — push at cancellation, in-app offer screen on next app launch. |
| Push | A default English push you can edit per locale. |
| In-app action | A Paywall model screen carrying the promotional offer. |
| Limit | Once per user. |
For the shared mechanics — Configuration / Push / In-app action tabs, lifecycle, Test — see Rules.
Set it up
- Open the Templates tab on the Rules page and click Add rule on Win back lost subscribers.
- Configuration — set the trigger to
trial_canceledand/orsubscription_canceled(add an audience to narrow it), and set timing/limit. - Push notification — write the Title and Text for your default locale (and translate to others).
- In-app action — choose Paywall model and select the paywall that carries your promotional offer.
- Save, then Enable.
Match the offer to the product the user cancelledIf you have several permission groups, add the Permission group filter so each cancelled user sees a promo offer from the same group they cancelled — not an irrelevant one. (This was called "Product group" previously.)
Make sure users are eligiblePromotional offers only apply to subscriptions the user has previously purchased. Confirm the offer shown targets a product the user is actually eligible for, or the purchase will fail.
Strategy: trial vs. paid cancellers
The single biggest lever is treating these two groups differently — they cancel for different reasons and respond to different offers.
- Trial cancellers usually bail out of price anxiety or because they haven't seen the value yet — and most cancel quickly to avoid the charge. Lead with a trial extension or a deep first offer, and point them at the premium feature that drives conversion.
- Paid cancellers are more deliberate. Offer a time-limited personalized discount, or upsell a longer (annual) plan at a better effective price.
Campaign recipes
A — Trial-cancel rescue (most urgent)
- Trigger:
trial_canceled - Timing: immediate (catch them before the trial actually ends)
- Offer: trial extension or a deep promo (extended free period / steep first-term discount)
- Message angle: "Still deciding? Here's a few more days free to finish what you started." Low-risk, value-first.
B — Paid-cancel "don't lose access" (loss aversion)
- Trigger:
subscription_canceled - Timing: immediate push, screen on next launch — while access is still active
- Offer: a modest first promo (e.g. a reduced next term)
- Message angle: "You'll lose [the feature they actually used] on [date]. Keep it for less." Name the specific benefit.
C — Re-engage lapsed users (scheduled)
For users who already expired without renewing, run a separate Scheduled rule over a custom audience of lapsed users (Subscription status = Expired, or the predefined Subscription expired audience).
- Offer: a stronger discount — they've lost access, so the incentive needs to be bigger.
- Message angle: "Come back — here's our best offer."
What this can and can't doUsers who re-subscribe automatically drop out of the lapsed audience (their status is no longer Expired), so you're only re-engaging people who didn't come back. Apphud does not track which users already received an earlier win-back push, so you can't exclude "already-messaged" users beyond setting Just once per user and relying on subscription status. Keep the cadence sane and don't stack overlapping win-back rules on the same users.
Going beyond 6 hoursA single rule's delay maxes out at 6 hours. For multi-day sequences, use a Scheduled rule plus a custom audience of users in the right subscription state. See Use Cases.
Best practices
- Don't bombard. Once-per-user is the safe default; for sequences, add delays and keep frequency low.
- Don't discount to everyone equally. Reserve the deepest offers for high-intent segments; a blanket discount erodes margin and trains users to cancel-for-a-deal.
- Fix the cause, not just the symptom. A flood of instant trial cancellations usually points to weak onboarding — an offer won't fix a broken first run.
- Segment by state: cancelled-but-active, expired, cancelled trial, expired trial each deserve different messaging.
FAQ
Which event should I trigger on?
Use trial_canceled for trial cancellers and subscription_canceled for paying cancellers — they split the two groups and capture the bulk of cancellation volume. autorenew_disabled is the deprecated legacy signal; avoid relying on it alone.
How do I tell trial cancellers from paying ones?
Trigger on the specific event — trial_canceled (never paid) vs. subscription_canceled (paying). If you must trigger on the broad autorenew_disabled, target the rule at a custom audience built with Is Customer = Yes (has paid before) or by Subscription status. An event-triggered rule's inline + Add filter only offers Permission Group and Product ID, so the trial/paid criteria belong to the audience, not the rule.
What's the difference between this and Apple's Win-Back Offers?
Apple's Win-Back Offers (iOS 18+) are configured in App Store Connect and auto-promoted by the App Store to lapsed users. This template uses Apphud Rules + a promotional offer via push + in-app screen — you control the trigger, timing, audience, and message. They're complementary; you can run both.
Why isn't the promo offer showing for some users?
Promotional offers require iOS 12.2+ and apply only to products the user has previously subscribed to. A user with no prior purchase of that product, or on an older iOS, won't see it. See Promo Offers.
Can I win back users who already fully expired?
Yes — see Recipe C: a Scheduled rule over a lapsed-user audience (Subscription status = Expired). Expired users have lost access, so a stronger offer usually performs better.
How do I measure if it's working?
Use the Rule filter/segment on revenue charts in Reports, plus the rule's own Analytics tab (performed / push sent / opened).
Learn more
- Understanding Rules in Apphud — the win-back use case end to end.
- How to increase revenue with subscription offers.
Updated 27 days ago