第2回継続率経営セミナー公開資料：データの設計・取得について

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

(c) 2013 pLucky, Inc

まずはpLuckyチーム自己紹介

Netageグループ各社で開発・経営企画に携わった後、頓智ドットにて
林宜宏経営指標管理を主導。自ら分析ツールを開発しつつ各種予測モデルを構
CEO 築し活用した。培ったノウハウを譲り受けて独立。京都大学卒業

SRA、頓智ドットを経て現職。Playing Managerとしてチームを束
河内崇ねる。各種Low Layerの分散システムの開発経験を持ち、前職では
開発チームマネージャ iPhone開発チームをリードした。東京大学大学院卒業

Netageから楽天、頓智ドットを経て現職。開発チームの柱としてチー
塚本朗仁ムに貢献。WEBの先端技術全般に明るく、ECからポータルサイトまで
テクニカルリード様々なタイプのWEB開発経験が豊富。

頓智ドットを経て現職。コンサルティングおよびマーケティング担当。
田畑直在学中に独立系コンサルを経て頓智ドットに。世界に向けてDoMoのプ
コンサルタントレゼンを手掛け経営企画に携わった。東京大学中退。米国帰国子女


この資料の目的
pLuckyはデータドリブン経営をサポートするための
ツール『SLASH-7』を開発しています。

今後『SLASH-7』をより多くの方に活用していただ
くためにも、データドリブン経営のサポートとなる考
え方やTIPSを皆様にご紹介していきたいと考えていま
す。この資料はその一環です。

今回はデータドリブンな経営を行う際に必要となる、
取得するべきデータ設計の流れを解説しました！

この資料に含まれているもの

１．サービス改善とデータによる分析の関係
２．データ取得・設計のプロセスを各ステップ毎に解説


この資料が意味を持ちそうな人

・データドリブン経営に興味があり試してみたい人
・プロジェクトのKPI設計に迷っている人
・データの取得はしているが施策に活用できていない人


サービス改善とデータによる分析


Build Measure Learnが開発の基本

・製品は必ず改善可能
Build
という前提にたつ
Idea Product ・常に新たな課題を発
見し改善し続ける
・１サイクルの期間は
長くて１∼２週間、
Learn Measure 短いほど良い

Data

(c) 2013 pLucky, Inc 参考： THE LEAN STARTUP

サイクルを回す上で、よくある課題

・データを見るのが大
Build
事なのは分かるけど
Idea Product
イマイチ効果が説明
できず踏み切れない
・なんとなく大切だと
思う数字を追っては
Learn Measure いるが施策に繋がっ
ている気がしない
Data


そのほとんどがMeasureの課題

・具体的な仮説の無い
Build
データを取得してお
Idea Product
り施策に繋がらない
・最終的な目標のみの
データを取得してお
り施策が浮かばない
Learn Measure ・取得するデータがい
つも異なり、設計に
Data
時間がかかる

Measureを正しく意識して始めよう

・Measureするには
Build
仮説が必要になる
Idea Product ・仮説を明確にすると
Build目的も明確に
・Learnの精度はほぼ
Measureで決まる
Learn Measure
・最短でサイクルを回
す助けになる
Data


データ取得・設計のプロセス解説


Measureの流れ

Measure Data Learn Idea

全体像ゴールシナリオアクションファネル分析仮説データ
確認選定詳述確認作成作成取得


全体像確認 1/2
サービスの前提を確認するため説明を記述
参考： Agile Inception Deck

［製品名］というこのサービスは
［製品カテゴリ］に属するサービスです
［解決する課題］という問題や欲求を抱える
［ターゲットユーザ層］の人達に
［サービスが提供する内容］を提供します
［サービスの特徴］という点が特に魅力です

ユーザにどのような価値をもたらすのか
明確に言語化しておくことで大方針をブレさせない

全体像確認 2/2
ユーザの流入から収益化までの流れを記述
参考： AARRR!モデル

「獲得」象徴アクション：[サービスへ登録する、など]
「定着化」象徴アクション：[チュートリアル終了、など]
「継続」象徴アクション：[主機能の利用、など]
「紹介」象徴アクション：[ＳＮＳ紹介機能利用、など]
「収益」象徴アクション：[課金オプション利用、など]
※各ステップの象徴アクションは複数あってもよい

サービス内でユーザに想定する主要な動きを
全て記述し、目標とする行動を選びやすくする

AARRR!モデル
前スライドの分類はAARRR!モデルを利用

