ส่งออกข้อมูล Firebase Crashlytics ไปยัง BigQuery

คุณสามารถส่งออกข้อมูล Firebase Crashlytics ไปยัง BigQuery เพื่อ วิเคราะห์เพิ่มเติมได้ BigQuery ช่วยให้คุณวิเคราะห์ข้อมูลโดยใช้ BigQuery SQL ส่งออกไปยังผู้ให้บริการคลาวด์รายอื่น และใช้เพื่อ การแสดงภาพและแดชบอร์ดที่กำหนดเองด้วย Looker Studio

คุณทำอะไรกับข้อมูลที่ส่งออกได้บ้าง

การส่งออกไปยัง BigQuery จะมีข้อมูลข้อขัดข้องดิบ ซึ่งรวมถึงประเภทอุปกรณ์ ระบบปฏิบัติการ ข้อยกเว้น (แอป Android) หรือข้อผิดพลาด (แอป Apple) และ บันทึก Crashlytics รวมถึงข้อมูลอื่นๆ คุณสามารถตรวจสอบได้ว่า Crashlytics ข้อมูลใดบ้างที่ส่งออกและ สคีมาตารางของข้อมูลนั้นคืออะไรในส่วนท้ายของหน้านี้

ตัวอย่างสิ่งที่คุณทำได้ด้วยข้อมูล Crashlytics ที่ส่งออกมีดังนี้

• เรียกใช้การค้นหา
  คุณสามารถเรียกใช้การค้นหาในข้อมูล Crashlytics เพื่อสร้างรายงานที่ รวบรวมข้อมูลเหตุการณ์ข้อขัดข้องเป็นข้อมูลสรุปที่เข้าใจได้ง่ายขึ้น เนื่องจากรายงานประเภทเหล่านี้ไม่มีในแดชบอร์ดของคอนโซล CrashlyticsFirebase จึงสามารถช่วยเสริมการวิเคราะห์และความเข้าใจเกี่ยวกับข้อมูลข้อขัดข้อง ดูตัวอย่างคำค้นหาที่คัดสรรมาแล้วได้ที่ส่วนท้ายของหน้านี้

• ใช้Looker Studioเทมเพลต
  Crashlyticsมี Looker StudioเทมเพลตLooker Studioที่สร้างไว้ล่วงหน้า สําหรับการแสดงข้อมูลที่ส่งออกเป็นภาพ

• สร้างมุมมอง
  คุณสามารถสร้างมุมมองซึ่งเป็นตารางเสมือนจริง ที่กำหนดโดยการค้นหา SQL ได้โดยใช้ UI ของ BigQuery ดูวิธีการโดยละเอียดเกี่ยวกับข้อมูลพร็อพเพอร์ตี้ประเภทต่างๆ และวิธีสร้างได้ในBigQueryเอกสารประกอบ

• รวมข้อมูลเฉพาะของ Crashlytics กับข้อมูลเซสชัน Firebase
  คุณยังส่งออกข้อมูลเซสชัน Firebase ได้ด้วยเมื่อตั้งค่าการส่งออกข้อมูล Crashlytics ใช้ข้อมูลเซสชันนี้เพื่อทำความเข้าใจผู้ใช้ที่ไม่มีข้อขัดข้องและเซสชันที่ไม่มีข้อขัดข้องให้ดียิ่งขึ้น

ประโยชน์ของการส่งออกแบบสตรีมไปยัง BigQuery

โดยค่าเริ่มต้น ระบบจะส่งออกข้อมูลไปยัง BigQuery ในการส่งออกเป็นกลุ่มรายวัน นอกจากนี้ คุณยังสตรีมข้อมูล Crashlytics และเซสชัน Firebase แบบเรียลไทม์ได้ด้วยBigQuery สตรีมมิง คุณสามารถใช้สำหรับวัตถุประสงค์ใดก็ตามที่ต้องใช้ข้อมูลแบบเรียลไทม์ เช่น การนำเสนอ ข้อมูลในแดชบอร์ดแบบเรียลไทม์ การดูการเปิดตัวแบบเรียลไทม์ หรือการตรวจสอบ ปัญหาของแอปพลิเคชันที่ทริกเกอร์การแจ้งเตือนและเวิร์กโฟลว์ที่กำหนดเอง

เมื่อเปิดใช้การส่งออกแบบสตรีมไปยัง BigQuery คุณจะมีตารางแบบเรียลไทม์ (นอกเหนือจากตารางแบบกลุ่ม) ด้วย ตารางทั้ง 2 ประเภทจะมีสคีมาชุดข้อมูลเดียวกัน แต่ตารางแบบกลุ่มและตารางแบบเรียลไทม์มีความแตกต่างที่สำคัญดังนี้

