Power BIによるSaaS分析7 -分析の考え方①

基本的なメジャーを一通り作り終わりましたので、少し分析の話に入りたいと思います。Power BIで行う分析の多くは「探索的データ分析（EDA）*1」に区分されます。すなわち、データから主な特性を抽出し、変動やトレンド等をいち早く把握するため、可視化を行う分析手法となります。その結果、

過去→現在（→将来）

のうち、過去（時系列分析）と現在（スナップショット分析）をそれぞれ行うことで将来に対するアクションを決めることができるようになります。

長年アナリストをやっている人でも忘れがちですが、可視化はそれ自体が目的ではなく手段であること、「可視化＝ゴール」にならないよう、常に最終ゴールおよびそれを実現するために行う質問（5W1H）を意識することが重要となります。

可視化の前に考えること

ダミーデータとは言え、シリーズ別に今まで作ってきた指標は非常に多く、これら全てを可視化するのは現実的ではありません。従って、作った指標のうち、使用できるものとそうでないもの（＝重要性が低いもの、あるいはそもそも使用しないもの）に分けて考えることになります。

ただ、ここでも上述の探索的データ分析（EDA）になりますが、

可視化してみないと良く分からない

というのもまた事実です。そこでどこからor何から考えればよいのかについて少し見ていきます。

• 分析するサブジュクトが何か？（以下複数例）
  • ビジネス系（SaaSビジネス、在庫・販売分析、マーケティング等）
  • 顧客調査系（アンケートによる顧客満足度等）
  • HR系（人事データを使った離職率などに関する分析）
  • 一般公開情報系（COVID-19等）

• 分析の切り口
  • データの鮮度（時系列データの有無）
  • ファクト（実績・予算等のデータ）の整備
  • マスタ（商品・顧客・拠点等）のどれを使用するか

• 使用指標
  • 売上用指標
  • 在庫用指標
  • 利益率指標
  • 経費率指標
  • 顧客分析用指標, etc

これらをまとめたのが下図となります。

サブジェクト × 切り口 × 使用指標

ここで強調したいことは、サブジェクト別に見た場合、使用する切り口も指標も変わるため、ドメイン（その分野の）知識が重要になってくるということです。ビジネス系の分析に限って言えば、業界・業種、その他様々な制約や条件によって分析出来るコンテンツが変わってくるため、何も知らない状態から分析をいきなり開始しようとすると、ツールを使いこなす前に指標作りの段階でかなりハードルが高くなってしまいます。

そこで考えられるやり方の1つとして、分析を開始する前にその分野について徹底的に調べ、自分が納得できるレベルまでドメイン知識をある程度身に付けることです。当然ながら、自身のドメイン知識が豊富であれば見るべき指標に熟知しているはずですし、そこがスタート地点となります。一方、そうでない場合、実務経験がないとなかなか難しいですが、闇雲に"なんちゃってデータ分析"を開始するよりも事前調査・学習をある程度行ったほうが良いと思います。これは、

自分が良かれと思って分析した結果は、その道のプロから見れば素人レベル

になってしまう可能性があるからです。なお、その道（ドメイン知識）のプロがいる場合、その人にヒアリングしてベスト・プラクティス等を教えてもらうのも手です。しかし、これもそのような人が身の回りに居ればの話になりますので、まずは自分で頑張ることを意識したほうが良いでしょう。

指標の可視化

分析を開始するのに最も良いのが指標を可視化することです。分析は探索的分析、統計理論を使った分析、その他高度な数理的分析等、多くありますが、多くのケースでビジネスにおける困り事を解決するのは探索的分析（「ビジュアル分析」という表現でも良いかもしれませんが）で十分であることが多いように思います。

人間が理解でき、かつ次に何をすれば良いかを判断できる

限り、複雑な分析を必要としない場合も多いと思います。

今回のシリーズのSaaSビジネスにおける可視化を考えてみると、ビジネスインパクトが最も高い指標を重点的に可視化し、それをモニタリングしていくことが重要となります。そこで、分析において常に相互補完となる数量ベース vs 金額ベースの指標をバランス良く配置し、可視化していくことを念頭に置きます。

SaaSでは顧客数と収益額の2つから、成長性・ビジネスの健全性等を測るため、それぞれの項目から算出される指標をモニターしていくことがベースとなりますので、今まで作った指標を使って、例えば以下のようなレポートを構築してみます。

ここで、今まで話をしてきたことをもう一度まとめてみると、以下のようになります。

• サブジェクト
  • SaaSビジネス
• 切り口
  • 時系列に下記項目別
    • Country（国）
    • Sex（性別）
    • Price Type（課金タイプ）
• 指標
  • Total MRR: Monthly Recurring Revenue（月次売上高）
  • # Customers: 有料サインアップ顧客数（※後述）
  • MAU: Monthly Active Users（月次アクティブユーザー数）
  • # Lost Cust: 離反顧客数
  • ARPU: Average Revenue Per User（1ユーザーあたり平均売上※後述）
  • MRR by Signup Month: 有料顧客へSignup後のMRR推移
    ※コホート分析の1つ、その月でSignupした顧客のその後のMRR。この指標を算出するには、データモデルを少し変更する必要あり。
  • MRR from New Customers: 新規顧客によるMRR（その月のみ）

上記の組み合わせにより、何かしらの洞察を得られないかということを考えていくわけです。ここで重要なことは、探索的データ分析を始める場合、必ずしも上記のようなキレイなダッシュボード（orレポート）を最初に構築しなくても良いことです。

