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

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. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 本日お話させていただく内容  自己紹介＋発表の背景  ゲームを面白くするために、なぜ「分析」＝数字の手助けが必要になるか  データに振り回されて失敗した事例集と改善結果 ① リリース直後のタイトルの改善 ② プロモーション結果の分析 ③ ゲーム内のバトルが盛り上がらない ④ 割引に頼った売上増加策の失敗  まとめ 2

3. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 自己紹介  野上大介（のがみだいすけ） ⁃ 分析部シニアマネージャー  Mobage全体からタイトルまで、様々な問題の分析と改善提案 + ⁃ 複数の有力ゲームデベロッパーに対する分析のコンサルティング ⁃ 複数のタイトルの比較や相乗効果の分析に用いる指標の定義 ⁃ 指標を活用しやすくするためのデータ基盤整備  他の分析部アナリストの分析・改善提案のサポート ⁃ アナリスト＝担当するタイトル・サービスの「分析系事業参謀」 3

4. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 自己紹介  DeNA入社以前の経歴 • 東京大学大学院修了後、野村総合研究所を経て、DeNAに入社 • 野村総合研究所時代は、業界を限定せず、事業戦略の実現をクライアントの状況に合わせて支援（リサーチ・戦略立案から、戦略の具体化・業務改革、事業計画の管理体制構築までニーズに応じてカバー）  近頃の趣味…ロケット打ち上げ見学 ⁃ 11/30(日) 13:24:48のはやぶさ2打ち上げも種子島に行きます ⁃ ネット中継に加え札幌でもパブリックビューイングあり 4

5. 「良いタイトルを、長く楽しめるようにしたい！」  タイトルを提供しつづけるには、面白さと、(最低限の)収益の両方を考えた開発・運営がかかせない ⁃ 私自身も、サービス終了に涙したことがあり…  面白さをチームの「阿吽の呼吸」で維持するのは難しい  面白さを明確に共有し、タイトルが理想像に近づいているか、 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 客観的に確認するには「データ」は便利な道具  しかし、業界では、収益ばかりを気にした、「データだけ」を使った分析が目立ちました  タイトルが理想像に近づいているかを確認するための道具として「データも」をうまく活用した分析を増やしていきたい 5

7. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. なぜ「分析」＝数字の手助けが必要になるか  1人ないし少人数で遊ぶ、完成品を提供するゲームであれば、事前のテストプレイで改善点は見つけられる  数多くのユーザがお互いに影響し合いながら楽しむゲームでは、ユーザのゲーム内の状態も生活スタイルも、とにかく多様である  多くのユーザに対して面白さを提供できているかどうかを、事前の想定や、数人によるプレイだけで把握することは困難 7 よろこびいかりかなしみたのしみ

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. #1 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#1の直接の原因  タイトル改善のための課題が適切ではなかった ⁃ ユーザの定着のための課題：想定していたユーザ層の獲得状況をチェックしていなかった • 30代男性を想定してゲームを制作していたが、実際のユーザは 40代女性の割合が高く、全体的に継続率を押し下げていた ⁃ 課金率維持のための課題：課金継続率をチェックしていなかった • 初回限定の割引を利用して課金をしても、メリットが低かった（コンティニューをしてもクリアできないステージが多かった） • 課金継続率の変化を確認していれば、問題の重大さに早く気付くことができた 11

12. #1 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#1から得られる教訓  原因に挙げたことへの対処 ⁃ タイトルを改善するために適切な課題とKPIを設定する • ユーザの定着⇒想定していたユーザ層の獲得状況 • 課金の継続⇒課金継続率、LTV  加えて：さまざまな切り口とKPIを普段から貯めておく ⁃ 分析の切り口 • 性別、年代、端末、アクティビティを用いたセグメント、… • それらの切り口を用いた集計の仕方を普段から準備しておく ⁃ KPIの事例 • 複数日課金率( = 課金を2日以上したユーザ÷ 全ユーザ) ⁃ ゲームを始めてから、課金をした日が2日以上あるユーザの割合 ⁃ 日付が変わっても課金をしているということは、初回の課金の効果を感じてリピートしてくれているということ ⁃ 優秀なタイトルはこの割合が相対的に高めのことが多いです 12