ตารางกลุ่มเหมาะสําหรับการวิเคราะห์ระยะยาวและการระบุแนวโน้มเมื่อเวลาผ่านไป เนื่องจากเราจัดเก็บเหตุการณ์อย่างถาวรก่อนที่จะเขียน และสามารถป้อนข้อมูลย้อนหลัง ลงในตารางได้นานสูงสุด 30 วัน* เมื่อเขียนข้อมูลลงในตารางแบบเรียลไทม์ เราจะเขียนข้อมูลลงใน BigQuery ทันที จึงเหมาะสําหรับแดชบอร์ดแบบเรียลไทม์และการแจ้งเตือนที่กําหนดเอง ตารางทั้ง 2 ตารางนี้สามารถ รวมเข้ากับการค้นหาการเย็บเพื่อรับ ประโยชน์จากทั้ง 2 ตาราง

โดยค่าเริ่มต้น ตารางแบบเรียลไทม์จะมีเวลาหมดอายุของพาร์ติชันเป็น 30 วัน หากต้องการ ดูวิธีแก้ไข ให้ไปที่ ตั้งค่าการหมดอายุของพาร์ติชัน ในเอกสารประกอบของ BigQuery

^{* ดูรายละเอียดเกี่ยวกับการรองรับการแสดงโฆษณาสำรองได้ใน อัปเกรดเป็นโครงสร้างพื้นฐานการส่งออกใหม่}

เปิดใช้การส่งออกไปยัง BigQuery

1. ในFirebaseคอนโซล ให้ไปที่ หน้าการผสานรวม

2. คลิกลิงก์ในการ์ด BigQuery

3. ทำตามวิธีการบนหน้าจอเพื่อเปิดใช้การส่งออกไปยัง BigQuery รวมถึงตัวเลือกต่อไปนี้

   • หากต้องการทําความเข้าใจผู้ใช้และเซสชันที่ไม่มีข้อขัดข้องให้ดียิ่งขึ้น เปิดใช้การส่งออกข้อมูลเซสชัน Firebase

   • หากต้องการเข้าถึงข้อมูล Crashlytics และข้อมูลเซสชัน Firebase ใน BigQuery แบบเรียลไทม์เกือบทั้งหมด ให้เปิดใช้การส่งออกสตรีมมิง

จะเกิดอะไรขึ้นเมื่อคุณเปิดใช้การส่งออก

• Firebase จะส่งออกข้อมูลจากแอปที่ลิงก์กับ BigQuery

  • ในระหว่างการตั้งค่า ระบบจะลิงก์แอปทั้งหมดในโปรเจ็กต์กับBigQueryโดยค่าเริ่มต้น แต่คุณเลือกไม่ลิงก์แอปที่เฉพาะเจาะจงในระหว่างการตั้งค่าได้

  • แอปใดก็ตามที่คุณเพิ่มลงในโปรเจ็กต์ Firebase ในภายหลังจะลิงก์กับ BigQuery โดยอัตโนมัติ

  • คุณสามารถจัดการแอปที่ส่งออกข้อมูลได้ทุกเมื่อ

• Firebase จะส่งออกข้อมูลไปยังตำแหน่งชุดข้อมูลที่คุณเลือกในระหว่างการตั้งค่า

  • ตําแหน่งนี้มีผลกับทั้งชุดข้อมูล Crashlytics และชุดข้อมูลเซสชัน Firebase (หากเปิดใช้การส่งออกข้อมูลเซสชัน)

  • ตำแหน่งนี้ใช้ได้กับข้อมูลที่ส่งออกไปยัง BigQuery เท่านั้น และจะไม่ส่งผลต่อตำแหน่งของข้อมูลที่จัดเก็บไว้สำหรับ ใช้ในแดชบอร์ด Crashlytics ของคอนโซล Firebase หรือใน Android Studio

  • หลังจากสร้างชุดข้อมูลแล้ว คุณจะเปลี่ยนแปลงตำแหน่งไม่ได้ แต่จะคัดลอกชุดข้อมูลไปยังตำแหน่งอื่นหรือย้าย (สร้างใหม่) ชุดข้อมูลไปยังตำแหน่งอื่นด้วยตนเองได้ ดูข้อมูลเพิ่มเติมได้ที่ เปลี่ยนตำแหน่งสำหรับการส่งออกที่มีอยู่

