Analisis metrik langganan: Cara menghitung MRR, churn rate, ARPPU, dan lainnya

Oh MRR yang manis! Tolok ukur kemajuan untuk bisnis SaaS / langganan / keanggotaan / pendapatan berulang.

Bicaralah dengan pemilik atau kepala pemasaran bisnis langganan mana pun dan mereka akan menceritakan bagaimana MRR mereka tidak tumbuh seperti yang diharapkan, atau berbicara dengan fasih tentang MRR fenomenal mereka dan pertumbuhan tongkat hoki yang mereka saksikan.

Beberapa mungkin melanjutkan untuk menggambarkan tingkat churn dan rasio cepat mereka. Rencana tindakan mereka berupa dunning, email pemulihan, dan keterlibatan pengguna yang berkelanjutan untuk menurunkan churn sebesar 50 basis poin.

Baiklah, mari kita berhenti.

Jika Anda berada dalam bisnis penagihan berulang, Anda pasti tahu situasinya. Jika tidak, kemungkinan besar Anda ingin bermigrasi ke sistem berlangganan.

Jadi apa metrik langganan ini? Apa arti semua jargon itu?

Kita punya penjelasan mendalam untuk metrik bisnis SaaS / langganan / berulang ini. Untuk saat ini, izinkan saya memberi Anda penjelasan singkat.

Penjelasan paling sederhana tentang metrik bisnis berlangganan di Internet

• MRR, ARR: Pendapatan Berulang Bulanan dan Run Rate Tahunan. Intinya, berapa banyak uang yang Anda hasilkan per bulan?
  Langganan yang tidak berulang pada interval bulanan, "dikonversi" menjadi bulanan. Sebagai contoh, jumlah langganan tahunan dibagi 12, atau langganan mingguan dapat dikalikan dengan 4,33 dst.
• Churn: Kerugian Anda setiap bulan – pendapatan, pelanggan, jumlah langganan. Biasanya dilambangkan sebagai persentase dari MRR.
• Beralih: Orang-orang mengubah paket langganan mereka. Anda ingin melacak peningkatan dan penurunan versi. Upgrade memperluas MRR, downgrade mengontraknya.
• Uji Coba: jumlah uji coba, persentase konversi uji coba menjadi berbayar.. Uji coba dapat dianggap sebagai paket produk, dan Anda dapat menganggapnya sebagai "peningkatan" ketika orang beralih ke paket berbayar. Tapi itu layak diukur sendiri.
• ARPU, ARPPU, ARPA: Pendapatan Rata-Rata Per Pengguna (atau Per Pengguna Berbayar, atau Per Akun). Ini pada dasarnya adalah MRR dibagi dengan jumlah pelanggan (atau jumlah pelanggan berbayar saat Anda memiliki uji coba gratis). Dalam beberapa situasi, Anda mungkin ingin menggabungkan semua pengguna dari organisasi dan menghitung total pendapatan mereka sebagai Pendapatan Rata-Rata Per Akun.
• CLTV, LTV: Nilai Seumur Hidup Pelanggan. Dalam kebanyakan kasus, orang membalikkan tingkat churn mereka untuk sampai pada jumlah rata-rata bulan pelanggan tetap aktif. Kemudian kalikan dengan ARPU untuk sampai di LTV.
• CAC: Biaya Memperoleh Pelanggan. Ini sering merupakan metrik internal, karena sistem pelaporan sendiri tidak memperhitungkan biaya. Membandingkan CAC dengan LTV memberi tahu Anda seberapa menguntungkan pelanggan selama masa hidup mereka. Titik impas yang lebih cepat berarti skalabilitas yang lebih baik dan penilaian yang lebih baik!
• Rasio Cepat: Berapa banyak uang yang Anda tambahkan per bulan, dibagi dengan berapa banyak uang yang hilang. Cepat menunjukkan jika Anda mengambang atau tenggelam!
  Formula akan menjadi (MRR Baru + MRR Ekspansi) / (MRR Kontraksi + MRR Churned).
  Anda bahkan mungkin ingin mengukur langganan berdasarkan statusnya – Baru, Aktif, Diaktifkan kembali, Dipotong, Dibatalkan, Ditangguhkan, dll.
  Pengukuran penting lainnya adalah "Biaya yang gagal". Kartu kredit kedaluwarsa sepanjang waktu dan seiring bertambahnya basis pelanggan Anda, jumlah upaya penagihan yang gagal akan meningkat.
