3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

Firestore + BigQueryで簡単なログデータ&プッシュ基盤をつくった話

3
Posted at

導入

アプリのイベントログや、DAUなどの集計を考えるときに真っ先に選択肢に上がるのがFirebase Analyticsだ。
ユーザを特定のセグメントに分割して扱い、セグメントごとにプッシュ通知を送ったり、
特定のIn App Messageに対する特定のイベントへのコンバージョン率を自動で集計してくれたりと、
Firebaseの他のツールと連携がシームレスにできて良い体験ができる。
だがいろいろと制約もあり、より詳細な分析を行いときには実現できないこともあったので、
イベントログをFirestoreに飛ばし、BigQuery連携することで独自のログデータ基盤を構築したのでまとめる。

対象プロダクト

  • スマホアプリ

要件

  • 分析

    • ユーザがどの画面で、どうのような操作をして離脱したかを知りたい
    • ユーザがどのくらいの頻度でコア機能を使ってくれているかを知りたい
    • ユーザがどんな用途でアプリを使用してくれているかを知りたい
    • 細かく定着率を分析したい
    • 個人を特定する必要はないがユーザをユニークに扱いたい
      • (むしろプライバシーポリシーで約束しているので特定する情報は取らない)
  • データを活用した施策

    • 特定の行動のユーザにのみプッシュ通知で訴求したい

なぜFirebase Analyticsだとだめなのか

  • イベントログに含めるパラメータのサイズに制限がある

    • より詳細な内容を送りたいと思ったときに制限に引っかかり送りきれなかった
  • ユーザの時系列ログを扱えない

    • 特定のユーザがどういうイベント遷移をしたかを追おうとしたときに見るための術がない
    • イベント遷移を時系列順にみることができない
    • (一応StreamViewで直近アプリを開いていた人だけ見ることはできるがランダムでこちらで選択することはできない)
  • 詳細なセグメントわけをしてユーザを抽出することができない

    • 1週間以内にインストールし、コア機能をまだ使っていないユーザ、といった抽出するのがかなり困難
  • リテンションが見づらい

    • リテンションも見ることができるのだが、細かくみたりこちらの定義する「リテンション」で指標を追うことができない
  • ダッシュボードの読み込みが遅い

以上の理由により、Firebase Analyticsだと困難だったので自前で用意するようにした。

アーキテクチャ

routine-time-data-tool (1).png

極めて簡単で、アプリでイベントが発生するとFirestoreにログの内容が記録され、
ためていったログデータはCloud Functionによって日時バッチとしてBigQueryに連携される。

実装について

ログのバッファリング

ログを送る処理はイベント発生ごとに送ってしまうと、
無駄に端末リソースを食ってユーザ体験を損ねることになったり、
無駄にアクセスが頻発してしまうので、
バッファリングが必要になる。
そこで、Cookpad社製のPureeを使った。
これは、一定時間もしくは一定サイズのログがバッファされると非同期でログを送ってくれるライブラリだ。
ログの送り先も自分でインターフェースを実装するだけで変えられるので導入が簡単だった。

Firestoreの設計

コレクション定義は下記のようになっている

  • users
    • evens

userコレクションを作りユーザIDにはFirebaseのInstanceIDを割り当てて、サブコレクションとしてイベントを定義してあげている。
イベントは同時に大量に書き込みが発生するので、コレクションに対する同時書き込み制限に引っかからないようユーザごとにコレクションを分離してあげる形をとっている。
集計するときもeventsで、collection group queryを使えばサブコレクション横断でデータを引っ張って来られるので楽だ。

プッシュ通知

プッシュに関しては、BigQueryで訴求したいユーザ一覧を取得し、CSVをGCSにアップロードすることでPub/SubでトリガーされたCloudFunctionで飛ばすようにしている。
ここは若干面倒なのでうまいことできないか模索している。

やってみてどうか

実際にBigQueryに連携することでかなり細かい条件でユーザを抽出し、訴求することができるようになった。
また、特定のユーザの行動ログも簡単に追うことができ、ここで困ってるんだろうな、、、というのがかなり可視化されてきた。
BigQueryのRECORD型も優秀で、これをしっかり定義してあげれば特にダッシュボードなど用意しなくても見やすくデータが追えるのが良い。DAUやリテンションなど日次で追いたいような指標はデータポータルでダッシュボードを作ることで簡単に閲覧できるようにしている。

気になる料金も、

  • Firestore

    • 読み込み 50000回/dayまで無料
    • 書き込み 20000回/dayまで無料
  • BigQuery

    • ストレージ 10GB/monthまで無料
    • 処理されるクエリデータ 10TB/monthまで無料

なので、特に無料の範囲で運用できている。
※一応一定額の課金が発生したらアラートを飛ばすようGCP側で設定している。

まとめ

ツールを使うと、データの扱い方もツールに振り回されてしまうので、ときには自前で実装することも必要になるが、
FirebaseやGCPが充実してきたことでかなり簡単に、少ない工数でやりたいことが実現することができた。
まだ運用上課題はあるので様子をみつつ改善していく。

3
1
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
3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?