• Firebase จะตั้งค่าการซิงค์ข้อมูลแบบกลุ่มกับ BigQuery ทุกวัน

  • หลังจากลิงก์กับ BigQuery แล้ว ระบบอาจใช้เวลาสูงสุด 48 ชั่วโมงในการส่งออกข้อมูลกลุ่มเริ่มต้น

  • การซิงค์รายวันจะเกิดขึ้นวันละครั้ง ไม่ว่าคุณจะตั้งค่าการส่งออกที่กำหนดเวลาไว้ใน BigQuery หรือไม่ก็ตาม โปรดทราบว่าเวลาและระยะเวลาของงานซิงค์อาจเปลี่ยนแปลงได้ ดังนั้นเราจึงไม่แนะนำให้กำหนดเวลาการดำเนินการหรือการทำงานขั้นปลายตามเวลาที่เฉพาะเจาะจงของการส่งออก

• Firebase ส่งออกสำเนาข้อมูลที่มีอยู่ ไปยัง BigQuery

  • สําหรับแอปที่ลิงก์แต่ละแอป การส่งออกนี้จะมีตารางกลุ่มที่มีข้อมูล จากการซิงค์รายวัน

  • คุณสามารถกำหนดเวลาการป้อนข้อมูลย้อนหลังด้วยตนเอง สำหรับตารางกลุ่มได้สูงสุด 30 วันที่ผ่านมา หรือสำหรับวันที่ล่าสุด เมื่อเปิดใช้การส่งออกไปยัง BigQuery (วันที่ล่าสุด)

  โปรดทราบว่าหากเปิดใช้การส่งออกข้อมูล Crashlytics ก่อน กลางเดือนตุลาคม 2024 คุณจะกรอกข้อมูลย้อนหลังได้ 30 วันก่อนวันที่เปิดใช้ การส่งออกด้วย

• สิ่งต่อไปนี้จะมีผลหากคุณ เปิดใช้การส่งออกแบบสตรีมไปยัง BigQuery

  • นอกจากนี้ แอปที่ลิงก์แต่ละแอปจะมีตารางแบบเรียลไทม์ของตัวเองซึ่งมีข้อมูลที่อัปเดตอยู่ตลอดเวลา (นอกเหนือจากตารางกลุ่มของแอปสำหรับการส่งออกกลุ่มรายวัน)

  • หลังจากเปิดใช้การสตรีมแล้ว ระบบอาจใช้เวลาสูงสุด 1 ชั่วโมงก่อนที่ข้อมูลจะเริ่ม สตรีม

  หากไม่เห็นข้อมูลในตารางแบบเรียลไทม์

  1. ตรวจสอบว่าคุณได้ส่งเหตุการณ์อย่างน้อย 2 รายการจากแอปไปยัง Crashlytics และรอ 2-3 นาทีหลังจากส่ง

  2. ตรวจสอบว่าโปรเจ็กต์ Firebase ของคุณใช้แพ็กเกจราคา Blaze แบบจ่ายเมื่อใช้
     คุณตรวจสอบได้โดยดูที่มุมซ้ายล่างของFirebaseคอนโซล

  3. หากยังไม่มีข้อมูลในตารางแบบเรียลไทม์หลังจากส่งเหตุการณ์ 2 รายการและ รอ 2-3 นาที ให้ทำดังนี้

     1. ไปที่การ์ด BigQuery ในคอนโซล Firebase

     2. ปิดใช้แล้วเปิดใช้การส่งออกสตรีมมิงอีกครั้ง

     3. ตรวจสอบว่าบัญชีบริการ service-PROJECT_NUMBER@gcp-sa-crashlytics.iam.gserviceaccount.com อยู่ในโปรเจ็กต์ Firebase และมีบทบาทตัวแทนบริการ Firebase Crashlytics
        คุณสามารถตรวจสอบได้ในหน้า IAM ของ Google Cloud คอนโซล (อย่าลืมเลือกช่องทำเครื่องหมายสำหรับ รวมการมอบบทบาทที่ Google มีให้)

     4. ส่งเหตุการณ์อย่างน้อย 2 รายการไปยัง Crashlytics แล้วรอสักครู่

  4. หากยังไม่เห็นข้อมูลในตารางเรียลไทม์ โปรด ติดต่อทีมสนับสนุนของ Firebase

ตัวอย่างคำถาม

ตัวอย่างที่ 1: คำนวณเมตริกที่ไม่มีข้อขัดข้องโดยใช้ข้อมูลเซสชัน Firebase

