Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

データに振り回されて失敗した あんなことやこんなこと+α  〜なぜ数字の手助けが必要になるのか、その理由と分析の実践例〜

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige

Hier ansehen

1 von 33 Anzeige

データに振り回されて失敗した あんなことやこんなこと+α  〜なぜ数字の手助けが必要になるのか、その理由と分析の実践例〜

Herunterladen, um offline zu lesen

Sapporo CEDEC2014での講演資料です。

ソーシャルゲームの流行に伴って一躍脚光を浴びた、ビッグデータによる「分析」という手法ですが、分析という言葉が一人歩きして、どんなときにその強みを発揮するか、あまり知られていません。

本発表では、なぜソーシャルゲームでは分析が必要になったかを簡単に整理したうえで、具体的な分析の失敗例・成功例を通して、数字の手助けで、どのようなことが分かるのかを解説します。

Sapporo CEDEC2014での講演資料です。

ソーシャルゲームの流行に伴って一躍脚光を浴びた、ビッグデータによる「分析」という手法ですが、分析という言葉が一人歩きして、どんなときにその強みを発揮するか、あまり知られていません。

本発表では、なぜソーシャルゲームでは分析が必要になったかを簡単に整理したうえで、具体的な分析の失敗例・成功例を通して、数字の手助けで、どのようなことが分かるのかを解説します。

Anzeige
Anzeige

Weitere Verwandte Inhalte

Andere mochten auch (17)

Ähnlich wie データに振り回されて失敗した あんなことやこんなこと+α  〜なぜ数字の手助けが必要になるのか、その理由と分析の実践例〜 (20)

Anzeige

Aktuellste (20)

