Power BIによるSaaS分析8 -分析の考え方②

前回は分析の考え方の基本について紹介しました。今回は、実際に作ったレポートの各指標について、どのように分析を行うと良いかについて見てみます。

marshal115.hatenablog.com

レポートの概要

以下が作ったレポートとなります。

https://bit.ly/3q3Y1gV

Power BIを埋め込んでいることもあり、画面が小さいと思いますので、PCを使っている場合は上記リンクより新たなタブを開いて確認することをお勧めします。

このレポートですが、構成は以下の通りになっています。

  • 左側: カードビジュアル
  • 上方: スライサービジュアル
  • それ以外の部分: チャートビジュアル

本来であれば、他のページへのナビゲーションも考慮に入れてレポートを作るのですが、分析の考え方に関する記事となりますので、そちらは割愛しています。

カードビジュアル

前回の繰り返しになりますが、

時系列分析が必要なレポートを作る場合、カードビジュアルに表示された数字の正しさを担保

する必要があります。具体的には、カードビジュアルに表示された数値が

  • いつ時点のものか
  • それらは何を意味するものか

の2つを誰が見ても分かるようにしておく、ことが重要となります。そういった意味で、今回作ったレポートはそのような情報がないため、外部と共有する場合、未完成品と言われても仕方ありません。

説明用にざっくり作ったものですので、こちらについてはご勘弁いただきたいのですが、重要なことは、

カードビジュアルはスナップショットにおける情報

をいち早く伝達することができることです。スナップショットは「その時点」という意味になりますので、ユースケースとして多いのが

経営者等が現在の状況(数字)をざっくり把握したい

場合に有効なビジュアルとなります。経営者と限定していますが、もちろんそうでない人にとっても有益な情報となります。

ちなみに、カードビジュアルで# Lost Cust(離反(チャーン)顧客数)という指標が入っていますが、こちらは上にある# CustomersからMAUを差し引いた数字と等しいものとなります。例えば、CountryスライサーでChinaでフィルターしてみると、以下のような結果となります。

f:id:marshal115:20220314132120p:plain

合計10人の顧客がいたのですが、途中でサービスを解約した人(離反顧客)が4人、と瞬時に把握することができます。また、Countryという切り口以外で絞ってみると、計5人の離反顧客のうち、4人はMale(男性)、1人はFemale(女性)ということが分かります。

スライサービジュアル

スライサーはフィルター機能を果たすビジュアルであり、今回はCountry、Sex、PriceType、そしてカスタムビジュアルですが、CustomerIDをフィルターとして使用できるText Filterというビジュアルを使用しています。

f:id:marshal115:20220314132831p:plain

異なる切り口で可視化された指標を”探索”できるため、分析に際して重要な項目は常に表示させておきたいものです。スライサーを使うメリットとして、

多次元分析が可能

であることが挙げられます。まさしく、いろんな切り口(多次元)から指標を眺めることができるため、Power BIで可視化することで

”自分の中の常識”が”気づかなった事実”に変わる

ケースもあるのではないかと思います。

私も昔はそうだったのですが、複数の指標を作ったものの、切り口をうまく組み合わせなかったことにより、偏った解釈をしてしまったことが多くありました。Excelを使って分析することが殆どでしたので、柔軟性に欠けていたといえばそうですが、Power BIを使えば、モデリング及び指標作りがしっかり出来ていれば、可視化により様々な洞察をいち早く、簡単に得ることができるようになりました。

ちなみに、上図のText Filterというカスタムビジュアルを使用すれば、粒度の高い情報(例:顧客ID、顧客名、商品ID、商品名等)を検索することができるようになります。残念ながら、Power BIの標準スライサーとして現在は存在しませんが、搭載すべきスライサーの1つであると(個人的に)考えています。

チャートビジュアル

最後に、指標を可視化したチャートビジュアルですが、こちらは4つの項目に分けて構成されています。

f:id:marshal115:20220314135117p:plain

  1. MAUの国別推移
    国別のアクティブユーザーの把握

  2. MRR by Signup Month
    コホート分析(※後述)の1つ。

  3. MRR by Price Type
    料金プラン別MRR推移及びPremiumプランの割合

  4. Various MRR Trend
    各種MRRの推移(※後述)

