![\"Przep\u0142yw](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/ga4-bigquery-export-pl.png\")
Krok 1: W\u0142\u0105czenie eksportu<\/h2>\n
Po\u0142\u0105czenie tworzy si\u0119 w GA4 w sekcji Administracja, w obszarze po\u0142\u0105cze\u0144 z us\u0142ugami, przez po\u0142\u0105czenia BigQuery. Wymaga to uprawnie\u0144 do edycji us\u0142ugi GA4 oraz uprawnie\u0144 w\u0142a\u015bciciela docelowego projektu Google Cloud z w\u0142\u0105czonym interfejsem BigQuery API. Konfiguracja pyta o projekt Cloud, lokalizacj\u0119 danych, strumienie danych do uwzgl\u0119dnienia oraz cz\u0119stotliwo\u015b\u0107 eksportu.<\/p>\n
Do wyboru s\u0105 dwie cz\u0119stotliwo\u015bci i zachowuj\u0105 si\u0119 r\u00f3\u017cnie. Dzienna<\/strong> zapisuje jedn\u0105 tabel\u0119 na dob\u0119, Dwa ograniczenia maj\u0105 znaczenie, zanim cokolwiek na tym stanie. Eksport nie dzia\u0142a wstecz<\/strong> \u2014 zaczyna w dniu utworzenia po\u0142\u0105czenia i nie uzupe\u0142nia historii, dlatego w\u0142\u0105czenie go wcze\u015bnie op\u0142aca si\u0119 nawet bez natychmiastowego zastosowania dla danych. Us\u0142ugi standardowe podlegaj\u0105 te\u017c udokumentowanemu dziennemu limitowi eksportu wynosz\u0105cemu milion zdarze\u0144 na dob\u0119; jego przekroczenie mo\u017ce skutkowa\u0107 zawieszeniem eksportu, wi\u0119c bie\u017c\u0105cy wolumen warto zestawi\u0107 z limitem w dokumentacji Google, zanim eksport stanie si\u0119 elementem no\u015bnym.<\/p>\n Po stronie BigQuery bezp\u0142atny poziom obejmuje 10 GiB przestrzeni i 1 TiB przetworzonych danych zapyta\u0144 miesi\u0119cznie, co dla pojedynczej us\u0142ugi eksplorowanej r\u0119cznie jest warto\u015bci\u0105 hojn\u0105.<\/p>\n Unikni\u0119cie pr\u00f3bkowania w eksporcie nie jest technik\u0105 \u2014 wynika z tego, \u017ce eksport jest niezagregowanym strumieniem zdarze\u0144, a nie raportem. Trzy odr\u0119bne redukcje stosowane przez interfejs s\u0105 tam po prostu nieobecne:<\/p>\n \u017badna z tych trzech redukcji nie dotyczy wyeksportowanych tabel. Cen\u0105 jest to, \u017ce wszystko, co interfejs nadbudowuje nad surowymi danymi \u2014 modelowane konwersje, atrybucja oparta na danych, w\u0142asna definicja sesji \u2014 r\u00f3wnie\u017c tam nie wyst\u0119puje. W\u0142a\u015bnie dlatego sumy z BigQuery i sumy z interfejsu nie zgodz\u0105 si\u0119 dok\u0142adnie.<\/p>\n Ka\u017cdy wiersz to jedno zdarzenie. Osoby przychodz\u0105ce z klasycznego SQL najbardziej zaskakuje to, \u017ce interesuj\u0105ce warto\u015bci nie s\u0105 kolumnami: siedz\u0105 w Sesja nie ma w\u0142asnej kolumny. Rekonstruuje si\u0119 j\u0105, \u0142\u0105cz\u0105c Przed czymkolwiek analitycznym jedno zapytanie potwierdza, \u017ce dane nap\u0142ywaj\u0105, a odwo\u0142anie do tabeli jest poprawne:<\/p>\n Filtr Zapytaniem, kt\u00f3rego interfejs nie potrafi zwr\u00f3ci\u0107, jest pe\u0142na sekwencja stron w sesji. Odczyt warto\u015bci z Ka\u017cdy wiersz to droga jednej sesji w kolejno\u015bci, z usuni\u0119t\u0105 domen\u0105 i query stringiem, dzi\u0119ki czemu identyczne strony grupuj\u0105 si\u0119 razem. St\u0105d ta sama struktura odpowiada na bardziej szczeg\u00f3\u0142owe pytania: ograniczenie do sesji zawieraj\u0105cych konkretne zdarzenie, policzenie, jak cz\u0119sto jedna strona poprzedza drug\u0105, albo zmierzenie, ile krok\u00f3w poprzedza zakup.<\/p>\n Dwie rzeczy warto ustali\u0107, zanim te dane trafi\u0105 do raportu. Liczby z eksportu nie uzgodni\u0105 si\u0119 dok\u0142adnie z interfejsem GA4 i jest to za\u0142o\u017cenie projektowe, a nie usterka do \u015bcigania: interfejs nak\u0142ada na surowe dane modelowanie i w\u0142asn\u0105 logik\u0119 sesji, kt\u00f3rych tam nie ma. Eksport niesie te\u017c dane na poziomie zdarze\u0144 dotycz\u0105ce identyfikowalnych urz\u0105dze\u0144, wi\u0119c ta sama podstawa zgody i dyscyplina retencji, kt\u00f3re obowi\u0105zuj\u0105 dla danych analitycznych, obowi\u0105zuj\u0105 r\u00f3wnie\u017c dla zbioru w Cloud \u2014 \u0142\u0105cznie z tym, komu przyznawany jest dost\u0119p do projektu.<\/p>\n Z filtrem sufiksu z kroku 4 nie, bez niego by\u0107 mo\u017ce tak. Symbol wieloznaczny events_* obejmuje tak\u017ce tabele events_intraday_YYYYMMDD, bo ich nazwy r\u00f3wnie\u017c zaczynaj\u0105 si\u0119 od events_. Dla nich _TABLE_SUFFIX nie brzmi wtedy 20260926, lecz intraday_20260926.<\/p>\n Warunek Podw\u00f3jnie zapytanie mo\u017ce liczy\u0107 dopiero wtedy, gdy bez filtra sufiksu albo ze zbyt szerokim wzorcem obejmie oba rodzaje tabel, a dla tego samego dnia istniej\u0105 obie. Zapytanie \u0142\u0105cz\u0105ce oba \u017ar\u00f3d\u0142a powinno wi\u0119c dla ka\u017cdego dnia liczy\u0107 tylko jedno z nich.<\/p>\n Nie. BigQuery rozlicza bajty, kt\u00f3re zapytanie musi odczyta\u0107, a LIMIT ogranicza jedynie wynik, gdy dane s\u0105 ju\u017c odczytane. Poniewa\u017c BigQuery przechowuje dane kolumnami, oszcz\u0119dzaj\u0105 natomiast dwa inne zabiegi: wyb\u00f3r tylko potrzebnych kolumn zamiast SELECT * oraz filtr na _TABLE_SUFFIX, kt\u00f3ry wy\u0142\u0105cza z rachunku ca\u0142e tabele dzienne.<\/p>\n Nie. Ustawienie przechowywania danych w GA4 dotyczy danych w samym GA4. To, co raz trafi\u0142o do BigQuery, le\u017cy tam jako osobna kopia w projekcie Cloud i zostaje, dop\u00f3ki nie zostanie tam usuni\u0119te. Pozostawiony sam sobie zbi\u00f3r ro\u015bnie wi\u0119c z dnia na dzie\u0144, a razem z nim zajmowana przestrze\u0144, kt\u00f3ra mo\u017ce w ko\u0144cu przekroczy\u0107 bezp\u0142atne 10 GiB.<\/p>\n Dyscyplin\u0119 retencji, kt\u00f3rej artyku\u0142 wymaga tak\u017ce dla zbioru, trzeba zatem ustawi\u0107 w BigQuery. S\u0142u\u017cy do tego domy\u015blny czas wyga\u015bni\u0119cia tabel ustawiany na zbiorze (w API pole defaultTableExpirationMs); nowe tabele dzienne s\u0105 wtedy usuwane automatycznie po up\u0142ywie tego okresu. Dotyczy to wy\u0142\u0105cznie tabel utworzonych po zmianie; starsze tabele potrzebuj\u0105 w\u0142asnego czasu wyga\u015bni\u0119cia albo usuwa si\u0119 je r\u0119cznie.<\/p>\n Tak, BigQuery dzia\u0142a wtedy jako piaskownica (sandbox), ale z dwoma ograniczeniami, kt\u00f3re dla GA4 maj\u0105 znaczenie. Tabele w piaskownicy wygasaj\u0105 po 60 dniach, wi\u0119c eksport dzienny nigdy nie przechowuje wi\u0119cej ni\u017c oko\u0142o dw\u00f3ch miesi\u0119cy. Eksport strumieniowy nie jest tam natomiast dost\u0119pny. Do poznania danych to wystarcza; zbudowanie d\u0142ugiego szeregu czasowego wymaga konta rozliczeniowego, nawet je\u015bli wykorzystanie mie\u015bci si\u0119 w ramach bezp\u0142atnego poziomu.<\/p>\n<\/div>\nevents_YYYYMMDD<\/code>, zwykle dost\u0119pn\u0105 nast\u0119pnego dnia; dla us\u0142ug standardowych jest wliczona bez op\u0142at. Strumieniowa<\/strong> zapisuje na bie\u017c\u0105co do events_intraday_YYYYMMDD<\/code> i jest rozliczana wed\u0142ug stawek BigQuery za wstawianie strumieniowe. Do poznania danych i do wi\u0119kszo\u015bci analiz wystarcza sam eksport dzienny.<\/p>\nKrok 2: Co naprawd\u0119 oznacza \u201ebez pr\u00f3bkowania\u201d<\/h2>\n
\n
(other)<\/code>.<\/strong> Gdy wymiar generuje wi\u0119cej odr\u0119bnych warto\u015bci, ni\u017c raport jest w stanie pomie\u015bci\u0107, reszta zostaje zwini\u0119ta do jednego worka (other)<\/code> \u2014 realny problem przy \u015bcie\u017ckach stron, identyfikatorach produkt\u00f3w czy frazach wyszukiwania.<\/li>\nKrok 3: Kszta\u0142t danych<\/h2>\n
event_params<\/code>, powtarzalnym rekordzie par klucz-warto\u015b\u0107, w kt\u00f3rym sama warto\u015b\u0107 jest struktur\u0105 z osobnym polem na ka\u017cdy typ.<\/p>\n\n\n
\n \nPole<\/th>\n Typ<\/th>\n Co zawiera<\/th>\n<\/tr>\n<\/thead>\n \n event_date<\/code><\/td>\nSTRING<\/td>\n Dzie\u0144 w formacie YYYYMMDD<\/code>, zgodny z sufiksem tabeli.<\/td>\n<\/tr>\n\n event_timestamp<\/code><\/td>\nINT64<\/td>\n Mikrosekundy od epoki \u2014 klucz porz\u0105dkuj\u0105cy wewn\u0105trz sesji.<\/td>\n<\/tr>\n \n event_name<\/code><\/td>\nSTRING<\/td>\n page_view<\/code>, session_start<\/code>, purchase<\/code> oraz zdarzenia w\u0142asne.<\/td>\n<\/tr>\n\n user_pseudo_id<\/code><\/td>\nSTRING<\/td>\n Identyfikator klienta \u2014 urz\u0105dzenie lub przegl\u0105darka, nie osoba.<\/td>\n<\/tr>\n \n event_params<\/code><\/td>\nREPEATED RECORD<\/td>\n Pary klucz-warto\u015b\u0107: ga_session_id<\/code>, page_location<\/code>, page_title<\/code> i pozosta\u0142e.<\/td>\n<\/tr>\n\n items<\/code><\/td>\nREPEATED RECORD<\/td>\n Produkty e-commerce powi\u0105zane ze zdarzeniem.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n user_pseudo_id<\/code> z parametrem ga_session_id<\/code>, poniewa\u017c identyfikatory sesji s\u0105 unikalne wy\u0142\u0105cznie w obr\u0119bie jednego klienta.<\/p>\nKrok 4: Pierwsze zapytanie potwierdzaj\u0105ce, \u017ce eksport dzia\u0142a<\/h2>\n
SELECT\n event_date,\n COUNT(*) AS events,\n COUNT(DISTINCT user_pseudo_id) AS users\nFROM `project.analytics_XXXXXXXXX.events_*`\nWHERE _TABLE_SUFFIX BETWEEN '20260920' AND '20260926'\nGROUP BY event_date\nORDER BY event_date;<\/code><\/pre>\n_TABLE_SUFFIX<\/code> nie jest opcjonalnym porz\u0105dkowaniem. Symbol wieloznaczny events_*<\/code> odwo\u0142uje si\u0119 naraz do wszystkich tabel dziennych w zbiorze, a bez filtra sufiksu zapytanie skanuje ca\u0142\u0105 histori\u0119 eksportu \u2014 rozliczan\u0105 wed\u0142ug odczytanych bajt\u00f3w.<\/p>\nKrok 5: Wyci\u0105gni\u0119cie surowych \u015bcie\u017cek u\u017cytkownik\u00f3w<\/h2>\n
event_params<\/code> realizuje si\u0119 podzapytaniem skalarnym po UNNEST<\/code> \u2014 to konstrukcja warta zapami\u0119tania, bo powraca w ka\u017cdym zapytaniu do GA4:<\/p>\nWITH page_views AS (\n SELECT\n user_pseudo_id,\n (SELECT value.int_value FROM UNNEST(event_params)\n WHERE key = 'ga_session_id') AS session_id,\n event_timestamp,\n (SELECT value.string_value FROM UNNEST(event_params)\n WHERE key = 'page_location') AS page_location\n FROM `project.analytics_XXXXXXXXX.events_*`\n WHERE _TABLE_SUFFIX BETWEEN '20260920' AND '20260926'\n AND event_name = 'page_view'\n)\nSELECT\n CONCAT(user_pseudo_id, '-', CAST(session_id AS STRING)) AS session_key,\n COUNT(*) AS page_views,\n STRING_AGG(\n REGEXP_EXTRACT(page_location, r'^https?:\/\/[^\/]+([^?#]*)'),\n ' > ' ORDER BY event_timestamp\n ) AS path\nFROM page_views\nWHERE session_id IS NOT NULL\nGROUP BY session_key\nHAVING page_views > 1\nORDER BY page_views DESC\nLIMIT 100;<\/code><\/pre>\nPozostaj\u0105c w granicach<\/h2>\n
Pytania i odpowiedzi<\/h2>\n
Czy events_* liczy zdarzenia podw\u00f3jnie, gdy w\u0142\u0105czony jest eksport strumieniowy?<\/h3>\n
_TABLE_SUFFIX BETWEEN '20260920' AND '20260926'<\/code> wyklucza te tabele, poniewa\u017c por\u00f3wnanie odbywa si\u0119 znak po znaku, a litera i przy sortowaniu wypada za wszystkimi cyframi. Kto potrzebuje danych z bie\u017c\u0105cego dnia z tabeli intraday, musi wi\u0119c do\u0142\u0105czy\u0107 j\u0105 wprost, na przyk\u0142ad dodatkowym warunkiem _TABLE_SUFFIX = 'intraday_20260927'<\/code>.<\/p>\nCzy LIMIT 100 obni\u017ca koszt zapytania?<\/h3>\n
Czy okres przechowywania ustawiony w GA4 dotyczy tak\u017ce tabel w BigQuery?<\/h3>\n
Czy eksport dzia\u0142a tak\u017ce bez konta rozliczeniowego w Google Cloud?<\/h3>\n