TL;DR
- Apple's report reasons and your in-app survey answers are different taxonomies. Keep both.
- A selected reason is the start of a review, not a diagnosis.
- Separate product, price, reliability, competitor, and payment patterns.
- Pair the stated reason with behavior and revenue impact.
- Assign one owner and one next action, or stop collecting the reason.
Someone taps Cancel. The product, the price, a broken first week, or a charge that never went through might all be sitting behind that tap. If every loss lands in one bucket called churn, those events look the same. They should not get the same response. Pulling them apart is the work of a real churn analysis.
Cancellation reasons help only when they change a decision. You do not need a longer list of labels. You need the few patterns that explain a real share of lost subscribers, then an owner and a next action for each one.
Apple’s report reasons are not your survey
If you sell through the App Store, start with the table Apple already publishes. App Store Connect lists six cancellation reasons:
| Cancellation reason | What Apple means |
|---|---|
| Billing Issue | The subscription ended because the subscriber could not be billed, for example a declined card. |
| Price Increase Notice | The subscriber cancelled from the price-increase notice. |
| Price Increase Consent | The price rose and the subscriber did not consent, so the subscription ended. |
| Canceled | The subscriber cancelled. |
| Removed From Sale | You or Apple removed the subscription from sale. |
| Other | The subscription ended for a reason not listed above. |
Operators searching “subscription cancellation reasons” often want this table. It is the report taxonomy. It will not tell you why someone tapped Cancel.
An in-app survey sits under Canceled. Billing Issue belongs with failed payment recovery, not with a save-offer flow. Price Increase Notice and Price Increase Consent are pricing events. Treat them as their own cohort, not as a generic “too expensive” pile.
The five survey patterns below are a working split for that Canceled bucket. They are not a ranking of “most common” reasons, and they are not Apple’s labels.
Start with the reason, then look backward
Ask for a reason at cancellation. Keep the choices short. Then treat the answer as the beginning of an investigation.
A useful review has three layers:
- The stated reason: what the subscriber selected or wrote.
- The behavioral context: product use, support contacts, trial status, and renewal history before they cancelled.
- The business impact: how many subscriptions and how much recurring revenue the pattern represents.
The same label can mean different things across cohorts. “Too expensive” from people who used the product every week is a pricing and packaging signal. The same answer from people who never reached the first meaningful action is usually an activation problem wearing a price label. Apple’s report will not make that split. Joining the survey answer to activation events will.
Survey patterns worth separating
Match the options in your cancellation flow to your product. Most subscription businesses still benefit from splitting the following.
The product did not become a routine
This group often selects “I do not use it enough” or “I no longer need it.” That can look like a demand problem. Often it is onboarding.
Find the first action that predicts a subscriber returning in week two or week four. Compare early cancellers with people who stay. If early cancellers rarely reach that action, skip the win-back discount and shorten the path to value.
Questions that help:
- Did they complete the core action in the first session?
- Did they return after day one and day seven?
- Did they set up the feature that makes the product useful over time?
- Was first use different for a particular acquisition channel or device?
The fix may be a shorter first-run flow, a clearer prompt at the moment of value, or fewer steps before the first result.
Useful, but not worth the price
“Too expensive” is not always a request for a discount. It can mean they did not understand what they were paying for, the plan did not fit usage, or a competitor made a more credible offer.
Split price objections by engagement. A highly engaged subscriber who cancels after a price change is a different investigation from a low-engagement subscriber who cancels during a trial. Also split Apple’s price-increase reasons from survey “too expensive” answers. One is a store notice. The other is a self-report.
Before changing price, look at:
- cancellation rate before and after the price or plan change
- which plan attracts the highest-quality retained subscribers
- use of the features that make the plan distinct
- support conversations and free-text that mention a competitor or a missing capability
A lower price can retain some people. It can also hide a product-value problem and cut the revenue available to fix it. Decide whether the issue is willingness to pay, plan fit, or an unclear value story.
The experience broke at the wrong moment
Failed logins, lost data, slow performance, and billing confusion often show up as cancellations. Handle those as reliability issues, not lifecycle marketing.
Join cancellation responses to support tickets, crash reports, device versions, and recent releases. A spike after a release is an incident. A steady trickle from one platform is a quality backlog item. In both cases, fixing the path beats writing another message.
They found a better alternative
Competitor answers help only if the follow-up is specific. “Better app” does not tell a product team much. A small optional text field can show whether people left for a lower price, a particular feature, a simpler workflow, or a brand they already trust.
Do not treat every named competitor as a roadmap vote. Look for repetition in high-value cohorts. If people who activate well and pay for several months keep leaving for the same capability, that is evidence. Scattered one-off names are ordinary shopping.
The “cancellation” is a payment problem
Not every lost subscription is voluntary. A card can expire, a bank can decline a charge, or access can drop after retries end. Apple files many of those as Billing Issue. They need a recovery playbook, not a survey.
Track voluntary and involuntary churn separately. A cancellation survey cannot explain a failed renewal that never reached the subscriber. Watch payment failures, retry outcomes, grace-period recovery, and how many people return after updating payment. The failed payment recovery guide covers that system.
A reason-to-action map
The useful dashboard is a queue of decisions, not a pie chart.
| Pattern | What to check next | Likely owner | First useful response |
|---|---|---|---|
| Low use | activation and early retention by cohort | Product | shorten time to first value |
| Price objection | engagement, plan mix, price-change cohort | Growth or product | test packaging or value communication |
| Technical issue | release timing, support volume, device | Engineering | fix the broken path and notify affected users |
| Better alternative | repeated competitor and feature mentions | Product | validate the pattern before changing the roadmap |
| Failed payment / Billing Issue | decline reasons, retries, recovery rate | Revenue or growth | improve recovery and the payment-update flow |
| Price increase (Apple notice or consent) | affected plans, notice copy, consent rate | Growth or product | treat as a pricing cohort, not a generic cancel |
If no action follows a reason, stop collecting that reason until it earns a next step.
Watch trends, not only totals
A monthly total can hide when a problem began. Break cancellations down by signup and renewal cohort, plan, country, platform, acquisition channel, trial versus paid, time since first purchase, and product or pricing changes.
You are looking for changes, not a perfect benchmark. If “did not use enough” rises in a new signup cohort, inspect onboarding. If technical cancellations rise after a release, inspect the release. If price objections rise in one plan, inspect that plan’s promise.
Keep the flow easy to complete. A long survey produces abandoned forms. Ask one required reason, offer one optional text field, and use the data with behavior you already have.
Do not use a discount as the default answer
A save offer is one intervention. It is not a retention strategy.
Discounting someone who selected a technical issue does not repair trust. Discounting someone who never reached value subsidizes a broken first experience. Discounting a subscriber with an expired card may be unnecessary if a clear payment-update path would recover them.
Use an offer when the reason and the cohort support it. A long-tenured subscriber who is price sensitive may respond to a pause, a lower-commitment plan, or an annual option. Test against a holdout, and check whether retained subscribers stay after the offer period ends.
A 30-day cancellation-reason routine
If the data is noisy, start small. This routine belongs on this page only. The restore and payment guides have different operating loops.
- Week one: consolidate the current reasons. Merge vague duplicates and add an optional text field. Map survey options onto Apple’s report reasons so Billing Issue does not sit in the same chart as Canceled.
- Week two: compare early cancellations with retained subscribers. Find the first behavior that separates them.
- Week three: choose one reason with enough volume to matter. Assign one owner and one experiment.
- Week four: review the cohort after the change. Keep the change only if the relevant behavior or renewal outcome moves.
The aim is not to eliminate cancellations. It is to stop treating preventable ones as inevitable.
The question to ask every week
Ask which cancellation pattern changed, for whom, and what you will do about it.
That question moves the team from a list of exit responses to an operating loop. Refix is built to sit on the product, subscription, and support events behind that question. Use it if you want that join in Slack. The work still starts with a reason that has an owner.
See how Refix helps teams find retention opportunities.
FAQ
- What are the most common subscription cancellation reasons?
- Apple reports six reasons in App Store Connect: Billing Issue, Price Increase Notice, Price Increase Consent, Canceled, Removed From Sale, and Other. An in-app survey then splits Canceled into patterns such as low use, price, a broken experience, or a better alternative. Those survey labels are yours to design. They are not Apple's table.
- How should you use cancellation reasons?
- Treat the selected reason as the start of a review. Check what the subscriber did before they cancelled, how much revenue the pattern represents, and which owner can change it. A reason without a next action is not yet useful.
- When is a discount the right response to a cancellation?
- When the cohort and the reason support it, such as a long-tenured subscriber who is price sensitive. A discount does not fix a broken first experience, a technical issue, or an expired card.
- How is a cancellation different from a failed payment?
- A cancellation is a choice to stop. A failed payment can end a subscription even when the customer did not choose to leave. Apple files that as Billing Issue. Track the two separately, and recover failed payments with retries and a payment-update path, not a cancellation survey.