Jak korzystać ze zbioru danych BigQuery w zakresie CrUX

Rick Viscomi

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 SQL.

Z tego przewodnika dowiesz się, jak używać BigQuery do zapisywania zapytań do zbioru danych raportu CrUX w celu wyodrębnienia istotnych wyników dotyczących korzystania z internetu przez użytkowników:

  • Zrozumienie sposobu porządkowania danych
  • Utwórz podstawowe zapytanie, aby ocenić wydajność źródła
  • Utwórz zaawansowane zapytanie, aby śledzić wydajność na przestrzeni czasu

Organizacja danych

Zacznij od sprawdzenia podstawowego 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 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 są częścią tego samego źródła, jeśli mają ten sam schemat, host i port.

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

    • Nazwa projektu Cloud chrome-ux-report, w którym uporządkowane są wszystkie dane raportu na temat użytkowania Chrome
    • Zbiór danych all, który reprezentuje dane ze wszystkich krajów
    • Tabela 202206, rok i miesiąc danych w formacie RRRRMM

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

W każdym zbiorze danych znajdują się tabele odpowiadające poszczególnym miesiącom od 201710 r. Regularnie publikowane są nowe tabele z poprzedniego miesiąca kalendarzowego.

Struktura tabel danych (nazywanych też schematem) zawiera:

  • Źródło, np. origin = 'https://www.example.com', które reprezentuje zbiorczy rozkład wrażeń użytkowników ze wszystkich stron w tej witrynie.
  • 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.
    • first_paint (FP)
    • first_contentful_paint (FCP)
    • DOM_content_loaded (DCL)
    • onload (OL)
    • Experiment.first_input_delay (FID)

Dane poszczególnych wskaźników są uporządkowane w postaci tablicy obiektów. W notacji JSON wartość first_contentful_paint.histogram.bin wyglądałaby podobnie do tej:

[
    {"start": 0, "end": 100, "density": 0.1234},
    {"start": 100, "end": 200, "density": 0.0123},
    ...
]

Każdy przedział zawiera czas rozpoczęcia i zakończenia wyrażony w milisekundach oraz gęstość reprezentującą procent wrażeń użytkowników w danym przedziale czasu. Oznacza to, że 12, 34% operacji FCP w przypadku tego hipotetycznego źródła, szybkości połączenia i typu urządzenia trwa mniej niż 100 ms. Suma wszystkich gęstości pojemników wynosi 100%.

Przeglądanie struktury tabel w BigQuery

Ocena skuteczności

Możemy wykorzystać naszą wiedzę o schemacie tabeli, aby utworzyć zapytanie, które będzie 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

Wysyłanie zapytań o FCP na podstawie interfejsu CrUX w BigQuery

Wynik to 0.01115, co oznacza, że 1,115% wyświetleń w tym źródle trwa od 0 do 100 ms w sieci 4G i na telefonie. Jeśli chcemy uogólnić nasze zapytanie na dowolne połączenie i urządzenia dowolnego typu, możemy je pominąć w klauzuli WHERE i użyć funkcji agregatora SUM, aby zsumować wszystkie odpowiadające im wartości binarne:

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 FCP na podstawie interfejsu CrUX w BigQuery

Wynik to 0.05355, czyli 5,355% w przypadku wszystkich urządzeń i typów połączeń. Możemy nieco zmodyfikować zapytanie i zsumować gęstości wszystkich przedziałów, które mieszczą się w zakresie „szybkim” 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ń o szybkie FCP w BigQuery

Daje nam to 0.6977. Inaczej mówiąc, zgodnie z definicją zakresu FCP 69,77% wrażeń użytkowników korzystających z FCP w witrynie web.dev jest uważanych za „szybkie”.

Śledzenie skuteczności

Po wyodrębnieniu danych o skuteczności źródła możemy je porównać z danymi historycznymi dostępnymi w starszych tabelach. Aby to zrobić, możemy przepisać adres tabeli na wcześniejszy miesiąc lub użyć składni symbolu wieloznacznego, aby przesł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

Zapytanie o ciąg czasowy dotyczący FCP CrUX w BigQuery

Widzimy, że odsetek szybkich żądań związanych z 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ć wyniki punktu początkowego, obliczyć odsetek żądań szybko działających w Twojej witrynie i śledzić je w czasie. W kolejnym kroku spróbuj wysłać zapytania dotyczące co najmniej 2 źródeł i porównać ich wydajność.

Najczęstsze pytania

Oto niektóre z najczęstszych pytań dotyczących zbioru danych BigQuery w zakresie CrUX:

Kiedy warto korzystać z BigQuery zamiast innych narzędzi?

Usługa BigQuery jest potrzebna tylko wtedy, gdy nie można uzyskać tych samych informacji z innych narzędzi, takich jak panel CrUX i PageSpeed Insights. BigQuery umożliwia na przykład efektywne dzielenie danych na części, a nawet łączenie ich z innymi publicznymi zbiorami danych, takimi jak archiwum HTTP, na potrzeby zaawansowanego wydobywania danych.

Czy są jakieś ograniczenia w korzystaniu z BigQuery?

Tak. Najważniejszym ograniczeniem jest to, że domyślnie użytkownicy mogą przesyłać tylko zapytania o wielkości 1 TB danych miesięcznie. Oprócz tego obowiązuje standardowa stawka 5 USD/TB.

Gdzie znajdę więcej informacji o BigQuery?

Więcej informacji znajdziesz w dokumentacji BigQuery.