プロダクトマネジメント実践講座: シリコンバレーの現役プロダクトマネージャーが伝授する、世界の最前線で使われるKPI | Udemy

KPI の基礎知識

KPI とは

ゴールにたどり着くために必要な数値目標

シリコンバレーの格言
測定できなければ改善することもできない。破壊的想像なんてもってのほかだ

KPI の重要性

KPI を見ると、ビジネス等の成長度合いや問題点が一目瞭然
ユーザにプロダクトの価値を提供できているかを高い解像度で理解可能
数値で語ることにより、ステークホルダー間の認識を合わせられる
個々の施策の説明責任が一目瞭然

KPI の運用

KPI に必要な概念

要素	事例
数値	10%、10billion$
比較可能	前年比、地域別、プロダクト別
連続性	過去3年、直近4週間
自社で取得可能	データソースが自社内
利用目的が明快	社内で共通認識を持ち行動の指針

良い KPI の要素

Specific: 具体的な表現
Meaturable: 数値計測が可能
Agreeable: ステークホルダー間で合意
Relevant: 目標に関連
Time-bound: 期限の区切り

現場における導入初期の対応

導入初期は、データがそろってない場合が多い。

North Star Metric が決まり、 KSF を抽出
とりあえず判明しているデータから計測開始
「Build => Measure => Learn」のサイクルで回す
不適切な KPI の場合は、適宜修正

North Star Metric 詳説

North Star Metric とは

プロダクトや事業の価値が、ユーザに届いているかを測定する指標

何に力を置き、何にトレード歩するのか、判断の軸となる
施策のインパクトおよび進捗度を組織内にも共有しやすい
明瞭な説明責任を得られる

必要な５要素

ユーザ体験とプロダクト提供価値がリンクすること
ユーザがプロダクトにおける定着度となること
長期的には Up and to the right に進めること
収益に直結する Leading Indicator であること
組織内で共通認識を持てること

良い例

Uber: 月間アクティブプラットフォーム利用者数
- 増加するほど、ユーザが価値を感じてもらえる指標
- ユーザが継続して利用することを示す指標
- Uber としての成長指標
- 増加するほど、収益が増える指標
- 組織内でも明瞭な指標
Amazon: プライムユーザーの購買点数
Medium: 総読書時間
Facebook: 直近10日間で、7人以上友達を追加したユーザ数
airbnb: 予約された宿泊数

悪い例

ダウンロード数
- × ユーザが価値を感じる指標とならない
- × プロダクトに定着しているとは言えない
- × 場合によるが、多くの場合は増加しても、プロダクトの成長を示していない
- × 場合によるが、収益に結びつくと言えない
- ○ 組織内では理解してもらえる
登録ユーザ数
- × ユーザが価値を感じる指標とならない
- × プロダクトに定着しているとは言えない
- ○ 一応言える
- △ 場合による
- ○ 組織内では理解してもらえる

悪い例の理由

誰にでもわかる指標を安易に選択してしまった
Lagging Indicator (結果指標) を選択してしまった
- ユーザがどのようにプロダクトに辿り着いたか
- どのようにプロダクトから便益を受けているか

LinkedIn の失敗例

失敗例
1. LinkedIn のミッションは「世界中のプロフェッショナルが生産的かつ成功できるよう繋げていくこと」
2. その中で、Skill Endorsement という、自分のスキルを他人に証明してもらう機能を追加 (スキルに対するいいね機能)
3. 証明時は、複数のスキルを証明できてしまう
4. さらに証明してあげた相手には、通知がいく
5. そうすると、「たくさん証明してあげるから、僕のスキルにたくさん証明して！」という動機が生まれる
6. 最後は、スキルの証明数が意味を為さなくなった
対処例
1. スキルを証明した人を表示するだけでなく、特に秀でた人から証明された場合、その人を優先表示させた
2. 自分よりも証明数が多い人のお墨付きをもらう

North Star Metric と組織

North Star Metric は、会社組織に一つのみ設定する。
ただし、子要素として、複数の LeadingIndicator を持つことは良いこと。

配送会社のケース

親要素: North Star Metric
- 定時配達完了アイテム数
子要素
- 広がり: 新規ユーザ数
- 深さ: 注文あたりのアイテム数
- 頻度: ユーザあたりのアイテム数
- 効率: 定時配達のアイテム数

注意事項

設定時期

0->1 ではなく、1->100 の GrouthStage で設定する。
ProductMarketFit が見つかってからの方が効果が高い。

見直し時期

3年後を見据えて設定するため、頻繁に変更しない。
プロダクトのステージに合わせて変更する。

Introduction Stage
- Conversion Rate
Growth Stage
- User Retention (顧客維持)
- Lifetime Value (顧客生涯価値)
- Customer Acquisition Cost (顧客獲得コスト)
Maturity Stage
- Montly Recurring Revenue (月次経常収益)
- Annual Recurring Revenue (年間経常収益)
Decline Stage
- 新規サービス移行率 (新規サービスの投入)

その他見直し時期

会社の戦略変更
会社の統廃合
単純に上手く運用できていない時
- まだ、PMF に至らない状況
- 成長しない
- 成長しても、ビジネスの帰結が改善しない
- その場合、3, 6, 12ヶ月程度毎にヘルスチェックすべき

他指標の兼ね合い

NSM が増加に伴い、他の指標が下げる事例はよくあること。
その際は、NSM が最優先指標として取り扱うこと。
ただし、影響度をモニターする必要はある。

User Retention 詳説

User Retention とは

現代では、競合サービス数が多い。
そのため、ユーザ獲得のみならずユーザ定着率も非常に重要となる。

ユーザ定着率の算出方法

業界やプロダクトにより、定義が変わることに留意すること。
簡便な算出方法であるため、厳密な方法でないことに留意すること。

UR <= Daily Active User / Monthly Active User
UR <= DayN / Daily Active User
UR <= Day(N | Later) ユーザ数 / DAU
UR <= Day(N to N+α) / DAU

User Retention Curve (ユーザ定着率曲線)

...

Retention Life Cycle

概要

ユーザのステージ毎に分割される。
新規から現行へ、再起から現行へ移行させるソリューションが重要となる。

User Engagement により５つの種類に分割
- 新規ユーザ: プロダクト使い始め
- 現行ユーザ: 一定期間使用している
- パワーユーザ: ヘビロテする
- 休眠ユーザ: 一定期間後、使わなくなった
- 再起ユーザ: 休眠ユーザから再度使う

ステージの定義方法

タイプ	例
ユニーク	X 機能を使用したユニークユーザ
総イベント数	X, Y, Z 3種類のイベントが、アカウント登録から延べ100回以上のユーザ
アクティブ%	DAU における X イベントが発生したユーザ割合
平均	X 機能を Weekly で平均何回使用されたか
頻度	X 機能を Weekly で Y 回以上使用するユニークユーザ
特定プロパティの総計	X 機能の使用ユーザのうち、特定のデバイスや言語毎のユーザ数
特定プロパティの割合	X 機能の使用ユーザのうち、特定のデバイスや言語毎のユーザ割合

パワーユーザに注目

Heavy User
- プロダクトの使用頻度が多いのみならず、現行ユーザが普段使用しない機能も使用する
Core User
- プロダクトを「期待通り」に使用する
Passive User
- プロダクトを頻繁に使用するが、サービス提供方法と意図しない方法で使用する
- 新機能発見の源泉

Behavioral Persona

概要

ペルソナとは、ユーザ群に共通する属性等の情報群をまとめた姿
Behavioral Persona は、静的情報(地域、言語)より、動的情報(プロダクトの使用方法)を元にユーザ属性を抽出したもの
明確にすると、ペルソナに対するベスト体験を考えやすくなる
1%ルール
- 1%のユーザが、コンテンツを作成
- 9%のユーザが、コンテンツに対して反応
- 90%のユーザが、閲覧のみ

Instagram と Twitter の事例

Instagram
- 最初は、ロケーションアプリだった
- 現行ユーザの継続率が低くて伸び悩む。。
- ペルソナ分析の結果、パワーユーザは 写真のシェアとコメント を評価して使用していた
- Photo Sharing に特化し、他全ての機能を停止 (= 事業のピボット)
Twitter
- 最初は、簡易ブログプラットフォームだった
- 次第に、ユーザが様々なプロダクトやサービスの文句をツイートするようになる
- ペルソナ分析の結果、この使用方法が多かった
- ツイートから直接メッセージを送信可能になった

A/Bテストによる KPI 測定

具体例

AB Testing Case Studies from the world’s data driven marketeers | CRO cases

A/Bテスト手順

Step1: 問題設定
- データドリブンで理由付け ( ユーザ滞在時間数が少ない、DAUあたりアップロード数が少ない )
Step2: 仮説を立てる
- ユーザ体験を損なう仮説を設定 ( トップ画像でプロダクト価値を伝えられてない？、アップロード部分が面倒？ )
Step3: ゴールを決める
- どの KPI を増加させるか１つ決定
- 一度のテストで変更箇所を増やさない
Step4: ユーザを分割
- Test Group: 新しい施策を体験するユーザ群
- Control Group: 既存の状態を体験するユーザ群
Step5: テストバージョン投入
- 投入前にA/Aテストで、ユーザが分割しているか確認する時もあり
Step6: 他部署のA/Bテストや、ノイズが入らないよう調整
- テスト期間中に避けるべきこととして、バックエンドのアップデートやマーケティングキャンペーンを実施しないこと
Step7: テストバージョンの動作確認
Step8: テスト開始

確証バイアスに注意！

新情報に対して、自分の都合の良い結果として主観的に捉えてしまう
対策
- A/B テストの3要素(Why, What, How) をドキュメント化して、何を目的とするか事前に備える
- A/Bテストのメトリックとして、％ に拘らず、絶対数も確認する
- ユーザインタビューは、多様なバックグラウンドを持つ人に聞く