Analyse des métriques d'abonnement : comment calculer le MRR, le taux de désabonnement, l'ARPPU, etc.

Oh doux MRR! L'étalon de progrès d'un métier SaaS / abonnement / abonnement / revenus récurrents.

Parlez au propriétaire ou au responsable marketing de toute entreprise d'abonnement et ils vous diront que leur MRR n'augmente pas comme prévu, ou parleront avec éloquence de leur MRR phénoménal et de la croissance des bâtons de hockey dont ils ont été témoins.

Certains peuvent continuer à décrire leurs taux de désabonnement et leurs ratios rapides. Leur plan d'action de relance, d'e-mails de récupération et d'engagement continu des utilisateurs pour réduire le taux de désabonnement de 50 points de base.

Bon, arrêtons.

Si vous êtes dans une entreprise de facturation récurrente, vous connaissez certainement la situation. Si ce n'est pas le cas, vous souhaiterez probablement migrer vers un système d'abonnement.

Alors, quelles sont ces mesures d'abonnement ? Que veut dire tout ce jargon ?

Nous avons des explications détaillées sur ces métriques SaaS / abonnement / business récurrent. Pour l'instant, permettez-moi de vous donner un aperçu rapide.

L'explication la plus simple des mesures commerciales d'abonnement sur Internet

• MRR, ARR : revenus récurrents mensuels et taux d'exécution annuel. Concrètement, combien gagnez-vous par mois ?
  Les abonnements qui ne se reproduisent pas à intervalles mensuels sont « convertis » en abonnements mensuels. Par exemple, le montant de l'abonnement annuel est divisé par 12, ou l'abonnement hebdomadaire peut être multiplié par 4,33, etc.
• Churn : Ce que vous perdez chaque mois : revenus, clients, nombre d'abonnements. Généralement exprimé en pourcentage du MRR.
• Commutateurs : Les gens changent leurs plans d'abonnement. Vous souhaitez suivre les mises à niveau et les rétrogradations. Les mises à niveau étendent le MRR, les rétrogradations le contractent.
• Essais : nombre d'essais, pourcentage de conversion des essais en payants. L'essai peut être considéré comme un plan de produit, et vous pouvez le considérer comme une « mise à niveau » lorsque les gens passent à un plan payant. Mais il mérite d'être mesuré à lui seul.
• ARPU, ARPPU, ARPA : revenu moyen par utilisateur (ou par utilisateur payant ou par compte). Il s'agit essentiellement du MRR divisé par le nombre de clients (ou le nombre de clients payants lorsque vous avez des essais gratuits). Dans certaines situations, vous souhaiterez peut-être combiner tous les utilisateurs d'une organisation et comptabiliser leur revenu total en tant que revenu moyen par compte.
• CLTV, LTV : Valeur à vie d'un client. Dans la plupart des cas, les gens inversent leur taux de désabonnement pour arriver au nombre moyen de mois pendant lesquels un client reste actif. Multipliez ensuite cela par ARPU pour arriver à LTV.
• CAC : Coût d'acquisition d'un client. Il s'agit souvent d'une mesure interne, car les systèmes de reporting ne tiennent pas compte des coûts. La comparaison de CAC avec LTV vous indique la rentabilité d'un client au cours de sa vie. Un seuil de rentabilité plus rapide signifie une meilleure évolutivité et de meilleures valorisations !
• Quick Ratio : Combien d'argent vous ajoutez par mois, divisé par combien d'argent vous perdez. Indique rapidement si vous flottez ou coulez !
  La formule serait (Nouveau MRR + Expansion MRR) / (Contraction MRR + Barattage MRR).
  Vous pouvez même mesurer les abonnements en fonction de leur statut - Nouveau, Actif, Réactivé, Baratté, Annulé, Suspendu, etc.
  Une autre mesure importante est les « frais échoués ». Les cartes de crédit expirent tout le temps et à mesure que votre clientèle grandit, le nombre de tentatives de paiement infructueuses augmentera.
