サブスクリプションメトリクス分析：MRR、解約率、ARPPUなどを計算する方法

ああ甘いMRR！ SaaS/サブスクリプション/メンバーシップ/経常収益ビジネスの進歩の基準。

サブスクリプションビジネスの所有者またはマーケティング責任者に相談すると、MRRが期待どおりに成長していないことについて批判するか、目撃した驚異的なMRRとホッケースティックの成長について雄弁に語ります。

解約率と当座比率について説明する人もいます。 解約を50ベーシスポイント下げるための、督促、復旧メール、継続的なユーザーエンゲージメントのアクションプラン。

さて、やめましょう。

あなたが定期的な請求ビジネスにいるなら、あなたは確かに状況を知っています。 そうでない場合は、サブスクリプションシステムに移行することをお勧めします。

では、これらのサブスクリプションメトリックは何ですか？ その専門用語はどういう意味ですか？

我々は持っていますこれらのSaaS/サブスクリプション/定期的なビジネス指標の詳細な説明。 とりあえず、簡単に説明します。

インターネット上のサブスクリプションビジネスメトリックの最も簡単な説明

• MRR、ARR：月間経常収益と年間実行率。 基本的に、あなたは月にいくらのお金を稼いでいますか？
  月間隔で繰り返されないサブスクリプションは、月単位に「変換」されます。 例えば、 年間サブスクリプションの金額を12で割ったり、週間サブスクリプションに4.33を掛けたりすることができます。
• チャーン：毎月失っているもの–収益、顧客、サブスクリプションの数。 通常、MRRのパーセンテージとして示されます。
• スイッチ：人々はサブスクリプションプランを変更します。 アップグレードとダウングレードを追跡したい。 アップグレードはMRRを拡張し、ダウングレードはMRRを縮小します。
• トライアル：トライアルの数、トライアルから有料への変換率。トライアルは製品プランと見なすことができ、ユーザーが有料プランに切り替えると「アップグレード」と見なすことができます。 しかし、それ自体で測定する価値があります。
• ARPU、ARPPU、ARPA：ユーザーあたり（または有料ユーザーあたり、またはアカウントあたり）の平均収益。 これは基本的に、MRRを顧客数（または無料トライアルがある場合は有料顧客数）で割ったものです。 状況によっては、組織のすべてのユーザーを組み合わせて、それらの総収益をアカウントあたりの平均収益としてカウントしたい場合があります。
• CLTV、LTV：顧客の生涯価値。 ほとんどの場合、解約率を逆転させて、顧客がアクティブでいる平均月数に到達します。 次に、それをARPUで乗算して、LTVに到達します。
• CAC：顧客を獲得するためのコスト。 レポートシステム自体はコストを考慮していないため、これは多くの場合、内部メトリックです。 CACとLTVを比較すると、顧客が生涯にわたってどれだけ利益を上げているかがわかります。 損益分岐点が速いということは、スケーラビリティと評価が向上することを意味します。
• 当座比率： 1か月に追加する金額を、失う金額で割ったもの。 あなたが浮いているか沈んでいるかをすばやく示します！
  数式は（新しいMRR +拡張MRR）/（収縮MRR +チャーンMRR）。
  サブスクリプションをステータス（新規、アクティブ、再アクティブ化、チャーン、キャンセル、一時停止など）で測定することもできます。
  もう1つの重要な測定値は、「失敗した料金」です。 クレジットカードは常に有効期限が切れており、顧客ベースが拡大するにつれて、失敗した請求の試行回数は増加します。
• 督促：これは、これらの障害を回避して回復するプロセスです。 優れた督促ソリューションは、収益に10〜20％を簡単に追加できます。
• 払い戻し：多くの人は、キャッシュフローの変化であるため、チャーンに払い戻しを含めません。 払い戻しによってサブスクリプションがキャンセルされた場合、それはチャーンとしてカウントされます。
• キャッシュフロー：現金は正気であり、他は虚栄心です。 キャッシュフローを監視することは、ビジネスにとって非常に重要です。
  これらすべての指標の製品およびバリアントごとの内訳。 サブスクリプション製品を「プラン」と呼んでも、他の何かと呼んでも、各製品の重要な番号を追跡することは確かに役立ちます。

これらすべてとは別に、これらのメトリックを履歴データと比較して傾向を確認し、将来の計画の予測を取得することもできます。

信じられますか？ 私の簡単な説明はこれほど長いですか？

MRRおよびその他のメトリックの測定と計算–シンプルでありながら包括的なソリューション

ここでは、データベースとクエリについて説明します。 プログラミングやデータベースに興味がなくても心配しないでください。 できるだけシンプルにしておきます。

