Koszty BigQuery pod kontrolą: partycje, tabele pośrednie i limity dla zespołu marketingu

Za co płacisz w BigQuery

BigQuery rozlicza osobno przechowywanie i przetwarzanie. Dla zespołu marketingu, który korzysta z eksportu GA4, danych z Google Ads i kilku arkuszy, przechowywanie to zwykle kilka dolarów miesięcznie, a przetwarzanie – od zera do kwot, które zaskakują księgowość.

Ceny różnią się nieco między regionami, a Google może je zmieniać, więc przed planowaniem budżetu sprawdź cennik dla regionu Twojego zbioru danych. Każda tabela użyta w zapytaniu na żądanie jest liczona jako co najmniej 10 MB, co ma znaczenie przy setkach drobnych zapytań. Wyniki identycznego zapytania, uruchomionego ponownie na niezmienionych danych, są zwykle zwracane z pamięci podręcznej bez opłaty.

Edycje (Standard, Enterprise, Enterprise Plus) zmieniają logikę: płacisz za moc obliczeniową w czasie, a nie za przeskanowane bajty. Dla większości zespołów marketingu model na żądanie z dobrze zaprojektowanymi tabelami jest tańszy i prostszy. Po edycję warto sięgnąć dopiero wtedy, gdy miesięczne skanowanie stale idzie w dziesiątki terabajtów i potrzebujesz przewidywalnej faktury.

Dlaczego zapytania do eksportu GA4 generują wysokie koszty

Eksport GA4 jest zaprojektowany do przechowywania, a nie do raportowania. Każde zdarzenie niesie tablicę parametrów, dane urządzenia, lokalizacji i produktów, a tabele są dzielone na dni zamiast partycjonowane. Trzy nawyki najczęściej podbijają rachunek.

Pierwszy to brak filtra _TABLE_SUFFIX. Warunek na kolumnie event_date nie ogranicza listy czytanych tabel, więc zapytanie o wczorajszy dzień potrafi przeskanować cały rok. Drugi to SELECT * albo odwołania do całego rekordu event_params tam, gdzie wystarczyłyby dwa parametry. Trzeci, najdroższy, to raport w Looker Studio podpięty bezpośrednio do events_*.

Załóżmy, że duży sklep ma w BigQuery rok danych GA4, czyli ok. 350 GB. Dashboard ma 8 wykresów i każdy przy otwarciu czyta wybrane kolumny z 12 miesięcy, średnio 40 GB. Jedno otwarcie raportu to wtedy ok. 320 GB, a dziesięć otwarć dziennie przez zespół to ponad 3 TB dziennie i blisko 100 TB miesięcznie, czyli ok. 550 USD w modelu na żądanie. Ten sam dashboard oparty na tabeli dziennych agregatów o rozmiarze kilkudziesięciu megabajtów kosztuje praktycznie zero. Pamięć podręczna Looker Studio łagodzi problem, ale każda zmiana filtra czy zakresu dat wysyła nowe zapytania.

Jeśli dopiero zaczynasz pracę z eksportem, zasady bezpiecznego pisania zapytań znajdziesz w zestawie 10 zapytań do eksportu GA4, a koszty samego eksportu omawiamy w poradniku, jak połączyć GA4 z BigQuery.

Partycje i klastrowanie: jak przestać skanować całą historię

Partycjonowana tabela przechowuje dane w osobnych segmentach według kolumny daty, a BigQuery czyta tylko segmenty pasujące do filtra. Klastrowanie dodatkowo porządkuje dane w partycji według wybranych kolumn (maksymalnie czterech), dzięki czemu filtr na przykład po nazwie zdarzenia czyta jeszcze mniej bajtów.

Najprostszy pierwszy krok to przeniesienie potrzebnych kolumn z eksportu do własnej, partycjonowanej tabeli z wymuszonym filtrem partycji:

