FirebaseAnalytics運用のやらかし技師が教えるやらかし傾向と対策
この記事について
FirebaseAnalytics使ってますか?
ログを送ることでコンテンツの状況を閲覧できたり
セグメント切っての施策など便利な機能が多い反面やらかしてしまうポイントがいくつかあります。
今回は、
やらかしがちなところ
やらかしを未然に防ぐ方法
すでにやらかしてしまった場合の対応
以上3つについて書いてみようと思います。
やらかしとは?
・送るべきデータが送れていない
・FirebaseConsole上でリリース前に事前設定が必要なのに設定してない
現状上の二つをやらかしとしてます。
やらかすと以下二つの危険性が生じる可能性があります。
見たいデータが見れないので検証として成り立たない
セグメント切りたかったのにきれないなどリリース前に計画していたことが最悪パァ
このような最悪なケースにならないためにもFirebaseAnalyticsをセーフティに運用したいところ。
では、
具体的にどこでやらかしてしまうのでしょうか?
やらかしがちなところ
Event送信
class func logEvent(_ name: String, parameters: [String : Any]?)
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が表示されません。
気づいたタイミングで登録しなおしても、
リリースしてから気づいたタイミングまでの間のデータは確認できず、
登録した日からの集計になってるような気がします。
Audience作成
こちらもリリースする前に決めたAudienceを作成しておくべきです。
UserProperty同様、
リリース後にAudience作成してないことに気づいて作成しても気づいた日からの集計になります。
リリース前にやる必要がある系のやらかしは入るべきだったデータをロストすることになります。
細かいですが
Audienceで設定するEventはFirebaseConsoleのEventから閲覧できなくても設定できます。
言い換えると
Consoleで確認できるEventから必ず選択しなくてはいけないというルールではないということです。
具体的にどういうことかというと以下スクショでは,
入力したEventがまだFirebaseに送られていなくても
このEventを送ると決まっているのであれば送信前に設定することが可能です。
Consoleで確認できるEventに関してはAudience作成時に選択できる
Consoleで確認できるEventに関しては選択肢としてAudience作成時に表示されるので
送信前に設定したEvent名とコード側で送るEvent名が違うという入力ミスなどのヒューマンエラーを考えるとリリース前には全てのEventが送られている状態を作っておきEventを選択できる状態を作っておくのが吉かなぁと思っております。
やらかしを未然に防ぐには?
スプレットシート
FirebaseAnalyticsのルールから外れてないか?のチェックです。
Lintなど工夫入れてコードで落とせるようにするのもありかなと思ったのですが、
EventはエンジニアだけでなくBiz側も関係し決定権を持つのはBiz側が多いのかなと思っております。
Biz側でシートに入力してもらい文字数に問題がない状態でエンジニアに渡ればそのままいれることだけに集中すれば良いので現状スプレットシートで以下のように管理してます(スプレットシートは簡易版)
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を事前に設定してない場合
現状このケースのリカバリー方法は知らないです・・・
気づいたタイミングで作り直すのが良さそうです。
早めに気づけば遅く気づいた時よりもデータは溜まるので!
最後に
誰かがやらかす前に少しでも防ぐことに貢献できれば幸いです!
やらかし具合によっては
どんどん下へ掘っていくことになるんだろうなという体感値を図示したのが以下スクショになります。
これまでのFirebaseAnalyticsに関連する記事のリンクを添えておきますのでよかったらぜひ
Event, UserPropertiesを送っておくと戦略的に幅が広がる話
FirebaseAnalytics/BigQueryを使う上で覚えておきたい関数
弊社ではこんな感じで運用してますなど共有いただけると嬉しいです
Author And Source
この問題について(FirebaseAnalytics運用のやらかし技師が教えるやらかし傾向と対策), 我々は、より多くの情報をここで見つけました https://qiita.com/giiiita/items/e0ab22b8a1f337aa54fd著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .