Abonelik ölçümleri analitiği: MRR, kayıp oranı, ARPPU ve daha fazlası nasıl hesaplanır?

Ah tatlı MRR! Bir SaaS / abonelik / üyelik / sürekli gelir işi için ilerleme ölçütü.

Herhangi bir abonelik işinin sahibi veya pazarlama müdürüyle konuşun, MRR'lerinin beklendiği gibi büyümediğini ya da olağanüstü MRR'leri ve tanık oldukları hokey sopası büyümesi hakkında net bir şekilde konuşacaklar.

Bazıları, kayıp oranlarını ve hızlı oranlarını açıklamaya devam edebilir. İhtar, kurtarma e-postaları ve devam eden kullanıcı katılımından oluşan eylem planı, kesintiyi 50 baz puan aşağı çekmek için.

Tamam, duralım.

Yinelenen bir faturalandırma işindeyseniz, durumu kesinlikle biliyorsunuzdur. Değilseniz, büyük olasılıkla bir abonelik sistemine geçmek istersiniz.

Peki nedir bu abonelik metrikleri? Bütün bu jargon ne anlama geliyor?

Sahibiz bu SaaS / abonelik / yinelenen iş metrikleri için derinlemesine açıklamalar. Şimdilik size kısa bir özet geçeyim.

İnternetteki abonelik iş metriklerinin en basit açıklaması

• MRR, ARR: Aylık Yinelenen Gelir ve Yıllık Çalıştırma Oranı. Esasen, ayda ne kadar para kazanıyorsunuz?
  Aylık aralıklarla tekrarlanmayan abonelikler, aylık olarak “dönüştürülür”. Örneğin, yıllık abonelik tutarı 12'ye bölünür veya haftalık abonelik 4,33 ile çarpılır vb.
• Churn: Her ay kaybettiğiniz şey – gelir, müşteriler, abonelik sayısı. Genellikle MRR yüzdesi olarak belirtilir.
• Anahtarlar: İnsanlar abonelik planlarını değiştirir. Yükseltmeleri ve düşürmeleri izlemek istiyorsunuz. Yükseltmeler MRR'yi genişletir, düşürmeler daraltır.
• Denemeler: deneme sayısı, denemelerin ücretliye çevrilme yüzdesi. Deneme, bir ürün planı olarak kabul edilebilir ve insanlar ücretli bir plana geçtiğinde bunu bir "yükseltme" olarak düşünebilirsiniz. Ama kendi başına ölçümü hak ediyor.
• ARPU, ARPPU, ARPA: Kullanıcı Başına (veya Ücretli Kullanıcı Başına veya Hesap Başına) Ortalama Gelir. Bu, esas olarak MRR'nin müşteri sayısına (veya ücretsiz deneme süreniz olduğunda ücretli müşteri sayısına) bölünmesidir. Bazı durumlarda, bir kuruluştaki tüm kullanıcıları birleştirmek ve toplam gelirlerini Hesap Başına Ortalama Gelir olarak saymak isteyebilirsiniz.
• CLTV, LTV: Bir Müşterinin Yaşam Boyu Değeri. Çoğu durumda, insanlar bir müşterinin aktif kaldığı ortalama ay sayısına ulaşmak için kayıp oranlarını tersine çevirir. Ardından LTV'ye ulaşmak için bunu ARPU ile çarpın.
• CAC: Müşteri Edinme Maliyeti. Bu genellikle dahili bir ölçümdür, çünkü raporlama sistemleri kendi başlarına maliyetleri hesaba katmaz. CAC ile LTV'yi karşılaştırmak, bir müşterinin kullanım ömrü boyunca ne kadar karlı olduğunu size söyler. Daha hızlı başabaş, daha iyi ölçeklenebilirlik ve daha iyi değerlemeler anlamına gelir!
• Hızlı Oran: Ayda ne kadar para ekliyorsunuz, ne kadar para kaybettiğinize bölünüyor. Yüzer veya batarsanız hızlı bir şekilde gösterir!
  formül olurdu (Yeni MRR + Genişletme MRR) / (Daralma MRR + Çalkantılı MRR).
  Hatta abonelikleri durumlarına göre ölçmek isteyebilirsiniz – Yeni, Etkin, Yeniden Etkinleştirildi, Çalkalandı, İptal Edildi, Askıya Alındı ​​vb.
  Bir diğer önemli ölçüm ise “Başarısız ücretler”dir. Kredi kartlarının süresi her zaman sona erer ve müşteri tabanınız büyüdükçe başarısız ödeme girişimlerinin miktarı artacaktır.
• İhtar: Bu başarısızlıklardan kaçınma ve bunlardan kurtulma sürecidir. İyi bir ihtar çözümü, gelirinize kolayca %10-20 arasında katkı sağlayabilir.
• Geri Ödemeler: Birçok kişi, daha çok nakit akışı değişikliği olduğu için geri ödemeleri geri ödemeye dahil etmez. Bir geri ödeme bir aboneliği iptal ederse, bu kayıp olarak sayılır.
• Nakit akışı: Nakit akıl sağlığıdır, diğerleri kibirdir. Nakit akışını takip etmek iş için kritik öneme sahiptir.
  Tüm bu metriklerin ürün ve varyant bazında dağılımı. Abonelik ürünlerinize "planlar" veya başka bir şey deseniz de, her ürün için önemli numaraları izlemek kesinlikle yardımcı olacaktır.

Tüm bunların yanı sıra, eğilimleri görmek ve hatta geleceğe yönelik planlamalar için tahminler almak için bu metrikleri geçmiş verilerle karşılaştırmak da isteyebilirsiniz.

Buna inanabiliyor musun? Basit açıklamam bu kadar uzun muydu?

MRR ve diğer metrikleri ölçmek ve hesaplamak – basit ama kapsamlı çözüm

Burada veritabanları ve sorgular hakkında konuşacağım. Programlama veya veritabanlarıyla ilgilenmiyorsanız endişelenmeyin. Mümkün olduğunca basit tutacağım.

Ama bunları anlarsan faydalı olur. Günün sonunda matematik ve bu çok basit matematik.

bu bulduğumuz en kapsamlı, ancak kolay yaklaşım. Çözümdeki şıklığı yakında göreceksiniz.

Pekala, içeri girelim.

Bölüm 1: Önemli bilgilerin saklanması

İlk olarak, abonelik işlem bilgilerini MySQL tablolarında veya benzerlerinde depoladığınızı varsayıyorum. Bu nedenle, her yeni abonelik aldığınızda, ödeme aldığınızda veya durumunda bir şey değiştiğinde - iptal, sona erme, ücretlendirilmeme vb. - bu tabloda bir girişimiz olacak.

Tüm olayları aboneliğe kaydettiğiniz için bu tablo zaman geçtikçe büyüyecektir.

Bu tablodan MRR'yi hesaplamak iyi bir fikir değil.

MRR nasıl hesaplanır?

Sadece “önemli” olayları saklamak için yeni bir tablo oluşturalım. Aboneliği önemli ölçüde değiştiren şeyler. Kaydolma, yükseltme veya düşürme, sona erme, deneme sürümünden ücretli sürüme geçme vb.

MRR'yi (ve diğer metrikleri) varyasyon düzeyine kadar hesaplayabilmemiz için ürün ve varyasyon tanımlayıcılarını da tabloda saklamalıyız.

Metrikleri müşteri düzeyinde bile hesaplayabilmemiz için müşterinin kimliğini de saklamamız gerekiyor – unutmayın, birden fazla aktif abonelikleri olabilir!

İşte bu tablodan bir alıntı.

2018-07-25123john@domainputlerbüyümeupdated10079USD

Basit İngilizcede,

• John, 10 Temmuz'da bir deneme için kaydoldu. 25'inde, aylık 79$'lık ücretli plana dönüştürüldü.
• 15 Ağustos'ta 249 $/m daha yüksek bir plana yükseltildi.
• Her nasılsa devam etmek istemedi, bu yüzden 10 Aralık'ta iptal etti.
• Ancak aylık aboneliği ayın 14'üne kadar ödendiği için ürünü 14'üne kadar kullandı ve 15'inde kullanım süresi doldu.
• MRR'mizi 249 dolardan 0'a yuvarlamak.

Diğer bazı kullanıcılar için bu tabloya birkaç giriş daha ekleyelim ve ardından metriklerimizi hesaplamaya başlayalım.

• Burada iki müşteri daha kazandık – Annie ve Mark.
• Annie, Putler Starter'ın deneme sürümüyle başladı ve ertesi gün ücretli plana yükseltildi.
• Sonunda, 10x Formula adlı başka bir ürünü de 99/m dolardan satın aldı ve denemesi yapılmadı.
• Mark bir deneme için kaydoldu, 20 gün sonra 79 $/m ödemeye başladı.
• Sonunda, MRR'yi 290$/12 = 24.17$'a çekerek, yıllık ödemeyle (29$/milyon, ancak 290$/yıl) daha düşük bir plana indirdi.

Bölüm 2: MRR, Ücretli Denemeler, Churn ve daha fazlasının hesaplanması…

