Firebase Crashlytics データを BigQuery にエクスポートする

Firebase Crashlytics データを BigQuery にエクスポートして、詳細に分析できます。BigQuery では、BigQuery SQL を使用してデータを分析できます。また、データを別のクラウド プロバイダにエクスポートできるほか、可視化や Google データポータルのカスタム ダッシュボードでデータを使用できます。

BigQuery へのエクスポートを有効にする

1. Firebase コンソールで、[統合] ページに移動します。

2. [BigQuery] カードで [リンク] をクリックします。

3. 画面上の手順に沿って、BigQuery へのエクスポートを有効にします。

   BigQuery の Crashlytics データにほぼリアルタイムでアクセスする場合は、ストリーミング エクスポートへのアップグレードを検討してください。

エクスポートを有効にした場合の影響

• データセットのロケーションを選択します。データセットの作成後はロケーションを変更できませんが、データセットを別のロケーションにコピーするか、データセットを別のロケーションに手動で移動（再作成）することはできます。詳細については、既存のエクスポートのロケーションを変更するをご覧ください。

  このロケーションは、BigQuery にエクスポートされたデータにのみ適用されます。Firebase コンソールの Crashlytics ダッシュボードや Android Studio で使用するために保存されたデータのロケーションには影響しません。

• デフォルトでは、プロジェクト内のすべてのアプリが BigQuery にリンクされ、後からプロジェクトに追加するアプリもすべて BigQuery に自動的にリンクされます。データを送信するアプリを管理することもできます。

• Firebase は、BigQuery へのデータの毎日の同期を設定します。

  • 通常、プロジェクトをリンクした後、最初のデータセットが BigQuery にエクスポートされる翌日の同期まで待つ必要があります。

  • 毎日の同期は、BigQuery でスケジュール設定したエクスポートに関係なく、1 日 1 回行われます。同期ジョブのタイミングと所要時間は変更される可能性があるため、エクスポートの特定のタイミングに基づいてダウンストリーム オペレーションやジョブをスケジュールすることはおすすめしません。

• Firebase は BigQuery に既存データのコピーをエクスポートします。エクスポートするデータの初回の読み込みには、最長で 48 時間かかる場合があります。

  • リンクされたアプリごとのバッチテーブルからも、毎日の同期によりデータがエクスポートされます。

  • バッチテーブルのデータ バックフィルは手動でスケジュールできます。過去 30 日間または BigQuery へのエクスポートを有効にした最新の日付まで（どちらか最新のほう）スケジュールできます。

  2024 年 10 月中旬より前に Crashlytics データのエクスポートを有効にした場合は、エクスポートを有効にした日から 30 日前までバックフィルすることもできます。

• Crashlytics から BigQuery へのストリーミング エクスポートを有効にすると、リンクされたすべてのアプリに、常に更新されるデータを含むリアルタイム テーブルも作成されます。

BigQuery へのエクスポートを無効にするには、Firebase コンソールでプロジェクトのリンクを解除します。

BigQuery にエクスポートされるデータの概要

Firebase Crashlytics データは、firebase_crashlytics という名前の BigQuery データセットにエクスポートされます。デフォルトでは、プロジェクト内のアプリごとに用意される Crashlytics データセットに個々のテーブルが作成されます。Firebase は、アプリの ID に基づいてテーブルの名前を付けます。ピリオドはアンダースコアに変換され、名前の末尾にプラットフォーム名が追加されます。

たとえば、パッケージ名が com.google.test の Android アプリのデータは com_google_test_ANDROID という名前のテーブルに格納されます。このバッチテーブルは毎日 1 回更新されます。BigQuery への Crashlytics ストリーミング エクスポートを有効にすると、Crashlytics データも com_google_test_ANDROID_REALTIME という名前のテーブルにリアルタイムでストリーミングされます。

テーブルの各行はアプリで発生したイベント（クラッシュ、致命的でないエラー、ANR など）を表します。

BigQuery への Crashlytics のストリーミング エクスポート

