もんりぃ is undefined.

育児ネタとか、技術ネタとか。

Firebase Analytics の Raw Data を BigQuery で解析する時に起きた問題とその原因

はじめに

最近は専ら BigQuery とキャッキャウフフする日々を送っています。

今回は「何か特定の曜日だけデータがメッチャ多いんだけど…?」という問題が起きたので、それの備忘録を記します。

問題

  • BigQuery から集計したデータが、特定の日だけユニークユーザ数がやたらと多い
  • それ以外の日も Firebase Console の Audiences で表示される UU よりも、BigQuery で集計した UU の方が若干多い

前提

  • Firebase Analytics の Export BigQuery オプションを有効にしている
  • BigQuery 上で Raw Data を集計した中間テーブル的なモノを作っている
  • Google DataStudio を用いて中間テーブルに対してクエリを発行してビジュアライズしている *1

原因

  • Push Notification 関連のイベントも集計してしまっていた

詳細

Firebase Analytics のイベントには大きく分けて2種類のイベントがあります。

  1. Firebase Analytics が自動的に送信するイベント
  2. 開発者が独自に送信するイベント

そして、どちらのイベントにも user_pseudo_id というカラムに、インストール毎に変化する擬似的なユーザ IDが付与されており、この値をもとにユニークユーザ数などを集計するコトになります。*2
また、それぞれのイベントの種別を表すためのキーとして event_name というカラムも存在しています。

で、今回求めたいデータというのはアプリを起動したユニークユーザ数だったわけですが、Firebase Analytics の仕様として一部のイベントはアプリが起動していなくても送信される(ただし Android に限る)という点を失念しており、それらの数値も含まれてしまったが故にデータ数に乖離が発生してしまいました。

その一部のイベントというのは以下のようなモノが該当します。

  • notification_received: FCM *3 による PUSH 通知を受信
  • notification_opened: FCM による PUSH 通知を開封
  • notification_dismissed: FCM による PUSH通知を削除
  • app_updated: アプリを更新
  • app_data_cleared: アプリデータを削除
  • os_updated: OS を更新

今回の件で言うと、PUSH 通知周りのイベントを集計対象に含めてしまったコトにより、アプリを起動していないユーザも数えてしまったと言うわけです。

所感

原因が分かってしまえば「なーんだ、そんなことか。」という感じですが、いかんせんデータが多いので、調査はかなり大変でした。

仮説を立てては小規模な範囲でクエリを叩いて*4結果を検証して…、の繰り返しはなかなか頭がチリチリする感じがします。

おまけ

調査の過程で、Firebase Console の Audiences の値との差についても調べたのですが、どうやら Firebase Console 側は user_engagement かそれに類するイベントをベースに集計した数値のように見受けられました。*5

この辺、詳細なドキュメントあったら教えてください…。

*1:今回これは関係ないけど

*2:勿論、独自に発行したユーザ ID も付与可能で、その場合は user_id というカラムに設定されます。

*3:Firebase Cloud Messaging

*4:範囲がデカいと掛かるコストもデカいので…。

*5:厳密に一致するデータを集計することが出来なかったのですが、最も近い値となりました。