20 Aralık 2018'deki gibi farklı metrikleri hesaplayalım.
MRR'yi bulmak en basitidir!

Old_mrr'yi neden new_mrr'den düşüldüğünü sorgulayabilirsiniz? SQL sorgularına aşina değilseniz, oradaki SUM biti kafanızı karıştırabilir.

Bunu biraz düşünün. Bir kağıt kalem alın, farkları hesaplayın ve toplayın.

Sonra bu mantıkla MRR'yi farklı tarihlerdeki gibi hesaplayın.

Gerçekten, biraz zaman ayırın ve bunu düşünün. Bunu tam olarak kavradığınızda, diğer her şey basit olacaktır.

…

Tamamlandı?

Tamam.

Çürük nasıl hesaplanır?

Bu size, kayıp nedeniyle MRR'deki kaybı ve çalkalanan aboneliklerin sayısını gösterir.

Çok zor değil mi?

Ödenecek denemeler nasıl hesaplanır?

Biraz daha ilgili bir şeye bakalım.

Vay! Şimdiye kadar çok şey başardınız!

Size başka KPI'ları bulmanın olası yollarını hızlıca anlatayım.

• Anahtarlar: Olay türü 'güncellendiğinde' ve yeni MRR eski MRR'den daha fazlaysa, bu bir yükseltmedir. Aksi takdirde sürüm düşürün.
  Benzer şekilde, tüm yeni MRR + yükseltmeleri = MRR'de genişleme. Tüm kayıp + düşüşler = MRR'de daralma.
• Aktif Abonelikler: İptal edilen veya dönüştürülmeyen denemeler hariç Benzersiz Abonelik Kimlikleri.
• Ücretli Kullanıcı Başına Ortalama Gelir: MRR'nin Aktif Abonelik sayısına bölümü. ("Abonelikler" yerine "kullanıcılar" istiyorsanız, aktif abonelikleri olan benzersiz müşterilerin sayısını seçebilirsiniz.)

Resmi aldın!

Peki neden bu Pandora'nın kutusu diyorum???

Pandora kim? Ve kutusunda ne var?

Pandora, Yunan mitolojisinden bir karakterdir.

Prometheus cennetten ateşi çaldı, ceza olarak Zeus (tanrıların kralı) Pandora'yı Prometheus'un kardeşi Epimetheus'a sundu.

Pandora'nın bakımında bir kavanoz bırakıldı ve o onu açtı - sadece hastalık, ölüm ve diğer birçok kötülüğü dünyaya salmak için. Konteyneri çabucak kapattı ve Hope geride kaldı.

Bugün “to open a Pandora's box” deyimi, birçok büyük ve beklenmedik belaya neden olan bir şeyi yapmak veya başlatmak anlamına gelir. “Bir kutu solucan açmak” anlamında benzer.

Abonelik iş metriklerini hesaplamak, siz onu daha doğru hale getirmeye çalıştıkça daha da zorlaşır.

Metrikler, ilerlemenin bir ölçüsüdür. İnsanlar, hangi metriklerin rapor ettiğine göre gelecekteki eylemlerini planlar. Bu nedenle, doğru metriklere sahip olmak son derece önemlidir.

Hesaplamanız 12000 $ MRR gösteriyorsa ancak iptalleri bundan düşmeyi unuttuysanız, bu işe yaramayacaktır.

Metrikleri hesaplarken herhangi bir hata yaptıysanız, yanlış kararlar alırsınız.

Pekala, bu nedenle doğru ölçümlerin çok önemli olduğu konusunda hemfikiriz. Ama nasıl daha karmaşık hale gelir?

Abonelik geliri raporlamasının nasıl gerçekten karmaşıklaştığı aşağıda açıklanmıştır!

Gerçeği söylemek gerekirse, e-Ticaret analiz çözümümüz Putler'da Abonelik raporları oluşturmaktan uzun süre kaçındık. İlk birkaç denememiz çabucak başarısız oldu.

Son olarak, tüm komplikasyonları ve uç durumları ele alan bir çözüm oluşturduk.

Sonunda bunun da yetersiz olduğu ortaya çıktı. Bu, yukarıda ana hatlarıyla belirttiğim yaklaşıma dayanarak her şeyi yeniden inşa ettiğimiz zamandır.

Putler hakkında size daha sonra biraz daha bilgi vereceğim, ancak burada bir SaaS analitik / metrik çözümleri oluştururken gözlemlediğimiz başlıca sorunların listesi.

