BigQuery dla marketingu - wprowadzenie i połączenie GA4 z BigQuery

BigQuery to hurtownia danych w chmurze Google Cloud, która przechowuje i analizuje bardzo duże zbiory danych za pomocą zapytań SQL, bez utrzymywania własnego serwera. W marketingu BigQuery pełni rolę magazynu surowych danych: trafiają do niego pojedyncze zdarzenia z Google Analytics 4, koszty kampanii z Google Ads, dane z Google Search Console i rekordy z CRM, a rozliczenie opiera się na ilości danych przetworzonych przez zapytania oraz na wolumenie składowania. Połączenie GA4 z BigQuery jest bezpłatną funkcją standardowej usługi Google Analytics 4, którą uruchamia się w panelu administracyjnym w kilka minut.

Pierwszy sygnał, że czas na BigQuery, wygląda zwykle tak samo: dział handlowy pyta o coś, czego GA4 nie potrafi pokazać. Ilu klientów, którzy kupili po raz pierwszy w styczniu, wróciło po sześciu miesiącach? Które kampanie przyciągają ludzi kupujących drugi raz? Interfejs Google Analytics 4 odpowiada na pytania, które ktoś w Google przewidział podczas projektowania raportów. Reszta wymaga dostępu do surowych zdarzeń. Przez lata audytowania kont Google Ads i konfiguracji analityki widziałem dziesiątki firm, które kupowały drogie narzędzia BI, mając w zasięgu ręki bezpłatny eksport GA4 do BigQuery, którego nikt nie włączył.

Czym jest BigQuery i dlaczego marketerzy zaczęli go używać?

BigQuery jest serwerless-ową hurtownią danych Google Cloud, która wykonuje zapytania SQL na zbiorach liczących miliardy wierszy i rozlicza się za faktycznie przetworzone dane. Marketerzy sięgnęli po nią z jednego powodu: Google Analytics 4 udostępnia bezpłatny eksport surowych zdarzeń właśnie do BigQuery, a poprzednia wersja Analytics rezerwowała tę możliwość dla płatnej wersji Analytics 360.

Różnica między BigQuery a klasyczną bazą danych sprowadza się do modelu pracy. Nie zarządzasz serwerem, nie planujesz mocy obliczeniowej, nie robisz kopii zapasowych. Wrzucasz dane, piszesz zapytanie, płacisz za przemielone bajty. Dla działu marketingu to zmiana kategorii problemu: z „potrzebujemy infrastruktury” na „potrzebujemy kogoś, kto napisze zapytanie”.

W praktyce BigQuery pełni w marketingu trzy różne role, które warto rozdzielić, bo wymagają innych kompetencji:

• Archiwum surowych zdarzeń: przechowuje historię z Google Analytics 4 dłużej niż pozwala na to standardowa retencja GA4 i w postaci, której interfejs nie agreguje.
• Miejsce łączenia źródeł: jedna tabela z kosztami Google Ads, druga ze zdarzeniami GA4, trzecia z zamówieniami z CRM, a między nimi zwykły JOIN po identyfikatorze transakcji.
• Silnik pod raporty: Looker Studio, Power BI i arkusze pobierają gotowe, przeliczone tabele wynikowe zamiast odpytywać API narzędzi reklamowych.

Encja, którą warto tu zapamiętać, to „projekt Google Cloud”. Wszystko w BigQuery żyje wewnątrz projektu: zbiory danych, tabele, uprawnienia i rozliczenia. Jeden projekt na firmę to najczystszy układ, jaki widuję w dobrze poukładanych organizacjach. Szczegółowy kontekst całej warstwy pomiarowej opisuję w przewodniku analityka i pomiar w marketingu.

Dlaczego interfejs GA4 przestaje wystarczać przy większych danych?

Interfejs Google Analytics 4 zniekształca dane na trzy sposoby, których nie da się wyłączyć: progowanie danych, wiersz „(other)” przy wysokiej kardynalności oraz ograniczona retencja zdarzeń wynosząca 2 lub 14 miesięcy. Eksport do BigQuery omija wszystkie trzy, bo pracuje na zdarzeniach zapisanych przed agregacją.

Progowanie (thresholding) uruchamia się, gdy w usłudze włączone są sygnały Google, a raport mógłby pozwolić na identyfikację pojedynczych osób. Google po prostu ukrywa część wierszy. W raporcie widzisz wtedy komunikat o zastosowaniu progu, a suma nie zgadza się z tym, co pokazuje karta przeglądu. Wiersz „(other)” to inny mechanizm: gdy liczba unikalnych wartości w tabeli raportu przekroczy limit, GA4 zwija resztę do jednego zbiorczego wiersza.