例えば、まずはいくつかのグラフやテーブルを作り、ドラフトベースでいろいろ”探索”してみます（下図がこれに当たりますが、ドラフトのため、タイトルが中身と一致しなくても構いません）。

作成するグラフは適しているものとそうでないものが存在しますが、SaaSは時系列分析が必須となりますので、時系列 × 切り口 × （重要な）指標から切り込んでいくと、自ずと必要なビジュアルが分かるようになるわけです。

計算結果の正確性

ここで、下記2つについて考えてみます。

1. 全ての指標を使うことはできない
2. レポート上の数字はどの切り口から見ても正しく反映させること

上記2つの1番目は前述の通り、指標の”チェリーピック”を行う必要があります。指標を厳選するので、2番目の数値の正確性はより重要になってきます。以前の記事でも書きましたが、

DAXを使用してどのような条件下においても正しい数字を表示

させることはデータ・モデラー（データモデル・メジャー構築を行う人）の仕事であり、BI開発のテスト環境において、ビジュアル・デザイナーも巻き込んでチェックを行っていくことが必須です（以前の記事は以下より）。

特に合計値が期待する結果とならない場合、

カードビジュアルを安易に使用することができない

ことに留意する必要があります。今回の例では、以下の2つが間違っている（あるいは、説明を要する）ものとなります。

① # Customers vs MAU

# Customersは以前作った下記メジャーとなります（今回の例では# Customersとしてて使用）。

• 有料サインアップ顧客数（# Customers_Signup）

# Customers_Signup =
CALCULATE (
    [# Customers],
    KEEPFILTERS ( 'dEventType'[EventType] = "Signed-up" )
)
//有料顧客数（通常の顧客数メジャー）。合計値は集計できない、かつ、最終月とも一致しな

このメジャーは

# Customers = DISTINCTCOUNT( Sales[CustomerID] )

というメジャーを評価する前に、Sign-up顧客をフィルター条件として設定したものであり、DISTINCTCOUNTを使うメジャーはdCustomerテーブル以外、dCalendar等のテーブルでみた場合、

合計値 ≠ それぞれの年月の合計

となります。従って、# Customer = 30という数値は何を意味するのか、一見すると混乱を招く結果となっています。実際、この30というのは、観測期間における全ての有料サインアップ顧客数であり、この数字には離反（チャーン）顧客も含まれています。従って、この数字を表示させたい場合、注釈がない限り、非常にミスリーディングなものになる可能性があります。

在庫と同じ考え方であれば、通常この# Customersは直近月におけるユーザー数を表示させたほうが自然で、

1. その月において存在する客数
2. MAU（Monthly Active Users）
   月に1回でも当該サービスを利用したことがある顧客。通称「マウ」

のどちらかを使用することになると思います。今回の例では有料サインアップ顧客 = MAUと仮定しますので、MAUを使用します。MAUの計算は以下のようになります。

• MAU（Monthly Active Users）

MAU =
VAR _last_visible_date =
    CALCULATE ( MAX ( Sales[Date] ), ALLEXCEPT ( Sales, dCalendar ) )
VAR _result =
    CALCULATE ( [# Customers_Signup], dCalendar[Date] = _last_visible_date )
RETURN
    _result
//在庫残高を算出する場合と同じロジックを使用

_last_visible_dateはLASTDATE( dCalendar[Date] )を使って算出しても良いのですが、上記の書き方はパターンの1つで、なかなか応用も利きますので、Deep-diveしてみたい方は下記記事も併せて参考にしてみてください。

② ARPU_Wrong vs ARPU

次にARPUというメジャーですが、間違った結果と正しい結果の定義は以下の通り。

• ARPU_Wrong（Average Revenue Per User、1ユーザーあたり平均売上）

ARPU_Wrong =  DIVIDE( [Total MRR], [# Customers_Signup] )
//合計MRRを有料サインアップ顧客数で割った数値

• ARPU（Average Revenue Per User、1ユーザーあたり平均売上）

ARPU = 
VAR _number_customers_total =
    CALCULATE ( COUNTROWS ( Sales ), dEventType[EventType] = "Signed-up" )
VAR _result =
    DIVIDE ( [Total MRR], _number_customers_total )
RETURN
    _result
//合計MRRを月次の顧客数総数（合計は毎月の累積）で除算

この計算結果は以下の通りとなります。

赤枠内の5,331円は明らかに間違いであり、これは159,930円 ÷ 30人から算出されています。30という数字、また出てきましたが、ARPUの「合計」は毎月の顧客数を単純合計した数値で割る必要があるため、DISTINCTCOUNTが使われている# Customers_Signupというメジャーは使用できないことになるわけです。そこで正しいメジャーであるARPUはこの部分を加味し、結果的に正しい数値（1,367円）を算出しています。

まとめ

• 分析には様々なやり方があるが、探索的データ分析（EDA）が1つのやり方
• 分析を行うためには、過去から現在までのデータが必要であり、過去と現在を知ることで将来を予測していく
• 分析のための可視化は重要であり、如何にシンプル、かつ、示唆に富んだ指標・レポートを作れるかが重要である
• サブジェクト × 切り口 × 使用指標の組み合わせを考えて分析を行っていくと良い
• レポートに表示させた数字は間違えないよう、細心の注意を払うこと

次回は、コホート分析の入り口となるMRR by Signup Monthやその他指標について詳しく見ていきます。

marshal115.hatenablog.com

*1:Exploratory Data Analysisの略