Firebase Analyticsのユーザープロパティとユーザーリスト

関連記事

• Firebase Analyticsでイベントを送信する - Qiita

ユーザープロパティ

概要／コード上での実装

ユーザープロパティは名前の通り、ユーザーごとに要素を設定することができます（例えば利用プランだとか、スコア等に応じてつけたランクとか）。

コード上で実装するためにはイベントと同様にFirebaseAnalyticsインスタンス（swiftはFIRAnalyticsにsetUserProperty()（swiftはsetUserPropertyString()）を使って指定します。

Android.java

mFirebaseAnalytics.setUserProperty("favorite_food", mFavoriteFood);

iOS.swift

FIRAnalytics.setUserPropertyString(food, forName: "favorite_food")

ユーザープロパティは文字列情報のみ設定可能です。また、 ユーザープロパティはコードの実装だけでは反映されません。

コンソール画面にて同名のプロパティを設定する必要があります。（この順番はどちらでもいいのですが、後述する注意点を考えるとコンソール画面から先にやったほうがいいのかも）

コンソール画面での設定

ユーザープロパティの設定ですが、かなり気をつけないといけない点があります

• 設定できるユーザープロパティは最大25個（[参考](https://firebase.google.com/docs/reference/android/com/google/firebase/analytics/FirebaseAnalytics.html#setUserProperty(java.lang.String, java.lang.String))）
• 一度コンソール画面で設定したユーザープロパティは消せない
• 一度コンソール画面で設定したユーザープロパティの名前は変えられない（説明は変更可能）
• なぜかこの画面だけキーボードの反応がおかしく、テキスト入力途中の変換だろうがなんだろうが、エンターキーが押されたタイミングで作成を始めてしまう

無事に登録が完了し、アプリからもユーザープロパティが送信されるようになるとマイレポートなどに反映されます。

使いどころ

ユーザープロパティはレポートのフィルタリングの条件の他に、後述するユーザーリストの条件として利用できます。

これはユーザープロパティDeviceNameにメーカー＋デバイス名を送っているユーザープロパティです。

ユーザープロパティはイベントと違い、実際に送られたデータを推奨値にして表示してくれます。（ただ、「推奨値」なので一定数以上は送られてこない可能性があります）
推奨値にない値を指定する場合は、分かりづらいですが推奨値リストの上がテキストボックスになっているので直接入力することになります。

こうしたことから、例えばランキング情報をユーザープロパティとして送りたい場合は順位をそのまま送るのではなく、「TOP100」「101-200」などある程度カテゴリに分けて送る方が良さそうな気がします。

ユーザーリスト

概要

ユーザーリストはコンソール画面上で定義する「一定条件を満たしたユーザー」の設定を指します。「一定条件」にはイベントとユーザープロパティから指定します。

設定画面

例：OSバージョンが7.0.xもしくは6.0.xでvalueパラメータに100が入ったnum0イベントを発生させたユーザー

コンソール画面でイベントのパラメータとその内容を見る術はありませんが、ユーザーリストではパラメータに送信された値まで条件を絞り込むことができます。

なお、イベントとプロパティで推奨されているイベント名を選択した場合、そのまま推奨されていたパラメータが入力候補に表示されます。カスタムイベントや推奨されていなかったパラメータ（カスタムパラメータ）を選ぶ場合は、テキストボックスに１文字１文字正確に入力する必要があります。

（カスタムパラメータを指定する場合は「パラメータ名を入力」にパラメータ名を入力）

値の設定は文字列用と数値用がありますので、実際に送っている情報に合わせてください。文字列情報は正規表現が利用可能です。

ユーザーリストはそれ自体がイベントと同様のレポート画面表示も兼ね備えており、一覧でも該当するユーザー数を見ることができます。

（モザイクにしてる項目が新規で作成したユーザーリスト。値が同じなのは同じ条件にしているからです…）

All UsersとPurchasersはデフォルトで用意されているユーザーリストです。All Usersは名前の通りで、PurchasersはOSごとのネイティブな課金処理を行っているユーザーが条件となっています。

注意点

例え条件に一致するユーザーが設定した日より過去に存在しても、集計が開始されるのは設定日からになります。また、条件にヒットするユーザーが極端に少ないと（常に10人/日を下回る）集計されないことがあります。と思ったらいつの間にか集計されたりすることもあって、集計が開始されるまでの動作が不安定な印象があります。

もし「確かに存在するはずの条件なのに、いつまで経ってもレポートに反映されない」場合は、もしかしたら条件を絞りすぎているのかもしれません。

使いどころ

ユーザーリストもまた、レポート画面でのフィルタリングとして使うことに加え、Firebaseの機能であるRemote Configの対象条件として選択することができます。

ユーザーリストを設定することで、KPIとしてチェックしたいユーザー動向をスムーズに分析したり、直接的にA/Bテストを実施できるといった可能性があるんじゃないでしょうか。

おわりに

他にもFirebase Analyticsのメソッドはありますが、基本的な使い方はFirebase Analyticsでイベントを送信すると合わせてこれぐらいかなと思います。

こうしてみるとFirebase Analyticsは「想定したユーザーの動きを分析」という点には優れているものの、「ユーザーの動きを見る（俯瞰視点）」には弱い印象を持ちました。

Googleでは既にGoogle Analyticsでアプリの枠を作ろうとするとFirebase Analyticsの利用を推奨してきますが、俯瞰視点でのユーザー動作を見たい場合はFAとGAの両方を併用していくことになりそうです（Big Queryの使い方次第ではFAのみでも良いんでしょうが……）

参考

• コードの引用元
  • ユーザー プロパティを設定する（Android）  |  Firebase
  • ユーザー プロパティを設定する（iOS）  |  Firebase
• com.google.firebase.analytics  |  Firebase