Analiza valorilor abonamentului: Cum se calculează MRR, rata de pierdere, ARPPU și multe altele

O, dragă MRR! Etalonul progresului pentru o afacere SaaS / abonament / abonament / venituri recurente.

Discutați cu proprietarul sau cu șeful de marketing al oricărei afaceri cu abonament și ei vor discuta despre cum MRR-ul lor nu crește așa cum se aștepta, sau vor vorbi elocvent despre MRR-ul lor fenomenal și despre creșterea bastonului de hochei la care au fost martori.

Unii pot continua să-și descrie ratele de abandon și ratele rapide. Planul lor de acțiune de solicitare, e-mailuri de recuperare și implicare continuă a utilizatorilor pentru a reduce rata de pierdere cu 50 de puncte de bază.

Bine, hai să ne oprim.

Dacă sunteți într-o afacere cu facturare recurentă, cu siguranță cunoașteți situația. Dacă nu sunteți, cel mai probabil doriți să migrați la un sistem de abonament.

Deci, care sunt aceste valori pentru abonament? Ce înseamnă tot jargonul ăsta?

Avem explicații aprofundate pentru aceste valori SaaS / abonament / afaceri recurente. Deocamdată, permiteți-mi să vă fac o scurtă trecere în jos.

Cea mai simplă explicație a valorilor de afaceri abonamentului de pe Internet

• MRR, ARR: Venitul lunar recurent și rata anuală de rulare. În esență, câți bani câștigați pe lună?
  Abonamentele care nu se repetă la intervale lunare, sunt „convertite” în lunar. De exemplu, valoarea abonamentului anual este împărțită la 12 sau abonamentul săptămânal poate fi înmulțit cu 4,33 etc.
• Churn: ceea ce pierzi în fiecare lună – venituri, clienți, număr de abonamente. De obicei notat ca procent din MRR.
• Comutatoare: oamenii își schimbă planurile de abonament. Doriți să urmăriți upgrade-urile și downgrade-urile. Upgrade-urile extind MRR-urile, downgrade-urile îl contractează.
• Încercări: numărul de încercări, procentul de conversie a încercărilor în plătit.. Proba poate fi considerată un plan de produs și o puteți considera un „upgrade” atunci când oamenii trec la un plan plătit. Dar merită măsurat de la sine.
• ARPU, ARPPU, ARPA: Venitul mediu per utilizator (sau per utilizator plătit sau per cont). Acesta este în esență MRR împărțit la numărul de clienți (sau numărul de clienți plătiți atunci când aveți teste gratuite). În unele situații, este posibil să doriți să combinați toți utilizatorii dintr-o organizație și să contabilizați veniturile lor totale ca Venit mediu per cont.
• CLTV, LTV: Valoarea pe viață a unui client. În cele mai multe cazuri, oamenii își inversează rata de abandon pentru a ajunge la numărul mediu de luni în care un client rămâne activ. Apoi înmulțiți asta cu ARPU pentru a ajunge la LTV.
• CAC: Costul de achiziție a unui client. Aceasta este adesea o măsură internă, deoarece sistemele de raportare în sine nu țin cont de costuri. Compararea CAC cu LTV vă spune cât de profitabil este un client de-a lungul vieții. Punct de rentabilitate mai rapid înseamnă o scalabilitate mai bună și evaluări mai bune!
• Raport rapid: Câți bani adăugați pe lună, împărțit la câți bani pierdeți. Indică rapid dacă plutiți sau vă scufundați!
  Formula ar fi (MRR nou + MRR de extindere) / (MRR de contracție + MRR de extindere).
  Este posibil să doriți chiar să măsurați abonamentele în funcție de starea lor - Nou, Activ, Reactivat, Schimbat, Anulat, Suspendat etc.
  O altă măsură importantă este „Taxele eșuate”. Cardurile de credit expiră tot timpul și, pe măsură ce baza dvs. de clienți crește, numărul încercărilor de încărcare eșuate va crește.