ในเวอร์ชันล่าสุด คุณได้เปิดตัวการปรับปรุงแอปครั้งใหญ่เพื่อแก้ไขปัญหา การขัดข้องในเส้นทางของผู้ใช้ที่สําคัญ คุณได้รับรีวิวที่ยอดเยี่ยมจากผู้ใช้ แต่ต้องการหลักฐานเชิงปริมาณที่แสดงว่าแอปของคุณมีเสถียรภาพมากขึ้นกว่าเดิม

เมตริกแบบไม่มีข้อขัดข้องจะช่วยให้ข้อมูลนี้ได้ เมตริกเหล่านี้เป็นตัวชี้วัดที่สำคัญซึ่งช่วยให้คุณเข้าใจ สุขภาพโดยรวมของแอป ด้วยข้อมูลเซสชัน Firebase และ Crashlytics เหตุการณ์ คุณสามารถคํานวณเมตริกเหล่านี้ได้ด้วยการค้นหาพื้นฐาน

ต่อไปนี้คือตัวอย่างการค้นหาสำหรับแอป Android สำหรับแอป iOS ให้ใช้รหัสชุด และ 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(_PARTITIONTIME,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.event_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(_PARTITIONTIME,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 ให้ใช้รหัสชุด และ 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 ให้ใช้รหัสชุด และ 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 คุณได้สร้างคำค้นหาที่ระบุอุปกรณ์ 10 เครื่องที่เกิดข้อขัดข้องมากที่สุดในช่วงสัปดาห์ที่ผ่านมา (168 ชั่วโมง) เพื่อเตรียมรับมือกับความกังวลเรื่องความเข้ากันได้ที่กำลังจะเกิดขึ้น

นี่คือตัวอย่างคำค้นหาสำหรับแอป Android สำหรับแอป iOS ให้ใช้รหัสชุด และ 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: กรองตามคีย์ที่กำหนดเอง

คุณเป็นนักพัฒนาเกมที่ต้องการทราบว่าเกมระดับใดที่เกิดข้อขัดข้องมากที่สุด

คุณตั้งค่าคีย์Crashlyticsที่กำหนดเองชื่อ current_level เพื่อช่วยติดตามสถิติดังกล่าว และอัปเดตทุกครั้งที่ผู้ใช้เลื่อนระดับใหม่

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

CrashlyticsKit setIntValue:3 forKey:@"current_level";

Crashlytics.setInt("current_level", 3);

เมื่อมีคีย์ดังกล่าวในการส่งออกไปยัง BigQuery คุณจะเขียนการค้นหาเพื่อ รายงานการกระจายค่า current_level ที่เชื่อมโยงกับเหตุการณ์ ข้อขัดข้องแต่ละรายการได้

นี่คือตัวอย่างคำค้นหาสำหรับแอป Android สำหรับแอป iOS ให้ใช้รหัสชุด และ 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: การแยก User-ID

คุณมีแอป Android ในเวอร์ชันทดลองใช้ก่อนเปิดตัว ผู้ใช้ส่วนใหญ่ชื่นชอบแอปของคุณ แต่มีผู้ใช้ 3 รายที่พบการขัดข้องมากกว่าปกติ หากต้องการเจาะลึกถึงสาเหตุของปัญหา คุณต้องเขียนคําค้นหาที่ดึงเหตุการณ์ข้อขัดข้องทั้งหมดสําหรับผู้ใช้เหล่านั้นโดยใช้รหัสผู้ใช้

นี่คือตัวอย่างคำค้นหาสำหรับแอป Android สำหรับแอป iOS ให้ใช้รหัสชุด และ 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: ค้นหาผู้ใช้ทั้งหมดที่พบปัญหาข้อขัดข้องหนึ่งๆ

ทีมของคุณเผยแพร่ข้อบกพร่องร้ายแรงไปยังกลุ่มผู้ทดสอบเวอร์ชันเบต้าโดยไม่ตั้งใจ ทีมของคุณใช้คำค้นหาจากตัวอย่าง"ค้นหาข้อขัดข้องที่เกิดขึ้นบ่อยที่สุด" ด้านบนเพื่อระบุรหัสปัญหาข้อขัดข้องที่เฉพาะเจาะจงได้ ตอนนี้ทีมของคุณต้องการเรียกใช้คำค้นหาเพื่อดึงรายชื่อผู้ใช้แอปที่ได้รับผลกระทบจากข้อขัดข้องนี้

นี่คือตัวอย่างคำค้นหาสำหรับแอป Android สำหรับแอป iOS ให้ใช้รหัสชุด และ 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: จำนวนผู้ใช้ที่ได้รับผลกระทบจากปัญหาการขัดข้อง แยกตามประเทศ

ทีมของคุณตรวจพบข้อบกพร่องร้ายแรงระหว่างการเปิดตัวรุ่นใหม่ คุณใช้คำค้นหาจากตัวอย่าง"ค้นหาข้อขัดข้องที่เกิดขึ้นบ่อยที่สุด" ด้านบนเพื่อระบุรหัสปัญหาข้อขัดข้องที่เฉพาะเจาะจงได้ ตอนนี้ทีมของคุณต้องการทราบว่าข้อขัดข้องนี้แพร่กระจายไปยังผู้ใช้ในประเทศต่างๆ ทั่วโลกหรือไม่

หากต้องการเขียนคําค้นหานี้ ทีมของคุณจะต้องทําสิ่งต่อไปนี้

1. เปิดใช้การส่งออกข้อมูล Google Analytics ไปยัง BigQuery ดูส่งออกข้อมูลโปรเจ็กต์ไปยัง BigQuery

2. อัปเดตแอปเพื่อส่งรหัสผู้ใช้ไปยังทั้ง 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. เขียนคําค้นหาที่ใช้ฟิลด์รหัสผู้ใช้เพื่อรวมเหตุการณ์ในชุดข้อมูล Google Analytics กับข้อขัดข้องในชุดข้อมูล Crashlytics

   นี่คือตัวอย่างการค้นหาสำหรับแอป Android สำหรับแอป iOS ให้ใช้รหัสชุดและ 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 ให้ใช้รหัสชุด และ 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 อันดับแรกตั้งแต่วันที่ DATE รวมถึงวันนี้

นอกจากนี้ คุณยังรวมตารางแบบกลุ่มและแบบเรียลไทม์เข้ากับคําค้นหาการเย็บเพื่อเพิ่ม ข้อมูลแบบเรียลไทม์ลงในข้อมูลแบบกลุ่มที่เชื่อถือได้ เนื่องจาก event_id เป็นคีย์หลัก คุณจึงใช้ DISTINCT event_id เพื่อขจัดข้อมูลที่ซ้ำกันของกิจกรรมทั่วไปจากตารางทั้ง 2 ตารางได้

นี่คือตัวอย่างคำค้นหาสำหรับแอป Android สำหรับแอป iOS ให้ใช้รหัสชุด และ 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;

แสดงข้อมูล Crashlytics ที่ส่งออกด้วย Looker Studio

Looker Studio เปลี่ยนCrashlyticsชุดข้อมูลใน BigQuery เป็นรายงานที่ อ่านง่ายขึ้น แชร์ง่ายขึ้น และปรับแต่งได้อย่างเต็มที่

ดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้ Looker Studio ได้ที่คู่มือต้อนรับ

ใช้เทมเพลตรายงาน Crashlytics

Looker Studio มีรายงานตัวอย่างสําหรับ Crashlytics ซึ่งมีชุดมิติข้อมูลและเมตริกที่ครอบคลุมจากสคีมา Crashlytics BigQuery ที่ส่งออก หากเปิดใช้Crashlyticsการส่งออกแบบสตรีม ไปยัง BigQuery คุณจะดูข้อมูลดังกล่าวได้ในหน้าเทรนด์แบบเรียลไทม์ ของเทมเพลต Looker Studio คุณสามารถใช้ตัวอย่างเป็นเทมเพลต เพื่อสร้างรายงานและการแสดงภาพใหม่ๆ ได้อย่างรวดเร็วโดยอิงตามข้อมูลข้อขัดข้อง ดิบของแอปคุณเอง

1. เปิด Crashlytics Looker Studio เทมเพลตแดชบอร์ด

2. คลิกใช้เทมเพลตที่มุมขวาบน

3. ในเมนูแบบเลื่อนลงแหล่งข้อมูลใหม่ ให้เลือกสร้างแหล่งข้อมูลใหม่

4. คลิกเลือกในการ์ด BigQuery

5. เลือกตารางที่มีข้อมูล Crashlytics ที่ส่งออกโดยเลือกโปรเจ็กต์ของฉัน > PROJECT_ID > firebase_crashlytics > TABLE_NAME

   คุณเลือกตารางกลุ่มได้เสมอ หากเปิดใช้ Crashlyticsการส่งออกแบบสตรีมไปยัง BigQuery คุณจะ เลือกตารางแบบเรียลไทม์แทนได้

6. ในส่วนการกำหนดค่า ให้ตั้งค่าCrashlytics ระดับเทมเพลตเป็น ค่าเริ่มต้น

7. คลิกเชื่อมต่อเพื่อสร้างแหล่งข้อมูลใหม่

8. คลิกเพิ่มลงในรายงานเพื่อกลับไปที่เทมเพลต Crashlytics

9. สุดท้าย ให้คลิกสร้างรายงานเพื่อสร้างสำเนาของเทมเพลตแดชบอร์ด Crashlytics Looker Studio

ทำความเข้าใจสคีมาใน BigQuery

Firebase จะสร้างชุดข้อมูลใหม่ใน BigQuery สำหรับข้อมูลที่ส่งออก ดังนี้

• Crashlytics ชุดข้อมูล

• ชุดข้อมูลเซสชัน Firebase (หากเปิดใช้การส่งออกข้อมูลเซสชัน)

ชุดข้อมูล Crashlytics

ระบบจะส่งออกข้อมูล Crashlytics ไปยังชุดข้อมูล BigQuery ชื่อ firebase_crashlytics ชุดข้อมูลครอบคลุมทั้งโปรเจ็กต์ แม้ว่าจะมีแอปหลายแอปก็ตาม

ตาราง

โดยค่าเริ่มต้น Firebase จะสร้างตารางแต่ละรายการภายในCrashlytics ชุดข้อมูลสําหรับแต่ละแอปในโปรเจ็กต์ที่ลิงก์กับ BigQuery

ตารางจะมีชื่อตามตัวระบุของแอป (โดยแปลงจุดเป็นขีดล่าง) และต่อท้ายด้วยแพลตฟอร์มของแอป (_IOS หรือ _ANDROID) เช่น ข้อมูลสำหรับแอป Android ที่มีชื่อแพ็กเกจ com.google.test จะอยู่ในตารางชื่อ com_google_test_ANDROID

• หากเปิดใช้การส่งออกสตรีมมิงไปยัง BigQuery ระบบจะสตรีมข้อมูลแบบเรียลไทม์ไปยังตารางที่ต่อท้ายด้วย _REALTIME (เช่น com_google_test_ANDROID_REALTIME) ด้วย

• แต่ละแถวในตารางแสดงถึงเหตุการณ์ที่เกิดขึ้นในแอป ซึ่งรวมถึง การขัดข้อง ข้อผิดพลาดที่ไม่ร้ายแรง และ ANR

• ตารางจะมีชุดCrashlyticsข้อมูลมาตรฐานนอกเหนือจากคีย์Crashlyticsที่กำหนดเอง ที่คุณกำหนดไว้ในแอป

แถว

แต่ละแถวในตารางแสดงข้อผิดพลาดที่แอปพบ

คอลัมน์

คอลัมน์ในตารางจะเหมือนกันสำหรับข้อขัดข้อง ข้อผิดพลาดที่ไม่ร้ายแรง และ ANR

• หากเปิดใช้การส่งออกแบบสตรีมไปยัง BigQuery ตารางเรียลไทม์ จะมีคอลัมน์เหมือนกับตารางแบบกลุ่ม

• คุณอาจมีคอลัมน์ในแถวที่แสดงถึงเหตุการณ์ที่ไม่มี Stack Trace

ต่อไปนี้คือคอลัมน์ในตารางสำหรับข้อมูล Crashlytics ที่ส่งออก

ชุดข้อมูลเซสชัน Firebase

ระบบจะส่งออกข้อมูลเซสชัน Firebase ไปยังBigQuery ชุดข้อมูลชื่อ firebase_sessions ชุดข้อมูลครอบคลุมทั้งโปรเจ็กต์ แม้ว่าจะมีแอปหลายแอปก็ตาม

ตาราง

โดยค่าเริ่มต้น Firebase จะสร้างตารางแต่ละรายการภายในชุดข้อมูลเซสชัน Firebase สำหรับแต่ละแอปในโปรเจ็กต์ที่ลิงก์กับ BigQuery

ตารางจะมีชื่อตามตัวระบุของแอป (โดยแปลงจุดเป็นขีดล่าง) และต่อท้ายด้วยแพลตฟอร์มของแอป (_IOS หรือ _ANDROID) เช่น ข้อมูลสำหรับแอป Android ที่มีชื่อแพ็กเกจ com.google.test จะอยู่ในตารางชื่อ com_google_test_ANDROID

แถว

แต่ละแถวในตารางแสดงถึงเหตุการณ์เซสชันที่เกิดขึ้น

คอลัมน์

หากเปิดใช้การส่งออกแบบสตรีมไปยัง BigQuery ตารางเรียลไทม์ จะมีคอลัมน์เหมือนกับตารางแบบกลุ่ม

ต่อไปนี้คือคอลัมน์ภายในตารางสำหรับข้อมูลเซสชัน Firebase ที่ส่งออก

อัปเกรดเป็นโครงสร้างพื้นฐานการส่งออกใหม่

ในช่วงกลางเดือนตุลาคม 2024 Crashlytics ได้เปิดตัวโครงสร้างพื้นฐานใหม่สำหรับการส่งออกเป็นกลุ่ม ของข้อมูล Crashlytics ไปยัง BigQuery

ระบบจะอัปเกรดโปรเจ็กต์ Firebase ทั้งหมดเป็นโครงสร้างพื้นฐานการส่งออกแบบกลุ่มใหม่โดยอัตโนมัติภายในวันที่ 15 กันยายน 2025 คุณอัปเกรดก่อนวันที่นี้ได้ แต่โปรดตรวจสอบว่าตารางกลุ่ม BigQuery เป็นไปตามข้อกำหนดเบื้องต้นสำหรับการอัปเกรด

คุณอัปเกรดเป็นโครงสร้างพื้นฐานใหม่ได้ แต่โปรดตรวจสอบว่าตารางกลุ่ม BigQuery เป็นไปตามข้อกำหนดเบื้องต้นสำหรับการอัปเกรด

ตรวจสอบว่าคุณใช้โครงสร้างพื้นฐานใหม่หรือไม่

หากคุณเปิดใช้การส่งออกเป็นกลุ่มในช่วงกลางเดือนตุลาคม 2024 หรือหลังจากนั้น โปรเจ็กต์ Firebase จะใช้โครงสร้างพื้นฐานการส่งออกใหม่โดยอัตโนมัติ

คุณสามารถตรวจสอบโครงสร้างพื้นฐานที่โปรเจ็กต์ใช้ได้โดยทำดังนี้ ไปที่Google Cloud คอนโซล และหาก"การกำหนดค่าการโอนข้อมูล" มีป้ายกำกับเป็น Firebase Crashlytics with Multi-Region Support แสดงว่าโปรเจ็กต์ใช้โครงสร้างพื้นฐานการส่งออกใหม่

ความแตกต่างที่สำคัญระหว่างโครงสร้างพื้นฐานการส่งออกแบบเก่ากับโครงสร้างพื้นฐานการส่งออกแบบใหม่

• โครงสร้างพื้นฐานใหม่รองรับCrashlyticsตำแหน่งชุดข้อมูลนอก สหรัฐอเมริกา

  • เปิดใช้การส่งออกก่อนช่วงกลางเดือนตุลาคม 2024 และอัปเกรดเป็นโครงสร้างพื้นฐานการส่งออกใหม่ - ตอนนี้คุณเปลี่ยนตำแหน่งสำหรับการส่งออกข้อมูลได้แล้ว (ไม่บังคับ)

  • เปิดใช้การส่งออกในช่วงกลางเดือนตุลาคม 2024 หรือหลังจากนั้น - ระบบแจ้งให้คุณเลือกตำแหน่งสำหรับการส่งออกข้อมูลในระหว่างการตั้งค่า

• โครงสร้างพื้นฐานใหม่ไม่รองรับการเติมข้อมูลย้อนหลังก่อนที่คุณเปิดใช้การส่งออก

  • โครงสร้างพื้นฐานเดิมรองรับการเติมเต็มย้อนหลังได้สูงสุด 30 วันก่อนวันที่คุณเปิดใช้การส่งออก

  • โครงสร้างพื้นฐานใหม่รองรับการเติมเต็ม ย้อนหลังได้สูงสุด 30 วัน หรือวันที่ล่าสุดเมื่อคุณเปิดใช้การส่งออก ไปยัง BigQuery (แล้วแต่ว่าวันที่ใดจะล่าสุด)

• ชื่อโครงสร้างพื้นฐานใหม่BigQueryใช้ตารางกลุ่มโดยใช้ ตัวระบุที่ตั้งค่าไว้สำหรับแอป Firebase ในโปรเจ็กต์ Firebase

  • โครงสร้างพื้นฐานเดิมจะเขียนข้อมูลลงในตารางกลุ่มที่มีชื่อตามรหัสแพ็กเกจหรือชื่อแพ็กเกจในไบนารีของแอป

  • โครงสร้างพื้นฐานใหม่จะเขียนข้อมูลลงในตารางกลุ่มที่มีชื่อตาม รหัสแพ็กเกจหรือชื่อแพ็กเกจ ที่ตั้งค่าไว้สำหรับแอป Firebase ที่ลงทะเบียนในโปรเจ็กต์ Firebase

ขั้นตอนที่ 1: ข้อกำหนดเบื้องต้นสำหรับการอัปเกรด

1. ตรวจสอบว่าตารางกลุ่มBigQueryที่มีอยู่ใช้ตัวระบุที่ตรงกับรหัส Bundle หรือชื่อแพ็กเกจ ที่ตั้งค่าไว้สำหรับแอป Firebase ที่ลงทะเบียนในโปรเจ็กต์ Firebase หากไม่ตรงกัน คุณอาจพบปัญหาในการหยุดชะงักของข้อมูลกลุ่มที่ส่งออก โปรเจ็กต์ส่วนใหญ่จะอยู่ในสถานะที่เหมาะสมและเข้ากันได้ แต่คุณควรตรวจสอบก่อนอัปเกรด

   • คุณดูแอป Firebase ทั้งหมดที่ลงทะเบียนในโปรเจ็กต์ Firebase ได้ใน Firebase คอนโซล: ไปที่settings การตั้งค่าโปรเจ็กต์ จากนั้นเลื่อนไปที่การ์ดแอปของคุณเพื่อดูแอป Firebase ทั้งหมดและ ข้อมูลของแอป

   • คุณจะเห็นตารางกลุ่ม BigQuery ทั้งหมดใน BigQuery หน้า ของคอนโซล Google Cloud

   ตัวอย่างเช่น สถานะที่เหมาะสมซึ่งคุณจะไม่มีปัญหาในการอัปเกรดมีดังนี้

   • คุณมีตารางกลุ่มชื่อ com_yourcompany_yourproject_IOS และแอป Firebase iOS+ ที่มี Bundle ID com.yourcompany.yourproject ซึ่งลงทะเบียนไว้ในโปรเจ็กต์ Firebase

   • คุณมีตารางกลุ่มชื่อ com_yourcompany_yourproject_ANDROID และ แอป Firebase บน Android ที่มีชื่อแพ็กเกจ com.yourcompany.yourproject ซึ่งลงทะเบียนในโปรเจ็กต์ Firebase

2. หากคุณมีชื่อตารางกลุ่มที่ไม่ตรงกับ ตัวระบุที่ตั้งค่าไว้สำหรับแอป Firebase ที่ลงทะเบียน ให้ทำตามวิธีการ ในหน้านี้ในภายหลังก่อนที่จะอัปเกรดด้วยตนเองหรือ ก่อนวันที่ 15 กันยายน 2025 เพื่อไม่ให้การส่งออกกลุ่มหยุดชะงัก

ขั้นตอนที่ 2: อัปเกรดเป็นโครงสร้างพื้นฐานใหม่ด้วยตนเอง

หากเปิดใช้การส่งออกเป็นกลุ่มก่อนช่วงกลางเดือนตุลาคม 2024 คุณจะอัปเกรดเป็นโครงสร้างพื้นฐานใหม่ได้ด้วยตนเอง เพียงแค่สลับCrashlyticsการส่งออกข้อมูล เป็นปิดแล้วเปิดอีกครั้งในคอนโซล Firebase

ขั้นตอนโดยละเอียดมีดังนี้

1. ในFirebaseคอนโซล ให้ไปที่ หน้าการผสานรวม

2. คลิกจัดการในการ์ด BigQuery

3. สลับแถบเลื่อน Crashlytics เป็นปิดเพื่อปิดใช้การส่งออก เมื่อได้รับข้อความแจ้ง ให้ยืนยันว่าคุณต้องการหยุดการส่งออกข้อมูล

4. สลับCrashlyticsแถบเลื่อนเป็นเปิดอีกครั้งทันทีเพื่อเปิดใช้การส่งออกอีกครั้ง เมื่อได้รับข้อความแจ้ง ให้ยืนยันว่าต้องการส่งออกข้อมูล

   ตอนนี้การส่งออกข้อมูล Crashlytics ไปยัง BigQuery ใช้โครงสร้างพื้นฐานการส่งออกใหม่แล้ว

ชื่อตารางกลุ่มที่มีอยู่ไม่ตรงกับตัวระบุแอป Firebase