Nieprzetworzone dane z raportu na temat użytkowania Chrome (CrUX) są dostępne w BigQuery – bazie danych w Google Cloud. Korzystanie z BigQuery wymaga projektu GCP i podstawowej wiedzy o języku SQL.
Z tego przewodnika dowiesz się, jak używać BigQuery do zapisywania zapytań na zbiorze danych CrUX w celu wyodrębniania wnikliwych wyników dotyczących wrażeń użytkowników w internecie:
- Zrozumienie sposobu porządkowania danych
- Tworzenie podstawowego zapytania do oceny skuteczności źródła
- Napisz zaawansowane zapytanie, aby śledzić wydajność na przestrzeni czasu
Organizacja danych
Zacznij od prostego zapytania:
SELECT COUNT(DISTINCT origin) FROM `chrome-ux-report.all.202206`
Aby uruchomić zapytanie, wpisz je w edytorze zapytań i kliknij „Uruchom zapytanie” przycisk:
To zapytanie składa się z 2 części:
SELECT COUNT(DISTINCT origin)oznacza wysłanie zapytania o liczbę źródeł w tabeli. Ogólnie rzecz biorąc, 2 adresy URL są częścią tego samego źródła, jeśli mają ten sam schemat, hosta i port.FROM chrome-ux-report.all.202206określa adres tabeli źródłowej, która składa się z 3 części:- Nazwa projektu Cloud
chrome-ux-report, w którym są zorganizowane wszystkie dane Crux - Zbiór danych
allobejmujący dane ze wszystkich krajów - Tabela
202206, rok i miesiąc danych w formacie RRRRMM.
- Nazwa projektu Cloud
Dane są też dostępne dla każdego kraju. Na przykład chrome-ux-report.country_ca.202206 reprezentuje tylko dane dotyczące wrażeń użytkowników pochodzące z Kanady.
W zbiorze danych są tabele odpowiadające poszczególnym miesiącom od 201710 r. Nowe tabele z poprzedniego miesiąca kalendarzowego są regularnie publikowane.
Struktura tabel danych (nazywany też schematem) zawiera:
- punkt początkowy, np.
origin = 'https://www.example.com', który reprezentuje zbiorczy rozkład wrażeń użytkowników na wszystkich stronach tej witryny; - szybkość połączenia w momencie wczytywania strony, np.
effective_connection_type.name = '4G'; - Typ urządzenia, np.
form_factor.name = 'desktop' - same dane dotyczące UX.
Informacje o poszczególnych wskaźnikach są uporządkowane w formie tablicy obiektów. W notacji JSON pole first_contentful_paint.histogram.bin wyglądałoby podobnie do tego:
[
{"start": 0, "end": 100, "density": 0.1234},
{"start": 100, "end": 200, "density": 0.0123},
...
]
Każdy przedział zawiera czas rozpoczęcia i zakończenia w milisekundach oraz gęstość obrazu, która odzwierciedla odsetek wrażeń użytkowników w danym przedziale czasu. Oznacza to, że 12, 34% wyników FCP w przypadku tego hipotetycznego źródła, szybkości połączenia i typu urządzenia wynosi mniej niż 100 ms. Suma wszystkich gęstości pojemników to 100%.
Przeglądaj strukturę tabel w BigQuery.
Ocena skuteczności
Dzięki swojej wiedzy o schemacie tabel możemy napisać zapytanie wyodrębniające te dane o wydajności.
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
Wynik to 0.01115, co oznacza, że 1,115% wrażeń użytkownika w tym źródle trwa od 0 do 100 ms w sieci 4G i na telefonie. Jeśli chcesz uogólnić nasze zapytanie do dowolnego połączenia i dowolnego typu urządzenia, możesz pominąć je w klauzuli WHERE i użyć funkcji agregatora SUM, aby zsumować wszystkie odpowiednie gęstości przedziałów:
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
Wynik to 0.05355, czyli 5,355% w przypadku wszystkich urządzeń i typów połączeń. Możemy nieznacznie zmodyfikować zapytanie i zsumować gęstości dla wszystkich kontenerów, które są „szybkie” Zakres FCP: 0–1000 ms:
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
Daje nam to 0.6977. Oznacza to, że 69,77% wyświetleń stron FCP na stronie web.dev jest uznawanych za „szybkie”. zgodnie z definicją zakresu FCP.
Śledzenie skuteczności
Po wyodrębnieniu danych o wydajności źródła możemy porównać je z danymi historycznymi dostępnymi w starszych tabelach. Aby to zrobić, możemy zmienić adres tabeli na wcześniejszy miesiąc lub użyć składni z symbolem wieloznacznym, aby wysłać zapytanie dotyczące wszystkich miesięcy:
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
Widzimy, że odsetek szybkich wyrenderowanych treści zmienia się w miesiącu o kilka punktów procentowych.
| rrrrmm | fast_fcp |
|---|---|
| 202206 | 69,77% |
| 202205 | 70,71% |
| 202204 | 69,04% |
| 202203 | 69,82% |
| 202202 | 67,75% |
| 202201 | 58,96% |
| 202112 | 41,69% |
| … | … |
Dzięki tym technikom możesz sprawdzać wydajność źródła, obliczać odsetek szybkich rozwiązań i śledzić je w czasie. W następnym kroku przeprowadź zapytanie dotyczące co najmniej 2 źródeł i porównaj ich skuteczność.
Najczęstsze pytania
Oto niektóre z najczęstszych pytań o zbiór danych BigQuery w CrUX:
Kiedy warto używać BigQuery zamiast innych narzędzi?
Usługa BigQuery jest potrzebna tylko wtedy, gdy nie możesz uzyskać tych samych informacji z innych narzędzi, takich jak panel CrUX czy PageSpeed Insights. Na przykład BigQuery umożliwia dzielenie danych na sensowne części, a nawet ich złączanie z innymi publicznymi zbiorami danych, takimi jak archiwum HTTP, aby przeprowadzać zaawansowane wydobywanie danych.
Czy są jakieś ograniczenia dotyczące korzystania z BigQuery?
Tak. Najważniejszym ograniczeniem jest to, że domyślnie użytkownicy mogą wysyłać zapytania dotyczące danych o wielkości maksymalnie 1 TB na miesiąc. Poza tym obowiązuje standardowa stawka 5 USD za TB.
Gdzie znajdę więcej informacji o BigQuery?
Więcej informacji znajdziesz w dokumentacji BigQuery.