Jak pracować z polami zagnieżdżonymi (nested fields) z ChatGPT

PrzezBartosz Spychalski Czas czytania 4 min.

Jeśli korzystasz z eksportu danych z Google Analytics 4 do BigQuery, prędzej czy później trafisz na ten sam problem:
dane, których szukasz, nie są „normalnymi kolumnami”.

Zamiast tego znajdują się w strukturach zagnieżdżonych, takich jak event_params, user_properties czy items.
Dla wielu osób to moment frustracji — „przecież ten parametr jest wysyłany, dlaczego go nie widzę?”

Ten artykuł pokazuje dokładnie, jak wydobywać (extractować) zagnieżdżone pola z GA4 BigQuery, krok po kroku, bez magii i bez zgadywania.

Uwaga: artykuł odnosi się do narzędzia GA4 BigQuery Composer By Optimize Smart (Himanshu)

Dlaczego GA4 zapisuje dane jako pola zagnieżdżone?

GA4 został zaprojektowany jako system event-based, a nie sesyjny jak Universal Analytics.
Każde zdarzenie (event) może mieć dowolną liczbę parametrów, dlatego Google przechowuje je w elastycznej strukturze:

  • event_params → tablica (ARRAY)
  • każdy element tablicy → struktura (STRUCT)
  • każda struktura → para key + value

Dzięki temu GA4 może przechowywać setki parametrów bez tworzenia setek kolumn — ale kosztem prostoty zapytań SQL.

Najczęstszy przykład: gdzie jest page_location?

W GA4 UI page_location widzisz bez problemu.
W BigQuery… nie ma takiej kolumny.

Dlaczego?
Bo page_location jest parametrem zdarzenia, zapisanym wewnątrz:

event_params.key = 'page_location'

Twoim zadaniem jest:

  • „rozpakować” tablicę event_params
  • znaleźć element z właściwym kluczem
  • pobrać odpowiednią wartość (string_value, int_value itd.)

Krok 1: Zidentyfikuj parametr, którego szukasz

Zanim napiszesz zapytanie, musisz wiedzieć:

  • dokładną nazwę parametru (case-sensitive)
  • typ wartości (najczęściej string_value)

Przykłady:

  • page_location → string
  • page_title → string
  • engagement_time_msec → int
  • utm_campaign → string

Krok 2: Podstawowa struktura zapytania

Pracujemy na tabelach:
events_YYYYMMDD

Każda tabela zawiera:

  • jedno zdarzenie = jeden wiersz
  • parametry zdarzenia = event_params (ARRAY)

Minimalny szkielet zapytania wygląda tak:

SELECT
  event_date,
  event_name
FROM
  `twoj_projekt.twoj_dataset.events_20251101`

To jest punkt wyjścia.

Krok 3: Wyciągnięcie wartości z event_params

Aby pobrać np. page_location, używamy podzapytania skalarnego:

(
  SELECT value.string_value
  FROM UNNEST(event_params)
  WHERE key = 'page_location'
) AS page_location

Pełne zapytanie:

SELECT
  event_date,
  event_name,
  (
    SELECT value.string_value
    FROM UNNEST(event_params)
    WHERE key = 'page_location'
  ) AS page_location
FROM
  `twoj_projekt.twoj_dataset.events_20251101`
WHERE
  event_name = 'page_view'
LIMIT 10

Efekt:

  • każda odsłona strony ma przypisany URL
  • brak (not set)
  • pełna kontrola nad danymi

Krok 4: Dodanie kolejnego parametru (np. content_group)

Możesz wyciągnąć dowolną liczbę parametrów, powielając ten sam schemat:

Możesz wyciągnąć dowolną liczbę parametrów, powielając ten sam schemat:

SELECT
  event_date,
  event_name,
  (
    SELECT value.string_value
    FROM UNNEST(event_params)
    WHERE key = 'page_location'
  ) AS page_location,
  (
    SELECT value.string_value
    FROM UNNEST(event_params)
    WHERE key = 'content_group'
  ) AS content_group
FROM
  `twoj_projekt.twoj_dataset.events_20251101`
WHERE
  event_name = 'page_view'
LIMIT 10

Krok 5: Filtrowanie po wartości parametru

Chcesz np. tylko strony z określonej grupy treści?

Dodajesz warunek:

WHERE
  event_name = 'page_view'
  AND (
    SELECT value.string_value
    FROM UNNEST(event_params)
    WHERE key = 'content_group'
  ) = 'Google Analytics'

To bardzo potężny mechanizm — pozwala analizować:

  • konkretne sekcje serwisu
  • kampanie
  • typy użytkowników
  • wersje aplikacji
  • wszystko, co wysyłasz jako parametr

Krok 6: Najczęstsze błędy (i jak ich uniknąć)

1. Zły typ wartości
Jeśli parametr jest liczbowy, a użyjesz string_value → dostaniesz NULL.

2. Parametr nie istnieje w danym evencie
Nie każdy event ma każdy parametr. To normalne.

3. Mylenie custom dimension z parametrem
Custom dimension to tylko „etykieta raportowa”.
W BigQuery zawsze pracujesz na parametrze, nie na wymiarze.

4. Oczekiwanie danych historycznych
Jeśli parametr nie był wysyłany wcześniej — danych nie będzie. BigQuery nie „uzupełnia wstecz”.

Dlaczego warto opanować nested fields w GA4?

Bo wtedy:

  • przestajesz polegać na ograniczeniach interfejsu GA4
  • masz dostęp do 100% surowych danych
  • unikasz (not set)
  • budujesz własne modele atrybucji
  • kontrolujesz jakość danych, a nie zgadujesz

To jest moment, w którym GA4 przestaje być czarną skrzynką, a zaczyna być normalnym systemem danych.

Podobne wpisy