データに振り回されて失敗した あんなことやこんなこと+α  〜なぜ数字の手助けが必要になるのか、その理由と分析の実践例〜

  1. 1. データに振り回されて失敗した あんなことやこんなこと+α ~なぜ数字の手助けが必要になるのか、 その理由と分析の実践例~ Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. November 22, 2014 NOGAMI Daisuke (@dnogami_dena) Senior Manager Analytics Dept. DeNA Co., Ltd.
  2. 2. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 本日お話させていただく内容  自己紹介+発表の背景  ゲームを面白くするために、 なぜ「分析」=数字の手助けが必要になるか  データに振り回されて失敗した事例集と改善結果 ① リリース直後のタイトルの改善 ② プロモーション結果の分析 ③ ゲーム内のバトルが盛り上がらない ④ 割引に頼った売上増加策の失敗  まとめ 2
  3. 3. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 自己紹介  野上大介(のがみだいすけ) ⁃ 分析部シニアマネージャー  Mobage全体からタイトルまで、様々な問題の分析と改善提案 + ⁃ 複数の有力ゲームデベロッパーに対する分析のコンサルティング ⁃ 複数のタイトルの比較や相乗効果の分析に用いる指標の定義 ⁃ 指標を活用しやすくするためのデータ基盤整備  他の分析部アナリストの分析・改善提案のサポート ⁃ アナリスト=担当するタイトル・サービスの「分析系事業参謀」 3
  4. 4. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 自己紹介  DeNA入社以前の経歴 • 東京大学大学院修了後、野村総合研究所を経て、DeNAに入社 • 野村総合研究所時代は、業界を限定せず、 事業戦略の実現をクライアントの状況に合わせて支援 (リサーチ・戦略立案から、戦略の具体化・業務改革、 事業計画の管理体制構築までニーズに応じてカバー)  近頃の趣味…ロケット打ち上げ見学 ⁃ 11/30(日) 13:24:48のはやぶさ2打ち上げも 種子島に行きます ⁃ ネット中継に加え 札幌でもパブリック ビューイングあり 4
  5. 5. 「良いタイトルを、長く楽しめるようにしたい!」  タイトルを提供しつづけるには、面白さと、(最低限の)収益の 両方を考えた開発・運営がかかせない ⁃ 私自身も、サービス終了に涙したことがあり…  面白さをチームの「阿吽の呼吸」で維持するのは難しい  面白さを明確に共有し、タイトルが理想像に近づいているか、 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 客観的に確認するには「データ」は便利な道具  しかし、業界では、収益ばかりを気にした、 「データだけ」を使った分析が目立ちました  タイトルが理想像に近づいているかを確認するための道具として 「データも」をうまく活用した分析を増やしていきたい 5
  6. 6. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 会場にいらっしゃる皆様に質問です 担当業務: イベント等の企画をする側 プランナー、企画など 「分析」や「データ」は ゲーム作りの 参考になると思う 正直、データや数字で ゲーム作りをすることは 好まない・納得できない 6 担当業務: 企画を形にする側 エンジニア、 アート・シナリオなど
  7. 7. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. なぜ「分析」=数字の手助けが必要になるか  1人ないし少人数で遊ぶ、完成品を提供するゲームであれば、 事前のテストプレイで改善点は見つけられる  数多くのユーザがお互いに影響し合いながら楽しむゲームでは、 ユーザのゲーム内の状態も生活スタイルも、とにかく多様である  多くのユーザに対して面白さを提供できているかどうかを、 事前の想定や、数人によるプレイだけで把握することは困難 7 よろこびいかりかなしみ たのしみ
  8. 8. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. なぜ「分析」=数字の手助けが必要になるか  「分析」≒「コックピットの計器もみながら飛行機を操縦する」 ⁃ 自分の目や感覚だけではなく、数字“も”つかうことで、 ユーザが感じている喜怒哀楽をより丁寧に知ることができる 8
  9. 9. データに振り回されて失敗した事例集と改善結果 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. ① リリース直後のタイトルの改善 ② プロモーション結果の分析 ③ ゲーム内のバトルが盛り上がらない ④ 割引に頼った売上増加策の失敗 9
  10. 10. 他と比べて継続率が 低いステップがあれば それが原因だが、 全体的に低かった Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#1 リリース直後のタイトルの改善  とあるタイトルのリリース直後の話 ⁃ n日後の継続率が低く、ユーザが定着しない • チュートリアルの各段階での継続率に分解したが (いわゆるファネル分析)が、原因を発見できず 継続率 ⁃ 日次の課金率(=課金UU / DAU)は悪くなかった • 新規ユーザ向け限定に、コンティニュー初回限定の割引を実施  そのタイトルは成功せず ⁃ ユーザが定着せず、課金率も低下してしまった 10 ステップ番号1 2 3 4 5 6 7 8 … #1
  11. 11. #1 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#1の直接の原因  タイトル改善のための課題が適切ではなかった ⁃ ユーザの定着のための課題: 想定していたユーザ層の獲得状況をチェックしていなかった • 30代男性を想定してゲームを制作していたが、実際のユーザは 40代女性の割合が高く、全体的に継続率を押し下げていた ⁃ 課金率維持のための課題: 課金継続率をチェックしていなかった • 初回限定の割引を利用して課金をしても、メリットが低かった (コンティニューをしてもクリアできないステージが多かった) • 課金継続率の変化を確認していれば、問題の重大さに 早く気付くことができた 11
  12. 12. #1 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#1から得られる教訓  原因に挙げたことへの対処 ⁃ タイトルを改善するために適切な課題とKPIを設定する • ユーザの定着⇒想定していたユーザ層の獲得状況 • 課金の継続⇒課金継続率、LTV  加えて:さまざまな切り口とKPIを普段から貯めておく ⁃ 分析の切り口 • 性別、年代、端末、アクティビティを用いたセグメント、… • それらの切り口を用いた集計の仕方を普段から準備しておく ⁃ KPIの事例 • 複数日課金率( = 課金を2日以上したユーザ÷ 全ユーザ) ⁃ ゲームを始めてから、課金をした日が2日以上あるユーザの割合 ⁃ 日付が変わっても課金をしているということは、初回の課金の 効果を感じてリピートしてくれているということ ⁃ 優秀なタイトルはこの割合が相対的に高めのことが多いです 12
  13. 13. #1 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. KPIの事例をもう1つ…DAUの読み解き方  DAU(Daily Active Users、その日に遊んだユーザ数)を ユーザの状態で色分けする ⁃ DAUのノイズが分かりやすくなると共に、 ユーザの気持ちが読み取りやすくなる • CEDEC2013で発表しました • 資料はCEDiLとSlideshareにて公開中 13
  14. 14. 失敗談#1 を繰り返さないための分析業務の進め方  失敗をしないためには、仕事の進め方から変えることが望ましい  製造業などで用いられる課題解決の手法「シックスシグマ」が Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 行動につなげやすい 14 • タイトルを改善するために適切な課題とKPIを設定する • 様々なKPIを普段から貯めておく 取り組む課題の定義 (Define) • (様々なKPIを、すぐに見れるようにしておく) 現状の把握 (Measure) • 事象の背景の構造に対する仮説を立てた上で分析をする • 様々な切り口を普段から貯めておく、すぐ集計できるようにする 根本原因の特定 (Analyze) 改善策の検討・設計 (Improve / Design ) 効果や設計の検証 (Control / Verify ) #1
  15. 15. 新規新規ユーザの売上が Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#2 プロモーション結果の分析  プロモーション予算を変えたときの話 新規 既存既存 ⁃ 先月と今月の違いはプロモーション予算を減らしたことだけ ⇒LTVで採算性を確認、予算を元の水準に増やして集客した 16 5月の売上6月の売上 減少していた 新規=その月にゲームを 始めたユーザ 既存=前月迄にゲームを 始めたユーザ #2
  16. 16. #2 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#2の直接の原因  本当の課題「ゲーム開始翌月以降のユーザからの売上減少」 5月 4月 以前 6月 5月 4月 以前 ⁃ 始めて1,2ヶ月すると課金を止めるタイトルになっている ⁃ よって、タイトルの中身を改善する方が優先課題 17 5月の売上6月の売上 ゲームを始めた月に 読み替えると、 原因は「既存」にあることが 分かる
  17. 17. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#2と似た事例…LTVを基にした広告出稿  プロモーションの予算を立てるときの考え方 • 「LTVが、1人当たりのユーザ獲得費用を上回っていれば、 プロモーションをいくらでも続けても良い」  実績を元にLTVを予測して出稿したが、予測どおりにならない • ターゲットとするユーザ層以外のLTVは低くなりがち • いつかはターゲット層を獲得しつくすので、LTVは低下する 18 遊び続ける = 継続率 課金する = 生涯課金率 課金を続ける = 課金継続率 月額平均課金額 × 課金継続月数 ターゲットのユーザ層とそれ以外では、 継続率などが大きくことなる #2
  18. 18. 失敗談#2から得られる教訓と、分析業務の進め方  事象の背景の構造に対する仮説を立てた上で分析をする  他の担当者にもサポートを求め、自分の守備範囲外の情報も得る 19 • (手段と目的の関係を明確にする) • タイトルを改善するために適切な課題とKPIを設定する • 様々なKPIを普段から貯めておく Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 取り組む課題の定義 (Define) • (様々なKPIを、すぐに見れるようにしておく) 現状の把握 (Measure) • 事象の背景の構造に対する仮説を立てた上で分析をする • 様々な切り口を普段から貯めておく、すぐ集計できるようにする 根本原因の特定 (Analyze) 改善策の検討・設計 (Improve / Design ) 効果や設計の検証 (Control / Verify ) #2
  19. 19. 変更前…遊ぶ日数は考慮せず変更後…全チームに毎日遊ぶ人がいる Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#3 ゲーム内のバトルが盛り上がらない  ゲーム内でのグルーピングを改善してバトルを盛り上げたい ※チーム同士で競ったり戦ったりするバトルを想定 ⁃ 「各チームに毎日遊んでいる人を必ず入れる」という グルーピング方式を野上が提案して導入 ⁃ 初回のバトルは大きく盛り上がりました ⁃ しかし、2回目以降は効果がなくなり元に戻りました 20 チームX チームY 眠眠眠 活活眠 眠眠眠 眠眠眠 チームX’ チームY’ 眠眠眠 活眠眠 眠眠眠 活眠眠 #3 相手チームは 反撃しない ⇒楽勝! お互いに 反撃の応酬 ⇒激戦!
  20. 20. #3 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#3の直接の原因  成功の要因を適切に把握せず、改良すべき点に気づかなかった ⁃ 実際にゲームの中で起きていたこと • 改良前のイベント: 敵チームが1人も遊んでいないことが多いので、 バトルの開始直後は様子見をすることが多い • 改良直後のイベント: 今回は全チームで遊んでいるユーザがいたので、多くのチームで 「敵チームはやる気がある!」と誤解しバトルを始めた (ただし、遊ぶユーザが分散したので、1人当たりの負担は増えた) • 2回目以降のイベント: 1人当たりの負担が増えたことでユーザが疲れるイベントと認識。 バトル開始直後の様子見で、敵チームの動いている人数も 気にするようになった ⇒ 2回目は複数の指標を組み合わせる方式に改良すべきだった ※その他のKPIの例は来週Mobage Developers Blogに 後輩アナリストが記事を書きます!(http://developers.mobage.jp/blog/) 21
  21. 21. #3 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#3から得られる教訓  原因に挙げたことへの対処 ⁃ 成功の要因を的確に把握し、常に改善を加える • 変更が悪影響を与えている部分は把握して対処する • 成功の前提条件が変わった場合にはやり方を見直す  加えて:前提条件や悪影響を測るKPIの集計は自動化する ⁃ 問題が顕在化しないと、分析を後回しにしてしまいがち ⁃ 集計を自動化し、チームのメンバーが自分で 過去と比較できるようにしておけば、チェックは漏れにくい • 自分でも確認しやすいし、チームのメンバーにも気づいてもらえる • 今回であれば、チームごとの活動している人数を比較すべきだった 22
  22. 22. 失敗談#3 を繰り返さないための分析業務の進め方  この失敗への予防策・改善策は、ImproveとControlで行う Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 必要がある ⁃ Measureが改善されているとより確実になる 23 • (手段と目的の関係を明確にする) • タイトルを改善するために適切な課題とKPIを設定する • 様々なKPIを普段から貯めておく 取り組む課題の定義 (Define) • 様々なKPIを、すぐに見れるようにしておく 現状の把握 (Measure) • 事象の背景の構造に対する仮説を立てた上で分析をする • 様々な切り口を普段から貯めておく、すぐ集計できるようにする 根本原因の特定 (Analyze) • 前提条件が変わった場合にはやり方を見直す 改善策の検討・設計 (Improve / Design ) • 改善策が悪影響を与えている部分を把握して対処する 効果や設計の検証 (Control / Verify ) #3
  23. 23. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#4 割引に頼った売上増加策の失敗  ガチャの施策で売上を改善しようとした話 ⁃ 「目玉カードを手に入りやすくすれば(=価格を割引けば)、 多くの人がガチャを回してくれるのでは」 「負担が軽くなれば、ゲームを続けやすくなるのでは」 ⁃ 実際にはユーザ数は増えず、単価が下がって売上も減少、 タイトルの継続率はとくに変わらず 24 ○○ガチャ第2弾 第1弾 より確率 アップ! (1%->2%) 3回目 まで割引 SSR ガチャる! 目玉となるカードが より低価格で手に入ると 訴求した #4 ※分かりやすさのため、実際に行った施策とは表現を変えてあります。 ※ ここで示した「確率」とは、アイテム別提供割合のことです。
  24. 24. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#4の直接の原因(1,2)  課題に対する手段が適切ではなかった ⁃ 離脱理由ごとの離脱ユーザ数を把握しておくべきだった ※正確な推定は難しいですが、多いか少ないかくらいは把握できる  事象の背景や構造、原理に対する理解が薄かった ⁃ ユーザの、ガチャを回す判断基準は期待値だけではない • 多くのガチャでは、期待値は一目では分からないので、 期待値を下げたことをユーザが気づかないこともある • ターゲットとなる(普段ガチャを回さない)ユーザが欲しくない カードを提供しても、ユーザはガチャを回さない 25 ○○ガチャ第2弾 第1弾 より確率 アップ! (1%->2%) SSR 確率が2倍と いっても 半額で手に入る わけは無いよな… どうせ高いでしょ 僕はこんなに 強いカードでなく ても十分満足 #4
  25. 25. ガチャの回数1 2 3 4 5 6 7 8 … Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. n回以上 ガチャをした ユーザ数 確率から想定した ユーザ数 失敗談#4の直接の原因(3)  事前検討やシミュレーションが不足していた ⁃ ユーザ数を増やしても、必ずしも売上が増えないことがある • 期待値を計算するときは、ガチャを回し始めた全員が 「目玉カードを取れるまで回し続ける」前提を置くことが多い • 実際は途中であきらめるユーザさんも多い 26 実際にガチャを したユーザ数 割引が効く3回目で あきらめたため ユーザ数が減った #4
  26. 26. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#4と似た事例…セット販売の副作用  セット販売で、アイテムの価値を高く見せようとした話 ⁃ 本当に売りたい商品と、比較対象のやや劣る商品を見せる ことで、高額なセット商品が買いたくなるようにした ⁃ しかし、セット販売が常態化したときに、 売りたい商品の魅力も薄れてしまった (例:不必要なものが手元にあるので、トレード等で節約できる) 27 アイテム8個付き 10連ガチャ 2,700円 アイテム10個 3,000円 10連ガチャ 3,000円 1個300円の アイテムの おまけ8個分、 10連ガチャが 劣ってみえる ガチャが10回 引けるので、 アイテムだけの セットが 劣ってみえる ガチャで 強くなりたい! アイテムで 沢山戦いたい! #5 余ったアイテム、 トレードに使っ てガチャ不要! 余ったカードを トレードして アイテムに!
  27. 27. 割引が効く3回目を過ぎた影響 ⇒次回は~~をして改善を狙う Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#4から得られる教訓  原因に挙げたことへの対処 ⁃ 課題に対する手段を適切に選ぶ ⁃ 事象の背景や構造、原理を十分に理解する ⁃ 事前検討やシミュレーションを十分にしておく  加えて:平均値を要素に分解してみる ⁃ 具体例:ガチャでも”継続率”を見る 28 継続率 ガチャの回数1 2 3 4 5 6 7 8 … #4
  28. 28. 失敗談#4 を繰り返さないための分析業務の進め方  この失敗への予防策・改善策は、Define,Analyze,Improveで Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 行う必要がある ⁃ これまでの改善点すべてが必要になる事例 29 • 課題に対する手段を適切に選ぶ(手段と目的の関係を明確にする) • タイトルを改善するために適切な課題とKPIを設定する • 様々なKPIを普段から貯めておく 取り組む課題の定義 (Define) • 様々なKPIを、すぐに見れるようにしておく 現状の把握 (Measure) • 事象の背景や構造、原理を十分に理解する • 事象の背景の構造に対する仮説を立てた上で分析をする • 様々な切り口を普段から貯めておく、すぐ集計できるようにする 根本原因の特定 (Analyze) • 前提条件が変わった場合にはやり方を見直す • 事前検討やシミュレーションを十分にしておく 改善策の検討・設計 (Improve / Design ) • 改善策が悪影響を与えている部分を把握して対処する 効果や設計の検証 (Control / Verify ) #4
  29. 29. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. • なぜ「分析」=数字の手助けが必要になるか • データに振り回されて失敗しないために大切なこと • 明後日からすぐにできる「分析」 まとめ 30
  30. 30. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. なぜ「分析」=数字の手助けが必要になるか  「分析」≒「コックピットの計器もみながら飛行機を操縦する」 ⁃ 自分の目や感覚だけではなく、数字“も”つかうことで、 ユーザが感じている喜怒哀楽をより丁寧に知ることができる 31
  31. 31. データに振り回されて失敗しないために大切なこと  「現状を正しく把握して改善策を考えよう」とはよく言われる  でも、より大事なのは、「課題の定義」、「根本原因の特定」、 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 「効果や設計の検証」である 32 • 課題に対する手段を適切に選ぶ(手段と目的の関係を明確にする) • タイトルを改善するために適切な課題とKPIを設定する • 様々なKPIを普段から貯めておく 取り組む課題の定義 (Define) • 様々なKPIを、すぐに見れるようにしておく 現状の把握 (Measure) • 事象の背景や構造、原理を十分に理解する • 事象の背景の構造に対する仮説を立てた上で分析をする • 様々な切り口を普段から貯めておく、すぐ集計できるようにする 根本原因の特定 (Analyze) • 前提条件が変わった場合にはやり方を見直す • 事前検討やシミュレーションを十分にしておく 改善策の検討・設計 (Improve / Design ) • 改善策が悪影響を与えている部分を把握して対処する 効果や設計の検証 (Control / Verify ) )
  32. 32. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 明後日からすぐにできる「分析」 1. 自分自身をサンプルとして丁寧に観察してみる • 担当しているタイトルを、1人のユーザとして素直に遊ぶ • 遊んだときのログを取り出して、プレイヤーの気持ちが どのようなログに現れるか確認し、指標にする 2. 作業にかかる負担をなくす • 上記の観察用データを含め、データ集計や可視化は自動化してしまい、 作業を後回しにする言い訳をなくす 3. 普段から開発・運用チームのメンバーと真剣に議論をする • 上の2つができていれば、タイトルを理想像に近づける課題が 見えてきて、議論の材料もそろうはず • 議論を通じて、チームのメンバーも同じように客観的に ゲームの課題を捉えられるようになると、さらに効果が高まる  本日の発表が、より良いタイトル作り・タイトル運営のために 参考になれば幸いです 33
  33. 33. 34 本発表の内容のアップロード先は、@dnogami_dena でのツイートと Facebookでの投稿(https://www.facebook.com/daisuke.nogami)で告知します Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved.

×