您可以將 Crashlytics 資料匯出到BigQuery中以進行進一步分析。 BigQuery 允許您使用 BigQuery SQL 分析數據,將其匯出到另一個雲端供應商,並透過 Google Data Studio 將其用於視覺化和自訂儀表板。
啟用 BigQuery 匯出
- 前往 Firebase 控制台中的整合頁面。
- 在BigQuery卡片中,點擊連結。
- 請依照螢幕上的指示啟用 BigQuery。
當您將項目連結到 BigQuery 時:
- Firebase 設定每日將資料從 Firebase 專案同步到 BigQuery。
- 預設情況下,專案中的所有應用程式都會連結到 BigQuery,並且您以後新增到專案中的任何應用程式都會自動連結到 BigQuery。您可以管理哪些應用程式發送資料。
- Firebase將現有資料的副本匯出到 BigQuery。對於每個連結的應用程序,這包括一個包含每日同步資料的批次表。
- 如果您啟用 Crashlytics BigQuery 串流匯出,所有連結的應用程式還將有一個包含不斷更新資料的即時表。
若要停用 BigQuery 匯出,請在 Firebase 控制台中取消連結您的專案。
哪些資料會匯出到 BigQuery?
Firebase Crashlytics 資料匯出到名為firebase_crashlytics
的 BigQuery 資料集。預設情況下,將為專案中的每個應用程式在 Crashlytics 資料集中建立單獨的表格。 Firebase 根據應用程式的套件標識符命名表,其中句點轉換為下劃線,並在末尾附加平台名稱。
例如,ID 為com.google.test
的應用程式的資料將位於名為com_google_test_ANDROID
的表中。此批次表每天更新一次。如果您啟用 Crashlytics BigQuery 串流匯出,Firebase Crashlytics 資料也會即時串流到com_google_test_ANDROID_REALTIME
。
表中的每一行代表應用程式中發生的一個事件,包括崩潰、非致命錯誤和 ANR。
啟用 Crashlytics BigQuery 串流匯出
您可以使用BigQueryStreaming即時串流 Crashlytics 資料。您可以將其用於需要即時資料的任何目的,例如在即時儀表板中呈現資訊、即時觀看部署或監控觸發警報和自訂工作流程的應用程式問題。
Crashlytics BigQuery 串流匯出不適用於 BigQuery 沙盒。
當您啟用 Crashlytics BigQuery 串流匯出時,除了批次表之外,您還將擁有即時表格。以下是您應該注意的表格之間的差異:
批次表 | 即時表 |
---|---|
|
|
批次表非常適合長期分析和識別一段時間內的趨勢,因為我們在寫入事件之前會持久儲存事件,並且它們可以回填到表中長達 90 天。當我們將資料寫入即時表時,我們會立即將其寫入 BigQuery,因此它非常適合即時儀表板和自訂警報。這兩個表格可以與拼接查詢結合起來,以獲得兩者的好處。請參閱下面的查詢範例 9 。
預設情況下,實時表的分區過期時間為30天。若要了解如何修改此設置,請參閱更新分割區過期時間。
啟用 Crashlytics BigQuery 串流
若要啟用串流傳輸,請導覽至 BigQuery整合頁面的 Crashlytics 部分,然後選擇包含串流複選框。
資料工作室模板
若要在 Data Studio 範本中啟用即時數據,請依照使用 Data Studio 視覺化匯出的 Crashlytics 資料中的說明進行操作。
意見
您可以使用 BigQuery UI 將下面的範例查詢轉換為檢視。有關詳細說明,請參閱建立視圖。
您可以使用匯出的資料做什麼?
BigQuery 匯出包含原始崩潰數據,包括設備類型、作業系統、異常(Android 應用程式)或錯誤(Apple 應用程式)、Crashlytics 日誌以及其他數據。
在 BigQuery 中使用 Firebase Crashlytics 數據
以下範例示範了您可以對 Crashlytics 資料執行的查詢。這些查詢會產生 Crashlytics 儀表板中不可用的報表。
Crashlytics 查詢範例
以下範例示範如何產生將崩潰事件資料聚合為更易於理解的摘要的報告。
範例 1:白天崩潰
在努力修復盡可能多的錯誤後,一位首席開發人員認為她的團隊終於準備好推出他們的新照片共享應用程式。在此之前,他們想要檢查過去一個月每天的崩潰次數,以確保他們的 bug 重擊使應用程式隨著時間的推移變得更加穩定:
SELECT COUNT(DISTINCT event_id) AS number_of_crashes, FORMAT_TIMESTAMP("%F", event_timestamp) AS date_of_crashes FROM `projectId.firebase_crashlytics.package_name_ANDROID` GROUP BY date_of_crashes ORDER BY date_of_crashes DESC LIMIT 30;
範例 2:找出最普遍的崩潰
為了正確確定生產計劃的優先級,專案經理思考如何指出其產品中最常見的 10 種崩潰。他們產生一個提供相關數據點的查詢:
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 `projectId.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 個崩潰設備
秋天是新手機季節!開發人員知道,這也意味著新的設備特定問題季節即將到來。為了解決迫在眉睫的兼容性問題,他們整理了一個查詢,識別過去一周崩潰次數最多的 10 台設備:
SELECT device.model, COUNT(DISTINCT event_id) AS number_of_crashes FROM `projectId.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:按自訂鍵過濾
遊戲開發者想知道他們的遊戲哪個關卡崩潰最多。為了幫助他們追蹤該統計數據,他們設定了一個自訂 Crashlytics 鍵current_level
,並在使用者每次達到新等級時更新它。
Objective-C
CrashlyticsKit setIntValue:3 forKey:@"current_level";
迅速
Crashlytics.sharedInstance().setIntValue(3, forKey: "current_level");
爪哇
Crashlytics.setInt("current_level", 3);
然後,他們使用 BigQuery 匯出中的該鍵編寫一個查詢來報告與每個崩潰事件關聯的current_level
值的分佈:
SELECT COUNT(DISTINCT event_id) AS num_of_crashes, value FROM `projectId.firebase_crashlytics.package_name_ANDROID` UNNEST(custom_keys) WHERE key = "current_level" GROUP BY key, value ORDER BY num_of_crashes DESC
範例5:用戶ID提取
開發者有一個處於早期訪問階段的應用程式。他們的大多數用戶都喜歡它,但其中三個用戶經歷了異常數量的崩潰。為了找出問題的根源,他們編寫了一個查詢,使用這些使用者的使用者 ID 來提取所有崩潰事件:
SELECT * FROM `projectId.firebase_crashlytics.package_name_ANDROID` WHERE user.id IN ("userid1", "userid2", "userid3") ORDER BY user.id
範例 6:尋找所有面臨特定崩潰問題的用戶
開發人員向一組 Beta 測試人員發布了一個嚴重錯誤。該團隊能夠使用上面範例 2 中的查詢來識別特定的崩潰問題 ID。現在他們想要執行一個查詢來提取受此崩潰影響的應用程式使用者清單:
SELECT user.id as user_id FROM `projectId.firebase_crashlytics.package_name_ANDROID` WHERE issue_id = "YOUR_ISSUE_ID" AND application.display_version = "" AND user.id != "" ORDER BY user.id;
範例 7:受崩潰問題影響的使用者數量(按國家/地區細分)
現在,該團隊在新版本的推出過程中檢測到了一個嚴重錯誤。他們能夠使用上面範例 2 中的查詢來識別特定的崩潰問題 ID。團隊現在想看看這次崩盤是否蔓延到世界各地不同國家的用戶。
要編寫此查詢,團隊需要:
為 Google Analytics 啟用 BigQuery 匯出。請參閱將項目資料匯出至 BigQuery 。
更新他們的應用程式以將使用者 ID 傳遞到 Google Analytics SDK 和 Crashlytics SDK 中。
Objective-C
CrashlyticsKit setUserIdentifier:@"123456789"; FIRAnalytics setUserID:@"12345678 9";
迅速
Crashlytics.sharedInstance().setUserIdentifier("123456789"); Analytics.setUserID("123456789");
爪哇
Crashlytics.setUserIdentifier("123456789"); mFirebaseAnalytics.setUserId("123456789");
編寫一個查詢,使用使用者 ID 欄位將 Google Analytics BigQuery 資料集中的事件與 Crashlytics BigQuery 資料集中的崩潰連接起來:
SELECT DISTINCT c.issue_id, a.geo.country, COUNT(DISTINCT c.user.id) as num_users_impacted FROM `projectId.firebase_crashlytics.package_name_ANDROID` c INNER JOIN `projectId.analytics_YOUR_TABLE.events_*` a on c.user.id = a.user_id WHERE c.issue_id = "YOUR_ISSUE_ID" AND a._TABLE_SUFFIX BETWEEN '20190101' AND '20200101' GROUP BY c.issue_id, a.geo.country, c.user.id
範例 8:今天迄今為止最重要的 5 個問題
需要啟用 Crashlytics BigQuery 串流匯出
SELECT issue_id, COUNT(DISTINCT event_id) AS events FROM `your_project.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 的問題
需要啟用 Crashlytics BigQuery 串流匯出。
在此範例中,我們將批量表和即時表結合起來,將即時資訊添加到可靠的批量資料中。由於event_id
是主鍵,因此我們可以使用DISTINCT event_id
從兩個表中刪除任何公共事件。
SELECT issue_id, COUNT(DISTINCT event_id) AS events FROM ( SELECT issue_id, event_id, event_timestamp FROM `your_project.firebase_crashlytics.package_name_ANDROID_REALTIME` UNION ALL SELECT issue_id, event_id, event_timestamp FROM `your_project.firebase_crashlytics.package_name_ANDROID`) WHERE event_timestamp >= "2020-01-13" GROUP BY issue_id ORDER BY events DESC LIMIT 5;
了解 BigQuery 中的 Firebase Crashlytics 架構
當您將 Crashlytics 與 BigQuery 關聯時,Firebase 會匯出最近的事件(當機、非致命錯誤和 ANR),包括連結前最多兩天的事件,並且可以選擇回填最多 90 天。
從那時起,直到您停用連結為止,Firebase 每天都會匯出 Crashlytics 事件。每次匯出後,資料可能需要幾分鐘的時間才能在 BigQuery 中可用。
數據集
Firebase Crashlytics 在 BigQuery 中為 Crashlytics 資料建立一個新資料集。該資料集涵蓋您的整個項目,即使它有多個應用程式。
表格
Firebase Crashlytics 在資料集中為專案中的每個應用程式建立一個表,除非您選擇不匯出該應用程式的資料。 Firebase 根據應用程式的套件標識符命名表,其中句點轉換為下劃線,並在末尾附加平台名稱。
例如,ID 為com.google.test
的 Android 應用程式的資料將位於名為com_google_test_ANDROID
的表中,即時資料(如果啟用)將位於名為com_google_test_ANDROID_REALTIME
的表中
除了開發人員定義的任何自訂 Crashlytics 鍵之外,表格還包含一組標準的 Crashlytics 資料。
行數
表中的每一行代表應用程式遇到的錯誤。
列
對於崩潰、非致命錯誤和 ANR,表中的欄位是相同的。如果啟用了 Crashlytics BigQuery 串流匯出,則即時表格將具有與批次表相同的欄位。下面列出了匯出中的列。
沒有堆疊追蹤
行中存在的列表示沒有堆疊追蹤的事件。
欄位名稱 | 資料類型 | 描述 |
---|---|---|
平台 | 細繩 | 蘋果或安卓應用程式 |
捆綁包標識符 | 細繩 | 捆綁 ID,例如 com.google.gmail |
事件ID | 細繩 | 事件的唯一 ID |
是致命的 | 布林值 | 應用程式是否崩潰 |
錯誤類型 | 細繩 | 事件的錯誤類型(FATAL、NON_FATAL、ANR) |
問題ID | 細繩 | 與事件相關的問題 |
變體_id | 細繩 | 與此事件相關的問題變體 請注意,並非所有事件都有關聯的問題變體。 |
事件時間戳 | 時間戳 | 事件發生時 |
裝置 | 記錄 | 發生事件的設備 |
設備製造商 | 細繩 | 設備製造商 |
設備型號 | 細繩 | 設備型號 |
裝置架構 | 細繩 | X86_32、X86_64、ARMV7、ARM64、ARMV7S 或 ARMV7K |
記憶 | 記錄 | 設備的記憶體狀態 |
已用記憶體 | INT64 | 使用的記憶體位元組數 |
無記憶體 | INT64 | 剩餘記憶體位元組數 |
貯存 | 記錄 | 設備的持久性存儲 |
儲存.已使用 | INT64 | 使用的儲存位元組數 |
免儲存 | INT64 | 剩餘儲存位元組數 |
作業系統 | 記錄 | 設備上作業系統的詳細信息 |
作業系統.顯示版本 | 細繩 | 裝置上作業系統的版本 |
作業系統名稱 | 細繩 | 設備上作業系統的名稱 |
作業系統修改狀態 | 細繩 | 設備是否已被修改,例如越獄/root(修改或未修改) |
作業系統類型 | 細繩 | 設備上運行的作業系統類型(例如 IOS、MACOS);僅適用於Apple平台應用程式 |
作業系統.設備類型 | 細繩 | 設備類型(例如,手機、平板電腦、電視等);也稱為“設備類別” |
應用 | 記錄 | 生成事件的應用程式 |
應用程式.build_version | 細繩 | 應用程式的建置版本 |
應用程式.display_version | 細繩 | |
使用者 | 記錄 | 可選:收集有關應用程式使用者的信息 |
使用者名稱 | 細繩 | 可選:用戶名 |
使用者信箱 | 細繩 | 可選:使用者的電子郵件地址 |
使用者身分 | 細繩 | 可選:與使用者關聯的應用程式特定 ID |
自訂鍵 | 重複記錄 | 開發者定義的鍵值對 |
自訂鍵.key | 細繩 | 開發者定義的金鑰 |
自訂鍵值 | 細繩 | 開發者定義的值 |
安裝uuid | 細繩 | 標識唯一應用程式和裝置安裝的 ID |
crashlytics_sdk_版本 | 細繩 | 產生事件的 Crashlytics SDK 版本 |
應用方向 | 細繩 | 肖像、風景、正面朝上或正面朝下 |
設備方向 | 細繩 | 肖像、風景、正面朝上或正面朝下 |
行程狀態 | 細繩 | 背景或前景 |
紀錄 | 重複記錄 | 由 Crashlytics 記錄器產生的帶有時間戳記的日誌訊息(如果啟用) |
日誌.時間戳 | 時間戳 | 日誌何時製作 |
日誌訊息 | 細繩 | 記錄的消息 |
麵包屑 | 重複記錄 | 帶有時間戳記的 Google Analytics 麵包屑(如果已啟用) |
麵包屑.時間戳 | 時間戳 | 與麵包屑關聯的時間戳 |
麵包屑.name | 細繩 | 與麵包屑相關的名稱 |
麵包屑.params | 重複記錄 | 與麵包屑相關的參數 |
麵包屑.params.key | 細繩 | 與麵包屑關聯的參數鍵 |
breadcrumbs.params.value | 細繩 | 與麵包屑相關的參數值 |
責怪框架 | 記錄 | 被確定為崩潰或錯誤根本原因的幀 |
怪罪框架.line | INT64 | 幀文件的行號 |
Blame_frame.file | 細繩 | 幀文件的名稱 |
Blame_frame.symbol | 細繩 | 水合符號,或原始符號(如果不可水合) |
Blame_frame.offset | INT64 | 包含程式碼的二進位映像的位元組偏移量,未設定 Java 異常 |
Blame_frame.地址 | INT64 | 包含程式碼的二進位映像中的位址,未針對 Java 幀設置 |
Blame_frame.library | 細繩 | 包含框架的庫的顯示名稱 |
責任框架.所有者 | 細繩 | 開發人員、供應商、運行時、平台或系統 |
責備框架.責備 | 布林值 | Crashlytics 的分析是否確定該幀是導致崩潰或錯誤的原因 |
例外情況 | 重複記錄 | 僅限 Android:此事件期間發生的異常。嵌套異常依時間倒序排列(閱讀:最後一筆記錄是第一個拋出的例外) |
異常類型 | 細繩 | 異常類型,例如java.lang.IllegalStateException |
異常.exception_message | 細繩 | 與異常相關的訊息 |
例外嵌套 | 布林值 | 對於除最後拋出的異常(即第一筆記錄)之外的所有異常均為 true |
例外.標題 | 細繩 | 線程的標題 |
異常.subtitle | 細繩 | 線程的副標題 |
例外.指責 | 布林值 | 如果 Crashlytics 確定異常是導致錯誤或崩潰的原因,則為 True |
異常.frames | 重複記錄 | 與異常相關的幀 |
異常.frames.line | INT64 | 幀文件的行號 |
異常.frames.文件 | 細繩 | 幀文件的名稱 |
異常.frames.symbol | 細繩 | 水合符號,或原始符號(如果不可水合) |
異常.frames.offset | INT64 | 包含程式碼的二進位映像的位元組偏移量,未設定 Java 異常 |
異常.幀.地址 | INT64 | 包含程式碼的二進位映像中的位址,未針對 Java 幀設置 |
異常.frames.庫 | 細繩 | 包含框架的庫的顯示名稱 |
異常.frames.owner | 細繩 | 開發人員、供應商、運行時、平台或系統 |
異常.框架.指責 | 布林值 | Crashlytics 的分析是否確定該幀是導致崩潰或錯誤的原因 |
錯誤 | 重複記錄 | 僅限 Apple 應用程式:非致命錯誤 |
錯誤.queue_name | 細繩 | 線程正在運行的隊列 |
錯誤代碼 | INT64 | 與應用程式的自訂記錄的 NSError 關聯的錯誤代碼 |
錯誤.標題 | 細繩 | 線程的標題 |
錯誤.字幕 | 細繩 | 線程的副標題 |
錯誤歸咎於 | 布林值 | Crashlytics 的分析是否確定此框架是導致錯誤的原因 |
錯誤訊框 | 重複記錄 | 堆疊追蹤的幀 |
錯誤.幀.行 | INT64 | 框架文件的行號 |
錯誤.幀.文件 | 細繩 | 幀文件的名稱 |
錯誤.幀.符號 | 細繩 | 水合符號,或原始符號(如果不可水合) |
錯誤.幀.偏移量 | INT64 | 包含程式碼的二進位影像的位元組偏移量 |
錯誤.幀.位址 | INT64 | 包含程式碼的二進位映像中的位址 |
錯誤.frames.庫 | 細繩 | 包含框架的庫的顯示名稱 |
錯誤.幀.所有者 | 細繩 | 開發人員、供應商、運行時、平台或系統 |
錯誤.幀.指責 | 布林值 | Crashlytics 的分析是否確定此框架是導致錯誤的原因 |
執行緒 | 重複記錄 | 事件發生時存在的線程 |
線程崩潰 | 布林值 | 線程是否崩潰 |
線程.線程名稱 | 細繩 | 線程的名稱 |
線程.queue_name | 細繩 | 僅限Apple應用程式:線程正在其上運行的隊列 |
線程.signal_name | 細繩 | 導致應用程式崩潰的訊號名稱,僅出現在崩潰的本機執行緒上 |
線程.signal_code | 細繩 | 導致應用崩潰的信號代碼;僅存在於崩潰的本機執行緒上 |
線程.crash_地址 | INT64 | 導致應用程式崩潰的信號的位址;僅存在於崩潰的本機執行緒上 |
執行緒程式碼 | INT64 | 僅限 Apple 應用程式:應用程式的自訂記錄 NSError 的錯誤代碼 |
線程.標題 | 細繩 | 線程的標題 |
線.subtitle | 細繩 | 線程的副標題 |
線被指責 | 布林值 | Crashlytics 的分析是否確定該幀是導致崩潰或錯誤的原因 |
執行緒.框架 | 重複記錄 | 線程的幀 |
線程.框架.線 | INT64 | 框架文件的行號 |
執行緒.框架.文件 | 細繩 | 幀文件的名稱 |
線程.框架.符號 | 細繩 | 水合符號,或原始符號(如果不可水合) |
線程.幀.偏移量 | INT64 | 包含程式碼的二進位影像的位元組偏移量 |
線程.幀.位址 | INT64 | 包含程式碼的二進位映像中的位址 |
執行緒.框架.庫 | 細繩 | 包含框架的庫的顯示名稱 |
執行緒.框架.所有者 | 細繩 | 開發人員、供應商、運行時、平台或系統 |
線程.幀.指責 | 布林值 | Crashlytics 的分析是否確定此框架是導致錯誤的原因 |
unity_metadata.unity_version | 細繩 | 該裝置上執行的 Unity 版本 |
unity_metadata.debug_build | 布林值 | 如果這是調試版本 |
unity_metadata.processor_type | 細繩 | 處理器類型 |
unity_metadata.processor_count | INT64 | 處理器數量(核心) |
unity_metadata.processor_Frequency_mhz | INT64 | 處理器的頻率(以 MHz 為單位) |
unity_metadata.system_memory_size_mb | INT64 | 系統記憶體大小(以 Mb 為單位) |
unity_metadata.graphics_memory_size_mb | INT64 | 圖形記憶體 (MB) |
unity_metadata.graphics_device_id | INT64 | 圖形設備的識別符 |
unity_metadata.graphics_device_vendor_id | INT64 | 圖形處理器供應商的識別符 |
unity_metadata.graphics_device_name | 細繩 | 圖形設備的名稱 |
unity_metadata.graphics_device_vendor | 細繩 | 圖形設備的供應商 |
unity_metadata.graphics_device_version | 細繩 | 圖形設備的版本 |
unity_metadata.graphics_device_type | 細繩 | 圖形設備的類型 |
unity_metadata.graphics_shader_level | INT64 | 圖形的著色器級別 |
unity_metadata.graphics_render_target_count | INT64 | 圖形渲染目標的數量 |
unity_metadata.graphics_copy_texture_support | 細繩 | 支援複製Unity API中定義的圖形紋理 |
unity_metadata.graphics_max_texture_size | INT64 | 專用於渲染紋理的最大尺寸 |
unity_metadata.screen_size_px | 細繩 | 螢幕大小(以像素為單位),格式為寬度 x 高度 |
unity_metadata.screen_resolution_dpi | 細繩 | 螢幕的 DPI(浮點數) |
unity_metadata.screen_refresh_rate_hz | INT64 | 螢幕更新率(以 Hz 為單位) |
使用 Data Studio 視覺化導出的 Crashlytics 數據
Google Data Studio將 BigQuery 中的 Crashlytics 資料集轉換為易於閱讀、易於共享且完全可自訂的報告。
要了解有關使用 Data Studio 的更多信息,請嘗試 Data Studio 快速入門指南歡迎使用 Data Studio 。
使用 Crashlytics 報告模板
Data Studio 有一個 Crashlytics 範例報告,其中包含匯出的 Crashlytics BigQuery 架構中的一組全面的維度和指標。如果您已啟用 Crashlytics BigQuery 串流匯出,則可以在 Data Studio 模板的即時趨勢頁面上查看該資料。您可以使用範例作為模板,根據您自己的應用程式的原始崩潰資料快速建立新的報表和視覺化效果:
- 開啟Crashlytics Data Studio 儀表板範本。
- 點選右上角的「使用模板」 。
- 在「新資料來源」下拉清單中,選擇「建立新資料來源」 。
- 點選BigQuery卡上的「選擇」 。
- 透過選擇My Projects > [your-project-name] > firebase_crashlytics > [your-table-name]選擇包含匯出的 Crashlytics 資料的表。您的批次表始終可供選擇;如果啟用了 Crashlytics BigQuery 串流匯出,您可以選擇即時表格。
- 在「配置」下,將「Crashlytics 模板層級」設定為「預設」 。
- 按一下「連接」以建立新的資料來源。
- 按一下「新增至報表」返回 Crashlytics 範本。
- 最後,按一下「建立報表」以建立 Crashlytics Data Studio 儀表板範本的副本。