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

Rick Viscomi

ข้อมูลดิบของรายงาน UX ของ Chrome (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 ส่วนดังนี้

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

นอกจากนี้ยังมีชุดข้อมูลสำหรับทุกประเทศ ตัวอย่างเช่น 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)
  • Large_contentful_paint (LCP)
  • dom_content_loaded (DCL)
  • ขณะโหลด (OL)
  • format_instability.cumulative_layout_shift (CLS)
  • Interaction_to_next_paint (INP)

ข้อมูลสำหรับแต่ละเมตริกจะได้รับการจัดระเบียบเป็นอาร์เรย์ของออบเจ็กต์ ในรูปแบบ 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 มิลลิวินาที ผลรวมของความหนาแน่นของ Bin ทั้งหมดเท่ากับ 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 เพื่อบวกความหนาแน่นของ Bin ที่เกี่ยวข้องทั้งหมด

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 กล่าวคือ ประสบการณ์ของผู้ใช้ FCP 69.77% ใน 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-3 เปอร์เซ็นต์ในแต่ละเดือน

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

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

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

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

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

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

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

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

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