Po co komu BigQuery, jeśli ma się panel GA4

Interfejs GA4 pokazuje dane po obróbce: policzone, zagregowane, ograniczone zestawem wymiarów, które ktoś w Google uznał za sensowne. Do części pytań to wystarcza. Do części nie wystarcza w ogóle.

W BigQuery dostaję coś innego: jeden wiersz na jedno zdarzenie, z pełną listą parametrów, identyfikatorem przeglądarki, znacznikiem czasu z dokładnością do mikrosekundy i całym kontekstem urządzenia. Nic nie jest zaokrąglone i nic nie zostało wcześniej pogrupowane. Widać to dopiero przy konkretnych pytaniach: ile razy ktoś wracał do tego samego produktu przed zakupem, w jakiej kolejności padały zdarzenia przed porzuceniem koszyka, jak wyglądały ścieżki osób, które weszły z reklamy, a kupiły z wyszukiwarki. W panelu każde z tych pytań albo wymaga karkołomnych eksploracji, albo nie da się na nie odpowiedzieć.

Dochodzi drugi argument, mniej ekscytujący, ale w praktyce ważniejszy: archiwum. Standardowa właściwość GA4 przechowuje dane zdarzeń maksymalnie czternaście miesięcy i to trzeba samodzielnie ustawić, bo domyślnie jest krócej. Tabele w BigQuery zostają tak długo, jak długo za nie płacisz.

Ile to naprawdę kosztuje

Słowo „darmowa” w kontekście tej integracji wymaga uczciwego doprecyzowania, bo pomyłka kończy się rachunkiem.

• Sam eksport z GA4 nie kosztuje nic — w wersji standardowej, dla wszystkich, bez limitu opłat. To jest ta część, która w Universal Analytics była zarezerwowana dla 360.

• Płacisz Google Cloud za przechowywanie i za zapytania — czyli za miejsce, które zajmują tabele, i za liczbę bajtów, które przeskanuje każde uruchomione zapytanie.

• Warstwa bezpłatna obejmuje 10 GB przestrzeni i 1 TB przeskanowanych danych miesięcznie. Dla małej i średniej witryny to zwykle mieści się z zapasem, o ile nie pisze się zapytań, które za każdym razem czytają całą historię.

Jest też ograniczenie po stronie GA4, o którym łatwo dowiedzieć się za późno: właściwość standardowa może eksportować dziennie do miliona zdarzeń. Przy większym ruchu eksport zostaje wstrzymany, a Google przysyła powiadomienie. Dotyka to głównie dużych sklepów, ale własny wolumen zdarzeń warto policzyć zawczasu.

Osobna sprawa to tryb strumieniowy, który dorzuca zdarzenia w ciągu kilku minut od ich wystąpienia. Wymaga konta rozliczeniowego i jest płatny od pierwszego wiersza. Do analizy marketingowej eksport dzienny wystarcza i od niego zaczynam zawsze.

Projekt w Google Cloud i region

Zaczynam od strony Google Cloud, bo bez gotowego projektu w GA4 nie ma czego wybrać.

Zakładam nowy projekt, nazywam go tak, żeby po roku było wiadomo, czyje dane w nim leżą, i włączam w nim BigQuery API. Do połączenia potrzebne są uprawnienia właściciela lub edytora projektu — jeśli firma ma administratora Cloud, to moment, w którym trzeba go poprosić o dostęp, a nie obchodzić temat prywatnym kontem Gmail.

Najważniejsza decyzja na tym etapie dotyczy lokalizacji zbioru danych. Regionu nie da się później zmienić — jedyna droga to skasowanie połączenia, założenie nowego i pogodzenie się z tym, że stare tabele zostają tam, gdzie były. Dla klientów z Polski wybieram region europejski i nie zastanawiam się dłużej.

Warto wiedzieć, czego ten wybór nie rozwiązuje. Trzymanie tabel w Europie nie zamyka dyskusji o zgodności z RODO, która toczy się od decyzji austriackiego i francuskiego organu ochrony danych w sprawie Google Analytics. Nowe ramy prawne transferu danych do Stanów Zjednoczonych są dopiero przygotowywane i na dziś nie obowiązują.

Łączenie właściwości z BigQuery

Po stronie Analyticsa wchodzę w Administrację, sekcję połączeń z usługami i wybieram połączenia z BigQuery. Potrzebna jest rola administratora właściwości.

Kreator prowadzi przez cztery decyzje. Wskazuję projekt Cloud, wybieram lokalizację, zaznaczam strumienie danych do eksportu i ustawiam częstotliwość — dzienną, strumieniową albo obie. Przy aplikacjach mobilnych dochodzi zgoda na dołączanie identyfikatorów reklamowych. Jest też opcja wykluczania wybranych zdarzeń; używam jej rzadko, bo w tabelach wolę mieć wszystko, ale ma sens przy zdarzeniach technicznych generowanych masowo przez skrypty na stronie — to one najszybciej zjadają dzienny limit.

