スマホゲームの運用フローで継続的に使っているFirebaseについて

本番アプリでのクラッシュについて少しでも情報を取得したいという要望は古くからありましたが、自前で UncaughtExceptionHandler を利用、サーバ側でデータを収集/分析するシステムを構築するのは非常に難易度が高いと考えていました。そこで Firebase の前身の Fabric の Crashlytics の利用を始めました。 その後 Fabric から Firebase への移行、そして、ネイティブ向け SDK の利用から Unity 版 SDK への移行を経て現在に至ります。

Firebase を導入したことで、アプリや機能のリリース監視と分析を行いやすくなりました。 自前でシステムを構築する場合と比べ、実装コストと運用負荷を大きく抑えられています。

現在は Crashlytics でクラッシュを監視し、Analytics でユーザー行動を分析する流れが定着しています。

スマートフォンアプリを運用する場合、リリース後のクラッシュを捕捉できるツールは必須です。特に Crashlytics はセットアップが簡単で、気軽に利用できる点が大きなメリットです。 ユーザー環境は多種多様なため、本番環境での問題を可視化できるかどうかが開発・運用する上で効率に大きく影響します。

ただし、ツールの価値や性能を引き出すには「カスタムキーやログの設計」と「ツールの使い方」を十分に把握する必要があります。導入時にチーム内で「どんな情報を載せるか」「どんな流れで情報を確認するか」「どんな情報を確認するか」をあらかじめ決めておくと、あとの分析がしやすくなります。

今後、Analytics で自前のカスタムイベントをさらに拡充していくことで、より多角的にユーザー行動を把握したいと考えています。

また、普段どのように活用しているかをチームに共有し、ツール利用に慣れたエンジニアを中心に運用知見を広げていきたいと考えています。 Crashlytics 側の集計やフィルタ機能が現在よりも充実すると、ツール間の組み合わせがしやすくなり、さらに調査効率が上がることを期待しています。