Tweet
Tweet

Slide 1

Slide 1 text

D1-3-S03 ゲームアプリ分析基盤としての BigQuery 活用事例 ～少人数チームが 20 タイトルを支えるための仕組み～ 9 月 19 日 宮﨑友輔 株式会社サイバード, データアナリスト / データ戦略部 部長 細川勇太 株式会社サイバード, データエンジニア

Slide 2

Slide 2 text

細川勇太 株式会社サイバード データエンジニア SIer を経て、2012 年サイバード入社。 スマートフォン向けゲームのサーバーサイドエンジニアとして 運用・開発を担当。 2017 年からデータ戦略部に異動し、データエンジニアとして 分析基盤における運用・開発を担当。 Photo Speaker

Slide 3

Slide 3 text

ゲーム事業 ● 女性向け恋愛シミュレーションゲーム　「イケメンシリーズ」 ○ イケメンとの恋愛ストーリーを楽しむノベル型ゲーム ○ アプリ版は 2012 年開始。シリーズ化され現在 10 タイトル配信中 ○ 累計ユーザ数は 2,000 万 ○ 英語版 4 タイトル（自社名義）、中国語版（ライセンスアウト） 会社紹介

Slide 4

Slide 4 text

ゲーム事業 ● サッカーシミュレーションゲーム「BFB Champions 2.0」 ● 上記の他、約 5 タイトル 会社紹介

Slide 5

Slide 5 text

コンテンツ事業 ● 占いサイト　「細木数子六星占術」 ● 波情報サイト「なみある？」 ● スマートスピーカー向け VOICE UI コンテンツ ● 女性向け情報メディア「 numan 」 会社紹介

Slide 6

Slide 6 text

分析チームについて ● ゲーム事業に属するデータ分析部門 ● 2013 年に立ち上げ ● 現在、3 名で構成（データアナリスト 2 名、エンジニア 1 名） ○ スキルを補い合う ● データを活用し、事業の収益に貢献することがミッション

Slide 7

Slide 7 text

分析チームのカバー範囲 ● 新規タイトルの検討 ● 運用中タイトル個別の問題分析、改善 ● シリーズものを統合した状況把握 ● 経営層、ゲーム事業責任者、ゲーム運営チームとの向き合い ● 上記を支える分析基盤の構築、運用 ○ KPI ダッシュボード ○ データアナリストのアドホック分析用 DB

Slide 8

Slide 8 text

Agenda エンジニアサイド ● 以前の分析基盤の課題 ● 解決策 ● 現在の分析基盤（データ処理編） ビジネスサイド ● 現在の分析基盤（可視化編） ● 活用状況 ● コスト ● まとめ

Slide 9

Slide 9 text

1 エンジニアサイド

Slide 10

Slide 10 text

Game Service BigQuery RDB Report & Analysis 以前の分析基盤 Cloud Storage 内製ダッシュボード Redash AWS S3 EC2 EC2 EC2 RDS

Slide 11

Slide 11 text

分析基盤の課題 1 ● データを処理する場所が分散しているため、保守性が低い

Slide 12

Slide 12 text

分析基盤の課題 2 ● アナリストがアドホック分析するとき、準備に手間が掛かる ○ アナリストがデータの可視化に Redash を使うようになったが ■ すぐに可視化できるが、自由度が少なく表現しづらい ○ 重複や不要データ除外のためのクエリが長い

Slide 13

Slide 13 text

分析基盤の課題 3 ● 内製 KPI ダッシュボードの運用に、工数や人員を確保できない

Slide 14

Slide 14 text

解決策 1. データを処理する場所が分散しているため、保守性が低い → 処理の経路を短く 2. アナリストがアドホック分析するとき、準備に手間が掛かる → データを扱いやすい構造に 3. 内製 KPI ダッシュボードの運用に、工数や人員を確保できない → 内製ダッシュボード廃止

Slide 15

Slide 15 text