• Dunning: Este un proces de evitare și de recuperare după aceste eșecuri. O soluție bună de reclamare poate adăuga cu ușurință 10-20% la venitul dvs.
• Rambursări: Mulți oameni nu includ rambursări în pierdere, deoarece este mai mult o modificare a fluxului de numerar. Dacă o rambursare anulează un abonament, aceasta va fi considerată renunțare.
• Fluxul de numerar: numerarul este sănătos, alții sunt vanitate. Urmărirea fluxului de numerar este esențială pentru afaceri.
  Defalcarea înțeleaptă a produselor și a variantelor a tuturor acestor valori. Indiferent dacă numiți produsele cu abonament „planuri” sau orice altceva, cu siguranță ar ajuta să urmăriți numerele importante pentru fiecare produs.

În afară de toate acestea, poate doriți să comparați aceste valori cu datele istorice pentru a vedea tendințele și chiar pentru a obține previziuni pentru planificarea viitoare.

Poți să-l crezi? Explicația mea simplă a fost atât de lungă?

Măsurarea și calcularea MRR și a altor valori – soluție simplă, dar cuprinzătoare

Voi vorbi aici despre baze de date și interogări. Dacă nu sunteți pasionați de programare sau baze de date, nu vă faceți griji. O voi păstra cât se poate de simplă.

Dar este util dacă le înțelegi. Este matematică la sfârșitul zilei și acea matematică prea simplă.

Acesta este cea mai cuprinzătoare, dar totuși ușoară abordare pe care am găsit-o. Veti vedea in curand eleganta in solutie.

Bine, hai să ne scufundăm.

Partea 1: Stocarea informațiilor importante

În primul rând, presupun că stocați informații despre tranzacția abonamentului în tabelele MySQL – sau similar. Deci, de fiecare dată când primiți un nou abonament, primiți o plată pentru acesta sau ceva se schimbă în starea lui – anulare, expirare, neîncărcare etc. – vom avea o intrare în acel tabel.

Deoarece înregistrați toate evenimentele în abonament, acest tabel se va mări pe măsură ce trece timpul.

Calcularea MRR din acest tabel nu este o idee bună.

Cum se calculează MRR?

Să creăm un nou tabel pentru a stoca doar evenimente „semnificative”. Lucruri care schimbă material abonamentul. Înregistrare, upgrade sau downgrade, expirare, trecerea de la probă la plătită etc.

De asemenea, ar trebui să stocăm identificatorii de produs și de variație în tabel, astfel încât să putem calcula MRR (și alte valori) până la nivelul variației.

De asemenea, trebuie să stocăm ID-ul clientului, astfel încât să putem calcula valorile chiar și la nivel de client - rețineți că aceștia pot avea mai multe abonamente active!

Iată un extras din acest tabel.

2018-07-25123john@domainputlergrowthactualizat10079USD

într-o engleză simplă,

• John s-a înscris pentru un proces pe 10 iulie. Convertit într-un plan plătit de 79 USD/lună pe 25.
• Upgrade la un plan mai mare de 249 USD/m pe 15 august.
• Cumva nu a vrut să continue, așa că a anulat pe 10 decembrie.
• Dar din moment ce abonamentul său lunar era plătit până pe 14 a lunii, a folosit produsul până pe 14, iar pe 15 a expirat.
• Scăderea MRR-ului nostru de la 249 USD la 0.

Să mai adăugăm câteva intrări în acest tabel pentru alți utilizatori, apoi să începem să ne calculăm valorile.

• Am câștigat încă doi clienți aici – Annie și Mark.
• Annie a început cu proba Putler Starter, actualizat la un plan plătit chiar a doua zi.
• În cele din urmă, ea a cumpărat și un alt produs, Formula 10x, la 99 USD/m, care nu a avut nicio încercare.
• Mark s-a înscris pentru un proces, a început să plătească 79 USD/m după 20 de zile.
• În cele din urmă, a trecut la un plan mai scăzut, cu plată anuală (29 USD/m, dar 290 USD/an), scăzând MRR la 290 USD/12 = 24,17 USD.

Partea 2: Calcularea MRR, Trials to Paid, Churn și multe altele...

