Tutorial: Eksport danych z GA4 do BigQuery i pierwsze zapytanie SQL

BigQuery udostępnia wyeksportowane zdarzenia GA4 do własnych analiz SQL: łączenia z danymi biznesowymi, jawnego definiowania wskaźników i odtwarzania zaobserwowanych sekwencji stron. GA4 również oferuje eksploracje ścieżek i ścieżek konwersji. SQL zwiększa kontrolę nad obliczeniami i postacią wyników.

Instrukcja zaczyna się od eksportu dziennego, sprawdza napływ zdarzeń, a następnie grupuje zaobserwowane odsłony według identyfikatorów sesji. Przykłady opisują wybrany eksport, bez gwarancji odtworzenia wszystkich rzeczywistych wizyt.

1. Konfiguracja eksportu dziennego

Połączenie powstaje w sekcji Administracja → Połączenia z usługami → Połączenia BigQuery. W GA4 potrzebne są co najmniej uprawnienia Edytora na poziomie usługi. Projekt Cloud wymaga udokumentowanych uprawnień IAM i uprawnień do usług. Rola Owner obejmuje te prawa, ale odpowiednia kombinacja węższych ról również może wystarczyć. Interfejs BigQuery API musi być włączony.

Konfiguracja obejmuje projekt Cloud, lokalizację danych, strumienie i wykluczone zdarzenia. W usługach standardowych opcje Daily i Streaming są niezależne; uprawnione usługi Analytics 360 oferują także Fresh Daily. Daily tworzy events_YYYYMMDD, a Streaming tymczasowe tabele events_intraday_YYYYMMDD, potencjalnie z lukami. Do analizy zakończonych dni lepiej nadaje się eksport dzienny, choć spóźnione zdarzenia mogą jeszcze zmieniać niedawne tabele.

Połączenie nie uzupełnia wcześniejszej historii usługi. Pierwsze dane zwykle pojawiają się w ciągu 24 godzin; konkretna pora codziennej dostawy nie jest gwarantowana. Usługi standardowe mają limit miliona eksportowanych zdarzeń dziennie. Przekroczenie może wstrzymać eksport dzienny. Wykluczenie strumieni lub zdarzeń zmniejsza wolumen, ale zmienia też zakres późniejszej analizy.

Eksport dzienny nie oznacza bezpłatnego korzystania z Cloud: przechowywanie i zapytania mogą generować opłaty, a Streaming dodatkowe koszty przesyłania. Przed pierwszym zapytaniem oszacowanie w edytorze lub dry run pokazuje przewidywane przetwarzanie. Dry run sprawdza zapytanie bez jego wykonywania. maximum bytes billed ogranicza rozliczane bajty pojedynczego zapytania w modelu on-demand. Poniższe przykłady celowo obejmują krótki okres.

2. Różnice względem raportów GA4

Eksport zdarzeń nie stosuje próbkowania ani nie łączy wielu odrębnych wartości wymiaru w wiersz (other). Raporty i eksploracje GA4 mogą korzystać z różnych tabel źródłowych; możliwe są próbkowanie, ograniczenia agregacji lub progi prywatności. Progi dotyczą między innymi danych demograficznych i wyszukiwanych fraz. Włączone sygnały Google nie wyjaśniają automatycznie każdego brakującego wiersza.

BigQuery nie odtwarza modelowania zachowania i kluczowych zdarzeń ani atrybucji opartej na danych z GA4. Nie oznacza to braku wszystkich pól atrybucji: obecny schemat zawiera między innymi zaobserwowane źródła sesji według ostatniego kliknięcia, gdy takie dane są dostępne. Przy rozbieżnościach potrzebne jest porównanie definicji wskaźnika, okresu, strefy czasowej usługi, metody identyfikacji, filtrów eksportu i aktualności danych. Różnica nie musi oznaczać błędu, ale nie powinna też być automatycznie ignorowana.

3. Zagnieżdżony schemat danych

Każdy wyeksportowany wiersz reprezentuje zdarzenie. Bezpośrednie kolumny obejmują event_name, event_date, event_timestamp i user_pseudo_id. Dodatkowe wartości, takie jak ga_session_id i page_location, znajdują się w event_params, liście nazw i odpowiadających im wartości wewnątrz wiersza zdarzenia. UNNEST udostępnia te rekordy, a podzapytanie skalarne zwraca jedną wartość dla szukanej nazwy.

event_date odpowiada skonfigurowanej strefie raportowania. event_timestamp jest zapisany w mikrosekundach UTC, lecz kilka zdarzeń wysłanych razem może mieć ten sam znacznik czasu. Pola batch uzupełniają informacje o kolejności. Pseudoidentyfikator oznacza instancję aplikacji lub kontekst przeglądarki, nie zweryfikowaną osobę. Brakujące i zmieniające się identyfikatory ograniczają rekonstrukcję. Zapytanie grupuje według osobnych pól stream_id, pseudoidentyfikatora i identyfikatora sesji.