• Tüm bu metrikleri hesaplamak için evrensel olarak kabul edilmiş bir yöntem yoktur: Farklı raporlama çözümlerinin farklı hesaplama yöntemleri vardır. Bu nedenle, verilerinizi başka biriyle karşılaştırıyorsanız, uyumsuzluklar görebilirsiniz.
• Garbage In, Garbage Out: Tüm işlemlerin kaydı eksik veya tutarsız ise, abonelik olayları tablomuzda yetersiz giriş olacaktır. Örneğin, son iki yılın işlemlerinden abonelik olayları verileri oluşturursanız, bu dönemden önce gerçekleşen kritik olayları kaçırabilirsiniz. Veya ödeme ağ geçidi / e-ticaret sisteminiz oluşturma ve ilk ödeme için aynı tarihi ayarlıyorsa - veya diğer tutarsızlıklar - metrikler yanlış olacaktır.
• E-ticaret sistemleri ve ödeme ağ geçidi API'leri değişir: Sağladıkları veri türünü değiştirebilirler. Bu iki anlama gelir: birincisi, mantığınızı sürekli güncellemeniz gerekir – ki bu hala sorun değil; ama ikincisi, eski veriler eski formatta, yeni veriler yeni standartta olabilir. Böyle bir durumda normalleştirmeniz ve her şeyi aynı formatta getirmeniz gerekecek!
• Yeni abonelik olayları: Her yeni abonelik olayı gerçekleştiğinde, gerekirse tabloyu kontrol etmeniz ve güncellemeniz gerekir. Çoğu ağ geçidi, yükseltmeleri/düşürmeleri göstermez. Birçoğu deneme bilgilerini göstermez. Bu yüzden bu kalıpları akıllıca tanımlamamız gerekiyor.
• Birden çok para birimi: Farklı para birimlerinde ödeme kabul ediyorsanız, döviz kurlarına bakmanız ve her şeyi bir "temel" para birimine dönüştürmeniz gerekir. Bu kendi başına bir meydan okuma olabilir.
• Çoklu ödeme ağ geçitleri / e-ticaret sistemleri: Ödemeler için hem Stripe hem de PayPal'ı kabul ediyorsanız, daha sonra bir işlem hakkında sağladıkları bilgi türü farklıdır. Örneğin PayPal API, abonelik aralıkları ve bitiş tarihi sağlamaz. Bu gibi durumlarda, abonelikleri ve ayrıntılarını algılamak için "bulanık" bir yöntem oluşturmamız gerekir. Bu tür farklılıkları ağ geçitleri arasında konsolide etmek ve verileri birleştirmek son derece zordur.
  Ürün ve varyasyon düzeyi metriklerini zaten sağladık. Ama ürün/plan isimleri sürekli değişiyor. Daha yüksek doğruluk için ürünleri birleştirmek/gruplandırmak için bir sistem kurmamız gerekiyor.
• Veri yanlışlığı e-ticaret sistemleri: Bir e-ticaret sistemi kullandığınızda en doğru verilere sahip olmayabilir. Onaylamak için ödeme ağ geçitleriyle ilişki kurmanız gerekir. Bu tekilleştirme süreci yoğundur.

Yinelenen gelir metriklerinizi izlemek ister misiniz? İşte seçenekleriniz…

