はじめに
ユーザ行動分析をおこなうためのツールとしてGoogleアナリティクスは有用で, これを導入すればアプリ利用状況を把握しアプリの改善に繋げることができます.
私はWebのフロントエンド開発よりAndroidといったモバイルアプリの開発が主で, 今回は Androidアプリ向けにGoogleアナリティクスを導入検討した際に調べたことをまとめました.
“なぜ今更Googleアナリティクスなのか？”というコメントもありそうですが, Googleも推奨するFirebaseアナリティクスは諸事情により採用しませんでした.
その辺りの話は文末で少し触れたいと思います.
Googleアナリティクスアカウント
Googleアナリティクスアカウント（トラッキングID）はデバッグ用とリリース用とで分けておいたほうが無難です.
トラッキングデータを送信せず空振りさせるDryRun機構もありますが, 市場ユーザのレポートにノイズが入るのは好ましくありませんし, 1ヶ月あたりの制限されたヒット数を無駄に消費する必要もありません.
多くのディベロッパーやテスターがいるプロジェクトや, UIテストを自動化しているプロジェクトはDryRunモードを上手く使い分けるか, アカウントを分ける検討をおすすめします.
アカウント情報は他のGoogleサービスと同じくgoogle-services.jsonに定義されます.
Build TypeやFlavor毎にこれを切り替える方法は下記が参考になります.
https://github.com/googlesamples/google-services/issues/54
開発グループ毎にレポートの参照権限や編集権限を設定できる仕組みがGoogleアナリティクスに備わっているので, ユーザ管理も柔軟に対応できます.
ユーザ権限:
https://support.google.com/analytics/answer/2884495
データ収集の制限
Googleアナリティクスの利用規約に従い, アカウント1つにつき1ヶ月あたり1,000 万ヒット以下に抑えなければなりません. これを超えるヒットは処理される保証が無く, プレミアムアカウントに移行する必要があります.
（プレミアムアカウントでは10億ヒット以上に上限が引き上げられます）
アプリにGoogleアナリティクスのコードを埋め込む際はヒット数の予測を立てることが必要です. 1,000万ヒットは多いように感じますが, あっという間に消費されます.
無駄なヒット数を減らし, 何を計測したいのかを明確にしてトラッキングレポート計画をたてましょう.
（Googleアナリティクスのカスタムレポートにヒット数のみを確認できるレポートを作ると便利です）
どうしても月毎のヒット数が1,000万を超えてしまう場合はサンプリングの導入を検討します. これは分析対象のユーザを数％に絞ってヒット数低減をはかる機能です.
サンプリングによるデータの信頼性低下が許容範囲内であれば採用できます.
サンプリングで対象のユーザを絞らず, ヒット数を下げる方法もあります.
たとえばユーザイベント発生の都度ヒット送信せずプーリングして, 週に1度や月に1度といったタイミングでトラッキングデータを1つのヒットにまとめて送信します.
この場合, 全ユーザが特定のタイミング（月末の午後三時 etc.）にヒット送信しないよう, トラフィック分散を考える必要があります.
デメリットとして, トラッキングデータを集約するコードを書く必要があることと, トラフィックに配慮が必要になること. また, トラッキングデータ自体の粒度が大きくなり情報が欠落するため, 後から多角的な分析ができない可能性があります.
注意すべき点として, サンプリングレート値はアプリに埋め込まれるということです.
つまり, Google Playへ公開後にレート値を下げたい場合はアプリのアップデートが必要です.
ユーザがアップデートを拒否して使い続けるケースも考慮しておく必要があります.
（こうした問題はGoogle Tag ManagerやFirebase Remote Configで解消できます）
Googleアナリティクス利用規約 2. 料金およびサービス:
https://www.google.com/analytics/terms/jp.html
データ制限:
https://support.google.com/analytics/answer/1070983?hl=ja
ヒット:
https://support.google.com/analytics/answer/6086082?hl=ja
Googleアナリティクスの導入
Android向けアナリティクスにはGoogle Analytics SDK v4を使用します.
開発にあたっては最新のAndroid StudioとGoogle開発者サービスアプリを用意します.
アナリティクスをAndroidアプリに追加する:
https://developers.google.com/analytics/devguides/collection/android/v4/?hl=ja
GoogleアナリティクスはGoogle開発者サービスがインストールされていない端末でも利用できます.
Googleアナリティクスの基本設定
Google Analytics SDK v4ではトラッカーに固有のパラメータとグローバルパラメータをXML設定ファイルで定義することができます.
GoogleアナリティクスSDK v4 – パラメータ:
https://developers.google.com/analytics/devguides/collection/android/v4/parameters?hl=ja
Googleアナリティクストラッカーの設定はソースコードから実行時に変更することも可能です.
ディスパッチ間隔
GoogleアナリティクスSDKはヒットの都度, トラッキングデータをサーバへ送信することはせず一定期間のトラッキングデータをまとめて送信（ディスパッチ）します. デフォルトで120秒間隔の自動ディスパッチ間隔が設定されます. これは消費電力への配慮とネットワーク接続が無い場合にデータが送信できない問題への対処によるものです.
この間隔を短くする場合には消費電力に注意する必要があります. デバッグ用アプリの場合, 送信されたトラッキングデータを即座に確認したい場合にこの間隔を短くすると便利です.（ヒットの都度ディスパッチする場合はディスパッチ間隔に0を指定します）
リリース用アプリの場合はデフォルトの120秒間隔以上としておくのが無難です.
ただし, ディスパッチ間隔を長くとりすぎるのも問題です. 詳しくは次の”ヒットデータの期限”をご確認ください.
Googleアナリティクスへのディスパッチ間隔はGoogle開発者サービスがインストールされた端末では定期的な自動ディスパッチとして120秒に設定され, 開発者が手動によるディスパッチを行うことができません.
Google開発者サービスがインストールされていない端末でも自動ディスパッチは使用できますが, バックグラウンドでこれをするためには次の一手間が必要です.
WALE_LOCK権限の取得AnalyticsReceiverを登録AnalyticsServiceを登録する
<manifest>
<!-- ... -->
<!-- Get permission for reliable local dispatching on non-Google Play devices. -->
<uses-permission android:name="android.permission.WAKE_LOCK" />
<application name="com.example.MyApp">
<!-- Register AnalyticsReceiver and AnalyticsService to support background
dispatching on non-Google Play devices. -->
<receiver android:name="com.google.android.gms.analytics.AnalyticsReceiver"
android:enabled="true">
<intent-filter>
<action android:name="com.google.android.gms.analytics.ANALYTICS_DISPATCH" />
</intent-filter>
</receiver>
<service android:name="com.google.android.gms.analytics.AnalyticsService"
android:enabled="true"
android:exported="false"/>
<!-- ... -->
</application>
</manifest>バックグラウンドでのディスパッチ:
https://developers.google.com/analytics/devguides/collection/android/v4/dispatch?hl=ja#background
この設定はGoogle開発者サービスがインストールされた端末のみを対象とするアプリには不要な設定です.
ヒットデータの期限
データのディスパッチが各Googleアナリティクスビューのローカルタイムゾーンで翌日の午前4時までに実施されない場合はローカルキャッシュされたヒットが破棄されます.
ディスパッチ:
https://developers.google.com/analytics/devguides/collection/android/v4/dispatch?hl=ja
アクティビティトラッキング
アクティビティ（フラグメント含む）の自動/手動トラッキング機能が用意されています.
スクリーントラッキング, フローレポートの類はヒット数の増加に繋がるため, 必要以上のヒットを発生させないようデータ収集の上限に気をつける必要があります.
スクリーン:
https://developers.google.com/analytics/devguides/collection/android/v4/screens?hl=ja
IPアドレスの匿名化
Googleアナリティクスに送信されるIPアドレス下位8bitを削除してIP情報を匿名化することが可能です. サーバやサービスのポリシーに従って設定します.
匿名ID:
https://developers.google.com/analytics/devguides/collection/android/v4/advanced?hl=ja#anonymizeIp
セッションタイムアウト
セッションはアプリの使用開始〜使用終了までの定義といえます. セッションのタイムアウトはデフォルトで30分です.
考慮すべき点として, たとえば動画視聴アプリの場合, 動画一本の再生時間が30分を超えるコンテンツを視聴すると, 途中でセッションが切れて新たな使用開始としてカウントされてしまいます.
（途中でユーザ操作があったとしてもセッションタイマーは延伸されません）
レポートの精度を上げるためにそういったユースケースがあるアプリではセッションタイムアウトの時間を見直す必要があります. アプリケーションの使われ方にあわせたセッションタイムアウト時間を設定します.
オプトアウト
ユーザの指定に従いGoogleアナリティクス機能の有効/無効を適切に処理する必要があります.
これはGoogleアナリティクスの利用規約に従うものです.
ユーザのオプトアウト意思が不明な場合はこれを”有効”（Googleアナリティクス機能無効）として扱い, アプリの初回起動時などオプトアウトのユーザ意思未確認の場合もこれに該当させるべきです.
アプリはオプトアウトの設定を監視し, ユーザがこれを変更した場合は即座位にGoogleアナリティクス機能の有効/無効を切り替える必要があります.
オプトアウトはデフォルトで無効（アナリティクス機能は有効）です.
Googleアナリティクス利用規約 7. プライバシー:
https://www.google.com/analytics/terms/jp.html
送信すべきでない情報
Googleアナリティクスの利用規約より, 個人情報（PII）（氏名、社会保障番号、メールアドレスなどのデータ）や, 個人の場所が合理的に推定できる GPS による場所情報や正確な場所情報, 特定のデバイスを恒久的に識別できるようなデータ（携帯電話固有の端末識別子で、リセットできないものなど）を, Googleアナリティクスに送信する行為を禁じています.
ユーザ入力データやインポートしたデータ, 例外メッセージやスタックトレースなどに含まれるデータも同様です. こうしたデータはハッシュ形式であっても絶対に送信してはいけません.
例外メッセージNG:
https://developers.google.com/analytics/devguides/collection/android/v4/exceptions?hl=ja
個人を特定できる情報（PII）を送信しないようにするためのおすすめの方法:
https://support.google.com/analytics/answer/6366371?hl=ja
ユーザエクスペリエンス
ユーザはGoogleアナリティクスの利用許諾, およびオプトアウト機能により発生するユーザエクスペリエンス以外において, Googleアナリティクスがアプリの振る舞いに介入・介在するなどしてユーザエクスペリエンスに割り込むべきかどうかを決めておく必要があります.
Googleアナリティクスによるデータ収集, データ送信およびGoogleアナリティクスが原因で発生するエラーは全てバックグラウンドで処理し, ユーザにそのことを認知させないようにするのが一般的です.
ユニークユーザの判別
アプリ初回起動時にSDKが生成・管理するユーザIDをもってユーザのユニーク性が判断されます. ただし, アプリのアンインストールやアプリ再インストールによりこのユーザIDは再生成されるため, 新規ユーザ扱いとなる点に注意が必要です.
デバイスやアプリをまたいで発生するユーザ行動を同一ユーザのものとみなしたい場合にはUserID機能の実装を検討します.
User ID:
https://developers.google.com/analytics/devguides/collection/android/v4/user-id?hl=ja
イベントのレポート構造と計画
イベントのレポート構造をあらかじめ計画しておくことが重要です.
“何のイベントをどのようにレポートするか”ある程度先を見越して計画しておく必要があります.
イベントは Category, Action, Label, Valueといった情報を載せてトラッキングします. これらはユーザ行動分析する上で指標となる重要なデータです.
イベントの送信内容を変更したい場合はGoogle Tag Managerなどを利用する場合を除き, アプリのアップデートが必要になります. 一度公開したアプリのトラッキングデータはユーザがアプリアップデートしない限り送信されることに留意する必要があります.
開発時に必要なトラッキングデータが1つだけであったとしても, 将来必要なトラッキングデータが増えないのか1度は考えるべきです. トラッキング対象となる様々なオブジェクトやイベントを全体的に把握しておけば, 後々トラッキングしたいデータが増えた場合でも柔軟に対応可能です.
難しいのがCategoryやActionの命名とその粒度を決定することです.
イベントには一貫性があり明確な命名規則を採用しましょう. レポートでの閲覧性が向上します.
また, 1組のカテゴリ/インタラクションは, レポートの固有の要素として扱われるため, 類似カテゴリに属するすべてのオブジェクトの統計情報をどのように計算するのか, あらかじめ検討しておくことが大切です.
“CategoryやActionを何にすべきか？”といったガイドラインについては イベントについて が参考になります.
Firebaseアナリティクス
GoogleアナリティクスとFirebaseアナリティクスの違いは下記に詳しく載っています.
Firebase Analytics と Google アナリティクスの違い
https://support.google.com/analytics/answer/2587087?hl=ja#firebase_vs_GA
Firebaseアナリティクスの優位性はなんといっても無制限・無料のイベントレポートでしょう.
Googleアナリティクス（無料枠）では1,000万ヒット/月に抑える必要があり, アプリの人気が出るにつれて, レポートの精度を落とさざるを得ないのが実状でした.
Firebaseアナリティクスはこれを根本的に解消するため非常に大きなアドバンテージを持っています.
ですが, 過去にいくつかの理由でFirebaseアナリティクスの採用を見送ったことがありました.
その内の2つを紹介します.
- Firebaseアナリティクスはレポート反映されるまで4時間程度待つ必要がある
- カスタムパラメータがレポートから閲覧できず, アクセスするにはBigQueryが必要
1点目は些細な理由です.
リリース用アプリにリアルタイムレポートのような機能は不要なので, その点においてはレポート反映が4時間後になっても問題ないのですが, 開発や評価時にトラッキングされているかを確認するのに最低4時間待たないのいけないのはマイナスの印象を受けました.
セッション数やリクエスト上限/秒の制限付きでもよいので, 即レポート反映される開発者モードの機能があれば導入が楽になりそうです.
2点目はまだFirebaseアナリティクスがアーリーアダプタ向けプロダクトであることを感じさせる内容です.
Firebaseアナリティクスには開発者が独自に定義したカスタムパラメータをトラッキングデータに載せることができますが, それをFirebaseアナリティクスのレポート画面から確認する手段がありません.
これを確認するにはBigQueryへ一度エクスポートして, クエリを発行し, Rawデータとして確認する必要があります.
レポートを閲覧するのが開発者ではない場合, 非常に敷居の高い操作を要求されます.
とはいえ, どちらも近い将来なにかしらの改善がなされる内容だと思いますので気長に期待して待ちたいと思います.
以上です.