1.
基本的なKPI分析の進めかた
― 継続率経営に向けて ―
株式会社pLucky
2013-01-24
(c) 2013 pLucky, Inc

2.
まずはpLuckyチーム自己紹介
Netageグループ各社で開発・経営企画に携わった後、頓智ドットにて
林 宜宏 経営指標管理を主導。自ら分析ツールを開発しつつ各種予測モデルを構
CEO 築し活用した。培ったノウハウを譲り受けて独立。京都大学 卒業
SRA、頓智ドットを経て現職。Playing Managerとしてチームを束
河内 崇 ねる。各種Low Layerの分散システムの開発経験を持ち、前職では
開発チームマネージャ iPhone開発チームをリードした。東京大学大学院 卒業
Netageから楽天、頓智ドットを経て現職。開発チームの柱としてチー
塚本 朗仁 ムに貢献。WEBの先端技術全般に明るく、ECからポータルサイトまで
テクニカルリード 様々なタイプのWEB開発経験が豊富。
頓智ドットを経て現職。コンサルティングおよびマーケティング担当。
田畑 直 在学中に独立系コンサルを経て頓智ドットに。世界に向けてDoMoのプ
コンサルタント レゼンを手掛け経営企画に携わった。東京大学 中退。米国帰国子女
(c) 2013 pLucky, Inc

3.
この資料の目的
pLuckyはデータドリブン経営をサポートするための
ツール『SLASH-7』を開発しています。
今後『SLASH-7』をより多くの方に活用していただ
くためにも、データドリブン経営のサポートとなる考
え方やTIPSを皆様にご紹介していきたいと考えていま
す。この資料はその一環です。
今回はデータドリブンな経営を行う際に必要となる、
取得するべきデータ設計の流れを解説しました！
(c) 2012 pLucky, Inc

4.
この資料に含まれているもの
１．サービス改善とデータによる分析の関係
２．データ取得・設計のプロセスを各ステップ毎に解説
(c) 2013 pLucky, Inc

5.
この資料が意味を持ちそうな人
・データドリブン経営に興味があり試してみたい人
・プロジェクトのKPI設計に迷っている人
・データの取得はしているが施策に活用できていない人
(c) 2012 pLucky, Inc

6.
サービス改善とデータによる分析
(c) 2013 pLucky, Inc

7.
Build Measure Learnが開発の基本
・製品は必ず改善可能
Build
という前提にたつ
Idea Product ・常に新たな課題を発
見し改善し続ける
・１サイクルの期間は
長くて１∼２週間、
Learn Measure 短いほど良い
Data
(c) 2013 pLucky, Inc 参考： THE LEAN STARTUP

8.
サイクルを回す上で、よくある課題
・データを見るのが大
Build
事なのは分かるけど
Idea Product
イマイチ効果が説明
できず踏み切れない
・なんとなく大切だと
思う数字を追っては
Learn Measure いるが施策に繋がっ
ている気がしない
Data
(c) 2013 pLucky, Inc

9.
そのほとんどがMeasureの課題
・具体的な仮説の無い
Build
データを取得してお
Idea Product
り施策に繋がらない
・最終的な目標のみの
データを取得してお
り施策が浮かばない
Learn Measure ・取得するデータがい
つも異なり、設計に
Data
時間がかかる
(c) 2013 pLucky, Inc

10.
Measureを正しく意識して始めよう
・Measureするには
Build
仮説が必要になる
Idea Product ・仮説を明確にすると
Build目的も明確に
・Learnの精度はほぼ
Measureで決まる
Learn Measure
・最短でサイクルを回
す助けになる
Data
(c) 2013 pLucky, Inc

11.
データ取得・設計のプロセス解説
(c) 2013 pLucky, Inc

12.
Measureの流れ
Measure Data Learn Idea
全体像 ゴール シナリオ アクション ファネル 分析仮説 データ
確認 選定 詳述 確認 作成 作成 取得
(c) 2013 pLucky, Inc

13.
全体像 ゴール シナリオ アクション ファネル 分析仮説 データ
確認 選定 詳述 確認 作成 作成 取得
(c) 2013 pLucky, Inc

