FirebaseAnalyticsをBigQueryから眺める

この記事は eureka Advent Calendar 2018 13日目の記事です。

PairsのGlobal版(台湾・韓国展開中)のAndroidエンジニアをしているt-kurimuraです。愛すべきJリーグが終わってしまい2018年をすでに終えたような気分です。残った力を振り絞り2本目のAdventCalendarです。

※ タイトルではGoogleAnalytis For Firebaseを便宜的に FirebaseAnalyticsと表記しています。

Firebaseとは

Firebaseとは、Googleによって提供されるフロントエンド開発者に向けた統合開発プラットフォームです。現在、FirebaseにはBeta版も含めおよそ20の機能があり、サービスの立ち上げ → 改善 → グロースといったすべてのサービス開発のフェーズをサポートしています。

https://firebase.google.com/?hl=ja

Eureka/PairsでのFirebaseの運用状況

Hosting

一部のコーポレート関連サイトでFirebase Hostingを利用しています。

Crashlytics

弊社の開発アプリのPairs,Pairs(Global版),CouplesのAndroid版/iOS版のすべてのチームでCrashlyticsを利用しています。チーム毎にクラッシュフリー率を確認し異常があれば対応します。

チームによっては、CrashlyticsのデータをBigQueryに連携することによって、アラートをより細かく設定できるようにしたり、より詳細なクラッシュ発生状況を確認することができるようにしています。

Performance Monitoring

私が担当しているPairsのGlobal版を含め、いくつかのチームでアプリの継続的改善にPerformance Monitoringを利用しています。Androidではgradleファイルに依存関係を追加するだけで、依存SDK内を含むHTTP通信の状況やアプリの起動・表示までの時間が計測できます。

API通信エラー割合からレアケースでの制御漏れを検知したり、起動から表示までの時間の短縮などの継続的改善に役立てたりしています。

Remote Config

新規機能追加時やABテストの開放・中止などにRemoteConfigを活用しています。サーバーサイドの負荷を見極めながら開放したかったり、特定機能のビジネス影響を小さく計測しながら確認したいときにも積極的に利用しています。

一部チームでは、自社APIから得られたUserIDをキーに制御することも可能にし、ビジネス指標の計測を行い行いやすくしています。

Google Analytics

サーバーサイドのログと合わせてGoogleAnalyticsのログもプロダクト改善に活用されています。どのページが一番訪れられているのかといった情報やプッシュ通知の開かれている数の計測、インストールから登録・ログインまでの経路の分析に役立てられているます。

この導入・運用方法について下で解説していきます。


その他、In-App MessagingやCloud Messagingも一部では運用可能フェーズにあり、他のツールからの代替を含め積極的に導入を行っています。

GoogleAnalytis For Firebaseについて

GoogleAnalytis For Firebaseは、AndroidやiOSのアプリからユーザーが操作したイベントを送信、集積、分析をすることができるツールです。ユーザーのページ遷移、ボタンの押下、商品の購入など様々なイベントを送ることができます。

また、ユーザーの情報に関しても詳細に設定することができ、そのユーザーの性別や年齢などアプリ上で付与したデータをそれぞれのイベントと紐付けることができます。

実装の簡単さ

こうしたアプリのイベントを自社APIなどを利用して送信を仕様とすると、Androidアプリでは当然非同期通信を必要とし、多くのコードを書かなければなりません。開発の難易度は高くないものの時間的・心理的に手間がかかります。

Firebaseを利用した場合、Bundleに関しては、イベントのカスタムプロパティがなければ必要ないので、実質1行で 完結します

デバックの簡単さ

Firebaseでは開発中の確認を行うためのDebugViewが用意されています。実際のデータの反映には最大24時間のタイムラグがありますが、DebugViewのConsoleを利用することで即座に正確にログ送信が行われていることの確認ができます。

DebugView

自動的に収集されるイベント

上では任意のイベントを送信する方法を紹介しましたが、Firebaseは多くのイベントを自動で収集してくれます。これらのイベントはSDKの導入のみ行えば、実装の必要はありません。

自動的に収集されるイベントは、アプリの基本的な操作によって発生します。Firebase SDK を使用していれば、これらのイベントを収集するコードを追加で記述する必要はありません。https://support.google.com/firebase/answer/6317485

