データに振り回されて失敗したあんなことやこんなこと＋α...

Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved.

データに振り回されて失敗したあんなことやこんなこと＋α～なぜ数字の手助けが必要になるのか、

その理由と分析の実践例～

November 22, 2014

NOGAMI Daisuke (@dnogami_dena)

Senior ManagerAnalytics Dept.DeNA Co., Ltd.


本日お話させていただく内容

自己紹介＋発表の背景

ゲームを面白くするために、なぜ「分析」＝数字の手助けが必要になるか

データに振り回されて失敗した事例集と改善結果

① リリース直後のタイトルの改善

② プロモーション結果の分析

③ ゲーム内のバトルが盛り上がらない

④ 割引に頼った売上増加策の失敗

まとめ2


自己紹介

野上大介（のがみだいすけ）

⁃ 分析部シニアマネージャー

Mobage全体からタイトルまで、様々な問題の分析と改善提案

+

⁃ 複数の有力ゲームデベロッパーに対する分析のコンサルティング

⁃ 複数のタイトルの比較や相乗効果の分析に用いる指標の定義

⁃ 指標を活用しやすくするためのデータ基盤整備

他の分析部アナリストの分析・改善提案のサポート

⁃ アナリスト＝担当するタイトル・サービスの「分析系事業参謀」

3


自己紹介

DeNA入社以前の経歴

• 東京大学大学院修了後、野村総合研究所を経て、DeNAに入社

• 野村総合研究所時代は、業界を限定せず、事業戦略の実現をクライアントの状況に合わせて支援（リサーチ・戦略立案から、戦略の具体化・業務改革、

事業計画の管理体制構築までニーズに応じてカバー）

近頃の趣味…ロケット打ち上げ見学

⁃ 11/30(日) 13:24:48のはやぶさ2打ち上げも種子島に行きます

⁃ ネット中継に加え札幌でもパブリックビューイングあり

4


「良いタイトルを、長く楽しめるようにしたい！」

タイトルを提供しつづけるには、面白さと、(最低限の)収益の両方を考えた開発・運営がかかせない

⁃ 私自身も、サービス終了に涙したことがあり…

面白さをチームの「阿吽の呼吸」で維持するのは難しい

面白さを明確に共有し、タイトルが理想像に近づいているか、客観的に確認するには「データ」は便利な道具

しかし、業界では、収益ばかりを気にした、「データだけ」を使った分析が目立ちました

タイトルが理想像に近づいているかを確認するための道具として「データも」をうまく活用した分析を増やしていきたい

5


会場にいらっしゃる皆様に質問です

担当業務：

イベント等の企画をする側

プランナー、企画など

「分析」や「データ」は

ゲーム作りの

参考になると思う

正直、データや数字で

ゲーム作りをすることは

好まない・納得できない

6

担当業務：

企画を形にする側

エンジニア、

アート・シナリオなど


なぜ「分析」＝数字の手助けが必要になるか

1人ないし少人数で遊ぶ、完成品を提供するゲームであれば、事前のテストプレイで改善点は見つけられる

数多くのユーザがお互いに影響し合いながら楽しむゲームでは、ユーザのゲーム内の状態も生活スタイルも、とにかく多様である

多くのユーザに対して面白さを提供できているかどうかを、事前の想定や、数人によるプレイだけで把握することは困難

7

よろこびかなしみいかりたのしみ



「分析」≒「コックピットの計器もみながら飛行機を操縦する」

⁃ 自分の目や感覚だけではなく、数字“も”つかうことで、ユーザが感じている喜怒哀楽をより丁寧に知ることができる

8


データに振り回されて失敗した事例集と改善結果

① リリース直後のタイトルの改善

② プロモーション結果の分析

③ ゲーム内のバトルが盛り上がらない

④ 割引に頼った売上増加策の失敗

9


失敗談#1 リリース直後のタイトルの改善

とあるタイトルのリリース直後の話

⁃ n日後の継続率が低く、ユーザが定着しない

• チュートリアルの各段階での継続率に分解したが（いわゆるファネル分析）が、原因を発見できず

⁃ 日次の課金率(=課金UU / DAU)は悪くなかった

• 新規ユーザ向け限定に、コンティニュー初回限定の割引を実施

そのタイトルは成功せず

⁃ ユーザが定着せず、課金率も低下してしまった10

ステップ番号 1 2 3 4 5 6 7 8 …

継続率

他と比べて継続率が低いステップがあればそれが原因だが、全体的に低かった