Rzecz, która zaskakuje najczęściej: eksport nie ma trybu wstecznego. Pierwsza tabela pojawia się dopiero za dane z następnej doby, a wszystko, co zebrało się wcześniej, zostaje wyłącznie w panelu. Dlatego integrację podłączam w pierwszym tygodniu każdego projektu, nawet gdy nikt jeszcze nie wie, do czego jej użyje. To kwadrans pracy, którego nie da się odrobić później.

Co zastaniesz w wyeksportowanych tabelach

Następnego dnia w BigQuery pojawia się zbiór danych o nazwie zbudowanej z identyfikatora właściwości, a w nim tabele dzienne — jedna na każdą dobę, z datą w nazwie. Przy eksporcie strumieniowym dochodzi osobna tabela z danymi z bieżącego dnia, jeszcze niepełnymi.

Struktura pojedynczego wiersza jest bogatsza, niż wygląda na pierwszy rzut oka. Poza nazwą i czasem zdarzenia znajdziesz w niej identyfikator przeglądarki, dane o urządzeniu i geolokalizacji, informacje o źródle pierwszej wizyty użytkownika, właściwości użytkownika oraz — w sklepach — tablicę pozycji z zamówienia.

Największa różnica względem arkusza polega na tym, że parametry zdarzeń nie są zwykłymi kolumnami. Siedzą w strukturze zagnieżdżonej: lista par klucz–wartość, w której wartość może być tekstem albo liczbą. Adres strony, tytuł, identyfikator sesji czy nazwa promocji — wszystko wyciąga się z tej samej struktury, a kto pisał dotąd SQL na płaskich tabelach, przy pierwszym zapytaniu zobaczy błąd i uzna, że coś jest zepsute. Nie jest — trzeba tylko rozwinąć strukturę operatorem rozbijającym tablice na wiersze.

Pierwsze zapytania i pilnowanie rachunku

Zanim napiszę cokolwiek ambitnego, sprawdzam podglądem, jak wygląda kilka wierszy z ostatniej tabeli. Podgląd nie kosztuje nic, w przeciwieństwie do zapytania.

Potem obowiązują trzy nawyki, których nauczyłem się w większości boleśnie. Po pierwsze: nigdy nie pobieram wszystkich kolumn, bo w BigQuery płaci się za przeskanowane kolumny, a nie za zwrócone wiersze. Po drugie: zawsze zawężam zakres tabel dziennych, zamiast odpytywać całą historię z gwiazdką w nazwie. Po trzecie: przed uruchomieniem patrzę na szacunek ilości danych, który edytor pokazuje w prawym górnym rogu — to jedna liczba, która chroni przed pomyłką za kilka dolarów.

Kiedy zapytanie już działa, zapisuję je jako widok i dopiero na nim buduję raporty. Dzięki temu nie kopiuję tej samej logiki do pięciu miejsc i mam jedno miejsce do poprawienia, gdy w tagowaniu zmieni się nazwa zdarzenia.

Do prezentacji podłączam Looker Studio bezpośrednio do BigQuery. Jedna uwaga z doświadczenia: raport odświeżany co kilkanaście sekund przez kilka osób naraz potrafi generować zaskakujące koszty. Włączam buforowanie i przygotowuję dane w tabelach pośrednich, zamiast liczyć wszystko na bieżąco.

Czego eksport nie naprawi

BigQuery nie jest lekiem na złą analitykę i chcę to powiedzieć wprost, bo słyszę odwrotne obietnice.

Surowe dane są tak dobre, jak tagowanie, które je wytworzyło. Jeśli zdarzenie zakupu odpala się dwa razy albo wartość transakcji przychodzi raz z podatkiem, raz bez, to w tabelach będzie ten sam bałagan, tylko w wyższej rozdzielczości. Eksport nie poprawia jakości pomiaru — on ją obnaża.

Nie dostajesz też gotowych metryk. Sesje, użytkownicy zaangażowani, przypisanie źródła do konwersji — w panelu są policzone, a tutaj trzeba je napisać samemu, pilnując definicji, których używa GA4. To najczęstsze źródło rozbieżności między jednym i drugim narzędziem.

I wreszcie kompetencje. Integracja bez kogoś, kto umie napisać SQL, jest tylko rosnącym rachunkiem za przechowywanie. Mimo tego podłączam ją każdemu klientowi od razu, bo dane, których się nie zbiera, nie pojawią się wstecz. Umiejętności można nadrobić w każdej chwili, historii ruchu — nie.