Data mentah Chrome UX Report (CrUX) tersedia di BigQuery, sebuah database di Google Cloud. Penggunaan BigQuery memerlukan project GCP dan pengetahuan dasar tentang SQL.
Dalam panduan ini, pelajari cara menggunakan BigQuery untuk menulis kueri terhadap set data CrUX guna mengekstrak hasil yang bermanfaat tentang status pengalaman pengguna di web:
- Memahami cara pengaturan data
- Menulis kueri dasar untuk mengevaluasi performa origin
- Menulis kueri lanjutan untuk melacak performa dari waktu ke waktu
Pengorganisasian data
Mulai dengan melihat kueri dasar:
SELECT COUNT(DISTINCT origin) FROM `chrome-ux-report.all.202206`
Untuk menjalankan kueri, masukkan ke dalam editor kueri, kemudian tekan tombol "Jalankan kueri" tombol:
Ada dua bagian untuk kueri ini:
SELECT COUNT(DISTINCT origin)berarti membuat kueri untuk jumlah asal dalam tabel. Sebenarnya, dua URL adalah bagian dari origin yang sama jika memiliki skema, host, dan port yang sama.FROM chrome-ux-report.all.202206menentukan alamat tabel sumber, yang memiliki tiga bagian:- Nama project Cloud
chrome-ux-reporttempat semua data CrUX diatur - Set data
all, yang mewakili data di semua negara - Tabel
202206, tahun, dan bulan data dalam format YYYYMM
- Nama project Cloud
Ada juga {i>dataset<i} untuk setiap negara. Misalnya, chrome-ux-report.country_ca.202206 hanya mewakili data pengalaman pengguna yang berasal dari Kanada.
Dalam setiap {i>dataset<i} terdapat tabel untuk setiap bulan sejak tahun 201710. Tabel baru untuk bulan kalender sebelumnya dipublikasikan secara berkala.
Struktur tabel data (juga dikenal sebagai skema) berisi:
- Asal, misalnya
origin = 'https://www.example.com', yang mewakili distribusi pengalaman pengguna gabungan untuk semua halaman di situs tersebut - Kecepatan koneksi pada saat pemuatan halaman, misalnya,
effective_connection_type.name = '4G' - Jenis perangkat, misalnya
form_factor.name = 'desktop' - Metrik UX itu sendiri
Data untuk setiap metrik diatur sebagai array objek. Dalam notasi JSON, first_contentful_paint.histogram.bin akan terlihat seperti ini:
[
{"start": 0, "end": 100, "density": 0.1234},
{"start": 100, "end": 200, "density": 0.0123},
...
]
Setiap kelompok berisi waktu mulai dan berakhir dalam milidetik dan kepadatan yang menunjukkan persentase pengalaman pengguna dalam rentang waktu tersebut. Dengan kata lain, 12,34% pengalaman FCP untuk asal hipotetis ini, kecepatan koneksi, dan jenis perangkat kurang dari 100 md. Jumlah semua kepadatan bin adalah 100%.
Jelajahi struktur tabel di BigQuery.
Mengevaluasi performa
Kita dapat menggunakan pengetahuan tentang skema tabel untuk menulis kueri yang mengekstrak data performa ini.
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
Hasilnya adalah 0.01115, yang berarti 1,115% pengalaman pengguna pada asal ini adalah antara 0 dan 100 md di 4G dan di ponsel. Jika ingin menggeneralisasi kueri ke koneksi apa pun dan jenis perangkat apa pun, kita dapat menghilangkannya dari klausa WHERE dan menggunakan fungsi agregator SUM untuk menjumlahkan semua kepadatan bin masing-masing:
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
Hasilnya adalah 0.05355, atau 5,355% di semua perangkat dan jenis koneksi. Kita dapat sedikit mengubah kueri dan menambahkan kepadatan untuk semua bin yang berada dalam rentang FCP "cepat" 0–1000 md:
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
Tindakan ini akan menghasilkan 0.6977. Dengan kata lain, 69,77% pengalaman pengguna FCP di web.dev dianggap "cepat" sesuai dengan definisi rentang FCP.
Lacak performa
Setelah mengekstrak data performa tentang origin, kita dapat membandingkannya dengan data historis yang tersedia di tabel lama. Untuk melakukannya, kita dapat menulis ulang alamat tabel ke bulan sebelumnya, atau kita dapat menggunakan sintaks karakter pengganti untuk melakukan kueri semua bulan:
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
Di sini, kita melihat bahwa persentase pengalaman FCP cepat bervariasi sebesar beberapa persen setiap bulan.
| ttttt | fast_fcp |
|---|---|
| 202206 | 69,77% |
| 202205 | 70,71% |
| 202204 | 69,04% |
| 202203 | 69,82% |
| 202202 | 67,75% |
| 202201 | 58,96% |
| 202112 | 41,69% |
| ... | ... |
Dengan teknik ini, Anda dapat mencari performa untuk origin, menghitung persentase pengalaman cepat, dan melacaknya dari waktu ke waktu. Sebagai langkah selanjutnya, coba buat kueri untuk dua origin atau lebih dan bandingkan performanya.
FAQ
Berikut adalah beberapa pertanyaan umum (FAQ) tentang set data BigQuery CrUX:
Kapan saya akan menggunakan BigQuery, bukan alat lainnya?
BigQuery hanya diperlukan jika Anda tidak bisa mendapatkan informasi yang sama dari alat lain seperti Dasbor CrUX dan PageSpeed Insights. Misalnya, BigQuery memungkinkan Anda membagi data dengan cara yang bermakna dan bahkan menggabungkannya dengan set data publik lainnya seperti HTTP Archive untuk melakukan beberapa penambangan data tingkat lanjut.
Apakah ada batasan untuk menggunakan BigQuery?
Ya, batasan yang paling penting adalah secara default pengguna hanya dapat membuat kueri data senilai 1 TB per bulan. Di luar itu, tarif standar $5/TB berlaku.
Di mana saya bisa mempelajari BigQuery lebih lanjut?
Baca dokumentasi BigQuery untuk mengetahui informasi selengkapnya.