Google Play's cancellation survey and how to reduce Android cancellations

Android subscribers usually cancel in the Google Play Store, not in your app. Google runs that flow, and when the user completes it, Play can ask them why they are leaving. The answer is not lost: it is stored on the subscription, and you can read it from the Google Play Developer API. Combined with pause, plan changes and restore, it gives you more to work with than many developers realize.

This guide shows where the survey answer lives, what Google lets you offer before and after a cancellation, and how to build an in-app flow that keeps the cancel button one tap away. It is based on Google’s documentation: the subscription lifecycle, subscriptions: deep links and customer management, the RTDN reference and the Google Play Developer API reference for purchases.subscriptionsv2 (all accessed November 2026).

Where cancellations come from

Google’s lifecycle guide lists three sources:

• The user, from the Play subscriptions center.
• Automatically, when a subscription does not recover after account hold. The same guide says users who don’t accept an opt-in price increase before renewal are also unsubscribed automatically.
• You, through purchases.subscriptionsv2.cancel.

In every case, a regular auto-renewing subscription sends a SUBSCRIPTION_CANCELED notification, the state becomes SUBSCRIPTION_STATE_CANCELED, and expiryTime holds the date access should end. The user keeps access until then. Google warns that removing access to content the user is still entitled to violates its subscriptions policy.

Reading the cancel survey

After a SUBSCRIPTION_CANCELED notification, call purchases.subscriptionsv2.get with the purchase token. The response has a canceledStateContext with one of four branches:

Branch	Meaning
userInitiatedCancellation	The user canceled
systemInitiatedCancellation	Google canceled, for example because of a billing problem
developerInitiatedCancellation	You canceled
replacementCancellation	The subscription was replaced by a new one

For user cancellations, userInitiatedCancellation contains cancelTime and a cancelSurveyResult. The API reference describes the latter as “information provided by the user when they complete the subscription cancellation flow (cancellation reason survey).” The reason field takes one of these values:

Value	Meaning
CANCEL_SURVEY_REASON_NOT_ENOUGH_USAGE	Not enough usage of the subscription
CANCEL_SURVEY_REASON_TECHNICAL_ISSUES	Technical issues while using the app
CANCEL_SURVEY_REASON_COST_RELATED	Cost related issues
CANCEL_SURVEY_REASON_FOUND_BETTER_APP	The user found a better app
CANCEL_SURVEY_REASON_OTHERS	Other reasons, with the user’s free text in reasonUserInput
CANCEL_SURVEY_REASON_UNSPECIFIED	Unspecified

Three practical notes:

1. Read it at cancellation time. The canceledStateContext is present only while the subscription is canceled or expired, and the purchase token stops working 60 days after expiration. If the user restores, Google says all cancellation fields are cleared.
2. Expect gaps. You cannot assume every user answered. Plan for unspecified reasons.
3. Store the free text as untrusted data. It is whatever the user typed.

Five fixed reasons are coarse, but they map well to actions: cost, usage, quality, competition.

What Google lets you offer instead

Pause

Google’s lifecycle guide says all subscriptions have pause enabled by default (you can disable it in the Play Console). Users choose a pause length based on the billing period:

Billing period	Pause lengths
Weekly	1, 2, 3 or 4 weeks
Monthly, three-month, six-month, annual	1, 2 or 3 months

Google notes the lengths are subject to change. The pause starts at the end of the current period; during the pause the user has no access and does not pay; at the end, Google tries to renew. Your backend sees SUBSCRIPTION_PAUSE_SCHEDULE_CHANGED when the user schedules it, SUBSCRIPTION_PAUSED when it starts, and SUBSCRIPTION_RECOVERED when it resumes (or SUBSCRIPTION_ON_HOLD if the payment fails on resume). Google suggests providing a way to resume manually, through a deep link to Google Play.

For a user who cancels because they “won’t use it for a while”, a pause is often the honest answer.

Plan changes

You can let users change tier or billing period in your app, with an offer if you want (Google’s example is a discount on the first year when switching from monthly to annual). The replacement mode decides when the change applies and how unused time is credited. DEFERRED, for example, applies the change at the next renewal. A cheaper tier is a natural answer to COST_RELATED.

Restore

A canceled subscription that has not expired can be restored by the user from the Play Store subscriptions center with the Resubscribe button. Google requires all developers to support it. You receive SUBSCRIPTION_RESTARTED and the subscription renews as before.

Building an in-app cancel flow

Google’s subscriptions guide says your app should include a link on a settings screen to let users manage their subscriptions, and that you “can also provide an option for users to cancel in your app or on your website.” That gives you two designs.

Option A: your screen, then Play

1. “Manage subscription” in settings opens your screen.
2. One question: why do you want to cancel? Use reasons close to Google’s five, so the data lines up.
3. One relevant answer per reason: pause for low usage, cheaper plan for cost, a fix or a contact for technical issues.
4. A Continue to cancel button, always visible, that opens the deep link to the subscription’s page in Play: https://play.google.com/store/account/subscriptions?sku= your product ID &package= your package name. Google says users can manage payment methods there and access “cancellation, resubscription, and pause.”

Option B: cancel in your app

Your backend can cancel through purchases.subscriptionsv2.cancel. The cancellationType matters:

• USER_REQUESTED_STOP_RENEWALS: cancellation requested by the user; it only stops the next renewal and the subscription can be restored.
• DEVELOPER_REQUESTED_STOP_PAYMENTS: requested by the developer; it cannot be restored.

For a user who asked to cancel, use USER_REQUESTED_STOP_RENEWALS, so they keep access until the end of the period and can still change their mind in the Play Store. With this design, the “Cancel” button in your flow really cancels, in one tap, which is the cleanest way to respect click-to-cancel expectations. Google describes its survey answer as coming from Play’s own cancellation flow, so for cancellations made through your app, rely on the reason you collect yourself.

Either way: same visual weight for “Cancel” and for the offer, no confirmation loops, no “contact support to cancel.”

After a cancellation

Between SUBSCRIPTION_CANCELED and SUBSCRIPTION_EXPIRED, the user is still a subscriber.

• Google suggests showing a message in your app with the expiration date.
• Google also notes you can detect cancellations in real time and “send them push notifications or in-app messages to ask them to resubscribe.”
• Match the message to the survey reason, and send one, not five.
• After expiry, move to win-back: see how to win back lapsed subscribers on Google Play.

Measuring

Per month and per reason: cancellations (from SUBSCRIPTION_CANCELED with a user-initiated context), restores (SUBSCRIPTION_RESTARTED), pauses scheduled, plan changes, and the share that actually expired. Compare reasons across app versions: a jump in TECHNICAL_ISSUES after a release is a bug report.

Doing this with NoChurn

NoChurn reads the cancel survey answer from Google Play with every cancellation and puts it on the customer’s timeline, next to the reasons collected in your own flow. Its cancel flow is available as a headless API for your Android app: reasons, one offer (discount, pause or plan change), and a cancel button that is always visible and opens Google Play’s subscription page. Google keeps payments, retries and its own cancel button. Reasons then drive win-back emails and the churn score. See NoChurn + Google Play.