• Dunning : C'est un processus d'évitement et de récupération de ces échecs. Une bonne solution de relance peut facilement ajouter 10 à 20 % à vos revenus.
• Remboursements : de nombreuses personnes n'incluent pas les remboursements dans le taux de désabonnement, car il s'agit plutôt d'un changement de flux de trésorerie. Si un remboursement annule un abonnement, cela sera compté comme désabonnement.
• Flux de trésorerie : l'argent est sain d'esprit, d'autres sont de la vanité. Garder un œil sur les flux de trésorerie est essentiel pour les entreprises.
  Répartition par produit et par variante de toutes ces métriques. Que vous appeliez vos produits d'abonnement "plans" ou autre chose, il serait certainement utile de suivre les numéros importants pour chaque produit.

En dehors de tout cela, vous pouvez également comparer ces mesures avec des données historiques pour voir les tendances et même obtenir des prévisions pour la planification future.

Peux-tu le croire? Mon explication simple était-elle si longue ?

Mesurer et calculer le MRR et d'autres métriques - une solution simple mais complète

Je vais parler ici des bases de données et des requêtes. Si vous n'êtes pas dans la programmation ou les bases de données, ne vous inquiétez pas. Je vais le garder aussi simple que possible.

Mais c'est utile si vous les comprenez. Ce sont des maths à la fin de la journée, et ces maths trop simples.

C'est le l'approche la plus complète et la plus simple que nous ayons trouvée. Vous verrez bientôt l'élégance de la solution.

Très bien, plongeons dedans.

Partie 1 : Stocker les informations importantes

Tout d'abord, je suppose que vous stockez les informations de transaction d'abonnement dans des tables MySQL - ou similaires. Ainsi, chaque fois que vous recevez un nouvel abonnement, que vous recevez un paiement ou que quelque chose change dans son statut - annulation, expiration, défaut de facturation, etc. - nous aurons une entrée dans ce tableau.

Étant donné que vous consignez tous les événements dans l'abonnement, ce tableau s'agrandira au fil du temps.

Calculer le MRR à partir de ce tableau n'est pas une bonne idée.

Comment calculer le MRR ?

Créons une nouvelle table pour stocker uniquement les événements "significatifs". Choses qui changent matériellement l'abonnement. Inscription, mise à niveau ou rétrogradation, expiration, passage de l'essai au paiement, etc.