• Dunning: Ini adalah proses menghindari dan memulihkan diri dari kegagalan ini. Solusi dunning yang baik dapat dengan mudah menambahkan 10-20% ke pendapatan Anda.
• Pengembalian Dana: Banyak orang tidak memasukkan pengembalian uang dalam churn, karena ini lebih merupakan perubahan arus kas. Jika pengembalian dana membatalkan langganan, itu akan dihitung sebagai churn.
• Arus Kas: Uang tunai adalah kewarasan, yang lain adalah kesombongan. Mengawasi arus kas sangat penting untuk bisnis.
  Pemisahan produk dan varian dari semua metrik ini. Apakah Anda menyebut produk langganan Anda "paket" atau apa pun, itu pasti akan membantu untuk melacak nomor penting untuk setiap produk.

Terlepas dari semua ini, Anda mungkin juga ingin membandingkan metrik ini dengan data historis untuk melihat tren, dan bahkan mendapatkan perkiraan untuk perencanaan masa depan.

Bisakah Anda mempercayainya? Penjelasan sederhana saya selama ini?

Mengukur dan menghitung MRR dan metrik lainnya – solusi sederhana namun komprehensif

Saya akan berbicara tentang database dan query di sini. Jika Anda tidak menyukai pemrograman atau database, jangan khawatir. Saya akan membuatnya sesederhana mungkin.

Tapi itu berguna jika Anda memahami ini. Ini matematika pada akhirnya, dan itu matematika yang terlalu sederhana.

Ini adalah pendekatan yang paling komprehensif, namun mudah yang kami temukan. Anda akan segera melihat keanggunan dalam solusi.

Baiklah, mari selami.

Bagian 1: Menyimpan informasi penting

Pertama, saya berasumsi Anda menyimpan informasi transaksi langganan di tabel MySQL – atau yang serupa. Jadi setiap kali Anda menerima langganan baru, menerima pembayaran, atau sesuatu yang mengubah statusnya – pembatalan, kedaluwarsa, kegagalan untuk menagih, dll – kami akan memiliki entri di tabel itu.

Karena Anda mencatat semua acara ke langganan, tabel ini akan menjadi lebih besar seiring berjalannya waktu.

Menghitung MRR dari tabel ini bukanlah ide yang baik.

Bagaimana cara menghitung MR?

Mari buat tabel baru untuk menyimpan hanya peristiwa "signifikan". Hal-hal yang secara material mengubah langganan. Mendaftar, meningkatkan atau menurunkan, kedaluwarsa, beralih dari uji coba ke berbayar, dll.

Kami juga harus menyimpan pengidentifikasi produk dan variasi dalam tabel sehingga kami dapat menghitung MRR (dan metrik lainnya) hingga ke tingkat variasi.

Kami juga perlu menyimpan ID pelanggan sehingga kami dapat menghitung metrik bahkan di tingkat pelanggan – ingat, mereka mungkin memiliki beberapa langganan aktif!

Berikut kutipan dari tabel ini.

2018-07-25123john@domainputlergrowthupdated10079USD

Dalam bahasa Inggris sederhana,

• John mendaftar untuk uji coba pada 10 Juli. Dikonversi ke paket berbayar $79/bulan pada tanggal 25.
• Ditingkatkan ke paket yang lebih tinggi $249/m pada tanggal 15 Agustus.
• Entah bagaimana dia tidak ingin melanjutkan, jadi dia membatalkannya pada 10 Desember.
• Tetapi karena langganan bulanannya dibayar hingga tanggal 14 setiap bulan, ia menggunakan produk tersebut hingga tanggal 14, dan pada tanggal 15 produk tersebut kedaluwarsa.
• Menurunkan MRR kami dari $249 menjadi 0.

Mari tambahkan beberapa entri lagi ke tabel ini untuk beberapa pengguna lain, lalu mulai menghitung metrik kita.

• Kami memenangkan dua pelanggan lagi di sini – Annie dan Mark.
• Annie memulai dengan uji coba Putler Starter, ditingkatkan ke paket berbayar keesokan harinya.
• Akhirnya, dia juga membeli produk lain, Formula 10x, dengan harga $99/m, yang tanpa uji coba.
• Mark mendaftar untuk uji coba, mulai membayar $79/m setelah 20 hari.
• Akhirnya, ia menurunkan ke paket yang lebih rendah, dengan pembayaran tahunan ($29/m, tetapi $290/tahun), menurunkan MRR menjadi $290/12 = $24,17.

Bagian 2: Menghitung MRR, Uji Coba untuk Dibayar, Churn, dan lainnya…

