Je connais deux équipes qui gèrent la même application et qui ont annoncé des taux de remboursement de 3.1% et 5.8% pour le même mois. Aucune des deux ne mentait. Elles avaient simplement défini la métrique différemment, et personne n'avait écrit cette définition noir sur blanc.
Voilà ce que personne ne mentionne sur une page de fonctionnalités à propos de l'analyse des remboursements d'applications mobiles. Le chiffre n'est fiable que si la règle d'attribution qui le sous-tend l'est aussi, et la plupart des dashboards ne précisent pas quelle règle ils utilisent.
Cet article présente donc ce que font ces outils, ainsi que l'unique question de méthodologie à poser avant de faire confiance à l'un d'eux. Pour la seule mécanique de suivi, comment suivre les remboursements sur l'App Store approfondit le sujet côté Apple.
Points clés
L'attribution par cohorte est préférable à l'attribution par période. Comptabilisez le remboursement par rapport au mois où l'achat a eu lieu, pas au mois où il a été réglé.
Le délai de remboursement se compte en semaines, parfois une période de facturation entière. Tout dashboard affichant le taux du mois en cours affiche un taux incomplet.
Les rétrofacturations ne sont pas des remboursements. RevenueCat précise clairement qu'elle n'en compte pas une comme un remboursement, il vous faut donc un flux séparé.
Les consoles des stores sont gratuites mais peu efficaces pour les tendances. Apple vous donne des rapports, Google une API avec un plafond quotidien.
Les meilleurs outils pour suivre les taux de remboursement des applications mobiles sont ceux qui publient leur dénominateur.
D'abord, le problème de définition
Il existe deux façons de suivre le taux de remboursement d'une application, et elles ne s'accordent pas.
Méthode par période : les remboursements arrivés en mars, divisés par les transactions facturées en mars. Facile à mettre en place. Fausse, car un remboursement de mars appartient souvent à un achat de janvier.
Méthode par cohorte : sur tout ce qui a été facturé en janvier, quelle part a été remboursée depuis. Plus difficile, car le chiffre ne cesse jamais de bouger.
Apphud documente cela honnêtement. Leur dénominateur est constitué des transactions facturées pendant la période, le numérateur correspond au nombre remboursé ultérieurement, y compris après la clôture. C'est l'approche par cohorte, et elle correspond au comportement réel des remboursements.
Il vous faut donc un seuil de coupure. Les abonnements mensuels se stabilisent autour de 30 à 45 jours, les plans annuels dérivent pendant des mois. Comparer un chiffre de 10 jours à un chiffre de 90 jours, c'est comparer du bruit.
Le niveau gratuit : les consoles des stores
Commencez par là. Ça ne coûte rien, et c'est là que la plupart des équipes s'arrêtent.
App Store Connect. Sales and Trends ainsi que les Financial Reports vous donneront les remboursements, et le rapport financier correspond à votre versement. C'est basé sur la période, manuel, et il n'y a aucune segmentation par produit ou canal. Correct pour une vérification mensuelle de routine. Inutile pour trouver quel paywall saigne.
Le meilleur flux gratuit ne se trouve pas du tout dans la console. L'endpoint Get Refund History d'Apple renvoie une liste paginée de chaque transaction remboursée par client, que vous pouvez importer dans votre propre entrepôt de données. Il est limité en débit, et Apple recommande les notifications plutôt que le polling, donc traitez-le comme un outil de rapprochement.
Google Play Console. Les rapports financiers à nouveau, plus l'API Voided Purchases, qui liste les achats remboursés, rétrofacturés ou révoqués sur une période donnée. Plafonnée à 6,000 appels par jour et 30 par 30 secondes, elle est donc conçue pour des récupérations planifiées, pas pour du temps réel.
Les deux consoles partagent une faiblesse pour l'analyse des tendances. Elles rapportent ce qui a été réglé, pas ce qui a été demandé, donc vous ne voyez jamais les demandes que vous avez défendues.
RevenueCat
Si vos abonnements passent déjà par cet outil, c'est la réponse par défaut.
Le taux de remboursement est une de leurs métriques de référence : la part des abonnements payants remboursés pendant leur première période de facturation, comparée aux applications de votre store et de votre catégorie. Ce benchmarking est la partie utile, car un taux brut sans contexte comparatif est difficile à exploiter. Leur rapport State of Subscription Apps couvre 75,000-plus applications et situe les médianes autour de 3% à 5%.
Il existe aussi un graphique App Store Refund Requests qui répartit les demandes accordées, refusées, annulées et en attente de résolution. C'est un niveau de détail par demande, que la plupart des outils ignorent.
Deux réserves. Les remboursements Play accordés par Google plutôt que par vous peuvent prendre jusqu'à 24 heures pour apparaître, et les remboursements émis sans que la case de révocation soit cochée ne sont tout simplement pas détectés. De plus, RevenueCat ne compte pas les rétrofacturations comme des remboursements. Le statut de l'achat est mis à jour, mais le taux de remboursement ne bouge pas.
Adapty
Plus solide que la plupart des autres en matière de segmentation. Le suivi des remboursements se décompose par jour, plan, produit et canal d'acquisition, ce qui est précisément la découpe qui permet de repérer les problèmes. Un taux qui semble correct globalement mais catastrophique sur un canal révèle un bug de messaging, pas un bug produit.
Leurs benchmarks s'appuient sur $1.9 milliard de revenus suivis sur 11,000-plus applications, et l'écart entre catégories est assez important pour compter : éducation et santé autour de 4.7% à 5.1%, voyage et utilitaires plus proche de 1.5% à 2.1%. Les plans annuels se font plus rembourser que les hebdomadaires. Les paywalls durs tournent autour de 5.8% contre 3.4% pour le freemium.
Le hic est le même qu'ailleurs dans leur produit : les bonnes analyses supposent que vous utilisez le SDK Adapty.
Apphud
Plus petit, moins cher, et d'une clarté méthodologique inhabituelle, ce qui suffirait à le placer sur ma shortlist. Leur documentation détaille la logique de cohorte au lieu de la masquer. Dashboards en temps réel, environ 18 événements d'abonnement, moins de marketing que les alternatives.
Si vous voulez un chiffre que vous pouvez défendre en comité de direction, la clarté vaut mieux qu'une liste de fonctionnalités plus longue.
Un suivi dédié des remboursements et des rétrofacturations
Voilà le vide. Les plateformes d'abonnement comptent les remboursements réglés. Aucune ne se situe à l'intérieur de la fenêtre de réponse, donc aucune ne peut vous dire combien de demandes vous avez défendues, ni votre taux de réussite par motif de remboursement.
C'est un ensemble de données différent, qui n'existe que si quelque chose répond réellement aux demandes. Refund Sensor suit les demandes de remboursement Apple et les examens de rétrofacturation Google Play comme des dossiers, avec chronologies, résultats et revenus défendus, les deux stores réunis dans un seul dashboard. Il montre les demandes qui ne sont jamais devenues des remboursements.
À associer, pas à remplacer. Une plateforme d'abonnement pour les analyses par cohorte, un logiciel de protection des revenus d'applications mobiles pour les tendances au niveau des demandes. Des questions différentes, et aucune des deux ne couvre l'autre.
Suivre les rétrofacturations séparément
Les tendances de rétrofacturation ne sont pas un sous-ensemble des tendances de remboursement, et les traiter comme telles est l'erreur la plus fréquente que je constate dans le suivi des remboursements pour applications mobiles.
Sur Google Play, les signaux diffèrent. Les notifications développeur en temps réel envoient une voidedPurchaseNotification quand quelque chose est annulé, et une pendingRefundReviewNotification quand une rétrofacturation nécessite votre intervention. L'API Voided Purchases comporte un champ voidedReason avec neuf valeurs, incluant fraud, friendly_fraud et chargeback. C'est ce qui se rapproche le plus d'une courbe de tendance de rétrofacturation gratuite.
Chez Apple, c'est une notification REFUND avec un motif de révocation, plus REFUND_DECLINED et REFUND_REVERSED pour les cas qui n'ont pas tenu.
Pour une tendance de rétrofacturation honnête, tracez voidedReason égal à chargeback dans le temps, découpé par produit. Puis tracez fraud et friendly_fraud séparément, car ces comptes récidivent et nécessitent une réponse différente. Nous avons détaillé ce que fait chaque flux dans Voided Purchases API versus real-time developer notifications.
Comment suivre les taux de remboursement et les rétrofacturations dans les applications mobiles
La pile technique que je construirais vraiment, dans l'ordre :
Choisissez une règle d'attribution et écrivez-la : cohorte, avec un seuil de coupure défini selon la durée du plan.
Connectez les flux des stores. App Store Server Notifications V2, et RTDN sur Play. Sans eux, vous lisez des CSV mensuels.
Stockez chaque événement de remboursement en le rattachant à la transaction d'origine, pas à la date du jour.
Ajoutez les événements au niveau des demandes, sinon vous ne verrez jamais ce que vous avez empêché.
Séparez les rétrofacturations avec leurs propres codes de motif.
Comparez-vous à votre catégorie, pas à une moyenne globale.
L'étape 3 est celle où les configurations maison se cassent silencieusement, et l'étape 6 est celle où les dashboards trompent silencieusement. Ni l'une ni l'autre n'est difficile. Les deux sont pourtant souvent sautées.
Pour l'aspect coût plutôt que l'aspect taux, comment les remboursements coûtent réellement à vos revenus d'application fait ce calcul. Un taux seul ne vous dit pas quoi faire ensuite.
Sources
Questions fréquentes
RevenueCat si vous voulez des benchmarks par catégorie et des graphiques Apple au niveau des demandes. Adapty si vous avez besoin d'une segmentation par canal et par plan. Apphud si vous voulez la méthodologie la plus clairement publiée. Ajoutez un outil de défense si vous voulez aussi voir les demandes qui ne sont jamais devenues des remboursements.
Les transactions remboursées divisées par les transactions payantes, rattachées à la période où l'achat a eu lieu. Ensuite, décidez combien de temps vous laissez une cohorte mûrir avant de considérer le chiffre comme définitif. Pour les plans mensuels, 30 à 45 jours. Pour les plans annuels, plus longtemps.
Entre 2% et 5% des transactions payantes pour les applications d'abonnement. Les catégories éducation, santé et fitness affichent des taux plus élevés, voyage et utilitaires plus bas. Au-delà de 10%, arrêtez de regarder le marketing et allez relire votre paywall.
Pas vraiment. Les rapports financiers d'Apple affichent les remboursements réglés. L'API Voided Purchases de Google affiche les achats annulés avec un code de raison, ce qui s'en rapproche le plus, mais elle est limitée à 6,000 appels par jour et nécessite une récupération planifiée.
C'est presque toujours un décalage d'attribution. Les rapports de revenus sont basés sur une période, les taux de remboursement devraient être basés sur une cohorte, et les deux ne convergent qu'une fois que tous les remboursements sont arrivés. Vérifiez aussi si les rétrofacturations sont incluses, car certains outils les excluent.
Apple ne publie aucun seuil, et je me méfierais de quiconque en cite un avec assurance. Ce qui est documenté, c'est que des taux de remboursement et de litige constamment élevés peuvent affecter la réputation du compte sur Google Play. C'est une raison plus solide de suivre la tendance que le taux lui-même.
