再現が難しい不具合調査のための Firebase Analytics 活用方法

はじめに

こんにちは！コンシューマ事業部所属iOSエンジニアの三浦です。
モバイルアプリの開発では、再現が難しい不具合に悩まされることが少なくありません。
特に、画面数や機能数が多いアプリでは、ユーザーから報告された不具合を再現しようとしても、同じ条件を再現するのが困難なケースがあります。
このような場合、Firebaseのイベントログを活用してユーザーの操作フローを特定するのが非常に有効です。
本記事では、調査手順を効率化し、不具合対応のスピードを向上させる手法を具体的に紹介します。

この記事は、株式会社asken (あすけん) Advent Calendar 2024 の12日目の記事です。

注意

Firebase Analytics で収集したデータを扱うため、アプリのプライバシーポリシーや社内規定を遵守しましょう。

具体例:

取得データの範囲を最小限に制限する。
個人情報（例: ユーザーIDやセッションID）をマスクまたは匿名化する。
不要なデータを保存しない。

Firebase Analytics Events を利用した調査方法

Firebase Events

前提として、今回の方法を利用するためにはアプリの操作ログを Firebase に送信・記録している必要があります。
モバイルアプリでは施策の分析や継続的な指標計測の目的で画面遷移や操作イベントのログを収集していることが多いかと思います。
本記事では以下のようなイベントが設定されていることを想定しています。

PVイベント: 各画面が表示された際に発火される。
TAPイベント: ボタンやリンクなどUI要素がタップされた際に発火される。
REQUESTイベント: APIリクエスト時に発火される。

これらのイベントを記録することで、ユーザーの操作フローを把握することができます。
ただし、操作ログのデータ量は膨大になるため、BigQuery を使用して効率的に分析する必要があります。

Google アナリティクスの設定

Firebase AnalyticsのログをBigQueryにエクスポートするには、事前に設定が必要です。
設定手順については本記事では割愛しますので、以下の公式ドキュメントをご参照ください。

Firebase AnalyticsからBigQueryへのエクスポート設定

以降は、FirebaseのイベントログがBigQueryにエクスポートされていることを前提に話を進めます。

1. BigQuery を用いたイベントログの抽出

BigQueryに保存されたイベントログから、不具合調査に必要なデータを抽出します。
以下は私が普段使用している参考クエリです。利用する際はコメント行の下の仮値を実際の値に置き換えて使用してください。クエリの処理内容としては下記になります。

不具合が発生した日のイベントデータを指定（_table_suffix）
特定の時間帯に該当するイベントを抽出
特定のユーザー（user_id）の操作ログに限定
日本時間で時刻を整形し、昇順にソート

WITH raw AS (
  SELECT
    *
  FROM
     -- 各プロジェクトのIDを指定
    `project_id.analytics_project_id.events_*` AS events,
    UNNEST(`event_params`) AS ep
  WHERE
    -- 日付を指定
    _table_suffix = "<対象の日付>"
    AND FORMAT_TIMESTAMP('%Y-%m-%d %H:%M:%S', 
        TIMESTAMP_TRUNC(timestamp_micros(event_timestamp), SECOND), 
        "Asia/Tokyo") 
        -- 時間帯を指定
        BETWEEN '<開始日時>' AND '<終了日時>'
    -- ユーザーIDを指定
    AND user_id = '<ユーザーID>'
)

SELECT
  FORMAT_TIMESTAMP('%Y-%m-%d %H:%M:%S', 
      TIMESTAMP_TRUNC(timestamp_micros(event_timestamp), SECOND), 
      "Asia/Tokyo") AS times,
  *
FROM
  raw
ORDER BY
  times ASC;

2. 抽出したログの整形

抽出したログはそのままだと情報量が多く、必要なデータを見つけるのが難しい場合があります。
そのため、まずはCSV形式でダウンロードし、不要な情報を整理して調査しやすい形に加工します。

整形のポイント

不要な情報の削除: 調査に不要なフィールドやイベントは削除
重要フィールドの抽出: イベント名、タイムスタンプ、関連するパラメータ（例: 画面名、ボタン名など）を中心に整理
AIを活用: 上記ポイントをAIに伝え、必要な情報に絞ったCSVファイルを出力してもらう

3. 再現手順の調査

整形したログをもとに、アプリ上で該当するイベントが発火する操作手順を辿り、不具合を再現します。

調査の流れ

ログからイベント順を確認
- ユーザーがどの画面を操作し、どのイベントを発生させたかを追跡します。
操作を再現
- ログに基づき、同じ操作フローをアプリで再現してみます。
不具合の原因を特定
- 再現できた場合、その状態や動作を観察して原因を特定します。

実際に利用してみての成果

これらの方法を活用することで、不具合調査にかかる時間を大幅に短縮することができました。
さらに、これまで再現が難しく対応が後回しになっていた不具合についても、ユーザーの操作ログを活用して再現手順を明確化できるようになりました。
これによって、調査や修正にかかる工数を大まかに見積もれるようになり、修正タスクとしてバックログに積みやすくなったことを実感しています。

今後の課題

一方で、この方法を運用していく中で以下の課題も見えてきました。

1. イベントログの仕様整理

課題: 現状イベント仕様がコードベースでしか確認できず、調査がモバイルエンジニアに依存している。
対策: ドキュメントを整理し、モバイルエンジニア以外でも仕様を簡単に確認できるようにする。

2. イベントの網羅性向上

課題: ログが不足している場合、操作フローの完全な追跡が困難。
対策: 施策分析目的以外でも、基本的なPVイベントやTAPイベントを積極的に設定し、不具合調査に役立てる。

おわりに

今回の記事では、Firebase Analytics を活用した不具合調査のアプローチをご紹介しました。
この記事をきっかけに、自分なりのデバッグ方法を作り上げ、不具合対応力をさらに高めていただければと思います。
本記事が、皆さんのスキルアップやチーム全体の成長に少しでもお役に立てれば幸いです！

参考

積極採用中です

askenではエンジニアを絶賛募集中です。
まずはカジュアルにお話しできればと思いますので、ぜひお気軽にご連絡ください！

asken テックブログ

askenエンジニアが日々どんなことに取り組み、どんな「学び」を得ているか、よもやま話も織り交ぜつつ綴っていきます。皆さまにも一緒に学びを楽しんでいただけたら幸いです！