Comment Luseri calcule le MRR, le churn et la rétention

Ce que Luseri lit chez Shopify

Tout vient de la Partner API de Shopify, l'interface qui donne accès aux données de ton compte Partner, en lecture seule, par un client d'API (un accès que tu crées toi-même) réservé à Luseri (voir comment ces accès sont protégés). Trois sortes de données sont lues :

• Les événements de l'application, dans le champ events de ton application : installations et désinstallations (avec la raison et le commentaire laissés par le marchand), désactivations et réactivations de boutiques, abonnements activés, résiliés, expirés, gelés et dégelés, frais d'usage, achats ponctuels et avoirs. Chaque événement de facturation porte son identifiant, son nom, son montant, sa devise, sa prochaine date de prélèvement (billingOn) et son indicateur de test.
• Les versements, par la requête transactions quand ton client d'API a la permission « View financials » (voir les finances) : ventes d'abonnements, frais d'usage, achats ponctuels, ajustements et avoirs, chacun avec son montant brut, son montant net, la commission de Shopify et, pour un abonnement, sa durée de facturation (EVERY_30_DAYS, tous les 30 jours, ou ANNUAL, annuelle).
• Sans « View financials », les mêmes versements viennent de l'historique des événements de ton organisation (la requête racine events, événements Earning), qui ne demande que « Manage apps » (gérer les applications). Cette voie ne donne pas la durée de facturation.

La première synchronisation recopie tout l'historique de ton application. Les suivantes repartent du dernier événement connu, moins six heures, au cas où Shopify publierait un événement en retard. Les chiffres se mettent à jour quand tu ouvres le tableau de bord s'ils ont plus d'une heure, quand tu le demandes, et une fois par jour en arrière-plan. Les autres types d'événements, comme un paiement accepté ou refusé, sont gardés mais ne changent aucun chiffre. Ce que Luseri garde, et combien de temps, est dans sa politique de confidentialité.

Comment le MRR est construit

1. Regrouper les événements par boutique et rejouer ceux de chaque boutique dans l'ordre du temps. Des événements arrivés au même instant suivent un ordre fixe, de l'installation à la désinstallation.
2. Garder l'abonnement en cours de chaque boutique et son état : en essai, payant ou suspendu.
3. Ramener le montant de l'abonnement au mois : un forfait annuel est divisé par 12, tout autre forfait est pris tel quel.
4. Le MRR d'un jour est la somme de ces montants mensuels pour chaque abonnement payant à la fin de ce jour. Le tableau de bord garde 730 jours de valeurs quotidiennes ; l'historique plus ancien fixe quand même le niveau de départ.

