نحوه استفاده از مجموعه داده CrUX BigQuery

Rick Viscomi

داده‌های خام گزارش تجربه کاربری کروم ( CrUX ) در BigQuery ، یک پایگاه داده در Google Cloud، موجود است. استفاده از BigQuery نیاز به یک پروژه GCP و دانش پایه SQL دارد.

در این راهنما، یاد بگیرید که چگونه از BigQuery برای نوشتن کوئری‌ها در مجموعه داده‌های CrUX استفاده کنید تا نتایج مفیدی در مورد وضعیت تجربیات کاربری در وب استخراج کنید:

• درک چگونگی سازماندهی داده‌ها
• یک کوئری ساده برای ارزیابی عملکرد یک مبدا بنویسید
• یک کوئری پیشرفته برای ردیابی عملکرد در طول زمان بنویسید

سازماندهی داده‌ها

با بررسی یک پرس و جوی اولیه شروع کنید:

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

برای اجرای پرس‌وجو، آن را در ویرایشگر پرس‌وجو وارد کنید و دکمه «اجرای پرس‌وجو» را فشار دهید:

این پرس و جو دو بخش دارد:

• SELECT COUNT(DISTINCT origin) به معنی جستجوی تعداد مبداهای موجود در جدول است. به طور کلی، دو URL در صورتی بخشی از یک مبدا هستند که طرح، میزبان و پورت یکسانی داشته باشند.

• FROM chrome-ux-report.all.202206 آدرس جدول منبع را مشخص می‌کند که دارای سه بخش است:

  • نام پروژه ابری chrome-ux-report که تمام داده‌های CrUX در آن سازماندهی شده‌اند.
  • مجموعه داده‌ها all ، نشان‌دهنده داده‌ها در تمام کشورها است
  • جدول 202206 ، سال و ماه داده‌ها با فرمت YYYYMM

همچنین مجموعه داده‌هایی برای هر کشور وجود دارد. برای مثال، chrome-ux-report.country_ca.202206 فقط داده‌های تجربه کاربری مربوط به کانادا را نشان می‌دهد.

در هر مجموعه داده، جداولی برای هر ماه از سال ۲۰۱۷ تا ۲۰۱۰ وجود دارد. جداول جدید برای ماه تقویمی قبل به طور منظم منتشر می‌شوند.

ساختار جداول داده (که به عنوان طرحواره نیز شناخته می‌شود) شامل موارد زیر است:

• مبدا، برای مثال origin = 'https://www.example.com' ، که نشان دهنده توزیع کلی تجربه کاربری برای تمام صفحات آن وب سایت است.
• سرعت اتصال در زمان بارگذاری صفحه، برای مثال، effective_connection_type.name = '4G' ( از فوریه 2025 حذف شده است )
• نوع دستگاه، برای مثال form_factor.name = 'desktop'
• خود معیارهای UX
  • first_paint (FP)
  • first_contentful_paint ( FCP )
  • largest_contentful_paint ( LCP )
  • dom_content_loaded (DCL)
  • onload (OL)
  • layout_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},
    ...
]

هر دسته شامل یک زمان شروع و یک زمان پایان بر حسب میلی‌ثانیه و یک چگالی است که نشان دهنده درصد تجربیات کاربران در آن محدوده زمانی است. به عبارت دیگر، ۱۲.۳۴٪ از تجربیات FCP برای این مبدا فرضی، سرعت اتصال و نوع دستگاه کمتر از ۱۰۰ میلی‌ثانیه است. مجموع چگالی همه دسته‌ها ۱۰۰٪ است.

ساختار جداول را در BigQuery مرور کنید.

ارزیابی عملکرد

ما می‌توانیم از دانش خود در مورد طرح جدول برای نوشتن پرس‌وجویی استفاده کنیم که این داده‌های عملکردی را استخراج کند.

SELECT
  fcp
FROM
  `chrome-ux-report.all.202502`,
  UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
  origin = 'https://web.dev' 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 تا 1000 میلی‌ثانیه هستند، جمع کنیم:

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 در web.dev طبق تعریف محدوده FCP، «سریع» در نظر گرفته می‌شوند.

عملکرد آهنگ

اکنون که داده‌های عملکرد مربوط به یک مبدا را استخراج کرده‌ایم، می‌توانیم آن را با داده‌های تاریخی موجود در جداول قدیمی‌تر مقایسه کنیم. برای انجام این کار، می‌توانیم آدرس جدول را به یک ماه قبل‌تر بازنویسی کنیم، یا می‌توانیم از سینتکس wildcard برای جستجوی همه ماه‌ها استفاده کنیم:

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 سریع هر ماه چند درصد تغییر می‌کند.

با این تکنیک‌ها، می‌توانید عملکرد یک مبدا را جستجو کنید، درصد تجربیات سریع را محاسبه کنید و آن را در طول زمان پیگیری کنید. به عنوان قدم بعدی، سعی کنید دو یا چند مبدا را جستجو کنید و عملکرد آنها را با هم مقایسه کنید.

سوالات متداول

اینها برخی از سوالات متداول در مورد مجموعه داده CrUX BigQuery هستند:

چه زمانی از BigQuery به جای سایر ابزارها استفاده کنم؟

BigQuery فقط زمانی مورد نیاز است که نتوانید همان اطلاعات را از ابزارهای دیگری مانند CrUX Vis و PageSpeed ​​Insights دریافت کنید. به عنوان مثال، BigQuery به شما امکان می‌دهد داده‌ها را به روش‌های معناداری برش دهید و حتی آنها را با سایر مجموعه داده‌های عمومی مانند HTTP Archive ترکیب کنید تا برخی از عملیات داده‌کاوی پیشرفته را انجام دهید.

آیا محدودیتی برای استفاده از BigQuery وجود دارد؟

بله، مهم‌ترین محدودیت این است که به‌طور پیش‌فرض کاربران فقط می‌توانند ماهانه ۱ ترابایت داده درخواست کنند. فراتر از آن، نرخ استاندارد ۵ دلار برای هر ترابایت اعمال می‌شود.

از کجا می‌توانم درباره BigQuery اطلاعات بیشتری کسب کنم؟

برای اطلاعات بیشتر ، مستندات BigQuery را بررسی کنید.