Acquisition :
獲得。様々なチャネルからユーザが訪問
Acquisition Activation :
獲得
Referral
定着化。初利用のユーザが「良い」体験をする
Activation
紹介 Retention :
定着化
継続。ユーザが繰り返しサービスを利用する
Retention
継続 Revenue Referral :
収益
紹介。ユーザがサービスを他ユーザへ紹介
Revenue :
収益。ユーザが何かしらの課金行動を行う

より詳しい説明については公開資料を参照

ゴール選定
このサイクルでユーザに達成して欲しい目標を決定

ゴール１：［前項で設定した象徴アクションのどれか］
ゴール２：［前項で設定した象徴アクションのどれか］
・
・
・

※複数あっても良いが、多くても３つ位を推奨

ユーザにどの行動をして欲しいのかを改めて明確にし
最適化・改善を行う対象を絞り込む

継続率の重要性について
ゴールとして「継続」関連の行動を推奨します

売上 = AU ARPU

継続率

さらにITにおける顧客満足度は継続率で計測
短期的な売上だけでなくユーザとの関係を良好に保つ

より詳しい説明については第一回セミナー資料を参照

シナリオ詳述
ゴールごとに、そこへ至るまでのユーザ行動を記述

［想定しているアクション１］
シ［想定しているアクション２］時系列
ナ・
リ［想定している期間］
オ・
［前項で設定したゴール］

※起点から終点まででかかるだろう時間についても記述

ゴールまでのユーザの動きを詳細に分割し
改善の可能性があるポイントを特定できるようにする

アクション確認
各アクションについてユーザの欲求と照らし合わせる

［前項のアクション］ [対応ユーザ欲求] [その時言う言葉]
・・・
・・・
※欲求だけでなくユーザの言葉も想定するとクリアに

アクションがユーザ欲求と乖離していないか確認する
と同時に、Learn時に参照できる前提を作っておく

１６分類の欲求
ユーザ欲求を考える際の参考としてください

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


ファネル作成
下記の表を埋め、目標を設定する

［アクション］ [ユーザ欲求] [想定絶対数] [想定CVR]
［アクション］ [ユーザ欲求] [想定絶対数] [想定CVR]
・・・・
・・・・
［ゴール］ [ユーザ欲求] [想定絶対数] ―
※CVRと絶対数は一方を決めればもう一方が決まる

改善プロセスを回す際に、改善が必要かどうか
施策が成功したかどうか、を判定する基準とする

分析仮説作成
ファネルを分析する際の切り口を準備しておく

・サービス内の切り口
利用時間に関するもの[サービス累計利用時間など]
利用金額に関するもの[サービス課金総額など]
成熟度に関するもの [サービス主機能利用有無など]
・サービス外の切り口
デモグラフィック [年齢など]

Learnでは成功集団と失敗集団の差分を探す
そのための要素を十分に準備しておく

オススメの分析切り口
pLuckyでは下記項目での分析を推奨します

サービス内サービス外
・利用時間関連・デモグラフィック
累計利用時間年齢、性別ほか
利用パターンライフスタイルの違いに注目

・利用金額関連・流入経路
累計利用金額広告、オーガニック、紹介
平均利用金額

・サービス成熟度関連
機能の利用有無

最低限でもこれらの内容は分析できる項目として準備

データ取得
実際にサービス上のデータを取得する

[イベントログ] [アプリＤＢ]
アクション毎の情報蓄積されていく情報

ゴールへ辿り着いた人数や、分析仮説で想定したユーザが
アクションが行われた回数サービス内に何人いるかなど

組み合わせて用いる
作成したファネルで定義されているアクションと
分析仮説で必要な属性情報を取得していく

データ取得のポイント
内製でも既存ツール利用でも下記３つのことに注意

・サービスに見合ったサイズのデータ処理が可能か

・ユーザの属性をイベントと紐付けて分析が可能か

・十分な速さデータの取得と処理が可能か



Measureのプロセスはこれで終了！


Measureのおさらい

・ただデータをとれば
Build
良いというのは大き
Idea Product
な間違い
・Measureの後にあ
るLearnを意識し、
目的のあるデータ取
Learn Measure 得を行う必要がある
・Build Measure
Data
Learnの基礎工事

おわりに


もっと知りたいという方へ

SLASH7導入 or コンサルご相談
まずは気軽にご相談ください
http://bit.ly/slash7reg

pLucky Facebook page
セミナーや資料の公開など
http://facebook.com/plucky.inc

担当者へ直接メールを送る
hello@p-lucky.net


第2回継続率経営セミナー公開資料：データの設計・取得について

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (15)

Similar to 第2回継続率経営セミナー公開資料：データの設計・取得について

Similar to 第2回継続率経営セミナー公開資料：データの設計・取得について (20)

Recently uploaded

Recently uploaded (9)