Bu uygun bir benzetme. Temel performans göstergelerinizi takip etmiyorsanız, nereye gittiğinizi bilmiyorsunuzdur. (Ve BTW, Crossing the Chasm'i okumadıysanız, fırsatınız olduğunda okuyun.)

Her ciddi iş insanı, temel ölçümleri izlemenin önemini bilir. Ve analitik ve raporlama araçları sıkıntısı yoktur.

Ama önce: SaaS abonelik ölçümlerinizi ve KPI'larınızı izlemek için bir Excel (veya Google!) elektronik tablosu kullanma hatasına düşmeyin. Ölçeklenmeyecek.

Öyleyse seçeneklerin neler?

Her e-ticaret sisteminin yerleşik bir raporlama sistemi vardır. Her ödeme ağ geçidi de öyle. Onlarla başlayabilirsiniz.

Google Analytics ve Mixpanel gibi genel amaçlı analiz çözümleri bile e-ticaret gelirlerinin izlenmesine olanak tanır. Bunları kullanabilirsiniz, ancak tartıştığımız abonelik KPI'larını alamayacaksınız – MRR / Churn vb…

SaaS'ın büyümesi ve tekrar eden iş modeli göz önüne alındığında, düzinelerce startup, SaaS ölçümlerinde uzmanlaşmış çözümler başlattı. Özellikle Stripe kullandığınızda çok fazla seçenek var. ChartMogul, Control, ProfitWell, Compass, Statsbot, Supermetrics… – liste uzayıp gidiyor. Bu çözümlerin çoğu, diğer ödeme ağ geçitleriyle de çalışır.

Ardından, abonelik iş analitiğinin poster çocuğu olan Baremetrics var. Harika bir ürün, yıllardır orada ve son zamanlarda birçok iyileştirme yaptı. Ve diğer herkes onları kopyaladı.

Putler'da abonelik geliri analitiği oluşturduğumuzda Baremetrics'i bile kopyaladık.

Evet, Putler size yinelenen iş raporlamasının tam gamını sunar.

Hala kafan mı karıştı? İşleri kolaylaştırmak için, farklı abonelik faturalandırma yazılımlarını karşılaştıran bir makaleyi burada bulabilirsiniz.

E-ticaret ve abonelik iş gelir analizi platformu sunma deneyimimiz

Putler, 2010 yılında basit bir PayPal satış takip aracı olarak başladı. Uzun yıllar bir masaüstü uygulaması olarak kaldı ve binlerce kullanıcı kazandı. Tüm sistemi yeniledik ve 2016'da Web'e taşıdık.

Putler'ın Abonelik Panosuna bakın

Putler, anlamlı bir e-ticaret analiz platformudur ve piyasadaki en iyilerden biridir.

Neden? Niye?

Temelde harika müşterilerimiz yüzünden. Putler'ı müşterilerden gelen sürekli geri bildirimlerle oluşturduk. İnsanlar için gerçek sorunları çözdük.

Putler, diğer analitik çözümlerin çoğunun yapmadığını yapar.

Putler'ın rakipleriyle karşılaştırması şu şekilde:

Peki, SaaS/abonelik analitiği ve raporlaması için en iyi çözüm nedir?

Birçok iyi çözüm var. Birkaç popüler de. Bazı ücretsiz, bazı ücretli ağır ücretler var.

İhtiyaçlarınız için en iyi çözümü keşfetmek için sorabileceğiniz bazı sorular.

• Sadece Stripe ile mi çalışıyor? Veya belirli bir ağ geçidi veya e-ticaret sistemi? Eğer öyleyse, bu gelecekte sizi sınırlayabilir.
  Sistemin inşa edildiği ağ geçidini kullanıyor olsanız bile, sizin durumunuzda çalışır mı? Örneğin bazı çözümler Stripe/gateway seviyesinde tanımlanmış planlara/ürünlere ihtiyaç duyar. WooCommerce gibi bir e-ticaret sistemi kullanıyorsanız ve Stripe'ı yalnızca ödemeler için kullanıyorsanız, çözümlerin çoğu çalışmayacaktır.
• Çözüm, yinelenmeyen ödemeleri kaldırabilir mi? SaaS için bile her dolar tekrarlanmaz. Her şeyi halledebilecek bir şeye ihtiyacınız var.
• Platform, ödeme / e-ticaret sisteminizle hazır bir entegrasyona sahip mi? Herkesin bir API'si vardır, ancak verilerinizi doldurmak için bir API kullanmak büyük bir görev olabilir.
• İzlemek istediğiniz metriklerin çoğunu (hepsini değilse de) veriyor mu? İşletmenizi daha iyi anlamanız için Google Analytics gibi diğer sistemlerden veri çekebilir mi?
• Sistem daha önce ana hatlarıyla belirttiğimiz karmaşıklıklarla nasıl başa çıkıyor? Sistemdeki değişiklikler, plan değişiklikleri, geri ödemeler, birden fazla para birimi vb.
• Birden fazla ödeme ağ geçidiniz / işletmeniz / web siteniz var mı? Eğer öyleyse, çözüm hepsini tek bir yerde doğru bir şekilde birleştirebilir mi?
• Ekip üyelerinize kısıtlı erişim verebilir misiniz? Pazarlama veya müşteri destek ekibine mi?
• Sadece bir raporlama aracı mı yoksa ötesine mi geçiyor? Müşteri profillerini zenginleştiriyor mu? Raporları e-postayla gönderebilir mi? İhtar/başarısız ücretleri kaldırabilir mi?
• Fiyatı nedir? Ücretsiz olsa bile, çalışması için ne kadar zaman ve çaba harcamanız gerekecek? Premium satışlar nasıl sunulur?
• Kullanımı kolay mı? İhtiyacınız olan bilgiyi çok fazla oraya buraya atlamadan alıyor musunuz?
• Platform hayatta kalacak mı? Yoksa önümüzdeki birkaç yıl içinde kaybolacak mı?

Beklediğinizden çok daha fazla soru oldu mu?

Ama bence tüm bu yönlere bakmak önemli.

Ne düşünüyorsun?

Onları deneyin. Ozaman karar ver.

Adil?