しかし、これらを理解していれば便利です。 それは一日の終わりの数学であり、それはあまりにも単純な数学です。

これは私たちが見つけた最も包括的でありながら簡単なアプローチ。 すぐにソリューションにエレガンスが表示されます。

さて、飛び込みましょう。

パート1：重要な情報の保存

まず、サブスクリプショントランザクション情報をMySQLテーブルなどに保存していると仮定します。 そのため、新しいサブスクリプションを受け取ったり、支払いを受け取ったり、ステータスが変更されたりするたびに（キャンセル、有効期限、請求の失敗など）、そのテーブルにエントリがあります。

すべてのイベントをサブスクリプションに記録しているため、このテーブルは時間が経つにつれて大きくなります。

この表からMRRを計算することはお勧めできません。

MRRの計算方法は？

「重要な」イベントのみを格納する新しいテーブルを作成しましょう。 サブスクリプションを大幅に変更するもの。 サインアップ、アップグレードまたはダウングレード、有効期限、試用版から有料版への移行など。

また、MRR（およびその他のメトリック）をバリエーションレベルまで計算できるように、製品とバリエーションの識別子をテーブルに保存する必要があります。

また、顧客レベルでもメトリックを計算できるように、顧客のIDを保存する必要があります。顧客には複数のアクティブなサブスクリプションがある可能性があることを忘れないでください。

これがこの表からの抜粋です。

2018-07-25123john @ domainputlergrowthupdated10079USD

簡単な英語で、

• ジョンは7月10日に裁判に申し込んだ。 25日に月額79ドルの有料プランに変換されます。
• 8月15日に$249/mのより高いプランにアップグレードされました。
• どういうわけか彼は続けたくなかったので、彼は12月10日にキャンセルしました。
• しかし、彼の月額サブスクリプションはその月の14日まで支払われたため、彼は14日まで製品を使用し、15日に期限切れになりました。
• MRRを249ドルから0ドルにタンブリングします。

他のユーザーのために、このテーブルにさらにいくつかのエントリを追加してから、メトリックの計算を開始しましょう。

• ここでは、アニーとマークの2人の顧客を獲得しました。
• アニーはPutlerStarterの試用から始め、翌日有料プランにアップグレードしました。
• 最終的に、彼女は別の製品である10xFormulaを$99 / mで購入しましたが、試用期間はありませんでした。
• マークはトライアルにサインアップし、20日後に$ 79/mの支払いを開始しました。
• 最終的に、彼は年払い（$ 29 / m、ただし$ 290 /年）のより低いプランにダウングレードし、MRRを$ 290/12 =$24.17に引き下げました。

パート2：MRRの計算、支払いの試行、チャーンなど…

2018年12月20日の時点で、さまざまな指標を計算してみましょう。
MRRを見つけるのが最も簡単です！

new_mrrからold_mrrを差し引く理由を疑問に思うかもしれません。 また、SQLクエリに精通していない場合は、そこにあるSUMビットで混乱する可能性があります。

これについて少し考えてみてください。 ペンと紙を取り、差を計算して合計します。

次に、そのロジックを使用して、異なる日付のMRRを計算します。

本当に、時間をかけて考えてみてください。 これを完全に理解すると、他のすべてが簡単になります。

…

終わり？

Ok。

解約率の計算方法は？

これは、解約によるMRRの損失、および解約したサブスクリプションの数を示しています。

難しくないですよね？

支払われるトライアルを計算する方法は？

もう少し複雑なものを見てみましょう。

わお！ これまでにたくさんのことを成し遂げました！

他のKPIを見つけるための可能な方法を簡単に説明します。

• スイッチ：イベントタイプが「更新」され、新しいMRRが古いMRRよりも大きい場合、それはアップグレードです。 それ以外の場合はダウングレードします。
  同様に、 すべての新しいMRR+アップグレード=MRRの拡張。 すべてのチャーン+ダウングレード=MRRの縮小。
• アクティブなサブスクリプション：キャンセルされたトライアルまたは変換されていないトライアルを除く、一意のサブスクリプションID。
• 有料ユーザーあたりの平均収益： MRRをアクティブなサブスクリプション数で割ったもの。 （「サブスクリプション」ではなく「ユーザー」が必要な場合は、アクティブなサブスクリプションを持つ一意の顧客の数を選択できます。）

あなたは写真を手に入れます！

それで、なぜ私はこのパンドラの箱を世界で呼んでいるのですか？

パンドラは誰ですか？ そして、彼女の箱には何が入っていますか？

パンドラはギリシャ神話の登場人物です。

プロメテウスは天から火を盗み、罰としてゼウス（神々の王）はパンドラをプロメテウスの兄弟エピメテウスに贈った。

