Reconquérir les abonnés partis sur Google Play

Sur Google Play, un abonné qui part passe par deux étapes. D’abord, il résilie : le renouvellement s’arrête mais l’accès continue jusqu’à la fin de la période. Ensuite, l’abonnement expire. Google vous donne des outils différents pour chaque étape, certains dans votre appli et d’autres dans le Play Store lui-même, et un abonné qui revient peut passer par n’importe lequel.

Ce guide fait le tour de ces outils, montre comment cibler des offres vers les utilisateurs partis, et explique le travail côté backend nécessaire pour qu’un abonné qui revient soit rattaché au bon compte. Il s’en tient à la documentation de Google, principalement abonnements : gestion client, le cycle de vie des abonnements, les codes promo et la référence de la Google Play Developer API pour les offres d’abonnement (tous consultés en novembre 2026).

Les quatre chemins de retour

Le guide des abonnements de Google contient un tableau des options de « winback » par étape et par lieu. En résumé :

	Avant l’expiration, dans l’appli	Avant l’expiration, dans le Play Store	Après l’expiration, dans l’appli	Après l’expiration, dans le Play Store
Fonctionnalité	Nouvel achat in-app	Restauration	Nouvel achat in-app	Resubscribe
Parcours de paiement	Oui	Non	Oui	Oui
Nouveau purchase token	Oui	Non	Oui	Oui
Activé par défaut	Non	Oui, tous les développeurs doivent le prendre en charge	Non	Oui pour les applis sur Billing Library 2.0+, désactivable
Quand l’utilisateur paie	Même produit : fin de la période en cours	Fin de la période en cours	Immédiatement	Immédiatement

Avant l’expiration : la restauration

Tant qu’un abonnement résilié est encore actif, l’utilisateur peut toucher Resubscribe dans le centre des abonnements du Play Store. Google appelle cela une restauration : la résiliation est annulée, l’abonnement garde son purchase token et se renouvelle comme si de rien n’était. La prise en charge est obligatoire pour tous les développeurs. Votre backend reçoit SUBSCRIPTION_RESTARTED, et Google suggère d’enregistrer que l’abonnement va se renouveler et de cesser d’afficher les messages de restauration.

Depuis votre appli, vous pouvez faire la même chose avec un nouvel achat. Pour le même produit, le nouvel abonnement remplace l’ancien et garde la même date de renouvellement. Pour un autre produit ou un prix de reconquête, Google suggère une montée ou une descente de gamme avec le replacement mode WITHOUT_PRORATION, pour que l’utilisateur soit débité du nouveau prix à la date d’expiration d’origine.

Après l’expiration : Resubscribe dans le Play Store

Si c’est activé pour le forfait de base (le comportement par défaut pour les applis éligibles), l’utilisateur peut racheter le même abonnement depuis le Play Store. Le guide des abonnements de Google indique que cela fonctionne « jusqu’à un an après l’expiration » ; le guide du cycle de vie ajoute que le bouton peut ne pas apparaître pour diverses raisons, par exemple quand un abonnement a expiré il y a longtemps.

Cela crée un nouvel achat avec un nouveau token, fait en dehors de votre appli. Vous devez le traiter dans votre backend (voir plus bas), sinon l’utilisateur est automatiquement remboursé au bout de trois jours.

Après l’expiration : dans votre appli

Un utilisateur qui a toujours votre appli peut se réabonner par le parcours d’achat normal. Ici, c’est vous qui choisissez quoi montrer : l’offre habituelle, ou une offre à prix réduit.

Proposer une offre de reconquête

Le guide de Google parle d’un « winback SKU » : un produit ou une offre à tarif spécial pour les utilisateurs qui reviennent, affiché dans votre appli ou envoyé « en dehors de l’appli, par exemple par email ».

Avec les forfaits de base et les offres, une remise de reconquête est une offre sur un forfait de base. Chaque offre peut avoir jusqu’à deux phases (par exemple trois mois à prix réduit, puis le prix de base) et des prix par région : un prix fixe, une remise en valeur absolue, une remise relative, ou la gratuité.

Qui voit l’offre

Le ciblage des offres dans la référence de l’API prend en charge deux types de règles :

• Acquisition : l’utilisateur n’a jamais eu cet abonnement, ou aucun abonnement dans l’appli.
• Upgrade : l’utilisateur a actuellement cet abonnement ou un abonnement précis, éventuellement avec une période de facturation donnée, et éventuellement une seule fois par utilisateur.

Aucune règle ne dit « abonné parti ». La référence ajoute que ce sont les conditions que Play évalue, et que « les développeurs peuvent filtrer davantage ces offres eux-mêmes ». En pratique, une offre de reconquête est une offre que vous ne montrez qu’aux utilisateurs dont votre backend sait qu’ils sont partis, filtrée dans votre appli grâce aux tags d’offre (jusqu’à 20 par offre).