Să calculăm diferite valori ca pe 20 decembrie 2018.
Găsirea MRR este cea mai simplă!

Vă puteți întreba de ce să deduceți old_mrr din new_mrr? Și dacă nu sunteți familiarizat cu interogările SQL, bitul SUM de acolo vă poate deruta.

Gândește-te puțin la asta. Ia un pix și hârtie, calculează diferențele și totalizează-le.

Apoi calculați MRR ca la date diferite cu acea logică.

Într-adevăr, ia-ți puțin timp și gândește-te la asta. Odată ce înțelegi pe deplin acest lucru, totul va fi simplu.

…

Terminat?

O.K.

Cum se calculează ratarea?

Aceasta vă spune pierderea în MRR din cauza abandonului și numărul de abonamente care au fost reluate.

Nu prea greu, nu?

Cum se calculează încercările care trebuie plătite?

Să ne uităm la ceva un pic mai implicat.

Wow! Ai realizat multe până acum!

Permiteți-mi să vă spun rapid modalități posibile de a găsi alți KPI-uri.

• Comutatoare: Când tipul de eveniment este „actualizat”, iar noul MRR este mai mult decât vechiul MRR, este o actualizare. În caz contrar, downgrade.
  În mod similar, toate MRR noi + upgrade = extindere în MRR. Toate abandonul + retrogradările = contracția MRR.
• Abonamente active: ID-uri unice de abonamente, excluzând încercările anulate sau neconvertite.
• Venitul mediu per utilizator plătit: MRR împărțit la numărul de abonamente active. (Dacă doriți „utilizatori” și nu „abonamente”, puteți alege numărul de clienți unici cu abonamente active.)

Obtii poza!

Deci de ce naiba numesc asta cutia Pandorei???

Cine este Pandora? Și ce este în cutia ei?

Pandora este un personaj din mitologia greacă.

Prometeu a furat focul din ceruri, drept pedeapsă, Zeus (regele zeilor) i-a prezentat Pandora fratelui lui Prometeu, Epimeteu.

Un borcan a fost lăsat în grija Pandorei, iar ea l-a deschis – doar pentru a elibera lumii boala, moartea și multe alte rele. A închis rapid containerul, iar Hope a rămas în urmă.

Astăzi, expresia „a deschide o cutie a Pandorei” înseamnă a face sau a începe ceva care provoacă multe necazuri mari și neașteptate. Este similar în sensul „deschiderii unei conserve de viermi”.

Calcularea valorilor de afaceri a abonamentului devine din ce în ce mai dificilă pe măsură ce încercați să o faceți din ce în ce mai precisă.

Valorile sunt o măsură a progresului. Oamenii își planifică acțiunile viitoare pe baza valorilor raportate. Prin urmare, este foarte important să aveți valori corecte.

Dacă calculul dvs. arată un MRR de 12 000 USD, dar ați uitat să deduceți anulările din acesta, atunci asta nu va funcționa.

Dacă ați făcut vreo greșeală în calcularea valorilor, veți ajunge să luați decizii greșite.

Bine, deci suntem de acord că valorile exacte sunt esențiale. Dar cum devine tot mai complex??

Iată cum raportarea veniturilor din abonament devine cu adevărat complexă!

Pentru a vă spune adevărul, am evitat pentru o lungă perioadă de timp să construim rapoarte de abonament în Putler – soluția noastră de analiză a comerțului electronic. Primele noastre încercări au eșuat rapid.

În cele din urmă, am construit o soluție care a gestionat toate complicațiile și cazurile marginale.

Până la urmă și asta s-a dovedit a fi insuficient. Atunci am reconstruit totul din nou pe baza abordării pe care am schițat-o mai sus.

Vă voi spune ceva mai multe despre Putler mai târziu, dar iată un listă cu problemele majore pe care le-am observat în construirea soluțiilor de analiză/metrică SaaS.

