วิธีใช้ชุดข้อมูล CrUX BigQuery

Rick Viscomi

ข้อมูลดิบของรายงาน Chrome UX (CrUX) มีอยู่ใน BigQuery ซึ่งเป็นฐานข้อมูลใน Google Cloud การใช้ BigQuery จำเป็นต้องมีโปรเจ็กต์ GCP และความรู้พื้นฐานเกี่ยวกับ SQL

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

• ทำความเข้าใจวิธีจัดระเบียบข้อมูล
• เขียนการค้นหาพื้นฐานเพื่อประเมินประสิทธิภาพของต้นทาง
• เขียนการค้นหาขั้นสูงเพื่อติดตามประสิทธิภาพเมื่อเวลาผ่านไป

การจัดระเบียบข้อมูล

เริ่มต้นด้วยการดูที่คำค้นหาพื้นฐาน

SELECT COUNT(DISTINCT origin) FROM `chrome-ux-report.all.202206`

หากต้องการเรียกใช้การสืบค้นข้อมูล ให้ป้อนลงในตัวแก้ไขการค้นหาและกดปุ่ม "เรียกใช้การสืบค้นข้อมูล"

คำค้นหานี้มี 2 ส่วน ดังนี้

• SELECT COUNT(DISTINCT origin) หมายถึงการค้นหาจำนวนต้นทางในตาราง โดยทั่วไปแล้ว URL 2 รายการเป็นส่วนหนึ่งของต้นทางเดียวกันหากมีรูปแบบ โฮสต์ และพอร์ตเหมือนกัน

• FROM chrome-ux-report.all.202206 ระบุที่อยู่ของตารางต้นทาง ซึ่งมี 3 ส่วนดังนี้

  • ชื่อโปรเจ็กต์ Cloud chrome-ux-report ซึ่งมีการจัดระเบียบข้อมูล CrUX ทั้งหมด
  • ชุดข้อมูล all ซึ่งแสดงข้อมูลในทุกประเทศ
  • ตาราง 202206 ปีและเดือนของข้อมูลในรูปแบบ YYYYMM

นอกจากนี้ยังมีชุดข้อมูลสำหรับทุกประเทศด้วย ตัวอย่างเช่น chrome-ux-report.country_ca.202206 แสดงเฉพาะข้อมูลประสบการณ์ของผู้ใช้ที่มาจากแคนาดาเท่านั้น

ภายในชุดข้อมูลแต่ละชุดจะมีตารางสำหรับทุกเดือนตั้งแต่ปี 201710 ระบบจะเผยแพร่ตารางใหม่สำหรับเดือนก่อนหน้าตามปฏิทินเป็นประจำ

โครงสร้างของตารางข้อมูล (หรือที่เรียกว่าสคีมา) มีดังนี้

• ต้นทาง เช่น origin = 'https://www.example.com' ซึ่งแสดงถึงการกระจายประสบการณ์ของผู้ใช้แบบรวมสําหรับทุกหน้าในเว็บไซต์นั้น
• ความเร็วในการเชื่อมต่อเมื่อโหลดหน้าเว็บ เช่น effective_connection_type.name = '4G'
• ประเภทอุปกรณ์ เช่น form_factor.name = 'desktop'
• ตัวเมตริก UX
  • first_paint (FP)
  • first_contentful_paint (FCP)
  • dom_content_โหลด (DCL)
  • ขณะโหลด (OL)
  • Experiment.first_input_delay (FID)

ข้อมูลสำหรับแต่ละเมตริกจะได้รับการจัดระเบียบเป็นอาร์เรย์ของออบเจ็กต์ ในรูปแบบ JSON ส่วน first_contentful_paint.histogram.bin จะมีลักษณะคล้ายกับด้านล่างนี้

[
    {"start": 0, "end": 100, "density": 0.1234},
    {"start": 100, "end": 200, "density": 0.0123},
    ...
]

โดยแต่ละ Bin จะมีเวลาเริ่มต้นและเวลาสิ้นสุดเป็นมิลลิวินาที และความหนาแน่นที่แสดงถึงเปอร์เซ็นต์ของประสบการณ์ของผู้ใช้ภายในช่วงเวลานั้น กล่าวคือ 12.34% ของประสบการณ์ FCP สำหรับต้นทางสมมติ ความเร็วในการเชื่อมต่อ และประเภทอุปกรณ์นี้มีระยะเวลาน้อยกว่า 100 มิลลิวินาที ผลรวมของความหนาแน่นของถังขยะทั้งหมดคือ 100%