4. Potwierdzenie napływu zdarzeń

Identyfikator projektu, zbiór usługi i daty są miejscami na rzeczywiste tabele dzienne. Zapytania wymagają GoogleSQL.

SELECT
  event_date,
  COUNT(*) AS events,
  COUNT(DISTINCT user_pseudo_id) AS distinct_pseudo_ids,
  COUNTIF(user_pseudo_id IS NULL) AS events_without_pseudo_id
FROM `project.analytics_XXXXXXXXX.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260920' AND '20260926'
GROUP BY event_date
ORDER BY event_date;

distinct_pseudo_ids liczy różne niepuste identyfikatory, a nie aktywnych użytkowników GA4 ani unikalne osoby. Dodatkowy licznik wartości null pokazuje brakujące identyfikatory. Dzień bez tabeli lub zdarzeń nie tworzy wiersza wyniku; ciągły kalendarz wymagałby osobnej tabeli dat.

5. Budowa zaobserwowanej sekwencji stron

Przykład dla witryny korzysta z page_view. Analiza ekranów aplikacji wymaga innego zdarzenia i odpowiedniego pola lokalizacji. Wybrane tabele muszą zawierać pokazane pola batch z obecnego schematu.

WITH page_views AS (
  SELECT
    stream_id,
    user_pseudo_id,
    (SELECT value.int_value FROM UNNEST(event_params)
      WHERE key = 'ga_session_id') AS session_id,
    event_timestamp,
    batch_page_id,
    batch_ordering_id,
    batch_event_index,
    (SELECT value.string_value FROM UNNEST(event_params)
      WHERE key = 'page_location') AS page_location
  FROM `project.analytics_XXXXXXXXX.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260920' AND '20260926'
    AND event_name = 'page_view'
)
SELECT
  stream_id,
  user_pseudo_id,
  session_id,
  COUNT(*) AS page_views,
  COUNTIF(page_location IS NULL) AS missing_locations,
  STRING_AGG(
    COALESCE(REGEXP_REPLACE(page_location, r'[?#].*$', ''),
             '[missing URL]'),
    ' > ' ORDER BY event_timestamp, batch_page_id,
      batch_ordering_id, batch_event_index, page_location
  ) AS observed_path
FROM page_views
WHERE user_pseudo_id IS NOT NULL
  AND session_id IS NOT NULL
GROUP BY stream_id, user_pseudo_id, session_id
HAVING COUNT(*) > 1
ORDER BY page_views DESC, stream_id, user_pseudo_id, session_id
LIMIT 100;

Brakujące pseudoidentyfikatory i identyfikatory sesji są wykluczane zamiast łączenia niezwiązanych zdarzeń we wspólną grupę null. Brakujące adresy pozostają widoczne w liczniku i ścieżce. Przykład usuwa parametry zapytania i fragmenty, zachowując nazwę hosta, dzięki czemu strony różnych hostów nie otrzymują przypadkowo tej samej etykiety. Routing oparty na parametrach zapytania wymaga innej normalizacji.

Sortowanie korzysta ze znaczników czasu i dostępnych pól batch. Końcowe pole URL rozstrzyga kolejność wyświetlania, nie stanowi dowodu chronologii. Równe lub brakujące wartości sortowania, równoległe karty i opóźnione przesyłanie mogą pozostawić rzeczywistą kolejność niejednoznaczną. Ścieżka zawiera tylko zaobserwowane odsłony w wybranym okresie. Sesje przecinające granice okresu mogą być ucięte, a sesje z jedną odsłoną są celowo pomijane przez HAVING.

Podzapytania skalarne zakładają najwyżej jedną wartość każdego szukanego klucza w zdarzeniu. Powtórzone klucze wymagają sprawdzenia źródła błędu; arbitralny wybór pierwszej wartości ukrywałby problem danych. Analiza kroków przed zakupem wymaga dodatkowo zdarzeń zakupu: obecny filtr zachowuje wyłącznie odsłony.

6. Kontrola przed użyciem w panelu

• Sprawdzenie dziennych liczb zdarzeń, wykluczonych strumieni i zdarzeń oraz udziału brakujących identyfikatorów.
• Porównanie kilku odtworzonych sesji z wierszami źródłowymi, także przy jednakowych znacznikach czasu i przejściu przez północ.
• Porównanie jawnie zdefiniowanego wskaźnika z GA4 przy jednakowych założeniach dat i identyfikacji; oddzielenie różnic modelowania od luk eksportu.
• Świadome ustawienie dostępu i wygasania tabel. Eksport ma osobny cykl życia poza GA4.