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

Native ⇄ Unityアプリのアナリティクス 2019.9.11 グリーグループモバイルアプリ勉強会 Vol.1 増住啓吾

自己紹介 • 増住啓吾 • Wright Flyer Live Entertainment •
EN • 最近 • クライアントサイド • iOS Native • その他 • データ基盤周り • CNCF系

Native ⇄ Unityアプリ

Native Unity

Embedded Unity? Unity as a library? Unityアプリのframework化？ And so on...
is 何いずれにせよ、世にあまり例のない形式（多分）

CASE: チュートリアル

画面遷移図 (一部抜粋)

背景 • 既存のデータ基盤は存在するが、サーバサイドのログベースのもの • チュートリアル突破率向上のため、より詳細な分析をしたい • そのために、クライアントサイドのイベントトラッキングを本格的に増やしていく

クライアントサイドのイベントトラッキング = 「まあ、普通に考えれば使うよな」

「そのデータ、その形式で取る必要あるの？」

文化が違うアプリのアーキテクチャと同じように、異なる文化圏のメンバーがMIXされたチーム

アナリティクス => Firebaseは”常識”ではない • グループ内の大勢を占めるゲーム事業ではほぼ使っていないので、既存のデータ基盤と連携できないのではないか • そもそも、既存の形式のサーバサイドのログを増やしていけばいいのではないか •
Bigqueryにexportした時のスキーマが扱いづらそうといったような意見をいただく

「常識だから」ではなく「なぜ使うか」を考える

• サーバサイドの開発工数削減 => 開発スピードUP! • サーバリソースは全てFirebase側 => サーバのパフォーマンス向上・コスト削減 • Firebase
(GCP) の他プロダクトとの連携 => Bigquery export, A/B Testing, In-App Messaging, ... メリットは？

実装

設計 • Unity側が依存する要素をなるべく減らしたい => Firebase ClientはNative側だけに持つ • UnityからNativeにEvent Paramsを通知し、Native側はそれを整形してFirebase
Analyticsに送信する　

Unity Unity Native Interface Native App (Swift / Kotlin) Native
App側へ通知イベントトラッキング実行 Bridge イベント発生 Bridge部分呼び出し Event Params JSON

• トラッキングするデータ構造がUnity, Nativeそれぞれに分散しているので、運用が重要 • 非ENのメンバーや、事業部外のチームとの連携も必要なので、スプシを地道に運用してます。。データ構造の管理

• イベントトラッキングのログをほぼリアルタイムで確認できる • イベントのパラメタやユーザープロパティも表示 => 開発者以外が確認する際 (QAなど) のテストケースとして設定しやすくなり、データの抜け漏れを防ぎやすくなる
Firebase DebugView

Firebase DebugView

BigQuery View • クエリによって生成する仮想テーブル =>データ集計処理不要 • 生成元が分割テーブルの場合、Partition Columnを参照したクエリで生成すればそのまま適用 =>
コストデメリットなし • スキーマが複雑なFirebase Analyticsのレコードの運用がラクに

クエリ行数: 165行 -> 6行

• Firebase AnalyticsはREALITYのような特殊な構造のアプリにおいても有効 • ただし、「普通そうだから」で導入してはいけない、「なぜ使うか」がより重要になる • Unity⇄Native間のインターフェイスを適切に設計することで、無駄な依存を作らずにシームレスに計測できる
まとめ

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

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

aroshipup

Other Decks in Programming

Featured

Transcript