Native ⇄ Unityアプリのアナリティクス

グリーグループモバイルアプリ勉強会 Vol.1
https://gree.connpass.com/event/142728/

Transcript

1. Native ⇄ Unityアプリの アナリティクス 2019.9.11 グリーグループモバイルアプリ勉強会 Vol.1 増住 啓吾
2. 自己紹介 • 増住 啓吾 • Wright Flyer Live Entertainment • EN • 最近 • クライアントサイド • iOS Native • その他 • データ基盤周り • CNCF系
3. Native ⇄ Unityアプリ
5. Native Unity
6. Embedded Unity? Unity as a library? Unityアプリのframework化？ And so on... is 何 いずれにせよ、 世にあまり例のない形式（多分）
7. CASE: チュートリアル
8. 画面遷移図 (一部抜粋)
9. 背景 • 既存のデータ基盤は存在するが、サーバサイドのログベース のもの • チュートリアル突破率向上のため、より詳細な分析をしたい • そのために、クライアントサイドのイベントトラッキングを 本格的に増やしていく
10. クライアントサイドのイベントトラッキング = 「まあ、普通に考えれば使うよな」
11. 「そのデータ、その形式で取る必要あるの？」
12. 文化が違う アプリのアーキテクチャと同じように、 異なる文化圏のメンバーがMIXされたチーム
13. アナリティクス => Firebaseは”常識”ではない • グループ内の大勢を占めるゲーム事業ではほぼ使っていない ので、既存のデータ基盤と連携できないのではないか • そもそも、既存の形式のサーバサイドのログを増やしていけ ばいいのではないか • Bigqueryにexportした時のスキーマが扱いづらそう といったような意見をいただく
14. 「常識だから」ではなく 「なぜ使うか」を考える
15. • サーバサイドの開発工数削減 => 開発スピードUP! • サーバリソースは全てFirebase側 => サーバのパフォーマンス向上・コスト削減 • Firebase (GCP) の他プロダクトとの連携 => Bigquery export, A/B Testing, In-App Messaging, ... メリットは？
16. 実装
17. 設計 • Unity側が依存する要素をなるべく減らしたい => Firebase ClientはNative側だけに持つ • UnityからNativeにEvent Paramsを通知し、Native側はそれ を整形してFirebase Analyticsに送信する 　
18. Unity Unity Native Interface Native App (Swift / Kotlin) Native App側へ 通知 イベント トラッキング 実行 Bridge イベント発生 Bridge部分 呼び出し Event Params JSON
19. • トラッキングするデータ構造がUnity, Nativeそれぞれに分散 しているので、運用が重要 • 非ENのメンバーや、事業部外のチームとの連携も必要なの で、スプシを地道に運用してます。。 データ構造の管理
20. TIPS
21. • イベントトラッキングのログをほぼリアルタイムで確認でき る • イベントのパラメタやユーザープロパティも表示 => 開発者以外が確認する際 (QAなど) のテストケースとして 設定しやすくなり、データの抜け漏れを防ぎやすくなる Firebase DebugView
22. Firebase DebugView
23. BigQuery View • クエリによって生成する仮想テーブル =>データ集計処理不要 • 生成元が分割テーブルの場合、Partition Columnを参照した クエリで生成すればそのまま適用 => コストデメリットなし • スキーマが複雑なFirebase Analyticsのレコードの運用がラク に
24. クエリ行数: 165行 -> 6行
25. • Firebase AnalyticsはREALITYのような特殊な構造のアプリに おいても有効 • ただし、「普通そうだから」で導入してはいけない、「なぜ 使うか」がより重要になる • Unity⇄Native間のインターフェイスを適切に設計すること で、無駄な依存を作らずにシームレスに計測できる まとめ