BigQuery ストリーミングを使用すると、Crashlytics データをリアルタイムでストリーミングできます。ライブ ダッシュボードでの情報の表示、ライブでのロールアウトの監視、アラートやカスタム ワークフローをトリガーするアプリケーション問題のモニタリングなど、ライブデータが必要なあらゆる目的で使用できます。

BigQuery への Crashlytics ストリーミング エクスポートを有効にすると、バッチテーブルに加えてリアルタイム テーブルも作成されます。この 2 つのテーブルには次の違いがあります。

バッチテーブルには書き込み前のイベントが永続的に保存されるため、このテーブルは長期分析で経時的な傾向を識別する場合に適しています。また、最大で 30 日前まで遡ってテーブルのバックフィルを行うことができます*。リアルタイム テーブルに書き込まれたデータはすぐに BigQuery に書き込まれるため、ライブ ダッシュボードやカスタム アラートにはリアルタイム テーブルが適しています。この 2 つのテーブルを合成クエリで組み合わせると、両方のメリットを利用できます。

デフォルトでは、リアルタイム テーブルのパーティションの有効期限は 30 日間です。これを変更する方法については、BigQuery ドキュメントのパーティションの有効期限を設定するをご覧ください。

^{* バックフィルのサポートの詳細については、新しいエクスポート インフラストラクチャにアップグレードするをご覧ください。}

BigQuery への Crashlytics のストリーミング エクスポートを有効にする

1. Firebase コンソールで、[統合] ページに移動します。

2. [BigQuery] カードで [管理] をクリックします。

3. [ストリーミングを含む] チェックボックスをオンにします。

この操作により、リンクされたすべてのアプリでストリーミングが有効になります。

エクスポートされたデータで可能な操作

BigQuery へのエクスポートには、デバイスの種類、オペレーティング システム、例外（Android アプリ）またはエラー（Apple アプリ）、Crashlytics ログなど、未加工のクラッシュ データが含まれます。

エクスポートされる Crashlytics データとそのテーブルのスキーマについては、このページの後の部分で詳しく説明します。

データポータルのテンプレートを使用する

データポータルのテンプレートでリアルタイム データを有効にするには、データポータルを使用してエクスポートされた Crashlytics データの可視化の手順に沿って操作します。

ビューを作成する

BigQuery UI を使用して、クエリをビューに変換できます。詳細な手順については、BigQuery ドキュメントのビューを作成するをご覧ください。

クエリを実行する

次の例は、Crashlytics データに対して実行して、障害イベントデータを、より簡単に理解できる概要に集約するレポートを生成するクエリを示しています。これらのタイプのレポートは Firebase コンソールの Crashlytics ダッシュボードでは利用できないため、クラッシュ データの分析と理解を補完できます。

例 1: 日別のクラッシュ数を確認する

できるだけ多くのバグを修正した後、チームは新しい写真共有アプリをリリースする準備が整ったと考えています。リリースする前に、過去 1 か月間の 1 日あたりの障害件数を確認し、バグバッシュでアプリが時間とともに安定してきたことを確認したいと考えています。

Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。

SELECT
  COUNT(DISTINCT event_id) AS number_of_crashes,
  FORMAT_TIMESTAMP("%F", event_timestamp) AS date_of_crashes