代表的な自動収集イベント

  • アプリ上でのページ遷移(screen_view)
  • ユーザーが最初にアプリを送信した時のイベント(first_open)
  • App Store/Google Play でアプリ内購入をユーザーが完了したとき(in_app_purchase

感動した自動収集イベント

  • アプリがアンインストールされた時(app_remove)

実装では難易度の高いアプリのアンインストールイベントが収集できます。自社サービスのユーザーIDを設定していれば、サービスのどのユーザーがアプリをどのようなタイミングでアンインストールしたかがわかります。

  • OSやアプリアップデートをしたとき(app_update/os_update)

ユーザーがアプリをアップデートした時にイベントが送信されます。以前のバージョンパラメーターとして送られるので、マイグレーションの確認などに役立ちます。

  • Notificationの受信・削除・開封(notification_dismiss/notification_open/notification_receive)

こちらはFirebase Notificationsから送信されたプッシュに限られますが、これらのイベント分析することによって、「どのようなプッシュだと横にスワイプして消されるのか」、「受信してからどれくらいで開封しているのか」といった情報が立体的に見えてきます

BigQueryとの連携

FirebaseのBlazeプランを利用すると、FirebaseのイベントをBigQueryに同期することが可能です。

BigQuery を Firebase アプリにリンクすることで、すべてのパラメータやユーザー プロパティと合わせて、サンプリングされていない元のイベントデータにアクセスできるようになります
https://support.google.com/firebase/answer/6318765

リンクしたBigQuery上からイベントを見ると、1イベントに対しておよそ50ものプロパティが自動でついています。

Firebase SDK を使用していれば、追加のコードを記述しなくても、多くのユーザー プロパティを自動的に収集できます。https://support.google.com/firebase/answer/6317486

イベントの「名前」や「発生時刻」は当然のこと、イベントが発生した「国・地域」「デバイスのOSバージョン/モデル/設定言語」「トラフィックソース」などの情報を得ることができます。

カスタムプロパティ

当然、自動収集のプロパティ以外にもカスタムプロパティも定義することができます。カスタムプロパティの種類は2つあります。

  • Custom User properties

そのユーザーの特性をイベントに紐付けることができます。

例えば、そのユーザーの性別や年齢、有料会員なのかどうかといった情報です。

  • Custom Event properties

そのイベント自体の属性をプロパティとして付与できます。

例えば、「チケット購入」イベントに対して、購入金額や決済手段、受け取り方法といった情報を付与することが適当です。

BigQuery上でのデータ構造

GoogleAnalytics for Firebaseのデータ構造はネストされたデータ形式をとっていて、MySQLなどになれているとやや見慣れない構造になっています。

1つのカラムに対してMap形式で複数のカラムをを挿入することができます。

BigQuery上でのデータ構造

したがってレコードは以下のようにツリー上になります。

BigQuery上でのレコードイメージ

実データでどのようになっているかを確認するためには、BigQuery上のプレビュー機能を利用することをおすすめします。

BigQueryのプレビュー機能

このネスト構造によって、時系列データのみやMySQLなどでよく利用される横断データのみだと分かりづらい「特定のイベント時点でのそのユーザーの状態」が非常に探索しやすくなります。

BigQueryのStandardSQLでデータを分析する

FirebaseのデータをBigQueryから探索するには上述のネスト構造になっているので、Unnestとゆう関数を使いネストしたカラムのレコードをばらした上で、CrossJoinを行います。

ページ遷移元・遷移先とユーザー情報の時系列データ

このクエリでは、ページ遷移について抽出してます。いずれのプロパティも自動で付与されるものです 。ここでのユーザーIDはFirebaseが自動でユーザー毎に付与しているものです。カスタムのuser_idを設定するとサービス独自のユーザーIDに代替可能です。

  • 時間
  • ユーザー ID(Firebaseサービスでの自動付与)
  • 遷移元
  • 遷移先
実際のActivityやViewControllerの名前はマスクしています

自動送信イベントのイベントプロパティとして、firebase_previous_classが送られているのでどのページからどのページへ遷移したかもわかります。自動送信イベントはActivity単位で送られるようになっていますが、Fragmentの場合もPVログを設定することによって集積可能です。

まとめ

振り絞った力で書いたわりには、少しボリューミーになってしまいましたが様々な機能をご紹介しました!

FirebaseAnalyticsは極めて簡単にイベントを蓄積することができます。またBigQueryにリンクすると簡単にユーザーの詳細なデータセットにアクセスでき、SQLを介して独自の形で分析することが可能です。

FirebaseAnalyticsをはじめとしたFirebaseの機能は、アプリ開発・フロントエンド開発のデファクトスタンダートとなりつつあります。チームや開発者やよりフォーカスすべきところに時間を使えるように、積極的に使えると良いと思います。

少しでも皆様さまの導入や運用の助けになれば幸いです。