Nous devons également stocker les identifiants de produit et de variation dans le tableau afin de pouvoir calculer le MRR (et d'autres mesures) jusqu'au niveau de variation.

Nous devons également stocker l'identifiant du client afin de pouvoir calculer des mesures même au niveau du client. N'oubliez pas qu'ils peuvent avoir plusieurs abonnements actifs !

Voici un extrait de ce tableau.

2018-07-25123john@domainputlergrowthupdated10079USD

En anglais simple,

• John s'est inscrit pour un essai le 10 juillet. Converti en un forfait payant de 79 $/mois le 25.
• Mise à niveau vers un plan supérieur de 249 $/m le 15 août.
• D'une manière ou d'une autre, il ne voulait pas continuer, alors il a annulé le 10 décembre.
• Mais comme son abonnement mensuel a été payé jusqu'au 14 du mois, il a utilisé le produit jusqu'au 14, et le 15, il a expiré.
• Faire chuter notre MRR de 249 $ à 0.

Ajoutons quelques entrées supplémentaires à ce tableau pour d'autres utilisateurs, puis commençons à calculer nos métriques.

• Nous avons gagné deux autres clients ici - Annie et Mark.
• Annie a commencé avec un essai de Putler Starter, mis à niveau vers un forfait payant dès le lendemain.
• Finalement, elle a également acheté un autre produit, la formule 10x, à 99 $/m, qui n'a pas eu d'essai.
• Mark s'est inscrit à un essai, a commencé à payer 79 $/mois après 20 jours.
• Finalement, il est passé à un plan inférieur, avec un paiement annuel (29 $/m, mais 290 $/an), ramenant le MRR à 290 $/12 = 24,17 $.

Partie 2 : Calculer le MRR, les essais à payer, le taux de désabonnement et plus encore…

Calculons différentes métriques au 20 décembre 2018.
Trouver MRR est le plus simple !

Vous pouvez vous demander pourquoi déduire old_mrr de new_mrr ? Et si vous n'êtes pas familier avec les requêtes SQL, le bit SUM peut vous dérouter.

Pensez-y un peu. Prenez un stylo et du papier, calculez les différences et additionnez-les.

Calculez ensuite le MRR à différentes dates avec cette logique.

Vraiment, prenez un peu de temps et réfléchissez-y. Une fois que vous aurez bien compris cela, tout le reste sera simple.

…

Fait?

D'accord.

Comment calculer le churn ?

Cela vous indique la perte de MRR due au taux de désabonnement et le nombre d'abonnements qui ont été générés.

Pas trop difficile non ?

Comment calculer les essais à payer ?

Regardons quelque chose d'un peu plus complexe.

Ouah! Vous avez accompli beaucoup de choses jusqu'à présent !

Permettez-moi de vous dire rapidement comment trouver d'autres KPI.

• Commutateurs : lorsque le type d'événement est "mis à jour" et que le nouveau MRR est supérieur à l'ancien MRR, il s'agit d'une mise à niveau. Dans le cas contraire, rétrogradez.
  De la même manière, tous les nouveaux MRR + mises à niveau = expansion dans MRR. All churn + downgrades = contraction du MRR.
• Abonnements actifs : identifiants d'abonnement uniques, à l'exclusion des essais annulés ou non convertis.
• Revenu moyen par utilisateur payant : MRR divisé par le nombre d'abonnements actifs. (Si vous voulez des "utilisateurs" et non des "abonnements", vous pouvez choisir le nombre de clients uniques avec des abonnements actifs.)

Vous obtenez l'image!

Alors pourquoi diable j'appelle cette boîte de Pandore ???

Qui est Pandore ? Et qu'y a-t-il dans sa boîte ?

Pandore est un personnage de la mythologie grecque.

Prométhée a volé le feu du ciel, en guise de punition, Zeus (le roi des dieux) a présenté Pandore au frère de Prométhée, Épiméthée.

Un pot a été laissé aux soins de Pandore, et elle l'a ouvert - seulement pour libérer la maladie, la mort et bien d'autres maux dans le monde. Elle a rapidement fermé le conteneur et Hope a été laissée pour compte.

Aujourd'hui, l'idiome « ouvrir une boîte de Pandore » signifie faire ou commencer quelque chose qui cause de nombreux problèmes importants et inattendus. Son sens est similaire à "ouvrir une boîte de Pandore".

Le calcul des métriques commerciales d'abonnement devient de plus en plus difficile à mesure que vous essayez de le rendre de plus en plus précis.

Les métriques sont une mesure du progrès. Les gens planifient leurs actions futures en fonction de ce que rapportent les métriques. Il est donc très important d'avoir des mesures correctes.

Si votre calcul montre un MRR de 12 000 $, mais que vous avez oublié d'en déduire les annulations, cela ne fonctionnera pas.

Si vous faites une erreur dans le calcul des métriques, vous finirez par prendre de mauvaises décisions.

Très bien, nous convenons donc que des mesures précises sont essentielles. Mais comment cela devient-il de plus en plus complexe ??

Voici comment les rapports sur les revenus des abonnements deviennent vraiment complexes !

Pour vous dire la vérité, nous avons évité de créer des rapports d'abonnement dans Putler - notre solution d'analyse de commerce électronique - pendant très longtemps. Nos premières tentatives ont rapidement échoué.

Enfin, nous avons construit une solution qui gère toutes les complications et les cas extrêmes.

Finalement, cela s'est également avéré insuffisant. C'est à ce moment-là que nous avons tout reconstruit sur la base de l'approche que j'ai décrite ci-dessus.

Je vous en dirai un peu plus sur Putler plus tard, mais voici un liste des problèmes majeurs que nous avons observés lors de la création de solutions d'analyse/de métrique SaaS.

• Aucune méthode universellement acceptée de calcul de toutes ces métriques : différentes solutions de reporting ont différentes méthodes de calcul. Donc, si vous comparez vos données avec quelqu'un d'autre, vous pouvez voir des incohérences.
• Garbage In, Garbage Out: Si le journal de toutes les transactions est incomplet ou incohérent, notre table d'événements d'abonnement aura des entrées insuffisantes. Par exemple, si vous créez des données d'événements d'abonnement à partir des transactions des deux dernières années, vous risquez de manquer des événements critiques qui se sont produits avant cette période. Ou si votre passerelle de paiement / système de commerce électronique fixe la même date pour la création et le premier paiement - ou toute autre incohérence - les mesures seront erronées.
• Les systèmes de commerce électronique et les API des passerelles de paiement changent : ils peuvent modifier le type de données qu'ils fournissent. Cela signifie deux choses : premièrement, vous devez constamment mettre à jour votre logique – ce qui est toujours correct ; mais deuxièmement, les anciennes données peuvent être dans un ancien format, les nouvelles données dans une nouvelle norme. Dans un tel cas, vous devrez normaliser et tout ramener au même format !
• Nouveaux événements d'abonnement : chaque fois qu'un nouvel événement d'abonnement se produit, vous devez vérifier et mettre à jour le tableau si nécessaire. La plupart des passerelles n'indiquent pas les mises à niveau / rétrogradations. Beaucoup n'indiquent pas d'informations sur les essais. Nous devons donc identifier intelligemment ces modèles.
• Devises multiples : si vous acceptez des paiements dans différentes devises, vous devez rechercher les taux de change et tout convertir dans une devise de « base ». Cela peut être un défi en soi.
• Plusieurs passerelles de paiement / systèmes de commerce électronique : si vous acceptez à la fois Stripe et PayPal pour les paiements, le type d'informations qu'ils fournissent ultérieurement sur une transaction est différent. Par exemple , l'API PayPal ne fournit pas d'intervalles d'abonnement ni de date de fin. Dans de tels cas, nous devons construire une méthode « floue » de détection des abonnements et de leurs détails. Il est extrêmement difficile de consolider ces différences entre les passerelles et d'unifier les données.
  Nous avons déjà prévu des métriques de niveau de produit et de variation. Mais les noms de produits/plans changent tout le temps. Pour plus de précision, nous devons construire un système pour fusionner/regrouper les produits.
• Inexactitude des données Systèmes de commerce électronique : Lorsque vous utilisez un système de commerce électronique, il se peut qu'il ne dispose pas des données les plus précises. Vous devez établir une corrélation avec les passerelles de paiement pour confirmer. Ce processus de déduplication est intensif.

Vous souhaitez suivre vos statistiques de revenus récurrents ? Voici vos options…

C'est une bonne analogie. Si vous ne suivez pas vos indicateurs de performance clés, vous ne savez pas où vous allez. (Et BTW, si vous n'avez pas lu Crossing the Chasm, lisez-le quand vous en aurez l'occasion.)

Tout homme d'affaires sérieux connaît l'importance du suivi des mesures clés. Et les outils d'analyse et de reporting ne manquent pas.

Mais d'abord : ne commettez pas l'erreur d'utiliser une feuille de calcul Excel (ou Google !) pour suivre les métriques et les KPI de votre abonnement SaaS. Il n'évoluera pas.

Quelles sont donc vos options?

Chaque système de commerce électronique a une sorte de système de rapport intégré. Il en va de même pour chaque passerelle de paiement. Vous pouvez commencer par eux.

Même les solutions d'analyse à usage général telles que Google Analytics et Mixpanel permettent de suivre les revenus du commerce électronique. Vous pouvez les utiliser, mais vous n'obtiendrez pas les KPI d'abonnement dont nous avons discuté - MRR / Churn etc…

Compte tenu de la croissance du SaaS et du business model récurrent, des dizaines de startups ont lancé des solutions spécialisées dans les métriques SaaS. Il existe de nombreuses options, en particulier lorsque vous utilisez Stripe. ChartMogul, Control, ProfitWell, Compass, Statsbot, Supermetrics… – la liste est longue. Beaucoup de ces solutions fonctionnent également avec d'autres passerelles de paiement.

Ensuite, il y a Baremetrics - l'affiche de l'analyse commerciale par abonnement. C'est un excellent produit, qui existe depuis de nombreuses années et qui a fait de nombreuses améliorations ces derniers temps. Et tous les autres les ont copiés.

Même nous avons copié Baremetrics lorsque nous avons construit l'analyse des revenus d'abonnement dans Putler.

Oui, Putler vous offre toute la gamme des rapports d'activité récurrents.

Encore confus? Pour simplifier les choses, voici un article qui compare différents logiciels de facturation d'abonnements.

Notre expérience dans l'offre d'une plate-forme d'analyse des revenus des entreprises de commerce électronique et d'abonnement

Putler a commencé comme un simple outil de suivi des ventes PayPal en 2010. Il est resté une application de bureau pendant de nombreuses années et a gagné des milliers d'utilisateurs. Nous avons réorganisé l'ensemble du système et l'avons porté sur le Web en 2016.

Regardez le tableau de bord d'abonnement de Putler

Putler est une plate-forme d'analyse de commerce électronique significative et l'une des meilleures du marché.

Pourquoi?

Principalement à cause de nos formidables clients. Nous avons construit Putler avec les commentaires continus des clients. Nous avons résolu de vrais problèmes pour les gens.

Putler fait ce que la plupart des autres solutions d'analyse ne font pas.

Voici comment Putler se compare aux concurrents

Alors, quelle est la meilleure solution pour l'analyse et le reporting SaaS/abonnement ?

Il existe de nombreuses bonnes solutions. Quelques populaires aussi. Certains sont gratuits, d'autres facturent des frais élevés.

Voici quelques questions que vous pouvez poser pour découvrir la meilleure solution pour vos besoins.

• Est-ce que ça marche uniquement avec Stripe ? Ou une passerelle ou un système de commerce électronique spécifique ? Si c'est le cas, cela pourrait vous limiter à l'avenir.
  Même si vous utilisez la passerelle pour laquelle le système est conçu, cela fonctionnera-t-il dans votre cas ? Par exemple, certaines solutions nécessitent des plans/produits définis au niveau Stripe/passerelle. Si vous utilisez un système de commerce électronique - comme WooCommerce - et utilisez Stripe uniquement pour les paiements, la plupart des solutions ne fonctionneront pas.
• La solution peut-elle gérer les paiements non récurrents ? Même pour le SaaS, chaque dollar n'est pas récurrent. Vous avez besoin de quelque chose qui peut tout gérer.
• La plate-forme a-t-elle une intégration prête avec votre système de paiement/e-commerce ? Tout le monde a une API, mais utiliser une API pour remplir vos données peut être une tâche ardue.
• Vous donne-t-il la plupart (sinon la totalité) des mesures que vous souhaitez suivre ? Peut-il extraire des données d'autres systèmes, comme Google Analytics, pour vous donner une meilleure compréhension de votre entreprise ?
• Comment le système gère-t-il les complexités que nous avons décrites précédemment ? Changements de système, changements de plan, remboursements, devises multiples, etc. ?
• Avez-vous plusieurs passerelles de paiement / entreprises / sites Web ? Si oui, la solution peut-elle les regrouper avec précision en un seul endroit ?
• Pouvez-vous donner un accès restreint aux membres de votre équipe ? À l'équipe de marketing ou de support client ?
• S'agit-il simplement d'un outil de reporting ou va-t-il au-delà ? Enrichit-il les profils clients ? Peut-il envoyer des rapports par e-mail ? Peut-il gérer les relances / les échecs de facturation ?
• Quel est le prix? Même s'il est gratuit, combien de temps et d'efforts devrez-vous consacrer pour le faire fonctionner ? Comment les ventes incitatives premium sont-elles proposées ?
• Est-il facile à utiliser? Obtenez-vous les informations dont vous avez besoin sans trop sauter ici et là ?
• La plateforme survivra-t-elle ? Ou va-t-il se perdre au cours des prochaines années ?

Était-ce beaucoup plus de questions que prévu ?

Mais je pense qu'il est important d'examiner tous ces aspects.

Qu'est-ce que tu penses?

Essayez-les. Alors décidez.

Équitable?