Les essais gratuits pour les utilisateurs qui reviennent

Deux détails du guide de Google :

• Un utilisateur qui se réabonne au même produit « n’est plus éligible aux essais gratuits ni au prix de lancement ». Votre interface ne doit pas en promettre.
• Si vous mettez un essai gratuit ou un prix de lancement sur un produit de reconquête, vérifiez que le réglage Allow one free trial per app de la Play Console n’exclut pas les utilisateurs qui reviennent.

Les codes promo

Les codes promo donnent un essai gratuit sur un abonnement. Google indique que les utilisateurs qui ont été abonnés mais ne le sont plus « restent éligibles à un essai gratuit via une promotion ». Les limites à connaître :

• Les codes promo donnent des essais gratuits, pas des abonnements gratuits.
• Un seul code promo par produit d’abonnement.
• Jusqu’à 10 000 codes à usage unique par trimestre et par produit d’abonnement ; les codes non utilisés ne sont pas reportés.
• Les codes personnalisés (partagés) ne peuvent être utilisés que par des utilisateurs qui ne se sont jamais abonnés : pour la reconquête, utilisez donc des codes à usage unique.
• Une promotion peut durer jusqu’à un an.

Amener les utilisateurs au bon endroit

Google recommande un lien dans les réglages de votre appli pour gérer les abonnements, et documente deux deep links :

• Tous les abonnements : https://play.google.com/store/account/subscriptions
• Un abonnement précis : la même URL avec ?sku= votre ID produit et &package= votre nom de package.

Le premier est celui que Google suggère « pour aider un utilisateur à restaurer un abonnement résilié ». Pour les utilisateurs dont l’abonnement a expiré, envoyez-les plutôt vers l’écran d’abonnement de votre appli, où vous pouvez afficher l’offre de reconquête.

Traiter un achat de retour

C’est là que beaucoup de reconquêtes échouent sans bruit.

1. Écoutez SUBSCRIPTION_PURCHASED. Une réinscription depuis le Play Store est un nouvel achat avec un nouveau token, fait en dehors de votre appli.
2. Appelez purchases.subscriptionsv2.get. Pour les réinscriptions depuis le Play Store, la réponse inclut outOfAppPurchaseContext, avec le purchase token de l’abonnement expiré et les ID de compte et de profil obfusqués de cet abonnement précédent, si vous les avez définis. Utilisez l’un ou l’autre pour retrouver l’utilisateur.
3. Accusez l’achat depuis votre backend dans les trois jours, même si l’utilisateur n’ouvre jamais l’appli. Sinon Google le rembourse et le révoque.
4. Pour les réinscriptions dans l’appli avant l’expiration, le nouvel achat porte un linkedPurchaseToken qui pointe vers l’ancien. Google vous demande d’invalider l’ancien token.

Un plan pratique

1. Suivez l’étape. Résilié mais actif (SUBSCRIPTION_CANCELED, expiration future), expiré (SUBSCRIPTION_EXPIRED), ou perdu pour cause de facturation après un account hold. Chacun demande un message différent.
2. Lisez pourquoi ils sont partis. Le canceledStateContext de la ressource d’abonnement vous dit si c’est l’utilisateur, le système ou vous qui avez résilié, et donne la réponse de l’utilisateur à l’enquête de résiliation s’il en a donné une. Voir l’enquête de résiliation de Google Play.
3. Avant l’expiration, un message dans l’appli avec la date de fin et un lien de restauration. Pas encore de remise.
4. Après l’expiration, une séquence étalée sur plusieurs semaines, adaptée à la raison : le coût reçoit l’offre de reconquête, « pas assez d’usage » reçoit des nouveautés et éventuellement un essai par code promo, les problèmes techniques reçoivent un point honnête sur la correction.
5. N’écrivez qu’à ceux qui vous ont donné leur adresse. Les notifications en temps réel de Play n’incluent pas l’adresse email de l’utilisateur. Il vous faut votre propre compte et l’ID de compte obfusqué défini à l’achat pour relier les deux.
6. Mesurez les retours avec les SUBSCRIPTION_PURCHASED rattachés à un utilisateur précédemment expiré, et vérifiez s’ils restent au-delà de la phase à prix réduit.

Le faire avec NoChurn

NoChurn lit vos notifications en temps réel pour les développeurs Google Play et l’état des abonnements : il sait donc qui a résilié, qui a expiré, qui a été perdu après un account hold, et ce qu’ils ont répondu à l’enquête de résiliation. Il envoie des emails de reconquête à J30, J60 et J90 selon cette raison, aux utilisateurs dont vous partagez l’email depuis votre appli, en les renvoyant vers votre appli ou vers Google Play. Google garde le parcours de paiement, le prix des offres et le paiement. Voir NoChurn + Google Play.