5
6

More than 3 years have passed since last update.

FirebaseAnalytics運用のやらかし技師が教えるやらかし傾向と対策

Last updated at Posted at 2019-12-29

この記事について

FirebaseAnalytics使ってますか?

ログを送ることでコンテンツの状況を閲覧できたり
セグメント切っての施策など便利な機能が多い反面やらかしてしまうポイントがいくつかあります。

今回は、
やらかしがちなところ
やらかしを未然に防ぐ方法
すでにやらかしてしまった場合の対応
以上3つについて書いてみようと思います。

やらかしとは?

・送るべきデータが送れていない
・FirebaseConsole上でリリース前に事前設定が必要なのに設定してない

現状上の二つをやらかしとしてます。

やらかすと以下二つの危険性が生じる可能性があります。
見たいデータが見れないので検証として成り立たない
セグメント切りたかったのにきれないなどリリース前に計画していたことが最悪パァ

このような最悪なケースにならないためにもFirebaseAnalyticsをセーフティに運用したいところ。

では、
具体的にどこでやらかしてしまうのでしょうか?

やらかしがちなところ

Event送信

class func logEvent(_ name: String, parameters: [String : Any]?)

nameに指定できる文字数は1~40文字です
アプリ側で組み込む際には40文字を超えていようとエラーにはなりません。

class func setUserProperty(_ value: String?, forName name: String)

ちなみにUserPropertyのnameは1~24文字です。
こちらはこれまでの経験上ど色々登録してきましたが、24文字以内で済んでるのでそんなに気張る必要ないかもしれませんがふとしたときにやらかした1回がでかい問題になるかもしれないので気をつけましょう

FirebaseAnalytics Framework Reference

Consoleでの設定

FirebaseConsoleでUserPropertyを作成

アプリからこのUserPropertyを送ると決まれば
そのタイミングでFirebaseConsoleでUserPropertyを登録しておくべきです。

登録しないままリリースするとどうなるのか?

Eventごとの数値をFirebaseConsoleから
閲覧する際のフィルターに送っているUserPropertyが表示されません。

気づいたタイミングで登録しなおしても、
リリースしてから気づいたタイミングまでの間のデータは確認できず、
登録した日からの集計になってるような気がします。
スクリーンショット 2019-12-27 18.12.43.png

Audience作成

こちらもリリースする前に決めたAudienceを作成しておくべきです。

UserProperty同様、
リリース後にAudience作成してないことに気づいて作成しても気づいた日からの集計になります。

リリース前にやる必要がある系のやらかしは入るべきだったデータをロストすることになります。
スクリーンショット 2019-12-27 18.53.19.png

細かいですが
Audienceで設定するEventはFirebaseConsoleのEventから閲覧できなくても設定できます。

言い換えると
Consoleで確認できるEventから必ず選択しなくてはいけないというルールではないということです。

具体的にどういうことかというと以下スクショでは,
入力したEventがまだFirebaseに送られていなくても
このEventを送ると決まっているのであれば送信前に設定することが可能です。
スクリーンショット 2019-12-29 15.43.47.png

Consoleで確認できるEventに関してはAudience作成時に選択できる
スクリーンショット 2019-12-29 15.41.41.png

Consoleで確認できるEventに関しては選択肢としてAudience作成時に表示されるので
送信前に設定したEvent名とコード側で送るEvent名が違うという入力ミスなどのヒューマンエラーを考えるとリリース前には全てのEventが送られている状態を作っておきEventを選択できる状態を作っておくのが吉かなぁと思っております。

やらかしを未然に防ぐには?

スプレットシート
FirebaseAnalyticsのルールから外れてないか?のチェックです。

Lintなど工夫入れてコードで落とせるようにするのもありかなと思ったのですが、
EventはエンジニアだけでなくBiz側も関係し決定権を持つのはBiz側が多いのかなと思っております。

Biz側でシートに入力してもらい文字数に問題がない状態でエンジニアに渡ればそのままいれることだけに集中すれば良いので現状スプレットシートで以下のように管理してます(スプレットシートは簡易版)
スクリーンショット 2019-12-27 18.21.32.png

DebugView
コード側のミスで送られてないEventがあるか?のチェックです。

Eventが送られているかを手元の端末でアプリを触りながら確認する方法です。
経験上リリース前に一気にやろうとすると大変です。(他の作業と並行するケースが多く注意が散漫しがち)

なので、
機能実装者が機能の動作確認と並行してEventも送れているか確認すると良さそうです。

すでにやらかしてしまった時の対応

Eventが送れてない場合

Eventを送ったと同義になるものがないか探してみましょう。

例えば、
メッセージを送信したという"sent_message"が送れてないとします。

メッセージ自体は送られておりDBに入っているのであれば
DBに直接Queryを叩きに行けばなんとかなるかもしれません。

僕はFirestoreを叩きにいきました。
CollectionGroup Queryに感謝(<- 楽さ的に)

UserPropertyを事前に設定してない場合

BigQueryにQueryを投げると良さそうです。

Eventが送られていれば、
BigQueryのレコードにはEventとUserPropertyが一つのレコードに含まれます。

なので、調査用のQueryを作って実行すれば欲しいデータが取れそうです。

ただ、めんどくさいですしこのQueryいくら?を
気にするのも辛いのでUserPropertyは事前にConsoleで設定しておきましょう

Audienceを事前に設定してない場合

現状このケースのリカバリー方法は知らないです・・・
気づいたタイミングで作り直すのが良さそうです。
早めに気づけば遅く気づいた時よりもデータは溜まるので!

最後に

誰かがやらかす前に少しでも防ぐことに貢献できれば幸いです!

やらかし具合によっては
どんどん下へ掘っていくことになるんだろうなという体感値を図示したのが以下スクショになります。
スクリーンショット 2019-12-27 18.57.54.png

これまでのFirebaseAnalyticsに関連する記事のリンクを添えておきますのでよかったらぜひ:relaxed:
Event, UserPropertiesを送っておくと戦略的に幅が広がる話
FirebaseAnalytics/BigQueryを使う上で覚えておきたい関数

弊社ではこんな感じで運用してますなど共有いただけると嬉しいです:v:

5
6
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
6