CREATE TABLE IF NOT EXISTS `twoj-projekt.raporty.zdarzenia_ga4`
PARTITION BY data
CLUSTER BY event_name
OPTIONS (require_partition_filter = TRUE)
AS
SELECT
  PARSE_DATE('%Y%m%d', event_date) AS data,
  event_timestamp,
  event_name,
  user_pseudo_id,
  (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS ga_session_id,
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page_location,
  device.category AS urzadzenie,
  session_traffic_source_last_click.cross_channel_campaign.source AS zrodlo,
  session_traffic_source_last_click.cross_channel_campaign.medium AS medium,
  ecommerce.transaction_id,
  ecommerce.purchase_revenue
FROM `twoj-projekt.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260101' AND '20261026';

Opcja require_partition_filter sprawia, że zapytanie bez warunku na kolumnie data zakończy się błędem zamiast skanować całość. To najskuteczniejsza bariera przed przypadkowym kosztem. Jeśli nie potrzebujesz bardzo starych szczegółowych danych, dodaj też opcję partition_expiration_days, która automatycznie usuwa partycje starsze niż wskazana liczba dni.

Tabele pośrednie: architektura danych dla raportów marketingowych

Tabele pośrednie to warstwy między surowym eksportem a raportami. Każda kolejna jest mniejsza i bliższa pytaniom biznesowym, a raporty korzystają wyłącznie z ostatniej.

1. Warstwa surowa – tabele events_* z eksportu GA4 i dane z innych źródeł. Nikt poza osobą utrzymującą proces nie pisze do nich zapytań na co dzień.
2. Warstwa oczyszczona – partycjonowane tabele zdarzeń, sesji i transakcji z ujednoliconymi nazwami kolumn. Jak zbudować tabelę sesji, pokazujemy w artykule o sesjach i źródłach ruchu w SQL.
3. Warstwa raportowa – dzienne agregaty według kanału, kampanii, urządzenia i produktu, połączone z kosztami. To do niej podłączasz Looker Studio.
4. Odświeżanie przyrostowe – zapytanie zaplanowane codziennie rano przelicza tylko ostatnie dni, a nie całą historię.

Przy przyrostowym odświeżaniu pamiętaj, że tabela dzienna GA4 może być aktualizowana jeszcze przez około trzy dni. Dlatego bezpieczny wzorzec usuwa i wstawia ponownie trzy ostatnie dni:

DECLARE od_daty DATE DEFAULT DATE_SUB(CURRENT_DATE('Europe/Warsaw'), INTERVAL 3 DAY);
DECLARE do_daty DATE DEFAULT DATE_SUB(CURRENT_DATE('Europe/Warsaw'), INTERVAL 1 DAY);

DELETE FROM `twoj-projekt.raporty.zdarzenia_ga4`
WHERE data BETWEEN od_daty AND do_daty;

INSERT INTO `twoj-projekt.raporty.zdarzenia_ga4`
SELECT
  PARSE_DATE('%Y%m%d', event_date) AS data,
  event_timestamp,
  event_name,
  user_pseudo_id,
  (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id'),
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location'),
  device.category,
  session_traffic_source_last_click.cross_channel_campaign.source,
  session_traffic_source_last_click.cross_channel_campaign.medium,
  ecommerce.transaction_id,
  ecommerce.purchase_revenue
FROM `twoj-projekt.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', od_daty) AND FORMAT_DATE('%Y%m%d', do_daty);

Przed zapisaniem harmonogramu sprawdź w szacunku edytora, że zapytanie czyta tylko trzy tabele dzienne. Tak samo buduje się warstwę raportową z kosztami kampanii, którą potem łączysz z innymi źródłami według zasad z artykułu o łączeniu danych z Google Ads, Meta i GA4.

Limity, które chronią budżet zespołu marketingu

Dobre tabele zmniejszają koszt typowego zapytania, a limity chronią przed nietypowym. Ustaw je, zanim do projektu dostanie się więcej osób, automatyzacje lub agenci AI.

Maksymalna liczba rozliczanych bajtów. W ustawieniach zapytania (w edytorze: Więcej, a następnie Ustawienia zapytania) możesz wpisać limit, np. 50 GB. Zapytanie, które przekroczyłoby limit, kończy się błędem bez naliczania opłaty. W skryptach i narzędziach ten sam limit ustawisz parametrem maximum_bytes_billed.

Przydziały projektu. W konsoli Google Cloud, w sekcji przydziałów dla BigQuery API, możesz obniżyć dzienny limit przetwarzanych danych dla całego projektu i osobno dla pojedynczego użytkownika. Przydział na użytkownika jest szczególnie przydatny, gdy z danych korzystają osoby uczące się SQL albo konto usługi narzędzia raportowego.

Uprawnienia. Nie każdy potrzebuje prawa do uruchamiania zapytań. Osobom, które oglądają tylko dashboardy, wystarczy dostęp do raportu, a nie do projektu BigQuery.

Alerty budżetowe. Budżet w Cloud Billing wysyła powiadomienia po przekroczeniu progów, np. 50, 90 i 100 procent kwoty. Nie blokuje jednak wydatków – to sygnał ostrzegawczy, a nie hamulec.

Osobną kategorią ryzyka są narzędzia, które same piszą zapytania: asystenci SQL, skrypty i modele językowe (LLM) podłączone do danych. Jeśli łączysz model z BigQuery przez MCP, konto, z którego korzysta, powinno mieć własny niski przydział. Konfigurację takiego połączenia opisujemy w tekście o MCP w marketingu, a ryzyka generowanego SQL – w artykule o Gemini w BigQuery.

Jak monitorować, kto i ile przetwarza

BigQuery zapisuje historię zadań w widokach INFORMATION_SCHEMA. Poniższe zapytanie pokazuje, ile danych rozliczono dla każdego użytkownika w ostatnich 30 dniach. Kwalifikator regionu musi odpowiadać lokalizacji Twoich danych, np. region-eu albo region-europe-central2.

SELECT
  user_email,
  COUNT(*) AS zapytania,
  ROUND(SUM(total_bytes_billed) / POW(1024, 4), 3) AS tib_rozliczone,
  ROUND(SUM(total_bytes_billed) / POW(1024, 4) * 6.25, 2) AS szacunek_usd
FROM `region-eu`.INFORMATION_SCHEMA.JOBS
WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
  AND state = 'DONE'
GROUP BY user_email
ORDER BY tib_rozliczone DESC;

Szacunek nie uwzględnia bezpłatnego terabajta, więc traktuj go jako górną granicę. Zamieniając grupowanie na kolumnę query, znajdziesz konkretne zapytania, które kosztują najwięcej. Zadania uruchamiane przez Looker Studio zwykle rozpoznasz po koncie użytkownika lub etykietach w kolumnie labels. Dobrą praktyką jest cotygodniowy raport z tego widoku z alertem, gdy dzienne skanowanie przekroczy ustalony próg – mechanizm jest taki sam jak w monitoringu tagów z alertami w BigQuery.

Raz w miesiącu przejrzyj też listę tabel i usuń kopie robocze, bo przechowywanie zapomnianych tabel testowych bywa najczęstszą pozycją, której nikt nie potrafi wyjaśnić. Jeśli korzystasz z automatycznych raportów, np. z Google Ads przez Apps Script, sprawdź, czy nie odpytują hurtowni częściej, niż potrzeba; przykłady takich przepływów opisujemy w artykule o automatycznych raportach z Google Ads.

Problem kosztów często idzie w parze z problemem limitów API w łączniku GA4. Przeniesienie dashboardu na tabele raportowe rozwiązuje oba jednocześnie, co szerzej opisujemy w tekście o limitach GA4 w Looker Studio. Kolejne poradniki o pracy z hurtownią znajdziesz w podtemacie BigQuery i SQL.