#1


失敗談#1の直接の原因

タイトル改善のための課題が適切ではなかった

⁃ ユーザの定着のための課題：想定していたユーザ層の獲得状況をチェックしていなかった

• 30代男性を想定してゲームを制作していたが、実際のユーザは40代女性の割合が高く、全体的に継続率を押し下げていた

⁃ 課金率維持のための課題：課金継続率をチェックしていなかった

• 初回限定の割引を利用して課金をしても、メリットが低かった（コンティニューをしてもクリアできないステージが多かった）

• 課金継続率の変化を確認していれば、問題の重大さに早く気付くことができた

11

#1


失敗談#1から得られる教訓

原因に挙げたことへの対処

⁃ タイトルを改善するために適切な課題とKPIを設定する

• ユーザの定着⇒想定していたユーザ層の獲得状況

• 課金の継続 ⇒課金継続率、LTV

加えて：さまざまな切り口とKPIを普段から貯めておく

⁃ 分析の切り口

• 性別、年代、端末、アクティビティを用いたセグメント、…

• それらの切り口を用いた集計の仕方を普段から準備しておく

⁃ KPIの事例

• 複数日課金率 ( = 課金を2日以上したユーザ ÷ 全ユーザ )

⁃ ゲームを始めてから、課金をした日が2日以上あるユーザの割合

⁃ 日付が変わっても課金をしているということは、初回の課金の効果を感じてリピートしてくれているということ

⁃ 優秀なタイトルはこの割合が相対的に高めのことが多いです12

#1


KPIの事例をもう1つ…DAUの読み解き方

DAU（Daily Active Users、その日に遊んだユーザ数）をユーザの状態で色分けする

⁃ DAUのノイズが分かりやすくなると共に、ユーザの気持ちが読み取りやすくなる

• CEDEC2013で発表しました

• 資料はCEDiLとSlideshareにて公開中

13

#1


失敗談#1 を繰り返さないための分析業務の進め方

失敗をしないためには、仕事の進め方から変えることが望ましい

製造業などで用いられる課題解決の手法「シックスシグマ」が行動につなげやすい

14

• タイトルを改善するために適切な課題とKPIを設定する

• 様々なKPIを普段から貯めておく

取り組む課題の定義

（Define）

• （様々なKPIを、すぐに見れるようにしておく）現状の把握（Measure）

• 事象の背景の構造に対する仮説を立てた上で分析をする

• 様々な切り口を普段から貯めておく、すぐ集計できるようにする

根本原因の特定（Analyze）

改善策の検討・設計（Improve / Design ）

効果や設計の検証（Control / Verify ）

#1


失敗談#2 プロモーション結果の分析

プロモーション予算を変えたときの話

⁃ 先月と今月の違いはプロモーション予算を減らしたことだけ⇒LTVで採算性を確認、予算を元の水準に増やして集客した

16

5月の売上 6月の売上

既存既存

新規

新規新規ユーザの売上が減少していた

新規＝その月にゲームを始めたユーザ

既存＝前月迄にゲームを始めたユーザ

#2



本当の課題「ゲーム開始翌月以降のユーザからの売上減少」

⁃ 始めて1,2ヶ月すると課金を止めるタイトルになっている

⁃ よって、タイトルの中身を改善する方が優先課題17

5月の売上 6月の売上

4月以前

5月

4月以前

5月

6月

ゲームを始めた月に読み替えると、原因は「既存」にあることが分かる

#2


失敗談#2と似た事例…LTVを基にした広告出稿

プロモーションの予算を立てるときの考え方

• 「LTVが、1人当たりのユーザ獲得費用を上回っていれば、プロモーションをいくらでも続けても良い」

実績を元にLTVを予測して出稿したが、予測どおりにならない

• ターゲットとするユーザ層以外のLTVは低くなりがち

• いつかはターゲット層を獲得しつくすので、LTVは低下する

18

遊び続ける= 継続率

課金する= 生涯課金率

課金を続ける= 課金継続率

月額平均課金額×

課金継続月数

ターゲットのユーザ層とそれ以外では、継続率などが大きくことなる

#2


失敗談#2から得られる教訓と、分析業務の進め方

事象の背景の構造に対する仮説を立てた上で分析をする

他の担当者にもサポートを求め、自分の守備範囲外の情報も得る

19

• （手段と目的の関係を明確にする）




（Define）

• （様々なKPIを、すぐに見れるようにしておく）現状の把握（Measure）






