Jak korzystać ze zbioru danych BigQuery w zakresie CrUX

Dane nieprzetworzone raportu UX Chrome (CrUX) są dostępne w BigQuery, czyli w bazie danych w Google Cloud. Korzystanie z BigQuery wymaga projektu GCP i podstawowej znajomości języka SQL.

Z tego przewodnika dowiesz się, jak za pomocą BigQuery pisać zapytania dotyczące zbioru danych CRUX, aby uzyskiwać przydatne wyniki dotyczące wrażeń użytkowników w internecie:

  • Organizowanie danych
  • Tworzenie podstawowego zapytania do oceny skuteczności źródła
  • Tworzenie zaawansowanego zapytania do śledzenia wydajności w czasie

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 przycisk „Uruchom zapytanie”:

Wpisz proste zapytanie w edytorze i kliknij Uruchom.

Zapytanie to składa się z 2 części:

  • SELECT COUNT(DISTINCT origin) oznacza zapytanie o liczbę źródeł w tabeli. Ogólnie rzecz biorąc, 2 adresy URL należą do tego samego źródła, jeśli mają ten sam schemat, hosta i port.

  • FROM chrome-ux-report.all.202206 określa adres tabeli źródłowej, która ma 3 części:

    • Nazwa projektu Cloud chrome-ux-report, w którym są zorganizowane wszystkie dane Crux
    • Zbiór danych all zawierający dane ze wszystkich krajów
    • Tabela 202206, rok i miesiąc danych w formacie RRRRMM

Dane są też dostępne dla każdego kraju. Na przykład chrome-ux-report.country_ca.202206 zawiera tylko dane o wrażeniach użytkowników pochodzące z Kanady.

W każdym zbiorze danych znajdują się tabele z danymi z każdego miesiąca od 2017 roku10. Regularnie publikujemy nowe tabele dotyczące poprzedniego miesiąca kalendarzowego.

Struktura tabel danych (zwana też schematem) zawiera:

  • Źródło, np. origin = 'https://www.example.com', które reprezentuje zbiorczą dystrybucję wrażeń użytkowników na wszystkich stronach w danej witrynie.
  • Szybkość połączenia w momencie wczytywania strony, np. effective_connection_type.name = '4G'
  • Typ urządzenia, np. form_factor.name = 'desktop'
  • Dane dotyczące 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)

Dane dotyczące każdego rodzaju danych są uporządkowane w tablicę obiektów. W zapisie JSON element first_contentful_paint.histogram.bin wyglądałby tak:

[
    {"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ść reprezentującą odsetek doświadczeń użytkowników w tym zakresie czasowym. Inaczej mówiąc, w przypadku tego hipotetycznego źródła, szybkości połączenia i typu urządzenia 12, 34% użytkowników korzystających z protokołu FCP ma czas poniżej 100 ms. Suma wszystkich gęstości zbiorników wynosi 100%.

Przeglądaj strukturę tabel w BigQuery.

Ocena skuteczności

Na podstawie znajomości schematu tabeli możemy utworzyć zapytanie, które wyodrębnia te dane o skutecznoś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

Wykonywanie zapytań do zbioru danych CrUX FCP w BigQuery

Wynik to 0.01115, co oznacza, że w przypadku 1,115% użytkowników z tego źródła czas reakcji na połączenie 4G i telefon wynosi od 0 do 100 ms. Jeśli chcemy uogólnić zapytanie, aby dotyczyło dowolnego połączenia i dowolnego typu urządzenia, możemy pominąć te informacje w klauzuli WHERE i użyć funkcji agregatora SUM, aby zsumować wszystkie odpowiednie gęstości binó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

Sumowanie danych z FCP w BigQuery

Wynik to 0.05355, czyli 5,355% na wszystkich urządzeniach i we wszystkich typach połączeń. Możemy nieznacznie zmodyfikować zapytanie i dodać gęstości dla wszystkich przedziałów, które mieszczą się w zakresie „szybkiego” 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

Wysyłanie zapytań do szybkiego FCP w BigQuery

Dzięki temu mamy 0.6977. Inaczej mówiąc, 69,77% wrażeń użytkowników w ramach FCP w 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 je porównać 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 zapytać o wszystkie miesiące:

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

Wykonywanie zapytań do zbioru danych typu „timeseries” z danymi o dostępie do treści w BigQuery

Widać tu, że odsetek szybkich sesji FCP zmienia się co miesiąc 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 sprawdzić skuteczność pochodzenia, obliczyć odsetek szybkich doświadczeń i śledzić go na przestrzeni czasu. W następnym kroku przeprowadź zapytanie dotyczące co najmniej 2 źródeł i porównaj ich skuteczność.

Najczęstsze pytania

Oto kilka najczęstszych pytań dotyczących zbioru danych BigQuery w CRUX:

Kiedy warto używać BigQuery zamiast innych narzędzi?

BigQuery jest potrzebne tylko wtedy, gdy nie możesz uzyskać tych samych informacji z innych narzędzi, takich jak panel CrUX czy narzędzie 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 korzystanie z BigQuery wiąże się z jakimiś ograniczeniami?

Tak. Najważniejsze ograniczenie polega na tym, że domyślnie użytkownicy mogą przesłać w ciągu miesiąca tylko 1 TB danych. Po przekroczeniu tego limitu obowiązuje standardowa stawka 5 USD/TB.

Gdzie mogę dowiedzieć się więcej o BigQuery?

Więcej informacji znajdziesz w dokumentacji BigQuery.