L’enquête de résiliation de Google Play et comment réduire les résiliations Android

Les abonnés Android résilient en général dans le Google Play Store, pas dans votre appli. C’est Google qui gère ce parcours, et quand l’utilisateur le termine, Play peut lui demander pourquoi il part. La réponse n’est pas perdue : elle est enregistrée sur l’abonnement, et vous pouvez la lire depuis la Google Play Developer API. Combinée à la pause, aux changements d’offre et à la restauration, elle vous donne plus de leviers que beaucoup de développeurs ne le pensent.

Ce guide montre où se trouve la réponse à l’enquête, ce que Google vous permet de proposer avant et après une résiliation, et comment construire un parcours dans l’appli qui garde le bouton de résiliation à un geste. Il s’appuie sur la documentation de Google : le cycle de vie des abonnements, abonnements : deep links et gestion client, la référence RTDN et la référence de la Google Play Developer API pour purchases.subscriptionsv2 (tous consultés en novembre 2026).

D’où viennent les résiliations

Le guide du cycle de vie de Google en liste trois sources :

• L’utilisateur, depuis le centre des abonnements de Play.
• Automatiquement, quand un abonnement ne se rétablit pas après l’account hold. Le même guide indique que les utilisateurs qui n’acceptent pas une hausse de prix soumise à leur accord avant le renouvellement sont aussi désabonnés automatiquement.
• Vous, via purchases.subscriptionsv2.cancel.

Dans tous les cas, un abonnement classique à renouvellement automatique envoie une notification SUBSCRIPTION_CANCELED, l’état devient SUBSCRIPTION_STATE_CANCELED, et expiryTime contient la date à laquelle l’accès doit prendre fin. L’utilisateur garde l’accès jusque-là. Google prévient que retirer l’accès à un contenu auquel l’utilisateur a encore droit enfreint son règlement sur les abonnements.

Lire l’enquête de résiliation

Après une notification SUBSCRIPTION_CANCELED, appelez purchases.subscriptionsv2.get avec le purchase token. La réponse contient un canceledStateContext avec l’une de quatre branches :

Branche	Signification
userInitiatedCancellation	L’utilisateur a résilié
systemInitiatedCancellation	Google a résilié, par exemple à cause d’un problème de facturation
developerInitiatedCancellation	Vous avez résilié
replacementCancellation	L’abonnement a été remplacé par un nouveau

Pour les résiliations par l’utilisateur, userInitiatedCancellation contient cancelTime et un cancelSurveyResult. La référence de l’API décrit ce dernier comme « les informations fournies par l’utilisateur quand il termine le parcours de résiliation de l’abonnement (enquête sur la raison de la résiliation) ». Le champ reason prend l’une de ces valeurs :

Valeur	Signification
CANCEL_SURVEY_REASON_NOT_ENOUGH_USAGE	Pas assez d’usage de l’abonnement
CANCEL_SURVEY_REASON_TECHNICAL_ISSUES	Problèmes techniques en utilisant l’appli
CANCEL_SURVEY_REASON_COST_RELATED	Problèmes liés au coût
CANCEL_SURVEY_REASON_FOUND_BETTER_APP	L’utilisateur a trouvé une meilleure appli
CANCEL_SURVEY_REASON_OTHERS	Autres raisons, avec le texte libre de l’utilisateur dans reasonUserInput
CANCEL_SURVEY_REASON_UNSPECIFIED	Non précisé

Trois remarques pratiques :

1. Lisez-la au moment de la résiliation. Le canceledStateContext n’est présent que tant que l’abonnement est résilié ou expiré, et le purchase token cesse de fonctionner 60 jours après l’expiration. Si l’utilisateur restaure son abonnement, Google indique que tous les champs de résiliation sont effacés.
2. Attendez-vous à des trous. Vous ne pouvez pas supposer que chaque utilisateur a répondu. Prévoyez des raisons non précisées.
3. Stockez le texte libre comme une donnée non fiable. C’est ce que l’utilisateur a tapé, quoi que ce soit.

Cinq raisons fixes, c’est grossier, mais elles correspondent bien à des actions : coût, usage, qualité, concurrence.

Ce que Google vous permet de proposer à la place

La pause

Le guide du cycle de vie de Google indique que tous les abonnements ont la pause activée par défaut (vous pouvez la désactiver dans la Play Console). Les utilisateurs choisissent une durée de pause selon la période de facturation :

Période de facturation	Durées de pause
Hebdomadaire	1, 2, 3 ou 4 semaines
Mensuelle, trimestrielle, semestrielle, annuelle	1, 2 ou 3 mois

Google précise que ces durées peuvent changer. La pause commence à la fin de la période en cours ; pendant la pause, l’utilisateur n’a pas accès et ne paie pas ; à la fin, Google tente de renouveler. Votre backend voit SUBSCRIPTION_PAUSE_SCHEDULE_CHANGED quand l’utilisateur la programme, SUBSCRIPTION_PAUSED quand elle commence, et SUBSCRIPTION_RECOVERED quand l’abonnement reprend (ou SUBSCRIPTION_ON_HOLD si le paiement échoue à la reprise). Google suggère de proposer un moyen de reprendre manuellement, via un deep link vers Google Play.

