Help us understand the problem. What is going on with this article?

Firebase Analyticsの真面目なユーザープロパティ戦略

More than 3 years have passed since last update.

ユーザープロパティはFirebase運用の一番のボトルネック

いきなり怒りから入る文体もなかなかないが、ユーザープロパティはFirebaseの運用を考える上でコアの機能(特にRemote Configと組み合わせてのABテスト)でありながら、ボトルネックになるリスクが非常に高い。

特にやばいのが以下の仕様である。

  • ユーザープロパティは一度作成したら、ユーザプロパティ名を修正できない。
  • ユーザープロパティは一度作成したら、削除できない
  • ユーザープロパティの作成上限は25個である。
  • ユーザープロパティ名の文字上限は24文字である。

引用:
ユーザー プロパティを設定する
setUserProperty()

ユーザープロパティ戦略

上記より運用に際し、慎重に戦略を練らなければいけない。
ユーザープロパティで使用されると想定されるのが、そのままの意味だがユーザーのプロパティ(例えば、性別・地域など)、ABテストのフィルタとして使用される場合の2パターンである。

参考:
【Android】Firebase RemoteConfig + Firebase AnalyticsでABテストを試す

なお、前者のユーザーのプロパティとしての使い方で、もしアプリ内の情報の変更依存でRemoteConfigを使用する場合(例えば、地域情報を変えるとそれに応じてRemoteConfig値変更)、必ず必要となるので尚更意識する必要がある。
ユーザーリストも性質として一度その対象になったら永続的にそのメンバーとなるため、やはりこの場合はユーザープロパティを使わざるを得ないのが実情である。

参考:
ユーザーリスト

以下、戦略を書いていく。

1. 将来的にも使用がせいぜい数カ所に限られる場合

そのまま以下のプロパティ名で設定する。

・ユーザのプロパティとして利用する場合
「プロパティ名」

・ABテストのフィルタとして利用する場合
「AB_画面名_ABテスト事象名」(24文字制限が非常にネックになる
→ RemoteConfig値もこちらと全く同じに合わすと運用しやすい。

2. 将来的にユーザープロパティ25個を超える可能性が少しでもある場合

この場合、1.のような戦略は当然難しい。

自身が考えているのは以下の戦略である。
「ユーザーのプロパティとして15個、ABテストのフィルタとして10個。
計25個をユーザープロパティとして設定する。」

→ ユーザーのプロパティは、それ自体の用途以外にもRemoteConfigと組み合わせてあえて設定する可能性があるため、多めにとる。

それぞれのネーミングは、「Prop1」「AB1」みたいなシンプルなものにし、管理をしやすくする。
→ それぞれの変数がどのように使われているかユーザープロパティの『説明』設定部分で管理する。

所感

やはりこのユーザープロパティの仕様は不満が噴出しているし、Firebaseを考える上でもかなり致命的な気がする。。
仮に上記2.の戦略を適用したとしても、扱えるABテストは10個のみ。今後仕様の変更がなければ、正直きついと思う今日この頃です。


記事をお読みいただき、ありがとうございました!
もし参考になったと感じましたら、どうか「いいね」よろしくお願いいたしますm(_ _)m

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away