在 BigQuery 中對匯出的資料執行 SQL 查詢

將 Crashlytics 和 Firebase 工作階段資料 (選用) 匯出至 BigQuery 後，即可開始使用這些資料：

  • 使用 SQL 查詢分析資料
    您可以對 Crashlytics 資料執行查詢，產生自訂報表和摘要。由於 Firebase 控制台的 Crashlytics 資訊主頁不提供這類自訂報表，因此可做為分析及瞭解當機資料的輔助工具。請參閱本頁後續章節的查詢範例。

  • 彙整不同資料集的資料
    舉例來說，如果您在設定資料匯出時選擇匯出 Firebase 工作階段資料，就能進一步瞭解未發生當機情形的使用者和未發生當機情形的工作階段 (請參閱查詢範例)。Crashlytics此外，您也可以從各種 Firebase 產品 (例如 Performance Monitoring) 或 Google Analytics 匯出資料，然後在 BigQuery 中彙整及分析這些資料與 Crashlytics 資料。

  • 建立檢視表
    您可以使用 BigQuery UI 建立檢視表，也就是由 SQL 查詢定義的虛擬資料表。如需各種檢視表類型和建立方法的詳細操作說明，請參閱 BigQuery 說明文件。

如要進一步瞭解資料集結構定義，請參閱「BigQuery 中匯出資料的資料集結構定義」。

瞭解 BigQuery SQL

Crashlytics 資料的查詢範例

本節提供一些範例情境和範例查詢，示範如何搭配使用 BigQuery SQL 與匯出的 Crashlytics 資料和 Firebase 工作階段資料。

範例 1：使用 Firebase 工作階段資料計算無當機指標

在最新版本中，您大幅翻新應用程式，解決關鍵使用者歷程中的當機問題。您收到使用者的好評，但希望有量化證據，證明應用程式比以前更穩定。

未發生當機情形的指標可提供這類資訊。這些指標是重要評估依據，可協助您瞭解應用程式的整體健康狀態。有了 Firebase 工作階段資料和 Crashlytics 事件，您就能透過基本查詢計算這些指標。

以下是 Android 應用程式的查詢範例。如果是 iOS 應用程式，請使用軟體包 ID 和 IOS (而非套件名稱和 ANDROID)。

特定版本的未遇到當機情形的使用者：

SELECT
  TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY) AS event_date,
  (1 - (COUNT (DISTINCT installation_uuid) / COUNT (DISTINCT instance_id))) AS CFU
FROM
  `PROJECT_ID.firebase_sessions.PACKAGE_NAME_ANDROID` AS sessions
LEFT JOIN
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` AS crashlytics
ON
  TIMESTAMP_TRUNC(sessions.event_timestamp,DAY) = TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY)
WHERE
  crashlytics.error_type="FATAL"
  AND crashlytics.application.display_version="APP_VERSION"
  AND sessions.application.display_version = "APP_VERSION"
GROUP BY
  event_date
ORDER BY
  event_date

過去一週 (168 小時) 內未發生當機情形的工作階段：

SELECT
  TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY) AS event_date,
  (1 - (COUNT (DISTINCT crashlytics.firebase_session_id) / COUNT (DISTINCT sessions.session_id))) AS CFS
FROM
  `PROJECT_ID.firebase_sessions.PACKAGE_NAME_ANDROID` AS sessions
LEFT JOIN
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` AS crashlytics
ON
  TIMESTAMP_TRUNC(sessions.event_timestamp,DAY) = TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY)
WHERE
  crashlytics.error_type="FATAL" AND _PARTITIONTIME >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 168 HOUR)
  AND _PARTITIONTIME < CURRENT_TIMESTAMP()
GROUP BY
  event_date
ORDER BY
  event_date

範例 2：每日當機次數

在盡可能修正錯誤後，您認為團隊終於可以推出新的相片分享應用程式。不過，您想先查看過去一個月內每天的當機次數，確認錯誤修正活動確實讓應用程式變得更穩定。

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

範例 3：找出最常見的當機問題

為了妥善安排生產計畫的優先順序，您想找出應用程式中最常見的 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;

範例 4：當機次數前 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;

範例 5：依自訂鍵篩選

您是遊戲開發人員，想知道遊戲的哪個關卡當機次數最多。

為了追蹤這項統計資料，您設定了名為 current_level 的自訂 Crashlytics 鍵 (iOS+ | Android | Flutter | Unity)，並在使用者達到新等級時更新。

Swift

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

Objective-C

CrashlyticsKit setIntValue:3 forKey:@"current_level";

Java

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

範例 6：擷取使用者 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

範例 7：找出所有遇到特定當機問題的使用者

您的團隊不小心向一群 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;

範例 8：受當機問題影響的使用者人數 (依國家/地區細分)

團隊在推出新版本時偵測到重大錯誤。您可以使用上方「找出最常見的當機問題」範例中的查詢，找出特定當機問題 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

範例 9：今天目前為止的前 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;

範例 10：自 [日期] (含當天) 以來的前 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 >= PARSE_TIMESTAMP("%Y_%m_%d", "YYYY_MM_DD")
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

後續步驟