ゲームアプリ分析基盤としてのBigQuery活用事例 / How to use BigQuery as a platform for analysis of games

Transcript

1. D1-3-S03 ゲームアプリ分析基盤としての BigQuery 活用事例 ～少人数チームが 20 タイトルを支えるための仕組み～ 9 月 19 日 宮﨑友輔 株式会社サイバード, データアナリスト / データ戦略部 部長 細川勇太 株式会社サイバード, データエンジニア
2. 細川勇太 株式会社サイバード データエンジニア SIer を経て、2012 年サイバード入社。 スマートフォン向けゲームのサーバーサイドエンジニアとして 運用・開発を担当。 2017 年からデータ戦略部に異動し、データエンジニアとして 分析基盤における運用・開発を担当。 Photo Speaker
3. ゲーム事業 • 女性向け恋愛シミュレーションゲーム　「イケメンシリーズ」 ◦ イケメンとの恋愛ストーリーを楽しむノベル型ゲーム ◦ アプリ版は 2012 年開始。シリーズ化され現在 10 タイトル配信中 ◦ 累計ユーザ数は 2,000 万 ◦ 英語版 4 タイトル（自社名義）、中国語版（ライセンスアウト） 会社紹介
4. ゲーム事業 • サッカーシミュレーションゲーム「BFB Champions 2.0」 • 上記の他、約 5 タイトル 会社紹介
5. コンテンツ事業 • 占いサイト　「細木数子六星占術」 • 波情報サイト「なみある？」 • スマートスピーカー向け VOICE UI コンテンツ • 女性向け情報メディア「 numan 」 会社紹介
6. 分析チームについて • ゲーム事業に属するデータ分析部門 • 2013 年に立ち上げ • 現在、3 名で構成（データアナリスト 2 名、エンジニア 1 名） ◦ スキルを補い合う • データを活用し、事業の収益に貢献することがミッション
7. 分析チームのカバー範囲 • 新規タイトルの検討 • 運用中タイトル個別の問題分析、改善 • シリーズものを統合した状況把握 • 経営層、ゲーム事業責任者、ゲーム運営チームとの向き合い • 上記を支える分析基盤の構築、運用 ◦ KPI ダッシュボード ◦ データアナリストのアドホック分析用 DB
8. Agenda エンジニアサイド • 以前の分析基盤の課題 • 解決策 • 現在の分析基盤（データ処理編） ビジネスサイド • 現在の分析基盤（可視化編） • 活用状況 • コスト • まとめ
9. 1 エンジニアサイド
10. Game Service BigQuery RDB Report & Analysis 以前の分析基盤 Cloud Storage 内製ダッシュボード Redash AWS S3 EC2 EC2 EC2 RDS
11. 分析基盤の課題 1 • データを処理する場所が分散しているため、保守性が低い
12. 分析基盤の課題 2 • アナリストがアドホック分析するとき、準備に手間が掛かる ◦ アナリストがデータの可視化に Redash を使うようになったが ▪ すぐに可視化できるが、自由度が少なく表現しづらい ◦ 重複や不要データ除外のためのクエリが長い
13. 分析基盤の課題 3 • 内製 KPI ダッシュボードの運用に、工数や人員を確保できない
14. 解決策 1. データを処理する場所が分散しているため、保守性が低い → 処理の経路を短く 2. アナリストがアドホック分析するとき、準備に手間が掛かる → データを扱いやすい構造に 3. 内製 KPI ダッシュボードの運用に、工数や人員を確保できない → 内製ダッシュボード廃止
15. Game Service BigQuery RDB Report & Analysis 現在の分析基盤 Cloud Storage Data Studio AWS EC2 EC2 S3
16. Game Service BigQuery RDB Report & Analysis KPI 用共通フォーマットデータ Cloud Storage Data Studio AWS S3 EC2
17. KPI 用共通フォーマットデータ KPI 用共通フォーマットデータ ◦ ユーザープロフィール ◦ ログイン ◦ Sales ◦ アイテム ◦ ガチャ Amazon S3 Cloud Storage BigQuery S3
18. user_profile sales login XXX table 日次 user 別集計 月次 user 別集計 ログイン頻度別 XXX table 月次 KPI 集計 継続日数別 XXX 集計 table KPI 用共通フォーマットデータ
19. 日次 user 別集計 月次 user 別集計 外部リソースデータ Firebase データ 外部リソースデータ 広告データ 為替情報、 調整係数マスタ etc. organic セグメント集計 レベル別セグメント 集計 タイトル横断 集計 機種別 集計 XXX 集計 共通フォーマットデータ
20. Game Service BigQuery RDB Report & Analysis ゲーム固有データ Cloud Storage Data Studio AWS EC2
21. • Embulk と Digdag を用いたデータ抽出 ゲーム固有データ mysql BigQuery Embulk データの性質によって抽出条件を変える
22. ゲーム固有データ • user 系 ：更新データ、追加データのみ append updated_at >= ${start_unixtime}
23. ゲーム固有データ • log 系 ：追加データのみ append created_at >= ${start_unixtime}
24. ゲーム固有データ • master 系 ：全データを replace
25. ゲーム固有データ user 別集計 テーブル KPI 用共通フォーマットデータ ゲーム固有データ user log master ゲーム固有データ、KPI 用共通フォーマット データで結合でき、アドホックな分析が可能
26. 2 ビジネスサイド
27. 宮﨑友輔 株式会社サイバード データアナリスト / データ戦略部 部長 主要ゲームタイトルを担当するデータアナリストであり、データ分 析部門の責任者。 データ分析を通じて、ゲーム事業の収益につながる問題解決に取 り組んでいる。 Photo Speaker
28. Agenda エンジニアサイド • 以前の分析基盤の課題 • 解決策 • 現在の分析基盤（データ処理編） ビジネスサイド • 現在の分析基盤（可視化編） • 活用状況 • コスト • まとめ
29. 分析基盤の活用（可視化編） 課題 3 • 内製 KPI ダッシュボードの運用に、工数や人員を確保できない
30. 分析基盤の活用（可視化編） 課題 3 • 内製 KPI ダッシュボードの運用に、工数や人員を確保できない 解決策 ➔ 内製ダッシュボード廃止 データを可視化し、共有する製品の導入
31. KPI ダッシュボードの選定要件（機能面） 1. BigQuery に接続できる 2. ある程度のチャート、表、フィルタ、集計機能 ◦ 高度な機能は求めない 3. レポートの共有が簡単にできる
32. KPI ダッシュボードの選定要件（非機能面） 1. 非エンジニアがページを作成したり編集できる ◦ アナリストが SQL を使える前提 2. web ブラウザで動く 3. 学習コストが低い 4. アカウントや権限管理の手間が少ない 5. 利用ユーザ数の上限設定が細かくない
33. Data Studio を選択 理由 • 非機能面をすべて満たす • 機能面も十分 • アップデートの頻度が多く、充実していくと期待 • 分析基盤のデータが整っていれば、もしダメでも BI を換えればいい
34. • KPI ダッシュボードは、ほぼ想定通りの出来 • アドホック分析も、期待通り効率化 活用状況
35. Data Studio で作成。内製ダッシュボードとほぼ同等の機能を実現。 • 十分な種類のチャートや表、フィルタ • データの集計 / 変換 • URL を教えるだけでレポート共有 • レポート間のリンクやページ構成 KPI ダッシュボードの実際（機能面）
36. G Suite の恩恵を受け、管理のための工数を削減。 • G Suite の認証を使えるので、独自の認証やセキュリティは不要 • レポートはGoogle ドライブ上に保存される ◦ 閲覧範囲を制限する場合は、フォルダを分ける ◦ Google グループへの権限付与も可能 KPI ダッシュボードの実際（非機能面）
37. ユーザーセグメントごとに Sales 、DAU 、課金率などの指標を表示。 問題の切り分けに活用。 切り分けに使う軸 • レベル • ログイン頻度 • 累積課金額 • 直近 30 日間の課金額 • 継続日数 KPI ダッシュボード画面例
38. 例：特定セグメントの課金率が、上昇していることが分かる KPI ダッシュボード画面例
39. • セグメント情報が付与されたテーブルを利用し、効率化 ◦ 重複や不要データの除外、集計の短縮でクエリが短くなる ◦ 以前なら複雑なクエリになる要件の分析も、気兼ねなく行える • 分析用に作成したクエリを Data Studio に流用し、簡単に可視化 ◦ アドホック分析のクエリをそのまま、定常的なモニタリングに ◦ ダッシュボードに載せるレポートの試作 アドホック分析
40. シリーズものを複数タイトル利用するユーザの分析 1. シリーズ全体を一括りにした KPI 集計 2. 複数タイトル利用をモデル化し、広告費を調整 3. クラスタリングの結果を元に、新規タイトルの舞台設定を提案 分析事例
41. シリーズ全体を一括りにした KPI 集計 • 全体 → シリーズものの正味の利用者数が分かる • ログインタイトル数別 → 売上の食い合いがないかチェックできる 分析事例 1
42. 複数タイトル利用をモデル化し、広告費を調整 • 新規ユーザについて、シリーズ全体の LTV を算出 → 獲得単価を上げて、獲得件数が増加 分析事例 2
43. クラスタリングの結果を元に、新規タイトルの舞台設定を提案 • ログインや課金の実績から、近いタイトルをグループ化 分析事例 3
44. コスト • インフラそのもののコストは、ほぼ変わらず ◦ 集計処理やデータが増えた ◦ 過去データの再集計を行った分、初回だけ少し増加 • 保守にかかるコストは、減少 ◦ 再集計や調査の頻度低下 ◦ 内製ダッシュボードも保守不要
45. まとめ 1. データを処理する場所が分散しているため、保守性が低い → BigQuery に処理を集中し、内部を層別化 2. 内製 KPI ダッシュボードの運用に、工数や人員を確保できない → Data Studio に移行し、アナリストも編集可能に 3. アナリストがアドホック分析するとき、準備に手間が掛かる → アドホック分析にすぐ利用できるデータ構造に → Data Studio で容易に可視化、共有
46. • セグメント情報を活用した機械学習 • BigQuery への取り込みデータの拡張 ◦ ゲーム外データとの連携 • データ探索の効率化 ◦ Data Studio の Explorer 、データ統合機能 今後の展望
47. Thank you.