W jednym z audytów sklepu z oświetleniem dekoracyjnym wiersz „(other)” obejmował 38% odsłon stron produktowych. Klientka była przekonana, że jej najlepiej sprzedające się lampy to te z pierwszej dziesiątki raportu. Po przełożeniu tych samych danych na zapytanie w BigQuery okazało się, że dwa produkty spoza widocznej listy generowały więcej wyświetleń niż pozycja druga i trzecia razem wzięte.

Nie namawiam nikogo do porzucenia interfejsu GA4. Wielokrotnie obserwowałem sytuację, w której zespół marketingu przenosił do BigQuery raporty, które w GA4 działały świetnie, i kończył z wolniejszym procesem oraz rachunkiem za zapytania. Podstawy samego narzędzia opisuję osobno w tekście o tym, czym jest Google Analytics 4.

Jak połączyć GA4 z BigQuery krok po kroku?

Połączenie GA4 z BigQuery polega na utworzeniu projektu w Google Cloud, włączeniu w nim API BigQuery i wskazaniu tego projektu w sekcji „Powiązania produktów” w ustawieniach administracyjnych usługi Google Analytics 4. Cała konfiguracja zajmuje kilkanaście minut, a pierwsze tabele pojawiają się zwykle następnego dnia.

1. Załóż projekt Google Cloud na tym samym koncie Google, które ma uprawnienia administratora w usłudze GA4. Nazwa projektu powinna wskazywać firmę, nie kampanię ani rok.
2. Włącz rozliczenia lub tryb Sandbox. Sandbox nie wymaga karty płatniczej, ale tabele znikają po 60 dniach, więc do zastosowań produkcyjnych podepnij konto rozliczeniowe.
3. Aktywuj BigQuery API w bibliotece usług projektu. Bez tego kroku GA4 zgłosi błąd uprawnień przy próbie powiązania.
4. Dodaj konto usługi Analytics (firebase-measurement@system.gserviceaccount.com) jako edytora projektu, jeśli panel GA4 nie zrobi tego automatycznie.
5. W GA4 wejdź w Administracja, potem Powiązania produktów, potem Powiązania BigQuery i wskaż projekt oraz lokalizację danych. Dla firm z Unii Europejskiej wybierz region europejski, nie domyślny amerykański.
6. Wybierz typ eksportu: dzienny, ciągły (streaming) albo oba. Dzienny wystarcza do raportowania, streaming ma sens przy monitoringu w czasie zbliżonym do rzeczywistego.
7. Zdecyduj o zakresie danych: możesz wykluczyć wybrane zdarzenia z eksportu, co ma sens przy bardzo dużych wolumenach ruchu.

Wybór lokalizacji jest decyzją nieodwracalną w obrębie jednego zbioru danych. Zmiana regionu po fakcie oznacza utworzenie nowego zbioru i utratę ciągłości historii albo ręczne kopiowanie tabel. Rekomenduję podejście, w którym region ustala się raz, na etapie zakładania projektu, wspólnie z osobą odpowiedzialną w firmie za ochronę danych osobowych.

Co dokładnie trafia do BigQuery po włączeniu eksportu GA4?

Eksport GA4 tworzy w BigQuery zbiór danych o nazwie analytics_ z numerem usługi, a w nim dzienne tabele zdarzeń o nazwie events_ z datą w formacie rok-miesiąc-dzień. Jedna tabela to jedna doba, jeden wiersz to jedno zdarzenie, a parametry zdarzenia siedzą w zagnieżdżonej strukturze event_params.

Struktura zagnieżdżona bywa pierwszym zaskoczeniem dla osób znających SQL z klasycznych baz. Kolumna event_params nie zawiera jednej wartości, tylko listę par klucz-wartość, którą trzeba rozwinąć operatorem UNNEST. To rozwiązanie pozwala zapisać dowolny zestaw parametrów bez zmiany schematu tabeli.

Najważniejsze kolumny tabeli events_, od których zaczyna się każda analiza:

• event_name: nazwa zdarzenia, na przykład page_view, purchase, generate_lead.
• event_timestamp: moment zdarzenia w mikrosekundach, kluczowy przy odtwarzaniu ścieżek.
• user_pseudo_id: pseudonimowy identyfikator urządzenia i przeglądarki, odpowiednik dawnego Client ID.
• traffic_source oraz collected_traffic_source: źródło pierwszej wizyty i źródło zebrane przy danym zdarzeniu.
• items: tablica pozycji zamówienia w zdarzeniach handlowych, z ceną, ilością i kategorią.
• ecommerce: wartość transakcji, podatek, koszt dostawy oraz identyfikator zamówienia.

Ile kosztuje BigQuery przy danych marketingowych?

BigQuery rozlicza dwie rzeczy osobno: składowanie danych i przetwarzanie zapytań. W modelu on-demand Google Cloud podaje bezpłatny próg 1 TiB przetworzonych danych miesięcznie oraz 10 GB aktywnego składowania, a powyżej progu obowiązuje stawka rzędu 6,25 USD za TiB zapytań i 0,02 USD za GB składowania miesięcznie w regionie amerykańskim, stan na 2026 rok.

Sam eksport z Google Analytics 4 do BigQuery jest bezpłatny po stronie Analytics. Płacisz wyłącznie Google Cloud i wyłącznie za to, co realnie zajmiesz i przemielisz. Dla większości polskich sklepów internetowych oznacza to rachunek w okolicach kilku złotych miesięcznie, o ile nikt nie odpytuje surowych tabel bezpośrednio z odświeżanego co godzinę dashboardu.

W pracy z moimi klientami zawsze stosuję prostą zasadę kosztową: surowe tabele events_ są odpytywane wyłącznie przez zaplanowane zapytania, które budują tabele wynikowe raz na dobę. Wszystkie dashboardy patrzą już tylko na te tabele wynikowe. To jedna decyzja architektoniczna, która w praktyce decyduje o tym, czy rachunek za BigQuery będzie w groszach, czy w setkach złotych.

Jak wygląda pierwsze zapytanie SQL do danych GA4?

Pierwsze użyteczne zapytanie do danych GA4 w BigQuery liczy zdarzenia w wybranym zakresie dat i rozwija parametry operatorem UNNEST. Poniższy przykład zwraca liczbę transakcji i przychód w podziale na źródło ruchu, z ograniczeniem zakresu przez _TABLE_SUFFIX, czyli w sposób, który nie skanuje całej historii.

SELECT
  traffic_source.source AS zrodlo,
  COUNT(DISTINCT ecommerce.transaction_id) AS transakcje,
  ROUND(SUM(ecommerce.purchase_revenue), 2) AS przychod