13. #1 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. KPIの事例をもう1つ…DAUの読み解き方  DAU（Daily Active Users、その日に遊んだユーザ数）をユーザの状態で色分けする ⁃ DAUのノイズが分かりやすくなると共に、ユーザの気持ちが読み取りやすくなる • CEDEC2013で発表しました • 資料はCEDiLとSlideshareにて公開中 13

14. 失敗談#1 を繰り返さないための分析業務の進め方  失敗をしないためには、仕事の進め方から変えることが望ましい  製造業などで用いられる課題解決の手法「シックスシグマ」が Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 行動につなげやすい 14 • タイトルを改善するために適切な課題とKPIを設定する • 様々なKPIを普段から貯めておく取り組む課題の定義（Define） • （様々なKPIを、すぐに見れるようにしておく）現状の把握（Measure） • 事象の背景の構造に対する仮説を立てた上で分析をする • 様々な切り口を普段から貯めておく、すぐ集計できるようにする根本原因の特定（Analyze）改善策の検討・設計（Improve / Design ）効果や設計の検証（Control / Verify ） #1

15. 新規新規ユーザの売上が Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#2 プロモーション結果の分析  プロモーション予算を変えたときの話新規既存既存 ⁃ 先月と今月の違いはプロモーション予算を減らしたことだけ ⇒LTVで採算性を確認、予算を元の水準に増やして集客した 16 5月の売上6月の売上減少していた新規＝その月にゲームを始めたユーザ既存＝前月迄にゲームを始めたユーザ #2

16. #2 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#2の直接の原因  本当の課題「ゲーム開始翌月以降のユーザからの売上減少」 5月 4月以前 6月 5月 4月以前 ⁃ 始めて1,2ヶ月すると課金を止めるタイトルになっている ⁃ よって、タイトルの中身を改善する方が優先課題 17 5月の売上6月の売上ゲームを始めた月に読み替えると、原因は「既存」にあることが分かる

17. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#2と似た事例…LTVを基にした広告出稿  プロモーションの予算を立てるときの考え方 • 「LTVが、1人当たりのユーザ獲得費用を上回っていれば、プロモーションをいくらでも続けても良い」  実績を元にLTVを予測して出稿したが、予測どおりにならない • ターゲットとするユーザ層以外のLTVは低くなりがち • いつかはターゲット層を獲得しつくすので、LTVは低下する 18 遊び続ける = 継続率課金する = 生涯課金率課金を続ける = 課金継続率月額平均課金額 × 課金継続月数ターゲットのユーザ層とそれ以外では、継続率などが大きくことなる #2

18. 失敗談#2から得られる教訓と、分析業務の進め方  事象の背景の構造に対する仮説を立てた上で分析をする  他の担当者にもサポートを求め、自分の守備範囲外の情報も得る 19 • （手段と目的の関係を明確にする） • タイトルを改善するために適切な課題とKPIを設定する • 様々なKPIを普段から貯めておく Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 取り組む課題の定義（Define） • （様々なKPIを、すぐに見れるようにしておく）現状の把握（Measure） • 事象の背景の構造に対する仮説を立てた上で分析をする • 様々な切り口を普段から貯めておく、すぐ集計できるようにする根本原因の特定（Analyze）改善策の検討・設計（Improve / Design ）効果や設計の検証（Control / Verify ） #2

19. 変更前…遊ぶ日数は考慮せず変更後…全チームに毎日遊ぶ人がいる Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#3 ゲーム内のバトルが盛り上がらない  ゲーム内でのグルーピングを改善してバトルを盛り上げたい ※チーム同士で競ったり戦ったりするバトルを想定 ⁃ 「各チームに毎日遊んでいる人を必ず入れる」というグルーピング方式を野上が提案して導入 ⁃ 初回のバトルは大きく盛り上がりました ⁃ しかし、2回目以降は効果がなくなり元に戻りました 20 チームX チームY 眠眠眠活活眠眠眠眠眠眠眠チームX’ チームY’ 眠眠眠活眠眠眠眠眠活眠眠 #3 相手チームは反撃しない ⇒楽勝！お互いに反撃の応酬 ⇒激戦！

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. #3 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#3から得られる教訓  原因に挙げたことへの対処 ⁃ 成功の要因を的確に把握し、常に改善を加える • 変更が悪影響を与えている部分は把握して対処する • 成功の前提条件が変わった場合にはやり方を見直す  加えて：前提条件や悪影響を測るKPIの集計は自動化する ⁃ 問題が顕在化しないと、分析を後回しにしてしまいがち ⁃ 集計を自動化し、チームのメンバーが自分で過去と比較できるようにしておけば、チェックは漏れにくい • 自分でも確認しやすいし、チームのメンバーにも気づいてもらえる • 今回であれば、チームごとの活動している人数を比較すべきだった 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. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#4 割引に頼った売上増加策の失敗  ガチャの施策で売上を改善しようとした話 ⁃ 「目玉カードを手に入りやすくすれば（＝価格を割引けば）、多くの人がガチャを回してくれるのでは」「負担が軽くなれば、ゲームを続けやすくなるのでは」 ⁃ 実際にはユーザ数は増えず、単価が下がって売上も減少、タイトルの継続率はとくに変わらず 24 ○○ガチャ第2弾第1弾より確率アップ！ (1%->2%) 3回目まで割引 SSR ガチャる！目玉となるカードがより低価格で手に入ると訴求した #4 ※分かりやすさのため、実際に行った施策とは表現を変えてあります。 ※ ここで示した「確率」とは、アイテム別提供割合のことです。

24. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#4の直接の原因(1,2)  課題に対する手段が適切ではなかった ⁃ 離脱理由ごとの離脱ユーザ数を把握しておくべきだった ※正確な推定は難しいですが、多いか少ないかくらいは把握できる  事象の背景や構造、原理に対する理解が薄かった ⁃ ユーザの、ガチャを回す判断基準は期待値だけではない • 多くのガチャでは、期待値は一目では分からないので、期待値を下げたことをユーザが気づかないこともある • ターゲットとなる（普段ガチャを回さない）ユーザが欲しくないカードを提供しても、ユーザはガチャを回さない 25 ○○ガチャ第2弾第1弾より確率アップ！ (1%->2%) SSR 確率が2倍といっても半額で手に入るわけは無いよな… どうせ高いでしょ僕はこんなに強いカードでなくても十分満足 #4

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. 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. 割引が効く3回目を過ぎた影響 ⇒次回は～～をして改善を狙う Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#4から得られる教訓  原因に挙げたことへの対処 ⁃ 課題に対する手段を適切に選ぶ ⁃ 事象の背景や構造、原理を十分に理解する ⁃ 事前検討やシミュレーションを十分にしておく  加えて：平均値を要素に分解してみる ⁃ 具体例：ガチャでも”継続率”を見る 28 継続率ガチャの回数1 2 3 4 5 6 7 8 … #4

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

31. データに振り回されて失敗しないために大切なこと  「現状を正しく把握して改善策を考えよう」とはよく言われる  でも、より大事なのは、「課題の定義」、「根本原因の特定」、 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 「効果や設計の検証」である 32 • 課題に対する手段を適切に選ぶ（手段と目的の関係を明確にする） • タイトルを改善するために適切な課題とKPIを設定する • 様々なKPIを普段から貯めておく取り組む課題の定義（Define） • 様々なKPIを、すぐに見れるようにしておく現状の把握（Measure） • 事象の背景や構造、原理を十分に理解する • 事象の背景の構造に対する仮説を立てた上で分析をする • 様々な切り口を普段から貯めておく、すぐ集計できるようにする根本原因の特定（Analyze） • 前提条件が変わった場合にはやり方を見直す • 事前検討やシミュレーションを十分にしておく改善策の検討・設計（Improve / Design ） • 改善策が悪影響を与えている部分を把握して対処する効果や設計の検証（Control / Verify ））

32. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 明後日からすぐにできる「分析」 1. 自分自身をサンプルとして丁寧に観察してみる • 担当しているタイトルを、1人のユーザとして素直に遊ぶ • 遊んだときのログを取り出して、プレイヤーの気持ちがどのようなログに現れるか確認し、指標にする 2. 作業にかかる負担をなくす • 上記の観察用データを含め、データ集計や可視化は自動化してしまい、作業を後回しにする言い訳をなくす 3. 普段から開発・運用チームのメンバーと真剣に議論をする • 上の2つができていれば、タイトルを理想像に近づける課題が見えてきて、議論の材料もそろうはず • 議論を通じて、チームのメンバーも同じように客観的にゲームの課題を捉えられるようになると、さらに効果が高まる  本日の発表が、より良いタイトル作り・タイトル運営のために参考になれば幸いです 33

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

Estás leyendo una previsualización.

Eche un vistazo a continuación

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

Más Contenido Relacionado

A los espectadores también les gustó (17)

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

Más reciente (20)