「SaaSは科学」と言われるように、SaaS事業の成長はKPIの分解が鍵だ。
PLG（Product-Led Growth）戦略を掲げる場合、いわゆるTHE MODEL形式のKPIツリーとは異なった形となる。

基本的には口コミベースの流入からオンボーディングし、有料トライアルにつなげ、課金まで持っていくフローとなるためシンプルだ。



microCMS社で当初考えていたKPIの分解式はこんな感じだった。

しかし、改めて考えてみるとmicroCMSはアカウント単位ではなくサービス単位の課金である。
アカウント登録後、サービス作成のフローに進むので次のように改良した。

当月分だけを追っても不正確

microCMSにはユーザー招待の仕組みがある。
招待された場合はすでに作成済みサービスに所属することになるため、招待されたユーザーはアカウント登録はするがサービス作成はしないことになる。

また、サービスとアカウントの関係はN対Nであり、一人が複数サービスを作成できるし、一つのサービスに複数人が所属できる。
つまり、先月アカウント登録したアカウントでも今月2つめのサービスを作成する可能性があるため、上記の式に過去のアカウント登録数も考慮に入れる必要がありそうだ。

すでにだいぶ複雑になってきた。
当月のサービス作成数は当月アカウントと過去アカウント双方からの作成数で出すことができた。

実際に計測してみたところ、当月のサービス作成数の半数は過去アカウントからの登録だということがわかった。（衝撃）

仮に、1000件のアカウント登録数に対し、500件のサービス作成がされていたら作成率50％だと思うだろう？
実はその500件のうちの半分は過去のアカウント登録分からの作成で、1000件のアカウント登録からは250件しか作成されていなかったというわけだ。
つまり25%の作成率というわけだ。

そうなると完全に色々な仮説が崩れてしまうので、ちゃんと調べて本当に良かったと思った。


そして同じことが有料トライアル数にも言える。
当月作成されたサービスがトライアルする数と過去に作成されたサービスが遅れてトライアルする数の合計とするべきである。

microCMSはフリーミアム形式を取っているため、サービス作成時は無料プランから始めることができ、無料でも案件規模によっては問題なく使えるので、トライアルまでの期間が長くなってしまうケースは往々にある。



過去に作成されたサービスも考慮すると次のような式となる。

こちらも実際に計測してみたところ、当月のトライアル数の40%は過去サービスからのトライアルだということがわかった。（衝撃その２）

また、アクティブ数の計算式は下記とした。

これらをエクセル上で組み立てることで、どの数値を伸ばせばどれだけ売上を伸ばすことができるのか予測できる。

継続率という概念

ここまで分解してやっと出てくる数値が「継続率」だ。
プロダクトを改善する場合、継続率に直結する施策は多い。

しかし、継続率を改善したとして、実際にどれくらい売り上げに貢献できるか定量的に測れているケースは多くないと思う。

また、当月と過去分で分けた理由は、毎月ごとに改善の効果を計測するためだ。
これを丸っと全アカウント数や全サービス数で見てしまうと平された数字となってしまうため、効果が見えづらくなってしまう。

microCMSでいうと、先月までのアクティブサービスが翌月も継続する割合は90%以上だが、当月登録されたサービスが翌月も継続する割合は50%を切っているという結果が出た。
一度定着すれば継続しやすいが、最初の定着の難易度が高いというわけだ。（当たり前だが・・・）

90%超えの数値を改善するのは難しいが、50%未満の数値は改善しがいがある。

ちなみに継続率を改善するとどれくらい売り上げが伸びるかをエクセルで計算したところ、そこまで大きく伸びる要因ではなかった。
しかし、継続率を伸ばすことでトライアル率が増加したり、体験向上から口コミにつながり、そこからアカウント増加などの副次的な効果もありそうだ。

計測が大変

KPIを細かく分解するのは良いが、計測が結構大変である。
特に継続率は難しく、何を以て継続とみなすかをどう定義するのかが重要だ。

GAやらHubSpotやら色んな値をかき集めて計測しているが、ソースが一箇所ではないため不整合が起こってしまうことも多い。
（継続率が100%超えの数値になってしまうなど）

数字を細かく追いすぎてしまうのも泥沼にハマってしまうので良くない。

ある程度ラフな値でも、全体の傾向をつかみ、施策による改善を計測できるのであれば良いと思う。

まとめ

SaaSはシンプルに見えて、実際のユーザーの動きは複雑だ。
できる限りユーザーのフローに沿ったファネルを用意し、計測する基盤を作ることで改善を回しやすくなるだろう。

月ごとのファネルを作成する場合は、過去登録分も当月分に影響に与えている可能性もあるので注意が必要。
（プロダクトの性質にもよりけりだと思う）