• Nu există o metodă universal acceptată de calculare a tuturor acestor valori: diferite soluții de raportare au metode diferite de calcul. Deci, dacă vă comparați datele cu altcineva, este posibil să observați nepotriviri.
• Garbage In, Garbage Out: Dacă jurnalul tuturor tranzacțiilor este incomplet sau inconsecvent, tabelul nostru cu evenimente de abonament va avea intrări insuficiente. De exemplu, dacă creați date despre evenimentele de abonament din tranzacțiile din ultimii doi ani, este posibil să pierdeți evenimente critice care au avut loc înainte de această perioadă. Sau dacă portalul dvs. de plată/sistemul de comerț electronic stabilește aceeași dată pentru crearea și prima plată – sau orice alte inconsecvențe – valorile vor fi greșite.
• Sistemele de comerț electronic și API-urile gateway-urilor de plată se modifică: pot modifica tipul de date pe care le furnizează. Aceasta înseamnă două lucruri: unul, trebuie să vă actualizați constant logica – care este încă ok; dar al doilea este că datele vechi pot fi în format vechi, datele noi în standard nou. Într-un astfel de caz, va trebui să normalizați și să aduceți totul în același format!
• Evenimente noi de abonament: de fiecare dată când are loc un nou eveniment de abonament, trebuie să verificați și să actualizați tabelul dacă este necesar. Majoritatea gateway-urilor nu indică upgrade/downgrade. Mulți nu indică informații despre proces. Așa că trebuie să identificăm în mod inteligent aceste modele.
• Mai multe valute: dacă acceptați plăți în valute diferite, va trebui să căutați ratele de schimb și să convertiți totul într-o monedă „de bază”. Aceasta poate fi o provocare în sine.
• Gateway-uri de plată multiple/sisteme de comerț electronic: dacă acceptați atât Stripe, cât și PayPal pentru plăți, tipul de informații pe care le furnizează mai târziu despre o tranzacție este diferit. De exemplu , PayPal API nu furnizează intervale de abonament și data de încheiere. În astfel de cazuri, trebuie să construim o metodă „fuzzy” de a detecta abonamentele și detaliile acestora. Consolidarea acestor diferențe între gateway-uri și unificarea datelor este extrem de dificilă.
  Am furnizat deja valori pentru produse și niveluri de variație. Dar numele produselor/planului se schimbă tot timpul. Pentru o precizie mai mare, trebuie să construim un sistem de îmbinare/grupare a produselor.
• Sisteme de comerț electronic cu inexactitatea datelor: atunci când utilizați un sistem de comerț electronic, este posibil să nu aibă cele mai exacte date. Trebuie să vă corelați cu gateway-urile de plată pentru a confirma. Acest proces de deducție este intens.

Doriți să vă urmăriți valorile recurente ale veniturilor? Iată opțiunile tale...

Este o analogie potrivită. Dacă nu urmăriți indicatorii cheie de performanță, nu știți unde mergeți. (Și BTW, dacă nu ați citit Crossing the Chasm, citiți-l când aveți ocazia.)

Fiecare om de afaceri serios cunoaște importanța urmăririi măsurătorilor cheie. Și nu lipsesc instrumentele de analiză și raportare.

Dar mai intai: nu faceți greșeala de a folosi o foaie de calcul Excel (sau Google!) pentru a urmări valorile și KPI-urile abonamentului SaaS. Nu se va scala.

Deci care sunt opțiunile tale?

Fiecare sistem de comerț electronic are încorporat un fel de sistem de raportare. La fel și fiecare gateway de plată. Puteți începe cu ei.

Chiar și soluțiile de analiză de uz general, cum ar fi Google Analytics și Mixpanel, permit urmărirea veniturilor din comerțul electronic. Le puteți folosi, dar nu veți primi KPI-uri de abonament despre care am discutat – MRR / Churn etc...

Având în vedere creșterea SaaS și modelul de afaceri recurent, zeci de startup-uri au lansat soluții specializate în metrici SaaS. Există o mulțime de opțiuni, mai ales când utilizați Stripe. ChartMogul, Control, ProfitWell, Compass, Statsbot, Supermetrics... – lista poate continua. Multe dintre aceste soluții funcționează și cu alte gateway-uri de plată.

