將 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 中設定的排定匯出作業為何，系統每天都會執行一次每日同步作業。請注意，同步作業的時間和持續時間可能會變更，因此不建議根據匯出的特定時間安排下游作業或工作。

• 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 的資料表中。這個批次資料表每天更新一次。如果啟用Crashlytics串流匯出至 BigQuery，系統也會將Crashlytics資料即時串流至名為 com_google_test_ANDROID_REALTIME 的資料表。

表格中的每一列都代表應用程式中發生的事件，包括當機、非重大錯誤和 ANR。

Crashlytics串流匯出至 BigQuery

您可以透過BigQuery串流即時串流 Crashlytics 資料。 您可以使用這項功能處理任何需要即時資料的用途，例如在即時資訊主頁中呈現資訊、觀看發布作業的即時情況，或是監控會觸發快訊和自訂工作流程的應用程式問題。

啟用Crashlytics串流匯出至 BigQuery 後，除了批次資料表，您還會取得即時資料表。以下是您應注意的資料表差異：

批次資料表適合長期分析及找出一段時間內的趨勢，因為系統會先永久儲存事件，再寫入資料表，且最多可回填 30 天的資料*。當我們將資料寫入即時資料表時，會立即將資料寫入 BigQuery，因此非常適合用於即時資訊主頁和自訂快訊。這兩個資料表可以透過縫合查詢合併，同時享有兩者的優點。

根據預設，即時資料表的分割區到期時間為 30 天。如要瞭解如何修改這項設定，請參閱 BigQuery 說明文件中的「設定分割區到期時間」。

^{* 如要瞭解回填支援的詳細資訊，請參閱「升級至新的匯出基礎架構」。}

啟用 Crashlytics 串流匯出至 BigQuery

1. 前往 Firebase 控制台的「整合」頁面。

2. 在 BigQuery 資訊卡中，按一下「管理」。

3. 勾選「包含串流」核取方塊。

這項操作會為所有連結的應用程式啟用串流功能。

匯出資料的用途

匯出至 BigQuery 的檔案包含原始當機資料，包括裝置類型、作業系統、例外狀況 (Android 應用程式) 或錯誤 (Apple 應用程式)，以及 Crashlytics 記錄和其他資料。

如要瞭解匯出的 Crashlytics 資料和資料表結構定義，請參閱本頁稍後的內容。

使用數據分析範本

如要在數據分析範本中啟用即時資料，請按照「使用數據分析視覺化匯出的 Crashlytics 資料」一文中的操作說明進行。

建立檢視表

您可以使用 BigQuery UI 將查詢轉換為檢視區塊。 如需詳細操作說明，請參閱建立檢視區塊一文的BigQuery說明文件。

執行查詢

下列範例示範您可以在 Crashlytics 資料上執行的查詢，產生報表並將當機事件資料匯總至更容易理解的摘要中。由於這些類型的報表無法在 Firebase 控制台的 Crashlytics 資訊主頁中查看，因此可用於補充分析，並協助您瞭解當機資料。

範例 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：擷取 User-ID

您有一個處於搶先體驗階段的 Android 應用程式。大部分使用者都對該應用程式感到滿意，但有三位使用者則遇到不尋常的當機次數。為了釐清問題的真正原因，您撰寫查詢，使用這些使用者的 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：找出所有遇到特定當機問題的使用者

您的團隊不慎將重大錯誤發布給一群 Beta 版測試人員。 您的團隊已使用上述「找出最普遍的當機問題」範例中的查詢，找出特定當機問題 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，從這兩個資料表中移除任何常見事件的重複項目。

以下是 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;

瞭解 Crashlytics 結構定義 BigQuery

設定將資料匯出至 BigQuery 時，Firebase 會匯出近期事件 (當機、一般錯誤和 ANR)，包括連結前兩天出現的事件，並提供回填最多 30 天資料的選項。Crashlytics

從啟用匯出功能到停用匯出功能，Firebase 每天都會匯出 Crashlytics 事件。每次匯出後可能需要幾分鐘的時間，您才能在 BigQuery 中使用資料。

資料集

Crashlytics 會在 BigQuery 中為 Crashlytics 資料建立新的資料集。這個資料集會涵蓋整個專案，即使專案包含多個應用程式亦同。

表格

Crashlytics 會在資料集中為專案裡的每個應用程式建立資料表，除非您選擇停用該應用程式的匯出資料功能。Firebase 會依據應用程式的 ID 來命名資料表，同時會將句號轉換為底線，並將平台名稱附加到結尾處。

舉例來說，如果 Android 應用程式的套件名稱為 com.google.test，資料就會位於名為 com_google_test_ANDROID 的資料表中，而即時資料 (如已啟用) 則會位於名為 com_google_test_ANDROID_REALTIME 的資料表中。

除了您在應用程式中定義的任何自訂 Crashlytics 鍵之外，資料表還包含一組標準的 Crashlytics 資料。

資料列

每個在資料表中的資料列都代表應用程式遇到的某個錯誤。

欄

對於當機、輕微錯誤和 ANR 來說，資料表中的資料欄都完全相同。如果啟用 Crashlytics 串流匯出至 BigQuery，即時資料表就會與批次資料表有相同的資料欄。請注意，您可能在代表沒有堆疊追蹤的事件的資料列中，有資料欄。

系統匯出的資料欄如下表所示：

使用數據分析工具，以圖表呈現匯出的 Crashlytics 資料

Google 數據分析可將您在 BigQuery 中的 Crashlytics 資料集變成易於閱讀、共用且可完全自訂的報表。

如要進一步瞭解如何使用數據分析，請參閱《數據分析快速入門指南》中的歡迎使用數據分析。

使用 Crashlytics 報表範本

數據分析提供 Crashlytics 範例報表，其中包含從匯出的 Crashlytics BigQuery結構定義中取得的一組完整維度和指標。如果您已啟用Crashlytics串流匯出BigQuery功能，即可在數據分析範本的「即時趨勢」頁面查看資料。您可以使用該範例做為範本，依據您自己應用程式上的原始當機資料，快速建立新的報表與視覺化效果：

1. 開啟 Crashlytics 數據分析資訊主頁範本。

2. 按一下右上角的 [Use Template] (使用範本)。

3. 在「新資料來源」下拉式選單中，選取「建立新資料來源」。

4. 按一下「BigQuery」資訊卡上的「選取」。

5. 依序選擇「My Projects」> PROJECT_ID >「firebase_crashlytics」> TABLE_NAME，選取包含匯出 Crashlytics 資料的資料表。

   你隨時可以選取批次表格。如果啟用Crashlytics串流匯出至 BigQuery，則可改為選取即時資料表。

6. 在「Configuration」(設定) 底下，將「Crashlytics Template level」(範本等級) 設為「Default」(預設)。

7. 按一下 [Connect] (連結) 建立新的資料來源。

8. 按一下「加入報表」，即可返回 Crashlytics 範本。

9. 最後按一下「建立報表」，建立 Crashlytics 數據分析資訊主頁範本的副本。