Retention & Subscriptions

Subscription Pause

Scheduled pause → restart reminder → automatic reactivation

Manage a scheduled subscription pause from confirmation to the automatic restart.

  • Suspension & Restoration
  • Email
  • Push

Core rule

A scheduled pause ends automatically on the restart date unless the subscription changes first.

Journey plan

When to set it up

If paused subscriptions restart and charge quietly on the return date, and tickets about unexpected charges or cancellations pile up right after the restart, build this journey. Before launch, make sure the pause event carries its recorded restart date, that subscription state and the restart payment result are readable in real time, and that you hold the email address and push permission. You also need a way to hold renewal and usage sequences while the pause lasts. If people pause without picking a return date, or pause repeatedly, the issue is plan fit; a reminder schedule will not fix it.

How to measure success

Incremental continuation rate after restart vs control

The journey earns its place if informed users keep their subscription after the return date; opening the confirmation or the reminder proves nothing by itself.

How it is counted: Take every pause assigned at entry, journey group and control group together, and count the share whose subscription is still active within the same follow-up window after the restart date; the gap between the groups is the journey's effect. Delivered or opened messages do not shrink that denominator.

Also track

  • Successful restart rateAmong subscriptions that reach the restart date still paused, the share where automatic reactivation and the charge both complete; the step before continuation.
  • State change before restartRead the share of pauses cancelled or changed before the return date separately for both groups; the reminder may raise it, and that is a user's informed decision, not a loss to hide.
  • Share handed to payment recoveryPauses whose restart charge fails and move to Payment Failure Recovery, as a share of all pauses reaching the restart date; if it climbs, the problem is the stored payment method, not the reminder.
  • Push opt-outs and unsubscribesWatch push permission turned off after the reminder and email unsubscribes; a user who paused already asked for distance, so a rise here means the tone needs work.

How to set it up

  • Trigger and entryA subscription paused with a chosen restart date starts the journey. Split those pauses at random, at entry, into the journey group and a control group that still gets the automatic restart but none of the three messages.
  • Who must not enterPauses without a restart date and cancellations stay out. One pause period is the scope: if the user moves the restart date, update the existing timer instead of opening a second instance. While the pause lasts, take the user out of normal renewal and usage messaging.
  • Timing and channelsAn email confirming the pause window and the automatic restart date goes out right away; 3 days before the restart, a push reminds the user that the subscription will resume. On the restart date, the journey rechecks that the subscription is still paused and eligible, and only then reactivates it.
  • Exit and handoffIf the subscription state has changed by the restart date, the journey ends without another message. If the restart payment fails, the user moves to Payment Failure Recovery and this journey's remaining email is cancelled; if it succeeds, the restart confirmation email goes out and the journey closes at Subscription active.
  • Frequency and consentThree messages at most go out per pause: two emails and one push. Push permission decides whether the push goes out, and the emails follow the user's email preferences. Never send the restart confirmation before a successful charge is verified.

What to watch when reading the result

  1. 1Should the continuation rate after the restart fail to beat the control group, the confirmation and reminder are not changing the subscription decision, and a high open rate does not make up for it. Decide on the continuation gap between the groups, read alongside the cancellation counts.
  2. 2This read holds for these two emails, this push and the 3-day lead before the restart. A subscription recovered after a failed charge belongs to Payment Failure Recovery, not here; record the automatic restart and the successful charge as separate events.
  3. 3If the two groups sit close together or the direction is unclear, enter each group's pauses and continuing subscriptions into the A/B test significance calculator; if the difference is not significant, wait for more pause periods to accumulate, which can take months when pausing is rare.
  4. 4Send the restart confirmation only after the state check and the charge both succeed. If a renewal or usage message from another flow leaked in during the pause, do not credit or blame this journey for that period's result.

Frequently Asked Questions

How does pausing a subscription differ from cancelling it?

This example has a recorded restart date and automatically resumes an eligible subscription then. Cancellation ends the relationship under its terms. Pause confirmation should explain duration, restart date and any renewed charge.

Should normal usage and renewal messages continue during a pause?

Avoid messages assuming active use. Suspend normal sequences as appropriate for the pause state. This example reminds the user three days before restart. Update the old timer if the restart date changes.

What happens if payment fails at scheduled restart?

Recheck that the subscription remains paused and eligible. Route a required failed charge to Payment Failure Recovery. Do not confirm activation before restart is verified. Record automatic restart and successful collection as separate events.

Explore other journeys