เรียกดูโครงสร้างของตารางใน BigQuery

ประเมินประสิทธิภาพ

เราสามารถใช้ความรู้ของเราเกี่ยวกับสคีมาตารางเพื่อเขียนข้อความค้นหาที่แยกข้อมูลประสิทธิภาพนี้

SELECT
  fcp
FROM
  `chrome-ux-report.all.202206`,
  UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
  origin = 'https://web.dev' AND
  effective_connection_type.name = '4G' AND
  form_factor.name = 'phone' AND
  fcp.start = 0

ผลลัพธ์ที่ได้คือ 0.01115 ซึ่งหมายความว่าประสบการณ์ของผู้ใช้ 1.115% ในต้นทางนี้อยู่ระหว่าง 0 ถึง 100 มิลลิวินาทีเมื่อใช้ 4G และบนโทรศัพท์ หากต้องการทำให้คำค้นหาเป็นแบบทั่วไปกับการเชื่อมต่อและอุปกรณ์ทุกประเภท เราสามารถละเว้นคำถามเหล่านั้นในอนุประโยค WHERE และใช้ฟังก์ชันตัวรวบรวมข้อมูล SUM เพื่อเพิ่มความหนาแน่นของถังขยะที่เกี่ยวข้องทั้งหมดได้ ดังนี้

SELECT
  SUM(fcp.density)
FROM
  `chrome-ux-report.all.202206`,
  UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
  origin = 'https://web.dev' AND
  fcp.start = 0

ผลลัพธ์ที่ได้คือ 0.05355 หรือ 5.355% ในอุปกรณ์และการเชื่อมต่อทุกประเภท เราสามารถแก้ไขการค้นหาเล็กน้อยและเพิ่มความหนาแน่นสำหรับถังขยะทั้งหมดที่อยู่ในช่วง FCP แบบ "เร็ว" ที่ 0–1,000 มิลลิวินาที

SELECT
  SUM(fcp.density) AS fast_fcp
FROM
  `chrome-ux-report.all.202206`,
  UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
  origin = 'https://web.dev' AND
  fcp.start < 1000

การดำเนินการนี้จะทำให้เรา 0.6977 กล่าวคือ 69.77% ของประสบการณ์ของผู้ใช้ FCP บน web.dev ถือว่า "เร็ว" ตามคำจำกัดความของช่วง FCP

ติดตามประสิทธิภาพ

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

SELECT
  _TABLE_SUFFIX AS yyyymm,
  SUM(fcp.density) AS fast_fcp
FROM
  `chrome-ux-report.all.*`,
  UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
  origin = 'https://web.dev' AND
  fcp.start < 1000
GROUP BY
  yyyymm
ORDER BY
  yyyymm DESC

ในส่วนนี้ เราจะเห็นว่าเปอร์เซ็นต์ของประสบการณ์ FCP ที่รวดเร็วนั้นแตกต่างกันเพียงไม่กี่เปอร์เซ็นต์ในแต่ละเดือน

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

คำถามที่พบบ่อย

คําถามที่พบบ่อยเกี่ยวกับชุดข้อมูล CrUX BigQuery มีดังนี้

ฉันจะใช้ BigQuery แทนเครื่องมืออื่นๆ เมื่อใด

คุณจำเป็นต้องใช้ BigQuery ก็ต่อเมื่อคุณไม่สามารถรับข้อมูลเดียวกันนี้จากเครื่องมืออื่นๆ เช่น แดชบอร์ด CrUX และ PageSpeed Insights ตัวอย่างเช่น BigQuery ช่วยให้คุณแบ่งข้อมูลอย่างมีความหมาย และนำไปรวมกับชุดข้อมูลสาธารณะอื่นๆ เช่น HTTP Archive เพื่อดำเนินการขุดค้นข้อมูลขั้นสูงได้

การใช้ BigQuery มีข้อจำกัดไหม

ใช่ ข้อจำกัดที่สำคัญที่สุดคือโดยค่าเริ่มต้น ผู้ใช้จะค้นหาข้อมูลได้ 1 TB ต่อเดือนเท่านั้น หลังจากนั้นจะใช้อัตรามาตรฐาน $5/TB

ฉันจะดูข้อมูลเพิ่มเติมเกี่ยวกับ BigQuery ได้จากที่ใด

ดูข้อมูลเพิ่มเติมได้ในเอกสารประกอบของ BigQuery