それぞれのチャートは異なる指標を可視化しており、全てが時系列で見れるようになっているところが特徴です。なお、②のMRR by Signup Monthと④のVarious MRR Trendについては、下記詳述しますが、②は以下のチャートとしても表現することができます。

f:id:marshal115:20220314135635p:plain

チャートビジュアルは

  • 分析しようとしている中身
  • グラフとテーブルの組み合わせ
  • 作り手のこだわり

の3つでレポートの見た目や構成が大きく変わってしまいます。個人的には今回のように、時系列チャートだけでレポートを作ることは殆どなく、常に

STD分析 + FSBC

STD略称

Snapshot

Time-series

Detail

FSBC略称

Font

Size

Balance

Color

を意識しています。古い記事になりますが、興味ある方は下記記事を参考にしてみてください。

marshal115.hatenablog.com

MRR by Price Type

上記①~④のチャートビジュアルについて、①と③については特に言及しなくても、スライサーをクリックしていろいろチェックすれば、MAUの動向及び料金プラン別のMRR、各月におけるPremiumの構成を見ることができるようになります。

一例として、ここで③のMRR by Price TypeでCountry = Chinaにした場合、下図のように、2021年10月で% Customer_Premium(Premiumプランの顧客構成)が100%となり、その中身をもう少し掘り下げてみます。

f:id:marshal115:20220314141536p:plain

  • プレミアム顧客割合(% Customer_Premium)