Apoi mai este Baremetrics – afișul analizei de afaceri a abonamentului. Este un produs grozav, există de mulți ani și a adus multe îmbunătățiri în ultima vreme. Și toți ceilalți le-au copiat.

Chiar și noi am copiat Baremetrics atunci când am creat analize ale veniturilor din abonament în Putler.

Da, Putler vă oferă întreaga gamă de rapoarte de afaceri recurente.

Inca confuz? Pentru a simplifica lucrurile, iată un articol care compară diferite programe de facturare a abonamentelor.

Experiența noastră de a oferi platforme de analiză a veniturilor afacerilor prin abonamente și comerț electronic

Putler a început ca un simplu instrument de urmărire a vânzărilor PayPal încă din 2010. A rămas o aplicație desktop mulți ani și a câștigat mii de utilizatori. Am renovat întregul sistem și l-am portat pe Web în 2016.

Uitați-vă la Tabloul de bord pentru abonamente Putler

Putler este o platformă semnificativă de analiză a comerțului electronic și una dintre cele mai bune.

De ce?

În principal datorită clienților noștri minunați. Am construit Putler cu feedback continuu din partea clienților. Am rezolvat probleme reale pentru oameni.

Putler face ceea ce majoritatea soluțiilor de analiză nu fac.

Iată cum se compară Putler cu concurenții

Deci, care este cea mai bună soluție pentru analiza și raportarea SaaS/abonamentului?

Există multe soluții bune. Câteva populare, de asemenea. Există unele gratuite, altele percep taxe mari.

Iată câteva întrebări pe care le poți adresa pentru a descoperi cea mai bună soluție pentru nevoile tale.

• Functioneaza doar cu Stripe? Sau un anumit gateway sau sistem de comerț electronic? Dacă da, acest lucru vă poate limita în viitor.
  Chiar dacă utilizați gateway-ul pentru care este construit sistemul, va funcționa în cazul dvs.? De exemplu, unele soluții necesită planuri/produse definite la nivel Stripe/gateway. Dacă utilizați un sistem de comerț electronic – precum WooCommerce – și utilizați Stripe doar pentru plăți, majoritatea soluțiilor nu vor funcționa.
• Poate soluția să gestioneze plăți nerecurente? Chiar și pentru SaaS, nu fiecare dolar este recurent. Ai nevoie de ceva care să se ocupe de orice.
• Are platforma o integrare gata cu sistemul dvs. de plată/e-commerce? Toată lumea are un API, dar utilizarea unui API pentru a vă completa datele poate fi o sarcină mare.
• Vă oferă cele mai multe (dacă nu toate) valorile pe care doriți să le urmăriți? Poate extrage date din alte sisteme, cum ar fi Google Analytics, pentru a vă oferi o mai bună înțelegere a afacerii dvs.?
• Cum gestionează sistemul complexitățile pe care le-am subliniat mai devreme? Schimbări în sistem, schimbări de plan, rambursări, mai multe valute etc?
• Aveți mai multe gateway-uri de plată/afaceri/site-uri web? Dacă da, soluția le poate consolida pe toate într-un singur loc?
• Puteți acorda acces restricționat membrilor echipei dvs.? Către echipa de marketing sau de asistență pentru clienți?
• Este doar un instrument de raportare sau depășește? Îmbogățește profilurile clienților? Poate trimite rapoarte prin e-mail? Poate face față solicitărilor/încărcărilor eșuate?
• Care este pretul? Chiar dacă este gratuit, cât timp și efort va trebui să cheltuiți pentru ca acesta să funcționeze? Cum sunt oferite vânzările premium premium?
• Este usor de folosit? Obțineți informațiile de care aveți nevoie fără să faceți multe sărituri ici și colo?
• Va supraviețui platforma? Sau se va pierde în următorii câțiva ani?

Au fost mai multe întrebări decât ați anticipat?

Dar cred că este important să ne uităm la toate aceste aspecte.

Tu ce crezi?

Încercați-le. Atunci decide.

Corect?