#2



失敗談#3 ゲーム内のバトルが盛り上がらない

ゲーム内でのグルーピングを改善してバトルを盛り上げたい

※チーム同士で競ったり戦ったりするバトルを想定

⁃ 「各チームに毎日遊んでいる人を必ず入れる」というグルーピング方式を野上が提案して導入

⁃ 初回のバトルは大きく盛り上がりました

⁃ しかし、2回目以降は効果がなくなり元に戻りました

20

チームX チームY

眠眠眠

活眠活

眠眠眠

眠眠眠

変更前…遊ぶ日数は考慮せず変更後…全チームに毎日遊ぶ人がいる

チームX’ チームY’

眠眠眠

活眠眠

眠眠眠

活眠眠

#3

相手チームは反撃しない⇒楽勝！

お互いに反撃の応酬⇒激戦！



成功の要因を適切に把握せず、改良すべき点に気づかなかった

⁃ 実際にゲームの中で起きていたこと

• 改良前のイベント：敵チームが1人も遊んでいないことが多いので、バトルの開始直後は様子見をすることが多い

• 改良直後のイベント：今回は全チームで遊んでいるユーザがいたので、多くのチームで「敵チームはやる気がある！」と誤解しバトルを始めた（ただし、遊ぶユーザが分散したので、1人当たりの負担は増えた）

• 2回目以降のイベント：1人当たりの負担が増えたことでユーザが疲れるイベントと認識。バトル開始直後の様子見で、敵チームの動いている人数も気にするようになった

⇒ 2回目は複数の指標を組み合わせる方式に改良すべきだった