Le MRR laisse de côté les essais gratuits jusqu'à leur premier paiement, les frais d'usage et les achats ponctuels (comptés seulement dans le revenu encaissé), les abonnements de test (tout événement dont l'abonnement porte test: true est ignoré), et les avoirs que tu accordes à une boutique, qui apparaissent dans l'historique de cette boutique.

Forfaits annuels. Un abonnement compte comme annuel dès qu'un versement lu par la requête transactions donne sa durée de facturation comme ANNUAL ; son montant est alors divisé par 12. Tant que ce versement n'a pas été lu, et toujours sans « View financials », un forfait annuel compte à son prix entier, comme s'il était mensuel, et une remarque le dit dans les réglages. Si tu vends des forfaits annuels, coche « View financials » sur ton client d'API.

Remises. Luseri n'applique aucune remise de lui-même et ne lit pas les champs de remise de Shopify : le MRR prend le montant que Shopify donne sur l'abonnement, et la documentation de la Partner API ne dit pas si une remise en est déduite. Le revenu encaissé, lu dans les versements, est ce que les marchands ont réellement payé.

Devises. Le MRR est dans la devise de tes forfaits, celle qui revient le plus souvent sur tes abonnements. Le revenu encaissé est dans la devise de tes versements, celle qui revient le plus souvent sur tes versements. Les deux ne sont jamais additionnés et rien n'est converti. Si tes forfaits, ou tes versements, mélangent plusieurs devises, les montants sont additionnés tels quels et les réglages préviennent que les totaux sont approximatifs.

Ce qui fait bouger le MRR, événement par événement

Chaque mouvement est daté du jour où il arrive. Dans la page Revenus, les nouveaux abonnés, les montées en gamme et les retours d'anciens abonnés sont au-dessus de la ligne, les baisses de forfait et les résiliations en dessous, avec le solde de la période.

Essais. Les événements de Shopify ne disent pas qu'un abonnement est en essai : Luseri le déduit de la prochaine date de prélèvement. Un abonnement dont le billingOn tombe plus de 12 heures après son activation est en essai gratuit jusqu'à cette date, quelle que soit sa durée. À cette date, si l'abonnement est toujours là, son premier paiement est compté, et l'historique de la boutique le marque comme une fin d'essai calculée. Changer de forfait pendant l'essai ne démarre pas un nouvel essai. Un essai qui se termine par une résiliation ou une désinstallation avant cette date n'entre jamais dans le MRR, ni dans le revenu perdu en résiliations : il apparaît comme un essai arrêté avant le premier paiement.

Le revenu encaissé et les frais de Shopify

Le revenu encaissé additionne le montant brut de chaque versement, au jour où Shopify l'a enregistré ; Shopify définit ce montant comme ce que le marchand a payé, hors taxes. Il se répartit entre abonnements (ajustements, avoirs et remboursements compris), frais d'usage et achats ponctuels. La commission de Shopify sur chaque vente est montrée à part, sous « Frais prélevés par Shopify ». Un remboursement lu par la voie des événements Earning compte toujours en négatif.

Quand aucun versement ne peut être lu, le revenu encaissé est estimé à partir des abonnements : chaque abonnement payant compte comme facturé tous les 30 jours depuis son premier paiement, plus les frais d'usage et les achats ponctuels trouvés dans les événements. Cette estimation est dans la devise de tes forfaits, les frais de Shopify ne sont pas connus, et les réglages le disent.

La page Revenus estime aussi ton prochain versement : le revenu brut des 15 derniers jours moins les frais de Shopify. Ce que Shopify garde sur chaque paiement est expliqué dans la part de revenu de Shopify.

Abonnés, installations et taux de départ

Chaque indicateur ci-dessous est calculé jour par jour à partir du rejeu. Un taux se lit au dernier jour de la période choisie ; un total, comme les désinstallations ou le revenu perdu, s'additionne sur la période.

Le churn de revenu (la part du revenu récurrent perdue) laisse donc de côté les baisses de forfait, alors que comment mesurer le churn d'une application Shopify les ajoute à la perte ; ajoute le mouvement « Baisses de forfait » pour obtenir cette version. Un abonnement que Shopify gèle compte comme perdu le jour du gel, et revient comme un retour d'ancien abonné si Shopify le dégèle.

La rétention par cohorte d'installation

Une cohorte est l'ensemble des boutiques dont la première installation tombe dans le même mois du calendrier (en temps universel, UTC). La grille couvre les 12 derniers mois : pour chaque mois suivant, une case donne la part de la cohorte qui a l'application installée le premier jour de ce mois.

• Seule la première installation place une boutique dans une cohorte. Une boutique qui a désinstallé puis réinstallé compte comme restée si l'application est installée le jour du relevé.
• Le mois 1 se lit le premier jour du mois suivant : une boutique installée le dernier jour d'un mois est relevée dès le lendemain.
• Une boutique que Shopify signale comme désactivée garde son installation : elle compte comme restée tant qu'elle n'a pas désinstallé.
• C'est la rétention des installations, que la boutique paie ou non. Les boutiques payantes perdues apparaissent dans les taux de départ ci-dessus.
• Les trois chiffres de tête, « Encore installée après 1 mois », « après 3 mois » et « après 6 mois », sont la moyenne simple des cohortes assez anciennes pour avoir cet âge, sans tenir compte de leur taille. Le nombre de boutiques derrière chaque chiffre est affiché dessous.

Délai avant le départ : pour les désinstallations des 365 derniers jours, le temps écoulé depuis la dernière installation de la boutique, en six tranches (moins d'1 h, 1 à 24 h, 2 à 7 jours, 8 à 30 jours, 1 à 3 mois, plus de 3 mois). La part des départs en moins de 24 heures est affichée sous « Départs dès le premier jour ».

Les raisons de désinstallation

Shopify donne la raison sous forme de liste séparée par des virgules, plus un commentaire facultatif. Chaque raison est rangée sous un libellé simple : Trop cher, Je testais seulement, Je ne m'en sers plus, Je n'en ai plus besoin, Il manque une fonction, Trop compliqué à configurer, Passé à une autre application, Problème technique, Assistance insuffisante ou Boutique fermée ou en pause. « Autre » devient « Autre raison », une raison vide devient « Sans réponse », et un texte qui ne correspond à aucun libellé apparaît sur sa propre ligne.

Une raison écrite dans une autre langue est traduite par Claude, le modèle d'IA de la société Anthropic, et rejoint un libellé quand sa traduction en est un. Une raison qui parle de la fermeture ou de la mise en pause de la boutique, et la raison scheduled_cancellation de Shopify, sont rangées sous « Boutique fermée ou en pause ».

Les parts portent sur les 365 derniers jours. Un marchand qui donne deux raisons compte une fois dans chacune, et chaque part est celle de cette raison parmi toutes les raisons données. Le commentaire n'entre jamais dans les parts. Il est gardé avec la désinstallation et affiché après la raison dans l'historique de la boutique et dans le flux d'événements, traduit s'il a été écrit dans une autre langue. Ce que chaque raison veut dire en général est dans pourquoi les marchands désinstallent ton application.

Les cas particuliers

• Boutiques fermées : RELATIONSHIP_DEACTIVATED retire aussi la boutique des installations actives jusqu'à RELATIONSHIP_REACTIVATED ; un abonnement gelé, seul, ne le fait pas. Un essai gelé avant sa fin reprend comme un essai, et si sa fin est passée entre-temps, le premier paiement est compté le jour du dégel.
• Boutiques de développement (les boutiques de test des développeurs) : rien dans les événements de l'application ne permet de les reconnaître, donc leurs installations comptent dans les installations, les installations actives et les cohortes comme celles des autres boutiques. Les abonnements de test sont écartés, quelle que soit la boutique.
• Fermetures de boutique programmées : depuis avril 2026, quand la fermeture d'une boutique programmée par le marchand prend effet, Shopify désinstalle les applications de la boutique avec la raison scheduled_cancellation, selon un membre de l'équipe Shopify sur le forum des développeurs. Luseri les range sous leur propre raison, Boutique fermée ou en pause, pour qu'elles ne passent pas pour un jugement sur ton application. Elles comptent quand même dans les désinstallations, dans le taux de désinstallation et dans les cohortes comme les autres, et le MRR d'une boutique payante part en résiliation.
• Changements de forfait : Shopify résilie l'ancien abonnement quand le nouveau est activé. Une résiliation suivie dans les 10 minutes de l'activation d'un autre abonnement est lue comme un changement de forfait, et la résiliation d'un abonnement qui n'est plus celui en cours est ignorée.
• Une désinstallation sans installation connue, quand l'historique commence après l'installation, compte comme une désinstallation sans faire baisser les installations actives.

Pourquoi les chiffres diffèrent de ceux de Shopify

Les tableaux de bord de Shopify ne comptent pas la même chose, ni au même moment. La comparaison complète du Dev Dashboard et du tableau de bord Partner est dans Dev Dashboard et tableau de bord Partner.

Le moment diffère aussi : le MRR bouge le jour où un abonnement commence ou s'arrête, alors qu'un versement n'apparaît qu'une fois que le marchand a payé Shopify.

Ce qui a été vérifié, et ce qui ne l'a pas été

Luseri a d'abord tourné sur OptiDress, l'application de son auteur, avant de s'ouvrir aux autres développeurs : les revenus et les installations qu'il affichait ont été comparés aux chiffres de Shopify pour cette application (voir qui fait Luseri). Le 20 octobre 2026, sur la même application, les versements lus sans « View financials » ont été comparés à ceux lus avec : mêmes versements, mêmes dates, mêmes montants bruts et mêmes frais de Shopify.

C'est un seul vrai compte. Au 21 octobre 2026, les forfaits annuels et les forfaits ou versements en plusieurs devises n'ont pas été vérifiés sur un vrai compte, et la vitesse du calcul n'a été mesurée que sur des comptes simulés, jusqu'à 63 000 boutiques.

Trois règles sont la lecture que Luseri fait des événements, parce que la documentation de Shopify ne les tranche pas : l'écart de 12 heures qui signale un essai, la fenêtre de 10 minutes qui signale un changement de forfait, et le fait de compter un abonnement gelé comme perdu jusqu'à son dégel. Si un de tes chiffres te paraît faux, écris à l'adresse donnée sur qui fait Luseri. Le sens de chaque mot est dans le glossaire des métriques d'une application Shopify, et la méthode générale, hors outil, dans comment calculer le MRR d'une application Shopify.