14.
全体像確認 1/2
サービスの前提を確認するため説明を記述
参考： Agile Inception Deck
［製品名］というこのサービスは
［製品カテゴリ］に属するサービスです
［解決する課題］という問題や欲求を抱える
［ターゲットユーザ層］の人達に
［サービスが提供する内容］を提供します
［サービスの特徴］という点が特に魅力です
ユーザにどのような価値をもたらすのか
明確に言語化しておくことで大方針をブレさせない
(c) 2013 pLucky, Inc

15.
全体像確認 2/2
ユーザの流入から収益化までの流れを記述
参考： AARRR!モデル
「獲得」象徴アクション ：[サービスへ登録する、など]
「定着化」象徴アクション：[チュートリアル終了、など]
「継続」象徴アクション ：[主機能の利用、など]
「紹介」象徴アクション ：[ＳＮＳ紹介機能利用、など]
「収益」象徴アクション ：[課金オプション利用、など]
※各ステップの象徴アクションは複数あってもよい
サービス内でユーザに想定する主要な動きを
全て記述し、目標とする行動を選びやすくする
(c) 2013 pLucky, Inc

16.
AARRR!モデル
前スライドの分類はAARRR!モデルを利用
Acquisition :
獲得。様々なチャネルからユーザが訪問
Acquisition Activation :
獲得
Referral
定着化。初利用のユーザが「良い」体験をする
Activation
紹介 Retention :
定着化
継続。 ユーザが繰り返しサービスを利用する
Retention
継続 Revenue Referral :
収益
紹介。ユーザがサービスを他ユーザへ紹介
Revenue :
収益。ユーザが何かしらの課金行動を行う
より詳しい説明については公開資料を参照
(c) 2013 pLucky, Inc

17.
全体像 ゴール シナリオ アクション ファネル 分析仮説 データ
確認 選定 詳述 確認 作成 作成 取得
(c) 2013 pLucky, Inc

18.
ゴール選定
このサイクルでユーザに達成して欲しい目標を決定
ゴール１：［前項で設定した象徴アクションのどれか］
ゴール２：［前項で設定した象徴アクションのどれか］
・
・
・
※複数あっても良いが、多くても３つ位を推奨
ユーザにどの行動をして欲しいのかを改めて明確にし
最適化・改善を行う対象を絞り込む
(c) 2013 pLucky, Inc

19.
継続率の重要性について
ゴールとして「継続」関連の行動を推奨します
売上 = AU ARPU
継続率
さらにITにおける顧客満足度は継続率で計測
短期的な売上だけでなくユーザとの関係を良好に保つ
より詳しい説明については第一回セミナー資料を参照
(c) 2013 pLucky, Inc

20.
全体像 ゴール シナリオ アクション ファネル 分析仮説 データ
確認 選定 詳述 確認 作成 作成 取得
(c) 2013 pLucky, Inc

21.
シナリオ詳述
ゴールごとに、そこへ至るまでのユーザ行動を記述
［想定しているアクション１］
シ ［想定しているアクション２］ 時系列
ナ ・
リ ［想定している期間］
オ ・
［前項で設定したゴール］
※起点から終点まででかかるだろう時間についても記述
ゴールまでのユーザの動きを詳細に分割し
改善の可能性があるポイントを特定できるようにする
(c) 2013 pLucky, Inc

22.
全体像 ゴール シナリオ アクション ファネル 分析仮説 データ
確認 選定 詳述 確認 作成 作成 取得
(c) 2013 pLucky, Inc

23.
アクション確認
各アクションについてユーザの欲求と照らし合わせる
［前項のアクション］ [対応ユーザ欲求] [その時言う言葉]
［前項のアクション］ [対応ユーザ欲求] [その時言う言葉]
・ ・ ・
・ ・ ・
［前項のアクション］ [対応ユーザ欲求] [その時言う言葉]
※欲求だけでなくユーザの言葉も想定するとクリアに
アクションがユーザ欲求と乖離していないか確認する
と同時に、Learn時に参照できる前提を作っておく
(c) 2013 pLucky, Inc