パンドラの世話に瓶が残され、彼女はそれを開けました–病気、死、そして他の多くの悪を世界に解放するためだけに。 彼女はすぐに容器を閉め、ホープは取り残されました。

今日、「パンドラの箱を開ける」というイディオムは、多くの予期せぬ大きな問題を引き起こす何かをする、または始めることを意味します。 「ワームの缶を開ける」という意味に似ています。

サブスクリプションビジネスメトリックの計算は、より正確にしようとするとますます難しくなります。

指標は進捗状況の測定値です。 人々は、どのメトリクスが報告するかに基づいて、将来の行動を計画します。 したがって、正しいメトリックを持つことが非常に重要です。

計算で$12000MRRが示されているが、キャンセルを差し引くのを忘れた場合、それは機能しません。

メトリックの計算に誤りがあると、間違った決定をすることになります。

了解しました。正確な指標が不可欠であることに同意します。 しかし、それはどのようにしてますます複雑になりますか？

サブスクリプションの収益レポートが非常に複雑になるのは次のとおりです。

実を言うと、私たちは長い間、eコマース分析ソリューションであるPutlerでサブスクリプションレポートを作成することを避けました。 最初の数回の試みはすぐに失敗しました。

最後に、すべての合併症とエッジケースを処理するソリューションを構築しました。

結局、それも不十分であることが判明しました。 これは、上記で概説したアプローチに基づいてすべてを再構築したときです。

後でPutlerについてもう少しお話ししますが、ここにSaaS分析/メトリクスソリューションの構築で観察された主要な問題のリスト。

• これらすべてのメトリックを計算するための一般的に受け入れられている方法はありません。レポートソリューションが異なれば、計算方法も異なります。 したがって、データを他の人と比較している場合は、不一致が発生する可能性があります。
• ガベージイン、ガベージアウト：すべてのトランザクションのログが不完全または一貫性がない場合、サブスクリプションイベントテーブルのエントリが不十分になります。 たとえば、過去2年間のトランザクションからサブスクリプションイベントデータを作成すると、この期間より前に発生した重大なイベントを見逃す可能性があります。 または、支払いゲートウェイ/ eコマースシステムが作成と最初の支払いに同じ日付を設定している場合、またはその他の不整合がある場合、メトリックは間違っています。
• EコマースシステムとペイメントゲートウェイAPIは変化します：それらは提供するデータの種類を変えるかもしれません。 これは2つのことを意味します。1つは、ロジックを常に更新する必要があることです。これはまだ問題ありません。 しかし2つ目は、古いデータは古い形式であり、新しいデータは新しい標準である可能性があるということです。 このような場合は、すべてを正規化して同じ形式にする必要があります。
• 新しいサブスクリプションイベント：新しいサブスクリプションイベントが発生するたびに、必要に応じてテーブルを確認および更新する必要があります。 ほとんどのゲートウェイは、アップグレード/ダウングレードを示していません。 多くは試験情報を示していません。 したがって、これらのパターンをスマートに識別する必要があります。
• 複数の通貨：異なる通貨での支払いを受け入れる場合は、為替レートを調べて、すべてを「基本」通貨に変換する必要があります。 これは、それ自体が課題になる可能性があります。
• 複数の支払いゲートウェイ/eコマースシステム： StripeとPayPalの両方の支払いを受け入れる場合、後でトランザクションに関して提供される情報の種類は異なります。 たとえば、PayPalAPIはサブスクリプション間隔と終了日を提供しません。 このような場合、サブスクリプションとその詳細を検出する「ファジー」な方法を構築する必要があります。 ゲートウェイ間でこのような違いを統合し、データを統合することは非常に困難です。
  製品およびバリエーションレベルのメトリックはすでにプロビジョニングされています。 しかし、製品/プランの名前は常に変わります。 より高い精度を得るには、製品をマージ/グループ化するシステムを構築する必要があります。
• データの不正確なeコマースシステム：eコマースシステムを使用すると、最も正確なデータが得られない場合があります。 確認するには、支払いゲートウェイと関連付ける必要があります。 この重複排除のプロセスは集中的です。

経常収益の指標を追跡したいですか？ ここにあなたの選択肢があります…

これは適切な例えです。 主要業績評価指標を追跡していない場合は、どこに向かっているのかわかりません。 （ところで、Crossing the Chasmをまだ読んでいない場合は、機会があれば読んでください。）

すべての真面目なビジネスパーソンは、重要な測定値を追跡することの重要性を知っています。 そして、分析およびレポートツールに不足はありません。

でもまず： Excel（またはGoogle！）スプレッドシートを使用してSaaSサブスクリプションメトリックとKPIを追跡することを間違えないでください。 スケーリングしません。