FROM
 `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
GROUP BY
  date_of_crashes
ORDER BY
  date_of_crashes DESC
LIMIT 30;

例 2: 最も多いクラッシュを確認する

生産計画の優先順位を正しく判断するため、アプリで最も発生頻度の高いクラッシュの上位 10 件を特定します。関連するデータポイントを提供するクエリを作成します。

Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。

SELECT
  DISTINCT issue_id,
  COUNT(DISTINCT event_id) AS number_of_crashes,
  COUNT(DISTINCT installation_uuid) AS number_of_impacted_user,
  blame_frame.file,
  blame_frame.line
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(),INTERVAL 168 HOUR)
  AND event_timestamp < CURRENT_TIMESTAMP()
GROUP BY
  issue_id,
  blame_frame.file,
  blame_frame.line
ORDER BY
  number_of_crashes DESC
LIMIT 10;

例 3: クラッシュ数が多い上位 10 台のデバイスを特定する

秋は新しいスマートフォンのシーズンです。この季節はまた、新しいデバイス固有の問題が多発する時期でもあります（特に Android の場合）。今後起きる可能性がある互換性の問題を事前に把握するため、先週（168 時間）最も多く障害が発生した 10 台のデバイスを特定するクエリを作成しました。

Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。

SELECT
  device.model,
COUNT(DISTINCT event_id) AS number_of_crashes
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 168 HOUR)
  AND event_timestamp < CURRENT_TIMESTAMP()
GROUP BY
  device.model
ORDER BY
  number_of_crashes DESC
LIMIT 10;

例 4: カスタムキーでフィルタリングする

あるゲーム デベロッパーが、ゲームのどのレベルで最も多くの障害が発生するかを調べようとしています。

この統計情報を追跡するため、current_level というカスタム Crashlytics キーを設定し、ユーザーが新しいレベルに到達するたびに更新します。

Crashlytics.sharedInstance().setIntValue(3, forKey: "current_level");

CrashlyticsKit setIntValue:3 forKey:@"current_level";

Crashlytics.setInt("current_level", 3);

BigQuery へのエクスポートのそのキーを使用して、各クラッシュ イベントに関連付けられた current_level 値の分布を報告するクエリを作成できます。

Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。

SELECT
COUNT(DISTINCT event_id) AS num_of_crashes,
  value
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
UNNEST(custom_keys)
WHERE
  key = "current_level"
GROUP BY
  key,
  value
ORDER BY
  num_of_crashes DESC

例 5: ユーザー ID を抽出する

Android アプリの早期アクセスを利用している。ほとんどのユーザーは問題なく利用していますが、3 人のユーザーから異常な数の障害件数が報告されました。根本的な原因を突き止めるため、これらのユーザーの ID を使用して障害イベントを取得するクエリを作成しました。

Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。

SELECT *
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  user.id IN ("USER_ID_1", "USER_ID_2", "USER_ID_3")
ORDER BY
  user.id
 

例 6: 特定のクラッシュ問題が発生しているすべてのユーザーを抽出する

チームが誤って、ベータテスターのグループに重大なバグをリリースしました。チームは、上記の「最も多いクラッシュを確認する」の例のクエリを使用して、クラッシュ問題の ID を特定し、このクラッシュの影響を受けたアプリユーザーのリストを抽出するクエリを実行しました。

Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。

SELECT user.id as user_id
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  issue_id = "ISSUE_ID"
  AND application.display_version = "APP_VERSION"
  AND user.id != ""
ORDER BY
  user.id;

例 7: クラッシュの影響を受けたユーザーの数を国別にまとめる

新しいリリースのロールアウト中に重大なバグが見つかりました。上記の「最も多いクラッシュを確認する」の例のクエリを使用して、特定のクラッシュ問題 ID を特定できました。次に、このクラッシュが世界的にどのように影響しているのかを確認します。

このクエリを作成するために、次の作業が必要になります。

1. Google Analytics データの BigQuery へのエクスポートを有効にします。詳しくは、プロジェクト データを BigQuery にエクスポートするをご覧ください。

2. ユーザー ID を Google Analytics SDK と Crashlytics SDK の両方に渡すようにアプリを更新します。

   Swift

   Crashlytics.sharedInstance().setUserIdentifier("123456789");
   Analytics.setUserID("123456789");
   

   Objective-C

   CrashlyticsKit setUserIdentifier:@"123456789";
   FIRAnalytics setUserID:@"12345678 9";
   

   Java

   Crashlytics.setUserIdentifier("123456789");
   mFirebaseAnalytics.setUserId("123456789");
   

3. ユーザー ID フィールドを使用して、Google Analytics データセットのイベントと Crashlytics データセットのクラッシュを結合するクエリを作成します。

   Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。

   SELECT DISTINCT c.issue_id, a.geo.country, COUNT(DISTINCT c.user.id) as num_users_impacted
   FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` c
   INNER JOIN  `PROJECT_ID.analytics_TABLE_NAME.events_*` a on c.user.id = a.user_id
   WHERE
     c.issue_id = "ISSUE_ID"
     AND a._TABLE_SUFFIX BETWEEN '20190101'
     AND '20200101'
   GROUP BY
     c.issue_id,
     a.geo.country,
     c.user.id