Pour un utilisateur qui résilie parce qu’il « ne l’utilisera pas pendant un moment », la pause est souvent la réponse honnête.

Les changements d’offre

Vous pouvez permettre aux utilisateurs de changer de niveau ou de période de facturation dans votre appli, avec une offre si vous le souhaitez (l’exemple de Google est une remise sur la première année en passant du mensuel à l’annuel). Le replacement mode détermine quand le changement s’applique et comment le temps non utilisé est crédité. DEFERRED, par exemple, applique le changement au prochain renouvellement. Un niveau moins cher est une réponse naturelle à COST_RELATED.

La restauration

Un abonnement résilié qui n’a pas encore expiré peut être restauré par l’utilisateur depuis le centre des abonnements du Play Store, avec le bouton Resubscribe. Google exige que tous les développeurs le prennent en charge. Vous recevez SUBSCRIPTION_RESTARTED et l’abonnement se renouvelle comme avant.

Construire un parcours d’annulation dans l’appli

Le guide des abonnements de Google indique que votre appli doit inclure, sur un écran de réglages, un lien permettant aux utilisateurs de gérer leurs abonnements, et que vous « pouvez aussi proposer aux utilisateurs une option pour résilier dans votre appli ou sur votre site ». Cela vous donne deux conceptions possibles.

Option A : votre écran, puis Play

1. « Gérer l’abonnement » dans les réglages ouvre votre écran.
2. Une question : pourquoi voulez-vous résilier ? Utilisez des raisons proches des cinq de Google, pour que les données concordent.
3. Une réponse pertinente par raison : la pause pour un usage faible, une offre moins chère pour le coût, une correction ou un contact pour les problèmes techniques.
4. Un bouton Continuer la résiliation, toujours visible, qui ouvre le deep link vers la page de l’abonnement dans Play : https://play.google.com/store/account/subscriptions?sku= votre ID produit &package= votre nom de package. Google indique que les utilisateurs peuvent y gérer leurs moyens de paiement et accéder à « la résiliation, la réinscription et la pause ».

Option B : résilier dans votre appli

Votre backend peut résilier via purchases.subscriptionsv2.cancel. Le cancellationType compte :

• USER_REQUESTED_STOP_RENEWALS : résiliation demandée par l’utilisateur ; elle arrête seulement le prochain renouvellement et l’abonnement peut être restauré.
• DEVELOPER_REQUESTED_STOP_PAYMENTS : demandée par le développeur ; elle ne peut pas être restaurée.

Pour un utilisateur qui a demandé à résilier, utilisez USER_REQUESTED_STOP_RENEWALS, pour qu’il garde l’accès jusqu’à la fin de la période et puisse encore changer d’avis dans le Play Store. Avec cette conception, le bouton « Résilier » de votre parcours résilie vraiment, en un geste, ce qui est la façon la plus propre de respecter les attentes du click-to-cancel. Google décrit la réponse à son enquête comme venant du propre parcours de résiliation de Play : pour les résiliations faites via votre appli, appuyez-vous donc sur la raison que vous recueillez vous-même.

Dans les deux cas : même poids visuel pour « Résilier » et pour l’offre, pas de boucles de confirmation, pas de « contactez le support pour résilier ».

Après une résiliation

Entre SUBSCRIPTION_CANCELED et SUBSCRIPTION_EXPIRED, l’utilisateur est toujours abonné.

• Google suggère d’afficher un message dans votre appli avec la date d’expiration.
• Google note aussi que vous pouvez détecter les résiliations en temps réel et « leur envoyer des notifications push ou des messages dans l’appli pour leur demander de se réabonner ».
• Adaptez le message à la raison donnée dans l’enquête, et envoyez-en un, pas cinq.
• Après l’expiration, passez à la reconquête : voir comment reconquérir les abonnés partis sur Google Play.

Mesurer

Par mois et par raison : les résiliations (depuis SUBSCRIPTION_CANCELED avec un contexte initié par l’utilisateur), les restaurations (SUBSCRIPTION_RESTARTED), les pauses programmées, les changements d’offre, et la part qui a réellement expiré. Comparez les raisons d’une version de l’appli à l’autre : un bond de TECHNICAL_ISSUES après une mise à jour, c’est un rapport de bug.

Le faire avec NoChurn

NoChurn lit la réponse à l’enquête de résiliation de Google Play à chaque résiliation et la place dans la chronologie du client, à côté des raisons recueillies dans votre propre parcours. Son parcours d’annulation est disponible en API headless pour votre appli Android : raisons, une offre (remise, pause ou changement d’offre), et un bouton de résiliation toujours visible qui ouvre la page d’abonnement de Google Play. Google garde les paiements, les relances et son propre bouton de résiliation. Les raisons pilotent ensuite les emails de reconquête et le score de churn. Voir NoChurn + Google Play.