Mari kita hitung metrik yang berbeda pada 20 Desember 2018.
Menemukan MRR adalah yang paling sederhana!

Anda mungkin bertanya-tanya mengapa harus mengurangi old_mrr dari new_mrr? Dan jika Anda tidak terbiasa dengan kueri SQL, bit SUM di sana mungkin membingungkan Anda.

Pikirkan tentang ini sebentar. Ambil pena dan kertas, hitung perbedaannya dan jumlahkan semuanya.

Kemudian hitung MRR pada tanggal yang berbeda dengan logika tersebut.

Sungguh, luangkan waktu dan pikirkan itu. Setelah Anda sepenuhnya memahami ini, segala sesuatu yang lain akan menjadi sederhana.

…

Selesai?

Oke.

Bagaimana cara menghitung churn?

Itu memberi tahu Anda kerugian dalam MRR karena churn, dan jumlah langganan yang churn.

Tidak terlalu sulit bukan?

Bagaimana cara menghitung percobaan yang harus dibayar?

Mari kita lihat sesuatu yang sedikit lebih terlibat.

Wow! Anda telah mencapai banyak hal sejauh ini!

Biarkan saya dengan cepat memberi tahu Anda cara yang mungkin untuk menemukan beberapa KPI lainnya.

• Switch: Ketika tipe event 'diperbarui', dan MRR baru lebih banyak dari MRR lama, itu adalah upgrade. Turunkan versi sebaliknya.
  Demikian pula, semua MRR baru + peningkatan = ekspansi di MRR. Semua churn + downgrade = kontraksi di MRR.
• Langganan Aktif: ID Langganan Unik, tidak termasuk uji coba yang dibatalkan atau tidak dikonversi.
• Pendapatan Rata-Rata Per Pengguna Berbayar: MRR dibagi dengan jumlah Langganan Aktif. (Jika Anda menginginkan "pengguna" dan bukan "langganan", Anda dapat memilih jumlah pelanggan unik dengan langganan aktif.)

Anda mendapatkan gambarnya!

Jadi mengapa saya menyebut kotak Pandora ini???

Siapa Pandora? Dan apa yang ada di dalam kotaknya?

Pandora adalah karakter dari mitologi Yunani.

Prometheus mencuri api dari surga, sebagai hukuman, Zeus (raja para dewa) mempersembahkan Pandora kepada saudara Prometheus, Epimetheus.

Sebuah toples ditinggalkan dalam perawatan Pandora, dan dia membukanya – hanya untuk melepaskan penyakit, kematian, dan banyak kejahatan lainnya ke dunia. Dia dengan cepat menutup wadahnya, dan Hope tertinggal.

Hari ini, ungkapan "membuka kotak Pandora" berarti melakukan atau memulai sesuatu yang menyebabkan banyak masalah besar dan tak terduga. Ini mirip artinya dengan "membuka sekaleng cacing".

Menghitung metrik bisnis langganan menjadi semakin sulit saat Anda mencoba membuatnya semakin akurat.

Metrik adalah ukuran kemajuan. Orang-orang merencanakan tindakan mereka di masa mendatang berdasarkan metrik yang dilaporkan. Jadi sangat penting untuk memiliki metrik yang benar.

Jika perhitungan Anda menunjukkan MRR $ 12.000, tetapi Anda lupa untuk mengurangi pembatalan, maka itu tidak akan berhasil.

Jika Anda membuat kesalahan dalam menghitung metrik, Anda akhirnya akan mengambil keputusan yang salah.

Baiklah, jadi kami setuju bahwa metrik yang akurat sangat penting. Tapi bagaimana menjadi lebih dan lebih kompleks??

Begini cara pelaporan pendapatan langganan menjadi sangat rumit!

Sejujurnya, kami menghindari pembuatan laporan Langganan di Putler – solusi analitik eCommerce kami – untuk waktu yang lama. Beberapa upaya pertama kami gagal dengan cepat.

Akhirnya, kami membangun solusi yang menangani semua komplikasi dan kasus tepi.

Akhirnya itu terbukti tidak cukup juga. Saat itulah kami membangun kembali semuanya berdasarkan pendekatan yang saya uraikan di atas.

Saya akan memberi tahu Anda lebih banyak tentang Putler nanti, tetapi ini dia daftar masalah utama yang kami amati dalam membangun solusi analitik / metrik SaaS.