それで、あなたの選択肢は何ですか？

すべてのeコマースシステムには、ある種のレポートシステムが組み込まれています。 すべての支払いゲートウェイもそうです。 あなたはそれらから始めることができます。

Google AnalyticsやMixpanelのような汎用分析ソリューションでさえ、eコマースの収益を追跡できます。 それらを使用することはできますが、これまで説明してきたサブスクリプションKPI（MRR /チャーンなど）は取得できません。

SaaSの成長と繰り返し発生するビジネスモデルを考えると、数十の新興企業がSaaSメトリクスに特化したソリューションを立ち上げています。 特にStripeを使用する場合は、多くのオプションがあります。 ChartMogul、Control、ProfitWell、Compass、Statsbot、Supermetrics…–リストは続きます。 これらのソリューションの多くは、他の支払いゲートウェイでも機能します。

次に、サブスクリプションビジネス分析のポスターであるBaremetricsがあります。 それは素晴らしい製品であり、長年そこにあり、最近多くの改善を行いました。 そして、他のみんながそれらをコピーしました。

Putlerでサブスクリプション収益分析を構築したときに、Baremetricsをコピーしました。

はい、 Putlerは、定期的なビジネスレポーティングの全範囲を提供します。

まだ混乱していますか？ 物事を簡単にするために、ここにさまざまなサブスクリプション課金ソフトウェアを比較する記事があります。

eコマースおよびサブスクリプションビジネスの収益分析プラットフォームを提供した経験

Putlerは、2010年にシンプルなPayPal販売追跡ツールとしてスタートしました。それは何年もの間デスクトップアプリであり続け、何千人ものユーザーを獲得しました。 2016年にシステム全体を刷新し、Webに移植しました。

Putlerのサブスクリプションダッシュボードを見てください

Putlerは、意味のあるeコマース分析プラットフォームであり、最高のプラットフォームの1つです。

なんで？

主に私たちの素晴らしい顧客のために。 お客様からの継続的なフィードバックをもとにPutlerを構築しました。 私たちは人々の本当の問題を解決しました。

Putlerは、他のほとんどの分析ソリューションが実行しないことを実行します。

これがPutlerと競合他社との比較です

では、SaaS /サブスクリプションの分析とレポートに最適なソリューションは何ですか？

多くの良い解決策があります。 いくつかの人気のあるものも。 いくつかの無料、いくつかの高額な料金があります。

ニーズに最適なソリューションを見つけるために尋ねることができるいくつかの質問があります。

• Stripeでのみ機能しますか？ または特定のゲートウェイまたはeコマースシステム？ もしそうなら、これは将来あなたを制限する可能性があります。
  システムが構築されているゲートウェイを使用している場合でも、それはあなたの場合に機能しますか？ たとえば、一部のソリューションでは、Stripe/ゲートウェイレベルで定義されたプラン/製品が必要です。 WooCommerceなどのeコマースシステムを使用していて、支払いにのみStripeを使用している場合、ほとんどのソリューションは機能しません。
• ソリューションは定期的でない支払いを処理できますか？ SaaSの場合でも、すべてのドルが繰り返されるわけではありません。 すべてを処理できるものが必要です。
• プラットフォームは、支払い/ eコマースシステムとすぐに統合できますか？ 誰もがAPIを持っていますが、APIを使用してデータを入力するのは大きな作業になる可能性があります。
• 追跡したいほとんどの（すべてではないにしても）メトリックが得られますか？ Google Analyticsなどの他のシステムからデータを取得して、ビジネスをより深く理解できるでしょうか。
• システムは、前に概説した複雑さをどのように処理しますか？ システムの変更、プランの切り替え、払い戻し、複数の通貨など？
• 複数の支払いゲートウェイ/ビジネス/ウェブサイトがありますか？ もしそうなら、ソリューションはそれらすべてを1か所に正確に統合できますか？
• チームメンバーへのアクセスを制限できますか？ マーケティングチームまたはカスタマーサポートチームに？
• それは単なるレポートツールですか、それともそれ以上のものですか？ それは顧客プロファイルを豊かにしますか？ レポートをメールで送信できますか？ 督促/失敗した請求を処理できますか？
• いくらですか？ 無料だとしても、それを機能させるためにどれくらいの時間と労力を費やす必要がありますか？ プレミアムアップセルはどのように提供されますか？
• 使いやすいですか？ あちこちジャンプすることなく、必要な情報を入手できますか？
• プラットフォームは存続しますか？ それとも、今後数年間で失われるのでしょうか？

予想以上に多くの質問でしたか？

しかし、私はそれらすべての側面を見ることが重要だと思います。

どう思いますか？

それらを試してみてください。 次に決定します。

公平？