例 8: 今日ここまでの上位 5 件の問題

Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID_REALTIME`
WHERE
  DATE(event_timestamp) = CURRENT_DATE()
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

例 9: DATE 以降から今日までの上位 5 件の問題

バッチテーブルとリアルタイム テーブルを合成クエリと組み合わせて、信頼性の高いバッチデータにリアルタイム情報を追加することもできます。event_id が主キーであるため、DISTINCT event_id を使用して 2 つのテーブルで共通するすべてのイベントの重複を排除できます。

Android アプリのクエリの例を次に示します。iOS アプリの場合は、バンドル ID と IOS（パッケージ名と ANDROID の代わりに）を使用します。

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM (
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID_REALTIME`
  UNION ALL
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`)
WHERE
  event_timestamp >= "YYYY_MM_DD"
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

BigQuery の Crashlytics スキーマについて

Crashlytics から BigQuery へのデータ エクスポートを設定すると、Firebase は最近発生したイベント（クラッシュ、致命的ではないエラー、ANR）をエクスポートします。この中には、リンクの 2 日前までのイベントが含まれており、最大 30 日前まで遡ってテーブルのバックフィルを行えるオプションも用意されています。

リンクの 2 日前の時点からユーザーがリンクを無効にするまで、Firebase は Crashlytics イベントを毎日エクスポートします。エクスポート後に BigQuery でデータを利用できるようになるまでに数分かかることがあります。

データセット

Crashlytics は、Crashlytics データ用に BigQuery に新しいデータセットを作成します。このデータセットは、複数のアプリがある場合でもプロジェクト全体をカバーします。

テーブル

ユーザーがアプリのデータ エクスポートを無効にしない限り、Crashlytics はプロジェクトに含まれるアプリごとに、データセット内にテーブルを作成します。Firebase は、アプリのバンドル ID に基づいてテーブルの名前を付けます。ピリオドはアンダースコアに変換され、名前の末尾にプラットフォーム名が追加されます。

たとえば、パッケージ名が com.google.test の Android アプリのデータは com_google_test_ANDROID という名前のテーブルに格納され、リアルタイム データ（有効にされてる場合）は com_google_test_ANDROID_REALTIME という名前のテーブルに格納されます。

テーブルには、アプリで定義したカスタム Crashlytics キーに加えて、Crashlytics データの標準セットが含まれています。

行

テーブルの各行は、アプリで発生したエラーを表します。

列

テーブルの列は、クラッシュ、致命的でないエラー、ANR で同じです。BigQuery への Crashlytics ストリーミング エクスポートが有効になっている場合、リアルタイム テーブルにはバッチテーブルと同じ列があります。スタック トレースのないイベントを表す行に列が存在する場合があります。

エクスポート内の列は次の表のとおりです。

データポータルでエクスポートされた Crashlytics データを可視化する

Google データポータルを使うと、BigQuery の Crashlytics データセットを、見やすく簡単に共有できるうえ、全面的なカスタマイズも可能なレポートに変換できます。

データポータルの使用方法の詳細については、データポータル クイックスタート ガイドのデータポータルへようこそを試してください。

Crashlytics レポート テンプレートを使用する

データポータルには、エクスポートされた Crashlytics BigQuery スキーマからの包括的なディメンションと指標のセットを含む Crashlytics のサンプル レポートがあります。BigQuery への Crashlytics のストリーミング エクスポートを有効にしている場合、エクスポートされたデータはデータポータルのテンプレートの [Realtime trends] ページで確認できます。このサンプルをテンプレートとして使用すると、実際のアプリのクラッシュ データに基づいて新しいレポートやビジュアル資料を手軽に作成できます。

1. Crashlytics データポータル ダッシュボード テンプレートを開きます。

2. 右上にある [テンプレートを使用] をクリックします。

3. [新しいデータソース] プルダウンから [新しいデータソースを作成する] を選択します。

4. [BigQuery] カードで [選択] をクリックします。

5. [マイ プロジェクト] > [PROJECT_ID] > [firebase_crashlytics] > [TABLE_NAME] の順に選択して、エクスポートされた Crashlytics データを含むテーブルを選択します。

   バッチテーブルは常に選択可能です。BigQuery への Crashlytics ストリーミング エクスポートが有効になっている場合は、代わりにリアルタイム テーブルを選択できます。

6. [Configuration] で、[Crashlytics Template level] を [Default] に設定します。

7. [Connect] をクリックして新しいデータソースを作成します。

8. [Add to Report] をクリックして Crashlytics テンプレートに戻ります。

9. 最後に、[Create Report] をクリックして Crashlytics データポータル ダッシュボード テンプレートのコピーを作成します。

新しいエクスポート インフラストラクチャにアップグレードする

2024 年 10 月中旬、Crashlytics は Crashlytics データを BigQuery にエクスポートするための新しいインフラストラクチャをリリースしました。現時点では、この新しいインフラストラクチャへのアップグレードは任意です。

この新しいインフラストラクチャは、米国外の Crashlytics データセットのロケーションをサポートしています。

• 2024 年 10 月中旬以前にエクスポートを有効にした場合は、必要に応じて BigQuery でサポートされているデータセットのロケーションについて、データ エクスポートのロケーションを変更できます。

• 2024 年 10 月中旬以降にエクスポートを有効にした場合は、セットアップ時に BigQuery でサポートされているデータセットのロケーションを選択できます。

新しいインフラストラクチャのもう 1 つの違いは、エクスポートを有効にする前のデータのバックフィルをサポートしていないことです。（以前のインフラストラクチャでは、有効化日の 30 日前までバックフィルできました）。新しいインフラストラクチャは、過去 30 日間または BigQuery へのエクスポートを有効にした最新の日付まで（どちらか最新のほう）のバックフィルをサポートしています。

アップグレードの前提条件

新しいインフラストラクチャにアップグレードする前に、次の前提条件を満たしていることを確認してください。現在のバッチ BigQuery テーブルに、登録済みの Firebase アプリに対して設定されているバンドル ID またはパッケージ名と一致する ID があること。

次に例を示します。

• com_yourcompany_yourproject_IOS という名前の BigQuery テーブルがある場合は、Firebase プロジェクトにバンドル ID com.yourcompany.yourproject で Firebase iOS+ アプリが登録されている必要があります。

• com_yourcompany_yourproject_ANDROID という名前の BigQuery テーブルがある場合は、Firebase プロジェクトに Firebase Android アプリがパッケージ名 com.yourcompany.yourproject で登録されている必要があります。

Firebase プロジェクトに登録されているすべての Firebase アプリを確認する方法は次のとおりです。

1. Firebase コンソールで、settings [プロジェクト設定] に移動します。

2. [アプリ] カードまで下にスクロールし、目的の Firebase アプリをクリックして、ID などのアプリの情報を確認します。

新しいエクスポート インフラストラクチャは、登録済みの Firebase アプリに設定されているパッケージ名またはバンドル ID に基づいて各アプリのデータをエクスポートします。BigQuery ワークフローを中断しないようにするには、新しいインフラストラクチャがすべての新しいデータを既存のテーブルに追加できるように、現在のバッチテーブルにすでに正しい名前が付いていることを確認することが重要です。登録済みの Firebase アプリと一致しないバッチテーブル名があるにもかかわらず、アップグレードする場合は、Firebase サポートにお問い合わせください。

新しいインフラストラクチャにアップグレードする方法

エクスポートをすでに有効にしている場合は、Firebase コンソールで Crashlytics データ エクスポートをオフにしてからオンに戻すだけで、新しいインフラストラクチャにアップグレードできます。

詳しい手順は次のとおりです。

1. Firebase コンソールで、[統合] ページに移動します。

2. [BigQuery] カードで [管理] をクリックします。

3. Crashlytics スライダーをオフに切り替えて、エクスポートを無効にします。プロンプトが表示されたら、データ エクスポートの停止を確認します。

4. すぐに Crashlytics スライダーをオンに戻して、エクスポートを再度有効にします。プロンプトが表示されたら、データのエクスポートを確認します。

   BigQuery への Crashlytics データ エクスポートで、新しいエクスポート インフラストラクチャが使用されるようになりました。