• Tidak ada metode penghitungan semua metrik yang diterima secara universal: Solusi pelaporan yang berbeda memiliki metode penghitungan yang berbeda. Jadi, jika Anda membandingkan data Anda dengan orang lain, Anda mungkin melihat ketidakcocokan.
• Garbage In, Garbage Out: Jika log semua transaksi tidak lengkap atau tidak konsisten, tabel peristiwa langganan kami tidak akan memiliki entri yang cukup. Misalnya, jika Anda membuat data peristiwa langganan dari transaksi dua tahun terakhir, Anda mungkin melewatkan peristiwa penting yang terjadi sebelum periode ini. Atau jika gateway pembayaran / sistem e-commerce Anda menetapkan tanggal yang sama untuk pembuatan dan pembayaran pertama – atau ketidakkonsistenan lainnya – metrik akan salah.
• Sistem e-niaga dan API gateway pembayaran berubah: mereka dapat mengubah jenis data yang mereka berikan. Ini berarti dua hal: satu, Anda perlu terus memperbarui logika Anda – yang masih baik-baik saja; tetapi kedua adalah bahwa data lama mungkin dalam format lama, data baru dalam standar baru. Dalam kasus seperti itu, Anda perlu menormalkan dan membawa semuanya dalam format yang sama!
• Acara langganan baru: Setiap kali acara langganan baru terjadi, Anda perlu memeriksa dan memperbarui tabel jika diperlukan. Sebagian besar gateway tidak menunjukkan peningkatan/penurunan versi. Banyak yang tidak menunjukkan informasi percobaan. Jadi kita perlu cerdas mengidentifikasi pola-pola ini.
• Beberapa mata uang: Jika Anda menerima pembayaran dalam mata uang yang berbeda, Anda perlu mencari nilai tukar, dan mengubah semuanya menjadi mata uang "dasar". Ini bisa menjadi tantangan tersendiri.
• Beberapa gateway pembayaran / sistem e-commerce: Jika Anda menerima Stripe dan PayPal untuk pembayaran, jenis informasi yang mereka berikan tentang transaksi di kemudian hari, berbeda. Misalnya , PayPal API tidak menyediakan interval berlangganan dan tanggal akhir. Dalam kasus seperti itu, kami harus membangun metode "kabur" untuk mendeteksi langganan dan detailnya. Mengkonsolidasikan perbedaan seperti itu di seluruh gateway dan menyatukan data sangat sulit.
  Kami telah menyediakan metrik tingkat produk dan variasi. Tetapi nama produk / paket berubah setiap saat. Untuk akurasi yang lebih tinggi, kita perlu membangun sistem untuk menggabungkan / mengelompokkan produk.
• Sistem e-niaga ketidakakuratan data: Saat Anda menggunakan sistem e-niaga, sistem tersebut mungkin tidak memiliki data yang paling akurat. Anda perlu berkorelasi dengan gateway pembayaran untuk mengonfirmasi. Proses deduping ini intensif.

Ingin melacak metrik pendapatan berulang Anda? Berikut adalah pilihan Anda…

Itu analogi yang tepat. Jika Anda tidak melacak indikator kinerja utama Anda, Anda tidak tahu ke mana Anda akan pergi. (Dan BTW, jika Anda belum membaca Crossing the Chasm, bacalah saat Anda mendapat kesempatan.)

Setiap pebisnis yang serius mengetahui pentingnya melacak pengukuran kunci. Dan tidak ada kekurangan alat analisis dan pelaporan.

Tapi pertama-tama: jangan membuat kesalahan dengan menggunakan spreadsheet Excel (atau Google!) untuk melacak metrik dan KPI langganan SaaS Anda. Itu tidak akan skala.

Jadi apa pilihan Anda?

Setiap sistem e-commerce memiliki semacam sistem pelaporan bawaan. Begitu juga setiap gateway pembayaran. Anda bisa mulai dengan mereka.

Bahkan solusi analitik tujuan umum seperti Google Analytics dan Mixpanel memungkinkan pelacakan pendapatan e-niaga. Anda dapat menggunakannya, tetapi tidak akan mendapatkan KPI langganan yang telah kami diskusikan – MRR / Churn dll…

Mengingat pertumbuhan SaaS dan model bisnis yang berulang, lusinan perusahaan rintisan telah meluncurkan solusi yang berspesialisasi dalam metrik SaaS. Ada banyak pilihan terutama saat Anda menggunakan Stripe. ChartMogul, Control, ProfitWell, Compass, Statsbot, Supermetrics… – daftarnya terus berlanjut. Banyak dari solusi ini juga bekerja dengan gateway pembayaran lainnya.