Game Service BigQuery RDB Report & Analysis 現在の分析基盤 Cloud Storage Data Studio AWS EC2 EC2 S3

Slide 16

Slide 16 text

Game Service BigQuery RDB Report & Analysis KPI 用共通フォーマットデータ Cloud Storage Data Studio AWS S3 EC2

Slide 17

Slide 17 text

KPI 用共通フォーマットデータ KPI 用共通フォーマットデータ ○ ユーザープロフィール ○ ログイン ○ Sales ○ アイテム ○ ガチャ Amazon S3 Cloud Storage BigQuery S3

Slide 18

Slide 18 text

user_profile sales login XXX table 日次 user 別集計 月次 user 別集計 ログイン頻度別 XXX table 月次 KPI 集計 継続日数別 XXX 集計 table KPI 用共通フォーマットデータ

Slide 19

Slide 19 text

日次 user 別集計 月次 user 別集計 外部リソースデータ Firebase データ 外部リソースデータ 広告データ 為替情報、 調整係数マスタ etc. organic セグメント集計 レベル別セグメント 集計 タイトル横断 集計 機種別 集計 XXX 集計 共通フォーマットデータ

Slide 20

Slide 20 text

Game Service BigQuery RDB Report & Analysis ゲーム固有データ Cloud Storage Data Studio AWS EC2

Slide 21

Slide 21 text

● Embulk と Digdag を用いたデータ抽出 ゲーム固有データ mysql BigQuery Embulk データの性質によって抽出条件を変える

Slide 22

Slide 22 text

ゲーム固有データ ● user 系 ：更新データ、追加データのみ append updated_at >= ${start_unixtime}

Slide 23

Slide 23 text

ゲーム固有データ ● log 系 ：追加データのみ append created_at >= ${start_unixtime}

Slide 24

Slide 24 text

ゲーム固有データ ● master 系 ：全データを replace

Slide 25

Slide 25 text

ゲーム固有データ user 別集計 テーブル KPI 用共通フォーマットデータ ゲーム固有データ user log master ゲーム固有データ、KPI 用共通フォーマット データで結合でき、アドホックな分析が可能

Slide 26

Slide 26 text

2 ビジネスサイド

Slide 27

Slide 27 text

宮﨑友輔 株式会社サイバード データアナリスト / データ戦略部 部長 主要ゲームタイトルを担当するデータアナリストであり、データ分 析部門の責任者。 データ分析を通じて、ゲーム事業の収益につながる問題解決に取 り組んでいる。 Photo Speaker

Slide 28

Slide 28 text

Agenda エンジニアサイド ● 以前の分析基盤の課題 ● 解決策 ● 現在の分析基盤（データ処理編） ビジネスサイド ● 現在の分析基盤（可視化編） ● 活用状況 ● コスト ● まとめ

Slide 29

Slide 29 text

分析基盤の活用（可視化編） 課題 3 ● 内製 KPI ダッシュボードの運用に、工数や人員を確保できない

Slide 30

Slide 30 text

分析基盤の活用（可視化編） 課題 3 ● 内製 KPI ダッシュボードの運用に、工数や人員を確保できない 解決策 ➔ 内製ダッシュボード廃止 データを可視化し、共有する製品の導入

Slide 31

Slide 31 text

KPI ダッシュボードの選定要件（機能面） 1. BigQuery に接続できる 2. ある程度のチャート、表、フィルタ、集計機能 ○ 高度な機能は求めない 3. レポートの共有が簡単にできる

Slide 32

Slide 32 text

KPI ダッシュボードの選定要件（非機能面） 1. 非エンジニアがページを作成したり編集できる ○ アナリストが SQL を使える前提 2. web ブラウザで動く 3. 学習コストが低い 4. アカウントや権限管理の手間が少ない 5. 利用ユーザ数の上限設定が細かくない

Slide 33

Slide 33 text

Data Studio を選択 理由 ● 非機能面をすべて満たす ● 機能面も十分 ● アップデートの頻度が多く、充実していくと期待 ● 分析基盤のデータが整っていれば、もしダメでも BI を換えればいい