% Customer_Premium = DIVIDE( [# Customer_Premium], [# Customers_Signup] )
//Premiumプランの客数構成

MRR by Price Typeのチャートだけを見ても何が起こったのか不明ですが、右上のMRR by Signup Monthチャートを見ると、2021年10月に2021年7月時点のMRRが凡例として存在しているのが分かるかと思います。

これはつまり、2021年10月のMRRは2021年7月に有料サインアップした顧客によって生み出されていることを意味し、少々やり方は賢くないですが、Power BI Desktopのデータビュー(左側の2番目のアイコン)から見ると、当該顧客2人が2021年7月に有料サインアップし、同年10月にPremiumへアップグレードしていることが分かります(下図)。

f:id:marshal115:20220314142619p:plain

2021年10月では、Chinaにおいてこの2名しかユーザーがいなかったこともあり、Premiumプランの使用割合が100%になったのです。一方、その後を見ると、2022年になって新規顧客が増加したことを受け、この% Customer_Premiumの比率は大きく下落しています。

今回の例では、この100%を調べるためにどうすればよかったのか、ということになりますが、前述の通り、1つの切り口・指標だけではその要因を見つけることは至難の業であったことが言えます。MRR by Signup Monthという指標が役に立ったわけですが、こちらはSaaSビジネスにおいて必要不可欠な指標の1つであり、以下詳述します。

MRR by Signup Month

ネーミングが正しいのかどうかわかりませんが、実はこのMRR by Signup Monthという指標は、Total MRRという指標とそのまま使用しています。

  • 月次経常収益(Total MRR - Monthly Recurring Revenue)
Total MRR =
CALCULATE ( SUM ( Sales[MonthlyPrice] ), Sales[MonthlyPrice] > 0 )
//MRR = Monthly Recurring Revenue。通常の売上高に相当

f:id:marshal115:20220314143757p:plain

このチャートは積み上げグラフですが、凡例が年月になっているところがミソです。つまり、X軸は通常のdCalendar[Date]を使用していますが、あたかも同じdCalendarの中から[YM]という列を使って、積み上げグラフを作っているように見えているのです。しかし、それをやろうとすると、以下のようにエラーが発生してしまいます。

f:id:marshal115:20220314144501p:plain

MRRはSalesテーブルから算出されていますので、凡例は通常、

  • Salesテーブルにある列
  • SalesテーブルとN-1というリレーションシップのあるディメンションテーブルの列

のどちらかが使われます。実際、エラーメッセージを確認すると、以下のように「データ構造の間違い」として指摘されます。

f:id:marshal115:20220314144806p:plain

ここで、いったん立ち止まって、そもそもこのチャートは何を伝えたかったのかについて考えてみます。

詰まる所、

それぞれの月で有料サインアップした顧客がその後、有料顧客として継続した期間及び生み出したMRRの推移

を表現したものが、以下のグラフになるのです(どちらも同じもの)。

f:id:marshal115:20220314145936p:plain

どちらが見やすいかは個人の好みによりますが、金額の推移が分かりやすいのは①、開始・終了が分かりやすいのは②、といったところでしょうか。

例えば、2021年4月を見ると、この月に有料サインアップした顧客は2021年7月で最後となっており、継続期間は4か月、収益も微々たるものだったことから、有料サインアップ顧客の数も小さいことが予想されます。仮に1人だった場合、2021年6月にMRRが2倍になっているため、Premiumプランへアップグレードしたことも想定されます(実際にはこのシナリオの通りになっています)。

一方、2021年5月に有料サインアップした顧客によるMRRは最初の5ヵ月こそ良かったものの、その後はMRRが縮小してしまい、とはいえ観測期間の最後(2022年3月)まで続いています。ここで'21/05という凡例をクリックすると、クロスフィルター機能によりMAU及び課金プランの推移も分かるようになりました(下図)。

f:id:marshal115:20220314151128p:plain

この結果を見れば、自ずと顧客数推移及びMRRの減少要因が分かるようになったのではないかと思います。

このように、MRR by Signup MonthというグラフはMRRを効率よく増やせているかどうかを知るための非常に有効なビジュアルであることが分かります。いわゆるコホート分析*1と言われる指標・表現方法ですが、作り方は以下のステップ順に従います。

  1. SalesテーブルにSignupDate列(有料サインアップ日付)を追加
  2. dCalendarにFYQ(Fiscal Year Quarter)という計算列を追加
  3. dSignupという計算テーブルを作る
  4. dSignup[Date] - Sales[SignupDate]にリレーションシップを作る
  5. dSignupテーブル内の日付列(テキスト)を凡例として、MRR by Signup Monthのチャートに入れる

まずは1ですが、以下のDAX式でSignupDateを抽出できます。RELATED関数を使うことで、Salesテーブルに有料サインアップ年月(dCustomer[StartDate])を抽出します。

f:id:marshal115:20220314185358p:plain

1つの顧客に絞ってみると、全ての月において、SignupDateが抽出されていることが確認できます。

f:id:marshal115:20220314185553p:plain

2番目に、dCalendarでFYQを追加します。

f:id:marshal115:20220314190708p:plain

3番目にdSignupという計算テーブルを作りますが、Power BI Desktopより、

「モデリング」 > 「新しいテーブル」

f:id:marshal115:20220314190102p:plain

とクリックし、以下のDAX式を入力します。

  • dSignup(計算テーブル)
dSignup
    = SELECTCOLUMNS (
        dCalendar,
        "Date", dCalendar[Date],
        "YM", dCalendar[YM],
        "FYQ", dCalendar[FYQ]
    )
//dCalendarを再利用し、必要な項目を追加

SELECTCOLUMNSを使い、dCalendarから必要な列だけを抽出します。なお、dCalendarは月次ベースの日付テーブルになりますので、このやり方で作った計算テーブルのDateやYMといった列は全てユニークなレコードとなっています。仮に実務で年月日ベースの日付テーブルであった場合、下記のリレーションシップは多対多(many-to-many)となり、リレーションシップを作る場合は「dSignupテーブルでSalesテーブルをフィルターする」を選ぶ(設定する)必要があります。多対多のリレーションシップはカーディナリティが高い場合、クエリパフォーマンスが大きく劣化する可能性があるため、可能な限り1対多のスタースキーマを作ることがベスト・プラクティスとなります(今回の例ではこのケース)。

f:id:marshal115:20220314191019p:plain

4番目に、以下のように、dSignup[Date]とSales[SignupDate]のリレーションシップを作ります。

f:id:marshal115:20220314191309p:plain

これでdSignup(計算テーブルで作ったディメンション)とSales(ファクト)のリレーションシップが構築できたので、dSignupにある列をMRR by Signup Monthチャートの中で、凡例として使用できるようになりました。

f:id:marshal115:20220314191716p:plain

また、FYQを使うと、以下のように四半期別に見ることが可能となります。

f:id:marshal115:20220314191904p:plain

もちろん、Sales[SignupDate]の書式をテキストに変更し、Salesにある当該列を直接凡例として使用することも可能ですが、その都度FYQのように何度も計算列を追加しないといけないことがボトルネックとなります。それであれば、計算テーブルを1つ作り、リレーションシップを構築してディメンションテーブルにある列を凡例として追加したほうがスマートなやり方であると言えます。

Various MRR Trend

最後のチャートは下図の通り。

f:id:marshal115:20220314211656p:plain

指標(メジャー)は3つありますが、Total MRRは月次MRR、MRR from New Customersはその月における新規顧客によるMRR(Total MRRに含まれる)で紹介済みのため、MRR after SignedupのDAX式だけ見てみます。

  • MRR after Signedup
MRR after Signedup =
CALCULATE (
    [Total MRR],
    USERELATIONSHIP ( Sales[SignupDate], dCalendar[Date] )
)

このメジャーではUSERELATIONSHIPというリレーションシップを管理するDAX関数が使用され、クエリされた時(=ビジュアルにて値を返す時)にだけ、非アクティブになっているリレーションシップをアクティブにし、結果を算出する仕様となっています。そのため、Sales[SignupDate]とdCalendar[Date]の間には非アクティブのリレーションシップを作る必要があり、下記モデルビューの通り紐付けます。

f:id:marshal115:20220314222218p:plain

使用頻度は高くないのですが、必要になったら非常に便利なDAX関数であると言えます。これまでの説明を理解している人であれば何となくこのメジャーが計算している数値を想像できると思いますが、

各月において有料サインアップした顧客のそれ以降の全てのMRR

を月別に累積値として見たものとなります。この指標が面白いのは、例えば下図のように、2021年8月のMRR after Signedupの内訳を見たい場合、以下のように同月のグラフを「右クリック」 > 「増加について説明してください」をクリックすると、Power BIはAI機能を使用して、増加について候補を提示してくれるので、クリックしてみます。

f:id:marshal115:20220314213924p:plain

これにより差異要因の候補が表示され、

  • CountryではEnglandとKorea
  • CustomerIDではmps_00007とmps_00044

が影響していることが分かりました。

f:id:marshal115:20220314214214p:plain

ここで、それぞれのCustomerIDをText Filterで検索してみます。まずはmps_00007を検索(部分一致でOKなので、00007とに入力)してみると、以下のように分かりやすい結果として返ってきます。

f:id:marshal115:20220314214752p:plain

  • Englandのユーザーである
  • Total MRRが途中からPremiumに切り替わっている
  • 2022年3月まで当該ユーザーはサービスを継続利用している

一方、mps_00044を検索してみると、以下のようになります。

f:id:marshal115:20220314231858p:plain

  • Koreaのユーザーである
  • Total MRRが途中からPremiumに切り替わっている
  • 2022年3月まで当該ユーザーはサービスを継続利用している

これにより、どちらの顧客も継続利用期間が長く、かつ、Premiumへアップグレードしたことが、2021年8月時点から見たその後のMRRを効率よく生み出していたことが判明しました。

まとめ

2回にわたって、分析の考え方を作成したレポートをベースに解説しました。今回のまとめは以下の通りです。

  • チャートは作っただけでは完結ではなく、その先の活用まで考える
  • レポートは作る人、中身によって千差万別であるが、STDとFSBCに着目すると、それなりに見栄えの良いレポートを作れる可能性が高い
  • データモデルがしっかり構築できていれば、指標を作るためのDAXは非常にシンプルになる
  • いろいろ”探索”してみて、細かいところまで手が届くよう、ビジュアル・デザインを行う

探索的データ分析はそれ自体、難しいものではなく、Power BIでレポートを作る殆どの人が無意識的にやっている作業になります。シンプルですが、実はかなりパワフルな分析だと思いますので、ぜひ参考にしてみてください。次回はコホート分析についてもう少し見ていきたいと思います。

marshal115.hatenablog.com

*1:ユーザーの行動をグループ化し、指標ごとに数値化した分析