FROM `projekt.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260101' AND '20260131'
  AND event_name = 'purchase'
GROUP BY zrodlo
ORDER BY przychod DESC

Warunek na _TABLE_SUFFIX to najważniejsza linijka w tym zapytaniu. Bez niej BigQuery przeskanuje wszystkie tabele dzienne, jakie kiedykolwiek powstały w zbiorze. Z nią przetwarza wyłącznie 31 tabel ze stycznia, a koszt spada proporcjonalnie do liczby dni.

Kolejny krok to wyciąganie parametrów, których nie ma w kolumnach głównych. Ten wzorzec powtarza się w każdym raporcie:

• Podzapytanie z UNNEST: rozwija event_params i pozwala odfiltrować parametr po nazwie klucza.
• Wybór właściwego pola wartości: tekstowa nazwa strony leży w polu string, a wartość zdarzenia w polu liczbowym.
• Agregacja po user_pseudo_id: podstawa wszystkich analiz kohortowych i raportów o powracalności.
• Zapis wyniku jako tabeli: instrukcja CREATE TABLE albo zaplanowane zapytanie budujące tabelę raz na dobę.

Nie musisz umieć pisać tego z pamięci. W praktyce nawet doświadczeni analitycy trzymają bibliotekę gotowych zapytań i modyfikują daty oraz nazwy zdarzeń. Sam korzystam też z modeli językowych do generowania szkieletu zapytania, o czym piszę szerzej w tekście o AI w analizie danych marketingowych. Warunek jest jeden: wynik trzeba zweryfikować na znanym okresie, zanim trafi do raportu zarządczego.

Jakie dane poza GA4 warto trzymać w BigQuery?

Prawdziwa wartość BigQuery pojawia się dopiero wtedy, gdy obok zdarzeń GA4 leżą koszty kampanii, dane z wyszukiwarki i zamówienia z systemu sprzedażowego. Dopiero połączenie tych czterech źródeł pozwala policzyć rzeczywisty zwrot z kanału, bo przychód z GA4 nie zawiera zwrotów, a koszty z Google Ads nie trafiają do Analytics w rozbiciu na produkty.

• Google Ads przez usługę Data Transfer: BigQuery Data Transfer Service pobiera dane kampanii, grup reklam i słów kluczowych automatycznie. Sam transfer jest bezpłatny, płacisz za składowanie i zapytania.
• Google Search Console przez eksport zbiorczy: od 2023 roku GSC oferuje eksport zbiorczy do BigQuery, który omija limit tysiąca wierszy z interfejsu i daje pełne dane o zapytaniach.
• Zamówienia i zwroty z systemu sprzedażowego: najważniejsze źródło, bo tylko ono zna marżę i status zamówienia. Wystarczy dzienny plik CSV wgrywany do tabeli.
• Koszty z platform spoza Google: Meta Ads, Allegro Ads czy kampanie e-mail wymagają konektora zewnętrznego albo prostego skryptu, ale zasada pozostaje ta sama.
• Dane o klientach z CRM: segment, źródło pierwszego kontaktu, wartość życiowa. Łączone po identyfikatorze zamówienia albo po User-ID.

Uważam, że najczęstszym błędem na tym etapie jest odwracanie kolejności: firmy wpinają pięć źródeł, zanim ktokolwiek zada pierwsze sensowne pytanie biznesowe. Rekomenduję podejście odwrotne. Najpierw jedno pytanie, na które obecnie nikt nie umie odpowiedzieć, potem minimalny zestaw danych potrzebny do odpowiedzi. Jeśli chcesz sprawdzić, jak taka warstwa danych wygląda na Twoim koncie, od tego zwykle zaczynam audyt konta Google Ads.

Jak wizualizować dane z BigQuery bez zabijania budżetu?

Dashboard podłączony bezpośrednio do surowych tabel events_ jest najdroższym sposobem raportowania z BigQuery, ponieważ każde odświeżenie strony przez każdego użytkownika uruchamia nowe zapytanie. Bezpieczny układ to warstwa pośrednia: zaplanowane zapytanie buduje tabelę wynikową raz na dobę, a raport odpytuje wyłącznie ją.

Konkretne mechanizmy, które obniżają koszt i przyspieszają raporty:

1. Tabele wynikowe zamiast widoków na surowych danych. Widok nie przechowuje wyników, więc każde odwołanie do niego skanuje źródło od nowa.
2. Ekstrakt w Looker Studio dla małych zestawów. Dane lądują w pamięci podręcznej narzędzia i nie generują zapytań do BigQuery przy każdym kliknięciu filtra.
3. Partycjonowanie po dacie tabel własnych, dzięki czemu filtr okresu ogranicza skanowanie do wybranych partycji.
4. Klastrowanie po najczęściej filtrowanej kolumnie, na przykład po kanale albo kategorii produktu.
5. Limit kosztów na projekt ustawiony w Google Cloud, który zatrzymuje zapytania po przekroczeniu zadanego wolumenu.

Magda, e-commerce manager w sklepie z odzieżą dziecięcą, przyszła do mnie z raportem odświeżanym co 15 minut przez ośmiu użytkowników. Po przełożeniu tego samego raportu na dobową tabelę wynikową liczba zapytań spadła z około 250 dziennie do jednego, a czas ładowania dashboardu skrócił się z 22 sekund do niecałych 3. Zmieniła się architektura, nie zawartość raportu. Podstawy samego narzędzia raportowego opisuję w tekście Looker Studio dla początkujących.

Jakie błędy najczęściej pojawiają się przy wdrożeniu BigQuery?

Najkosztowniejszym błędem przy wdrożeniu BigQuery jest odkładanie włączenia eksportu GA4 do momentu, aż firma „będzie gotowa”, ponieważ Google nie uzupełnia danych wstecz. Pozostałe błędy dotyczą już konfiguracji i sposobu pracy z danymi, a każdy z nich widuję w audytach regularnie.

• Zostawienie trybu Sandbox na produkcji: tabele w piaskownicy wygasają po 60 dniach, więc historia znika dokładnie wtedy, gdy zaczyna być potrzebna.
• Wybór amerykańskiej lokalizacji zbioru danych mimo europejskiego charakteru działalności, co utrudnia rozmowę o zgodności z RODO i wymusza późniejszą migrację.
• Włączenie eksportu ciągłego bez potrzeby: streaming generuje tabele events_intraday_ z niepełnymi danymi, które w raportach dają zaniżone liczby.
• Odpytywanie surowych tabel z dashboardu: najczęstsza przyczyna niespodziewanego rachunku, opisana w symulacji kosztowej powyżej.
• Brak dokumentacji zdarzeń: po pół roku nikt nie pamięta, czym różni się zdarzenie add_to_cart wysyłane z listingu od tego z karty produktu.
• Porównywanie liczb z BigQuery i GA4 co do jednego zdarzenia: różnice rzędu kilku procent wynikają z odmiennego modelu sesji i są normalne, nie są błędem wdrożenia.

Kiedyś uważałem, że eksport ciągły to zawsze lepszy wybór, bo daje świeższe dane. Zmieniłem zdanie po kilku wdrożeniach, w których zespół raportował z tabel intraday i regularnie tłumaczył zarządowi, dlaczego poranne liczby nie zgadzają się z popołudniowymi. Streaming ma sens przy monitoringu awarii i kampanii jednodniowych. Do raportowania sprzedaży wystarczy eksport dzienny.

Kiedy BigQuery jest przerostem formy dla małej firmy?

BigQuery nie ma uzasadnienia jako narzędzie raportowe wtedy, gdy interfejs GA4 odpowiada na wszystkie zadawane pytania, a w firmie nie ma nikogo, kto napisze i utrzyma zapytania SQL. Włączenie samego eksportu ma jednak sens praktycznie zawsze, bo jest bezpłatne, a dane zbierają się na przyszłość.

To rozróżnienie bywa mylone. Eksport danych i praca z danymi to dwie oddzielne decyzje. Pierwszą podejmujesz raz, kosztuje kwadrans i nie generuje zobowiązań. Drugą podejmujesz wtedy, gdy pojawi się pytanie biznesowe, na które GA4 nie odpowiada, albo osoba zdolna zadać je językiem SQL.

Granica opłacalności biegnie przez kompetencje, nie przez wielkość firmy. Widziałem jednoosobową działalność, która świetnie wykorzystywała BigQuery, bo właściciel miał przeszłość w IT. Widziałem też spółkę z ośmioosobowym marketingiem, w której eksport działał trzy lata i nikt do niego nie zajrzał. Jeśli rozpoznajesz ten drugi wzorzec u siebie, warto zacząć od jednego konkretnego pytania i jednego raportu, a nie od pełnej hurtowni.

Podsumowanie

Przestań traktować BigQuery jak zaawansowane narzędzie dla działu IT. Zacznij postrzegać go jako darmowy magazyn na Twoje własne dane marketingowe, który zaczyna działać w dniu, w którym klikniesz powiązanie w Google Analytics 4. Sam eksport nie kosztuje nic i nie wymaga żadnych kompetencji technicznych. Kosztować zaczyna dopiero praca na danych, a i to zwykle w skali groszy, o ile raporty odpytują tabele wynikowe zamiast surowych zdarzeń.

Kolejność wdrożenia, którą polecam każdej firmie zaczynającej od zera, jest prosta:

1. Włącz eksport GA4 do BigQuery w europejskim regionie jeszcze w tym tygodniu, niezależnie od gotowości zespołu.
2. Podepnij konto rozliczeniowe i ustaw limit kosztów, żeby wyjść z tymczasowego trybu Sandbox.
3. Zapisz jedno pytanie biznesowe, na które obecne raporty nie odpowiadają, i dopiero pod nie buduj pierwsze zapytanie.
4. Zbuduj jedną tabelę wynikową odświeżaną raz na dobę i dopiero na niej oprzyj raport w Looker Studio.

Za dwa lata dane, które zbierasz od dziś, będą jedynym materiałem pozwalającym odpowiedzieć na pytanie o wartość klientów pozyskanych w konkretnej kampanii. Dane, których nie zacząłeś zbierać, nie odtworzy żaden konsultant ani żaden model. To jedyna rzecz w analityce, której nie da się nadrobić budżetem. Jeśli chcesz omówić, jak ułożyć warstwę danych pod swoje kampanie, napisz do mnie.

Samodzielny Specjalista Google Ads

Artur Smolicki

Od ponad 15 lat specjalizuję się w przygotowaniu, wdrożeniu i optymalizacji kampanii Google Ads. W 2024 roku uzyskałem status Google Premier Partner dla 3% najlepszych specjalistów i agencji w Polsce. Prowadzę kampanie reklamowe na 29 rynkach zagranicznych, tak dla segmentu e-commerce jak i B2B.

Współpraca →Poznaj mnie →