Slide 34

Slide 34 text

● KPI ダッシュボードは、ほぼ想定通りの出来 ● アドホック分析も、期待通り効率化 活用状況

Slide 35

Slide 35 text

Data Studio で作成。内製ダッシュボードとほぼ同等の機能を実現。 ● 十分な種類のチャートや表、フィルタ ● データの集計 / 変換 ● URL を教えるだけでレポート共有 ● レポート間のリンクやページ構成 KPI ダッシュボードの実際（機能面）

Slide 36

Slide 36 text

G Suite の恩恵を受け、管理のための工数を削減。 ● G Suite の認証を使えるので、独自の認証やセキュリティは不要 ● レポートはGoogle ドライブ上に保存される ○ 閲覧範囲を制限する場合は、フォルダを分ける ○ Google グループへの権限付与も可能 KPI ダッシュボードの実際（非機能面）

Slide 37

Slide 37 text

ユーザーセグメントごとに Sales 、DAU 、課金率などの指標を表示。 問題の切り分けに活用。 切り分けに使う軸 ● レベル ● ログイン頻度 ● 累積課金額 ● 直近 30 日間の課金額 ● 継続日数 KPI ダッシュボード画面例

Slide 38

Slide 38 text

例：特定セグメントの課金率が、上昇していることが分かる KPI ダッシュボード画面例

Slide 39

Slide 39 text

● セグメント情報が付与されたテーブルを利用し、効率化 ○ 重複や不要データの除外、集計の短縮でクエリが短くなる ○ 以前なら複雑なクエリになる要件の分析も、気兼ねなく行える ● 分析用に作成したクエリを Data Studio に流用し、簡単に可視化 ○ アドホック分析のクエリをそのまま、定常的なモニタリングに ○ ダッシュボードに載せるレポートの試作 アドホック分析

Slide 40

Slide 40 text

シリーズものを複数タイトル利用するユーザの分析 1. シリーズ全体を一括りにした KPI 集計 2. 複数タイトル利用をモデル化し、広告費を調整 3. クラスタリングの結果を元に、新規タイトルの舞台設定を提案 分析事例

Slide 41

Slide 41 text

シリーズ全体を一括りにした KPI 集計 ● 全体 → シリーズものの正味の利用者数が分かる ● ログインタイトル数別 → 売上の食い合いがないかチェックできる 分析事例 1

Slide 42

Slide 42 text

複数タイトル利用をモデル化し、広告費を調整 ● 新規ユーザについて、シリーズ全体の LTV を算出 → 獲得単価を上げて、獲得件数が増加 分析事例 2

Slide 43

Slide 43 text

クラスタリングの結果を元に、新規タイトルの舞台設定を提案 ● ログインや課金の実績から、近いタイトルをグループ化 分析事例 3

Slide 44

Slide 44 text

コスト ● インフラそのもののコストは、ほぼ変わらず ○ 集計処理やデータが増えた ○ 過去データの再集計を行った分、初回だけ少し増加 ● 保守にかかるコストは、減少 ○ 再集計や調査の頻度低下 ○ 内製ダッシュボードも保守不要

Slide 45

Slide 45 text

まとめ 1. データを処理する場所が分散しているため、保守性が低い → BigQuery に処理を集中し、内部を層別化 2. 内製 KPI ダッシュボードの運用に、工数や人員を確保できない → Data Studio に移行し、アナリストも編集可能に 3. アナリストがアドホック分析するとき、準備に手間が掛かる → アドホック分析にすぐ利用できるデータ構造に → Data Studio で容易に可視化、共有

Slide 46

Slide 46 text

● セグメント情報を活用した機械学習 ● BigQuery への取り込みデータの拡張 ○ ゲーム外データとの連携 ● データ探索の効率化 ○ Data Studio の Explorer 、データ統合機能 今後の展望

Slide 47

Slide 47 text

Thank you.