Lalu ada Baremetrics – anak poster analisis bisnis berlangganan. Ini adalah produk hebat, telah ada selama bertahun-tahun, dan telah membuat banyak peningkatan akhir-akhir ini. Dan semua orang menyalinnya.

Bahkan kami menyalin Baremetrics saat kami membangun analisis pendapatan langganan di Putler.

Ya, Putler memberi Anda keseluruhan pelaporan bisnis berulang.

Masih bingung? Untuk mempermudah, inilah artikel yang membandingkan berbagai perangkat lunak penagihan langganan.

Pengalaman kami dalam menawarkan platform analisis pendapatan bisnis e-niaga dan langganan

Putler dimulai sebagai alat pelacak penjualan PayPal sederhana pada tahun 2010. Putler tetap menjadi aplikasi desktop selama bertahun-tahun dan memperoleh ribuan pengguna. Kami mengubah seluruh sistem dan mem-porting-nya ke Web pada tahun 2016.

Lihat Dasbor Berlangganan Putler

Putler adalah platform analitik e-niaga yang bermakna, dan salah satu yang terbaik di luar sana.

Mengapa?

Terutama karena pelanggan kami yang luar biasa. Kami membangun Putler dengan umpan balik terus menerus dari pelanggan. Kami telah memecahkan masalah nyata bagi orang-orang.

Putler melakukan apa yang tidak dilakukan oleh kebanyakan solusi analitik lainnya.

Begini cara Putler dibandingkan dengan kompetitor

Jadi, apa solusi terbaik untuk analitik dan pelaporan SaaS / berlangganan?

Ada banyak solusi bagus. Beberapa yang populer juga. Ada yang gratis, ada pula yang memungut biaya yang lumayan.

Berikut adalah beberapa pertanyaan yang dapat Anda ajukan untuk menemukan solusi terbaik untuk kebutuhan Anda.

• Apakah ini hanya berfungsi dengan Stripe? Atau gateway atau sistem e-commerce tertentu? Jika demikian, ini dapat membatasi Anda di masa depan.
  Bahkan jika Anda menggunakan gateway tempat sistem dibuat, apakah itu akan berfungsi dalam kasus Anda? Misalnya, beberapa solusi memerlukan rencana / produk yang ditentukan pada tingkat Stripe / gateway. Jika Anda menggunakan sistem e-niaga – seperti WooCommerce – dan hanya menggunakan Stripe untuk pembayaran, sebagian besar solusi tidak akan berfungsi.
• Bisakah solusinya menangani pembayaran yang tidak berulang? Bahkan untuk SaaS, tidak setiap dolar berulang. Anda membutuhkan sesuatu yang dapat menangani semuanya.
• Apakah platform sudah terintegrasi dengan sistem pembayaran/e-commerce Anda? Setiap orang memiliki API, tetapi menggunakan API untuk mengisi data Anda bisa menjadi tugas besar.
• Apakah ini memberi Anda sebagian besar (jika tidak semua) metrik yang ingin Anda lacak? Bisakah itu menarik data dari sistem lain – seperti Google Analytics – untuk memberi Anda pemahaman yang lebih baik tentang bisnis Anda?
• Bagaimana sistem menangani kompleksitas yang kami uraikan sebelumnya? Perubahan dalam sistem, pengalih paket, pengembalian uang, berbagai mata uang, dll?
• Apakah Anda memiliki beberapa gateway pembayaran / bisnis / situs web? Jika demikian, dapatkah solusinya menggabungkan semuanya secara akurat di satu tempat?
• Bisakah Anda memberikan akses terbatas ke anggota tim Anda? Kepada tim pemasaran atau dukungan pelanggan?
• Apakah itu hanya alat pelaporan atau lebih dari itu? Apakah itu memperkaya profil pelanggan? Bisakah laporan email? Bisakah itu menangani biaya dunning/gagal?
• Berapa harganya? Meskipun gratis, berapa banyak waktu dan usaha yang harus Anda keluarkan untuk membuatnya bekerja? Bagaimana upsell premium ditawarkan?
• Apakah mudah digunakan? Apakah Anda mendapatkan informasi yang Anda butuhkan tanpa banyak melompat kesana kemari?
• Akankah platform bertahan? Atau akan hilang selama beberapa tahun ke depan?

Apakah itu lebih banyak pertanyaan daripada yang Anda perkirakan?

Tapi saya pikir penting untuk melihat semua aspek itu.

Bagaimana menurutmu?

Cobalah. Kemudian putuskan.

Adil?