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