24.
１６分類の欲求
ユーザ欲求を考える際の参考としてください
• 力：他人を支配したいという欲求 • 競争：競争したい、仕返ししたいという欲求
• 独立：人に頼らず自力でやりたいという欲求 • ロマンス：セックスや美しいものを求める欲求
• 好奇心：知識を得たいという欲求 • 食：ものを食べたいという欲求
• 承認：人に認められたいという欲求 • 運動：体を動かしたいという欲求
• 秩序：ものごとをきちんとしたいという欲求 • 安心：心穏やかでいたいという欲求
• 貯蔵：ものを集めたいという欲求
• 誇り：人としての誇りを求める欲求
• 理想：社会正義を追求したいという欲求
• 交流：人と触れあいたいという欲求 スティーブン・リース
• 家族：自分の子供を育てたいという欲求
• 地位：名声を得たいという欲求 『１６の基本的な欲求』
(c) 2013 pLucky, Inc

25.
全体像 ゴール シナリオ アクション ファネル 分析仮説 データ
確認 選定 詳述 確認 作成 作成 取得
(c) 2013 pLucky, Inc

26.
ファネル作成
下記の表を埋め、目標を設定する
［アクション］ [ユーザ欲求] [想定絶対数] [想定CVR]
［アクション］ [ユーザ欲求] [想定絶対数] [想定CVR]
・ ・ ・ ・
・ ・ ・ ・
［ゴール］ [ユーザ欲求] [想定絶対数] ―
※CVRと絶対数は一方を決めればもう一方が決まる
改善プロセスを回す際に、改善が必要かどうか
施策が成功したかどうか、を判定する基準とする
(c) 2013 pLucky, Inc

27.
全体像 ゴール シナリオ アクション ファネル 分析仮説 データ
確認 選定 詳述 確認 作成 作成 取得
(c) 2013 pLucky, Inc

28.
分析仮説作成
ファネルを分析する際の切り口を準備しておく
・サービス内の切り口
利用時間に関するもの[サービス累計利用時間など]
利用金額に関するもの[サービス課金総額など]
成熟度に関するもの [サービス主機能利用有無など]
・サービス外の切り口
デモグラフィック [年齢など]
Learnでは成功集団と失敗集団の差分を探す
そのための要素を十分に準備しておく
(c) 2013 pLucky, Inc

29.
オススメの分析切り口
pLuckyでは下記項目での分析を推奨します
サービス内 サービス外
・利用時間関連 ・デモグラフィック
累計利用時間 年齢、性別ほか
利用パターン ライフスタイルの違いに注目
・利用金額関連 ・流入経路
累計利用金額 広告、オーガニック、紹介
平均利用金額
・サービス成熟度関連
機能の利用有無
最低限でもこれらの内容は分析できる項目として準備
(c) 2013 pLucky, Inc

30.
全体像 ゴール シナリオ アクション ファネル 分析仮説 データ
確認 選定 詳述 確認 作成 作成 取得
(c) 2013 pLucky, Inc

31.
データ取得
実際にサービス上のデータを取得する
[イベントログ] [アプリＤＢ]
アクション毎の情報 蓄積されていく情報
ゴールへ辿り着いた人数や、 分析仮説で想定したユーザが
アクションが行われた回数 サービス内に何人いるかなど
組み合わせて用いる
作成したファネルで定義されているアクションと
分析仮説で必要な属性情報を取得していく
(c) 2013 pLucky, Inc

32.
データ取得のポイント
内製でも既存ツール利用でも下記３つのことに注意
・サービスに見合ったサイズのデータ処理が可能か
・ユーザの属性をイベントと紐付けて分析が可能か
・十分な速さデータの取得と処理が可能か
(c) 2013 pLucky, Inc

33.
全体像 ゴール シナリオ アクション ファネル 分析仮説 データ
確認 選定 詳述 確認 作成 作成 取得
Measureのプロセスはこれで終了！
(c) 2013 pLucky, Inc

34.
Measureのおさらい
・ただデータをとれば
Build
良いというのは大き
Idea Product
な間違い
・Measureの後にあ
るLearnを意識し、
目的のあるデータ取
Learn Measure 得を行う必要がある
・Build Measure
Data
Learnの基礎工事
(c) 2013 pLucky, Inc

35.
おわりに
(c) 2013 pLucky, Inc

36.
もっと知りたいという方へ
SLASH7導入 or コンサルご相談
まずは気軽にご相談ください
http://bit.ly/slash7reg
pLucky Facebook page
セミナーや資料の公開など
http://facebook.com/plucky.inc
担当者へ直接メールを送る
hello@p-lucky.net
(c) 2013 pLucky, Inc