※その他のKPIの例は来週Mobage Developers Blogに後輩アナリストが記事を書きます!(http://developers.mobage.jp/blog/) 21

#3




⁃ 成功の要因を的確に把握し、常に改善を加える

• 変更が悪影響を与えている部分は把握して対処する

• 成功の前提条件が変わった場合にはやり方を見直す

加えて：前提条件や悪影響を測るKPIの集計は自動化する

⁃ 問題が顕在化しないと、分析を後回しにしてしまいがち

⁃ 集計を自動化し、チームのメンバーが自分で過去と比較できるようにしておけば、チェックは漏れにくい

• 自分でも確認しやすいし、チームのメンバーにも気づいてもらえる

• 今回であれば、チームごとの活動している人数を比較すべきだった

22

#3



この失敗への予防策・改善策は、ImproveとControlで行う必要がある

⁃ Measureが改善されているとより確実になる

23

• （手段と目的の関係を明確にする）




（Define）

• 様々なKPIを、すぐに見れるようにしておく現状の把握（Measure）




• 前提条件が変わった場合にはやり方を見直す改善策の検討・設計（Improve / Design）

• 改善策が悪影響を与えている部分を把握して対処する効果や設計の検証（Control / Verify ）

#3


失敗談#4 割引に頼った売上増加策の失敗

ガチャの施策で売上を改善しようとした話

⁃ 「目玉カードを手に入りやすくすれば（＝価格を割引けば）、多くの人がガチャを回してくれるのでは」

「負担が軽くなれば、ゲームを続けやすくなるのでは」

⁃ 実際にはユーザ数は増えず、単価が下がって売上も減少、タイトルの継続率はとくに変わらず

24

○○ガチャ第2弾

ガチャる！

第1弾より確率アップ！

(1%->2%)

3回目まで割引

SSR目玉となるカードがより低価格で手に入ると訴求した

#4

※分かりやすさのため、実際に行った施策とは表現を変えてあります。※ここで示した「確率」とは、アイテム別提供割合のことです。


失敗談#4の直接の原因 (1,2)

課題に対する手段が適切ではなかった

⁃ 離脱理由ごとの離脱ユーザ数を把握しておくべきだった

※正確な推定は難しいですが、多いか少ないかくらいは把握できる

事象の背景や構造、原理に対する理解が薄かった

⁃ ユーザの、ガチャを回す判断基準は期待値だけではない

• 多くのガチャでは、期待値は一目では分からないので、期待値を下げたことをユーザが気づかないこともある

• ターゲットとなる（普段ガチャを回さない）ユーザが欲しくないカードを提供しても、ユーザはガチャを回さない

25

○○ガチャ第2弾

第1弾より確率アップ！

(1%->2%)

SSR

確率が2倍といっても半額で手に入るわけは無いよな…

どうせ高いでしょ僕はこんなに強いカードでなくても十分満足

#4


ガチャの回数 1 2 3 4 5 6 7 8 …

n回以上ガチャをしたユーザ数

確率から想定したユーザ数

失敗談#4の直接の原因 (3)

事前検討やシミュレーションが不足していた

⁃ ユーザ数を増やしても、必ずしも売上が増えないことがある

• 期待値を計算するときは、ガチャを回し始めた全員が「目玉カードを取れるまで回し続ける」前提を置くことが多い

• 実際は途中であきらめるユーザさんも多い

26

実際にガチャをしたユーザ数

割引が効く3回目であきらめたためユーザ数が減った

#4


失敗談#4と似た事例…セット販売の副作用

セット販売で、アイテムの価値を高く見せようとした話

⁃ 本当に売りたい商品と、比較対象のやや劣る商品を見せることで、高額なセット商品が買いたくなるようにした

⁃ しかし、セット販売が常態化したときに、売りたい商品の魅力も薄れてしまった

（例：不必要なものが手元にあるので、トレード等で節約できる）

27

10連ガチャ2,700円

アイテム10個3,000円

アイテム8個付き10連ガチャ

3,000円1個300円のアイテムのおまけ8個分、10連ガチャが劣ってみえる

ガチャが10回引けるので、アイテムだけのセットが劣ってみえる

ガチャで強くなりたい！

アイテムで沢山戦いたい！

#5

余ったアイテム、トレードに使ってガチャ不要！

余ったカードをトレードしてアイテムに！




⁃ 課題に対する手段を適切に選ぶ

⁃ 事象の背景や構造、原理を十分に理解する

⁃ 事前検討やシミュレーションを十分にしておく

加えて：平均値を要素に分解してみる

⁃ 具体例：ガチャでも”継続率”を見る

28

ガチャの回数 1 2 3 4 5 6 7 8 …

継続率

割引が効く3回目を過ぎた影響⇒次回は～～をして改善を狙う

#4



この失敗への予防策・改善策は、Define,Analyze,Improveで行う必要がある

⁃ これまでの改善点すべてが必要になる事例

29

• 課題に対する手段を適切に選ぶ（手段と目的の関係を明確にする）




（Define）


• 事象の背景や構造、原理を十分に理解する




• 前提条件が変わった場合にはやり方を見直す

• 事前検討やシミュレーションを十分にしておく

改善策の検討・設計（Improve / Design）


#4


まとめ

• なぜ「分析」＝数字の手助けが必要になるか

• データに振り回されて失敗しないために大切なこと

• 明後日からすぐにできる「分析」

30



「分析」≒「コックピットの計器もみながら飛行機を操縦する」

⁃ 自分の目や感覚だけではなく、数字“も”つかうことで、ユーザが感じている喜怒哀楽をより丁寧に知ることができる

31


データに振り回されて失敗しないために大切なこと

「現状を正しく把握して改善策を考えよう」とはよく言われる

でも、より大事なのは、「課題の定義」、「根本原因の特定」、「効果や設計の検証」である

32

• 課題に対する手段を適切に選ぶ（手段と目的の関係を明確にする）




（Define）


• 事象の背景や構造、原理を十分に理解する




• 前提条件が変わった場合にはやり方を見直す

• 事前検討やシミュレーションを十分にしておく




（Define）




明後日からすぐにできる「分析」

1. 自分自身をサンプルとして丁寧に観察してみる

• 担当しているタイトルを、1人のユーザとして素直に遊ぶ

• 遊んだときのログを取り出して、プレイヤーの気持ちがどのようなログに現れるか確認し、指標にする

2. 作業にかかる負担をなくす

• 上記の観察用データを含め、データ集計や可視化は自動化してしまい、作業を後回しにする言い訳をなくす

3. 普段から開発・運用チームのメンバーと真剣に議論をする

• 上の2つができていれば、タイトルを理想像に近づける課題が見えてきて、議論の材料もそろうはず

• 議論を通じて、チームのメンバーも同じように客観的にゲームの課題を捉えられるようになると、さらに効果が高まる

本日の発表が、より良いタイトル作り・タイトル運営のために参考になれば幸いです

33


34

本発表の内容のアップロード先は、 @dnogami_dena でのツイートとFacebookでの投稿（https://www.facebook.com/daisuke.nogami）で告知します

https://www.facebook.com/daisuke.nogami

データに振り回されて失敗した あんなことやこんなこと＋α...

Data & Analytics

データに振り回されて失敗したあんなことやこんなこと＋α...