La première fois que j'ai audité une application pour des revenus perdus, j'ai failli conclure que tout allait bien. Le taux de remboursement était de 2.4%, un bon chiffre selon tous les repères du secteur. L'équipe répondait aux demandes de consommation dans le délai imposé par Apple. Sur le papier, rien à récupérer.
J'ai alors lancé une requête supplémentaire, surtout par entêtement. Combien de personnes détenaient encore un droit d'accès payant sur une transaction déjà remboursée par Apple ? Quarante et un. Sur une application comptant environ 900 abonnés payants. J'ai relancé la requête deux fois parce que je ne croyais pas le résultat.
Cela représente près de 5% de la base qui utilisait le produit gratuitement, mois après mois, tandis que le dashboard restait au vert. Et le taux de remboursement n'a jamais bougé. J'ai détaillé cette correction des droits d'accès séparément dans comment reprendre l'accès après un remboursement.
Si vous essayez de comprendre comment récupérer des revenus d'abonnement perdus à cause des remboursements App Store, commencez par là, car le remboursement n'est que le plus petit des quatre endroits où votre argent disparaît réellement. Voici le tableau complet.
Les quatre catégories, classées selon leur valeur
Je vois cela comme quatre catégories, et le classement entre effort et bénéfice n'est pas celui que la plupart des gens imaginent.
La fuite : les utilisateurs remboursés qui n'ont jamais perdu l'accès. La correction la moins coûteuse, et la plus souvent négligée.
La défense : répondre aux demandes de consommation d'Apple avec des preuves. La catégorie dont parle chaque prestataire, puisque c'est celle que les logiciels peuvent automatiser.
La reconquête (win-back) : ré-acquérir les personnes qui ont été remboursées ou qui se sont désabonnées. La plus lente à rentabiliser. Apple l'a discrètement facilitée cette année.
La relance : les échecs de facturation qui se résolvent d'eux-mêmes si vous n'interférez pas.
La plupart des équipes ne travaillent que sur la deuxième catégorie. Les surprises se trouvent dans la première et la troisième.
Catégorie 1 : trouvez la fuite, cela prend une heure
Voici la requête, en gros. Prenez toutes les transactions avec une date de révocation dans les 12 derniers mois, croisez-les avec votre table des droits d'accès, et comptez qui apparaît encore comme ayant un accès actif.
Si la réponse est zéro, vraiment, passez cette section. Mais si elle ne l'est pas, vous venez de trouver des revenus d'abonnement qui s'échappent chaque mois jusqu'à ce que quelque chose les coupe. Apple annule son paiement. Apple ne touche pas à votre base de données. Les deux restent déconnectés jusqu'à ce que vous les reliiez vous-même. Les consommables sont pires : une fois l'article dépensé, StoreKit n'a plus rien à récupérer.
(J'ai moi-même fait cette erreur pendant des mois. Le gestionnaire de notifications enregistrait les événements REFUND dans une table que personne ne consultait. Enregistrer n'est pas traiter.)
La correction : écouter l'événement REFUND, révoquer à la date de révocation, et traiter REFUND_REVERSED en rétablissant l'accès. Apple annule parfois lui-même ses remboursements, après une contestation du client, et il ne faut pas pénaliser le client pour cela.
Une dernière requête tant que vous y êtes. Comptez les remboursements pour lesquels vous n'avez jamais reçu la moindre notification serveur. Si ce chiffre n'est pas nul, votre endpoint est défaillant, et la deuxième catégorie l'est aussi.
Catégorie 2 : défendez les demandes que vous pouvez encore influencer
Apple vous accorde environ 12 heures après un CONSUMPTION_REQUEST pour envoyer les données de consommation. Trois champs obligatoires, deux facultatifs, une préférence, et cela couvre désormais tous les types de produits, pas seulement les consommables.
Mon conseil ici sera bref, car cette catégorie est traitée en long et en large ailleurs. Répondez à chaque demande. Refusez celles où le produit a clairement été livré et beaucoup utilisé. Acceptez les véritables accidents. Une concession de bonne foi coûte peu. Contester chaque remboursement, en revanche, coûte cher, car Apple pondère son évaluation selon votre historique.
La dépendance que personne ne mentionne, c'est la preuve. Vous ne pouvez défendre que ce que vous pouvez prouver. Si personne ne peut répondre à « combien ont-ils réellement utilisé » pour un achat datant de sept semaines, aucune automatisation ne vous sauvera. C'est une lacune de modélisation des données à combler, quel que soit le prestataire.
Côté coûts, comment les remboursements affectent réellement les revenus de votre application fait le calcul, en incluant les dépenses d'acquisition derrière chaque utilisateur remboursé.
Catégorie 3 : reconquérir l'abonné
C'est ici que la protection des revenus d'abonnement cesse d'être défensive. Et c'est le domaine qu'Apple a remanié en votre faveur au cours de l'année écoulée.
Les offres de reconquête (win-back). Nouveauté depuis la WWDC24, iOS 18 et versions ultérieures. Vous les configurez par produit d'abonnement dans App Store Connect et définissez l'éligibilité : durée payée minimale, temps écoulé depuis le dernier abonnement, un délai de 2 à 24 mois entre les offres. Apple s'occupe ensuite de la diffusion. Elles apparaissent sur la page de gestion des abonnements du client, sur votre page produit, dans les recommandations personnalisées, et parfois dans des emplacements éditoriaux de l'onglet Aujourd'hui.
Relisez bien cette phrase. Apple affiche votre réduction à un abonné perdu, à un endroit que vous n'auriez jamais pu atteindre par e-mail. Limites : 350 offres par abonnement, 5 actives par storefront. Dans l'application, StoreKit déclenche un message winBackOffer quand quelqu'un devient éligible, et eligibleWinBackOfferIDs dans les informations de renouvellement indique ce qu'il peut utiliser. Le guide de configuration des offres de reconquête d'Apple détaille les champs d'éligibilité.
Les offres promotionnelles. Jusqu'à 10 par abonnement, disponibles depuis iOS 12.2, et elles nécessitent une signature JWS provenant de votre serveur. Plus de travail que les offres de reconquête. Mais vous contrôlez entièrement le ciblage, ce qui compte lorsque les motifs de remboursement révèlent quelque chose de précis, par exemple un problème de tarification dans un pays donné.
Les codes d'offre. Utilisables dans l'application ou en dehors. Ce sont donc le seul moyen réaliste d'atteindre quelqu'un qui a été remboursé puis a désinstallé l'application. Tous les autres, vous pouvez les atteindre dans l'application. Ces personnes-là, non.
Prolonger la date de renouvellement d'un abonnement. La plus sous-estimée, je trouve. L'API serveur d'Apple vous permet de repousser la date de renouvellement d'un abonné, pour une transaction ou en masse. Nous l'utilisons comme geste commercial après de mauvaises versions : quelqu'un contacte le support à propos d'un bug de facturation, vous prolongez d'un mois, cela ne coûte presque rien et c'est plus efficace que n'importe quel coupon. Un remboursement évité vaut mieux qu'un remboursement reconquis.
Une exception. Si quelqu'un a été remboursé à cause d'une surprise de facturation plutôt qu'à cause du produit lui-même, ne le relancez pas avec une réduction. Corrigez d'abord le texte de votre paywall, puis laissez-le le redécouvrir par lui-même. La gestion des remboursements App Store couvre cet aspect opérationnel.
Catégorie 4 : le désabonnement qui se résout tout seul
Apple relance les paiements échoués pendant jusqu'à 60 jours, ou jusqu'à ce que le client corrige sa carte ou annule. Si l'abonnement se renouvelle dans cette fenêtre, le service payant se poursuit à partir de la date de récupération.
Donc, une partie de ce qui ressemble à des revenus d'abonnement perdus ne l'a jamais vraiment été. C'était simplement en attente. Deux choses peuvent casser cela : une période de grâce que vous n'avez jamais activée, et un e-mail de relance qui, en substance, incite les gens à annuler. Vérifiez les deux avant de dépenser de l'argent dans des outils de rétention.
Mesurer tout cela sans se raconter d'histoires
Gérer les remboursements sans attribution par cohorte produit des conclusions assurées mais erronées.
Attribuez chaque remboursement à la période de l'achat d'origine, pas à celle où le remboursement a eu lieu. Laissez ensuite la cohorte mûrir. Trente à 45 jours pour les forfaits mensuels, plus longtemps pour les forfaits annuels, car les demandes de remboursement peuvent arriver des mois plus tard.
C'est aussi là que le suivi des remboursements d'abonnement devient difficile, et que la plupart des dashboards trichent discrètement. Une offre de reconquête acceptée en novembre appartient à la cohorte qui s'est désabonnée en août. Si votre reporting ne relie pas ces éléments, votre chiffre de récupération est fictif.
Suivez quatre chiffres, pas un seul.
Taux de remboursement par cohorte.
Demandes traitées dans le délai imparti.
Revenus défendus, répartis par motif de remboursement.
Fuites de droits d'accès en cours, qui devraient tendre vers zéro et y rester.
Si je ne pouvais en placer qu'un seul sur un dashboard, ce serait le nombre de fuites. C'est le seul chiffre qui est sans ambiguïté anormal dès qu'il n'est pas nul.
Où se situe réellement le logiciel
Les catégories deux et quatre s'automatisent proprement. La première s'automatise une fois, puis nécessite simplement une surveillance. La troisième relève de la configuration et du jugement, et aucun outil ne fait ce jugement à votre place.
Refund Sensor gère le volet défense sur les deux stores, en répondant à chaque demande éligible dans le délai imparti avec des preuves de transaction, et en suivant ce que vous avez conservé. Il ne reconquerra personne et ne corrigera pas un paywall confus. Rien ne fait cela à votre place, à part vous.
Sources
Questions fréquentes
Quatre pistes, dans l'ordre où je les testerais. Repérez les utilisateurs qui conservent l'accès sur une transaction remboursée et coupez-le. Répondez à chaque demande de consommation dans les 12 heures. Reconquérez les abonnés perdus grâce aux offres de reconquête (win-back) ou promotionnelles. Vérifiez ensuite les relances de facturation et les périodes de grâce, car certains désabonnements n'ont jamais été définitifs.
Pas directement, non. Apple annule parfois lui-même un remboursement après une contestation du client et envoie alors une notification REFUND_REVERSED. Quand elle arrive, rétablissez l'accès. C'est une récupération que vous n'avez pas eu à négocier.
Elles ciblent les abonnés inactifs qui ont désactivé le renouvellement automatique, et l'éligibilité dépend de la durée payée ainsi que du temps écoulé depuis le dernier abonnement. Un abonnement remboursé compte comme inactif, donc en général oui. Configurez tout de même les règles et vérifiez.
La requête sur les droits d'accès (entitlements). Une heure de travail, sans prestataire, sans nouvelle version de l'application. Sur chaque application où je l'ai testée, le résultat n'était jamais nul.
Plus que le montant du remboursement. Les taux habituels se situent entre 2% et 5% des transactions payantes. Le coût réel inclut les dépenses d'acquisition liées à cet utilisateur, la fuite de droits d'accès si vous avez manqué la notification, et la LTV surestimée qui vous fait payer trop cher le prochain.
Non. Corriger la fuite ne coûte rien, c'est un bug. Le logiciel répond aux demandes auxquelles vous ne répondez pas, ce qui est un vrai problème, mais pas le premier à traiter.
