Dlaczego to zadanie na teraz, a nie na później

Najczęstsza reakcja, na jaką trafiam, brzmi: „mamy jeszcze czas”. Formalnie tak. Praktycznie nie, i to z trzech powodów.

Pierwszy jest oczywisty: im dłużej czekasz, tym więcej masz do wyeksportowania. Dopóki UA zbiera dane, archiwum trzeba będzie i tak uzupełnić o ostatnie miesiące. Lepiej zrobić duży eksport historyczny raz, spokojnie, a potem dokładać przyrosty.

Drugi jest mniej oczywisty. Część danych w Universal Analytics podlega ustawieniu przechowywania danych na poziomie użytkownika i zdarzenia — domyślnie 26 miesięcy. Raporty zagregowane to inna sprawa, ale jeśli ktoś kiedyś ustawił krótszy okres, to głębsza historia w niektórych przekrojach już mogła zostać przycięta. Warto sprawdzić to ustawienie, zanim założysz, że masz w panelu pięć lat.

Trzeci to zwykła kolejka zadań. Wyłączenie UA zbiegnie się z sezonem, konfiguracją GA4, poprawianiem konwersji i pytaniami zarządu, dlaczego liczby się nie zgadzają. Archiwizacja jest wtedy pierwszą rzeczą, która wypada z listy — a to jedyne zadanie z tej listy, którego nie można zrobić później. Wszystko inne da się nadgonić, danych sprzed wyłączenia nie odtworzysz.

Dodam jeszcze jedno, żeby nie było niedomówień: eksportu z darmowego Universal Analytics nie da się zrobić na poziomie surowych trafień. Standardowa usługa nie ma eksportu do BigQuery — to funkcja Analytics 360. Wszystko, co wyciągniesz, będzie zagregowane w takich przekrojach, jakie sam zadasz. To ma bezpośrednie konsekwencje dla tego, co warto pobrać.

Zdecyduj, co naprawdę chcesz zachować

„Zarchiwizujmy wszystko” nie jest planem, bo „wszystko” w modelu zagregowanym nie istnieje — każda kombinacja wymiarów to osobne zapytanie i osobna tabela. Zamiast tego pytam klienta, do czego archiwum będzie służyć, i zwykle wychodzi z tego kilka konkretnych zestawów.

• Podsumowanie dzienne — sesje, użytkownicy, odsłony, współczynnik odrzuceń, konwersje i przychód w podziale na dzień. Najmniejszy zestaw i ten, który ratuje najwięcej rozmów o „wynikach rok do roku”.

• Źródła i kanały — dzień plus source / medium / campaign, z sesjami i konwersjami. To baza pod porównania kanałów po przejściu na GA4.

• Strony docelowe i treści — dzień plus landing page albo page path, z odsłonami i wejściami. Przy pracy nad SEO to najczęściej odpytywana część archiwum.

• Cele i e-commerce — realizacje poszczególnych celów, transakcje, przychód, ewentualnie produkty. Tu pilnuj, żeby zapisać też definicje celów, bo numer celu bez opisu po roku nic nie znaczy.

• Wymiary niestandardowe i grupy treści, jeśli są używane — o tych zapomina się najczęściej, a to zwykle dane najbliższe biznesowi.

Osobna decyzja dotyczy widoków. Universal Analytics ma widoki z własnymi filtrami, strefą czasową i ustawieniami wyszukiwania w witrynie, więc te same daty w dwóch widokach dadzą różne liczby. Archiwizuj ten widok, na którym faktycznie raportowałeś, i zapisz obok jego identyfikator oraz listę filtrów. Bez tego po dwóch latach nikt nie odtworzy, skąd wzięła się różnica.

Eksport z panelu — kiedy wystarcza

Najprostsza droga to ręczny eksport z interfejsu: otwierasz raport, ustawiasz zakres dat i wymiary, klikasz eksport do CSV, Arkuszy Google albo Excela. Dla małej witryny z jednym widokiem i kilkoma raportami to bywa całkowicie wystarczające i zajmuje jedno popołudnie.

Ograniczenia poznasz szybko. Eksport z interfejsu obejmuje maksymalnie 5000 wierszy na raz, więc dłuższy okres w rozbiciu na dni i strony trzeba dzielić na kawałki. Nazwy kolumn są przetłumaczone i sformatowane pod człowieka, a nie pod bazę danych — procenty, czasy w formacie godzinowym, przecinki dziesiętne. Do arkusza to wejdzie, do tabeli SQL trzeba to najpierw wyprostować.

Pośrednim rozwiązaniem, które lubię, jest dodatek Google Analytics do Arkuszy Google. Definiujesz zapytanie w wierszach konfiguracji — widok, zakres dat, metryki, wymiary, sortowanie, limit — i dodatek pobiera dane przez API prosto do arkusza. Zaletą jest powtarzalność: raz opisane zapytanie można uruchomić ponownie dla kolejnego miesiąca albo poprawić bez klikania po panelu. To też najłatwiejszy sposób, żeby zobaczyć, jak w praktyce wygląda odpowiedź API, przed napisaniem czegokolwiek w kodzie.

Trzymam się jednej zasady: eksport ręczny robię tylko wtedy, gdy wiem, że nie będę go powtarzał. Jeśli operacja ma się wykonać więcej niż dwa razy, przechodzę na API.

Reporting API — pełna i powtarzalna kopia

Przy większym koncie sensowną drogą jest skrypt odpytujący API raportowania Universal Analytics. Nie trzeba być programistą, wystarczy podstawowa znajomość Pythona albo Node.js i konto usługi w Google Cloud z dostępem do widoku.

Kilka rzeczy, które warto wiedzieć, zanim zaczniesz pisać.

• Limity zapytania. W jednym zapytaniu zmieścisz do 7 wymiarów i 10 metryk, a odpowiedź zwraca maksymalnie 10 000 wierszy na stronę. Większe zbiory pobiera się stronicowaniem po tokenie.

• Limity dobowe. Na widok przypada 50 000 zapytań na dobę, a jednocześnie może działać 10 żądań. Przy eksporcie kilku lat dzień po dniu to zwykle wystarcza, ale warto obsłużyć błędy limitu i ponawiać żądania z opóźnieniem.

• Próbkowanie. W darmowym Universal Analytics zapytania ad hoc są próbkowane po przekroczeniu 500 tysięcy sesji na poziomie usługi w wybranym zakresie dat. Dlatego pobieram dane osobno dla każdego dnia, a nie jednym zapytaniem o cały rok — dzienne zakresy są znacznie poniżej progu, więc odpowiedź wraca nieprzybliżona. Odpowiedź API zawiera informację, czy dane zostały spróbkowane; zapisuj tę flagę razem z danymi.

• Metryki unikalne się nie sumują. Użytkownicy za rok nie są sumą użytkowników z 365 dni, bo ta sama osoba wraca. Jeśli potrzebujesz miesięcznych i rocznych wartości unikalnych, pobierz je osobnymi zapytaniami dla tych zakresów i zapisz jako oddzielne wiersze. Inaczej po latach ktoś zsumuje kolumnę i wyjdą mu bzdury.

• Wiersz „other”. Przy dużej liczbie unikalnych wartości wymiaru UA zwija resztę do zbiorczego wiersza. To normalne zachowanie systemu, nie błąd skryptu — ale trzeba o tym pamiętać, patrząc na sumy w archiwum.

Gdzie to składować

Wybór miejsca docelowego zależy od tego, kto będzie z archiwum korzystał.

Arkusz Google albo plik CSV na dysku firmowym to minimum, które i tak jest lepsze niż nic. Sprawdza się przy małych zestawach i przy odbiorcach, którzy nie napiszą zapytania SQL. Wada jest oczywista: przy kilkuset tysiącach wierszy arkusz staje się nieużywalny.

Własna baza — MySQL, MariaDB albo PostgreSQL to mój domyślny wybór, gdy klient ma już jakiś serwer i kogoś, kto go pilnuje. Robię jedną tabelę na zestaw wymiarów, z kolumną daty, kolumnami wymiarów, kolumnami metryk i kolumną z identyfikatorem widoku. Klucz unikalny na dacie i wymiarach pozwala uruchamiać eksport ponownie bez tworzenia duplikatów — to samo podejście, którego używam w każdym imporcie danych.

BigQuery ma sens, gdy danych jest dużo albo gdy archiwum ma stać obok innych źródeł. Podkreślę raz jeszcze, bo to bywa źródłem nieporozumień: darmowe Universal Analytics nie ma automatycznego eksportu do BigQuery, więc dane trzeba tam wstawić samodzielnie — z tego samego skryptu, który odpytuje API. Nowa usługa GA4 taki eksport ma w wersji bezpłatnej i to jeden z niewielu argumentów, dla których naprawdę warto się do niej przekonać.

Nad każdym z tych wariantów można postawić warstwę raportową. Looker Studio łączy się i z arkuszem, i z BigQuery, i z bazą SQL, więc jeden raz zbudowany raport historyczny będzie działał niezależnie od tego, że źródłowa usługa przestanie istnieć. To dobre miejsce, żeby zestawić archiwum UA z danymi z GA4 obok siebie, z wyraźną adnotacją, że to dwie różne metodologie.

Konektory zamiast pisania kodu

Jeśli w firmie nie ma nikogo, kto napisze i utrzyma skrypt, zostają gotowe konektory. Narzędzia w rodzaju Supermetrics, Fivetran czy Coupler.io potrafią pobrać dane z Universal Analytics do arkusza, BigQuery albo bazy według harmonogramu, bez linijki kodu.

Rozważam je, gdy liczy się czas wdrożenia i gdy zestawów danych jest kilkanaście. Płacisz abonament, ale dostajesz obsługę limitów API, ponawianie nieudanych pobrań i konfigurację przez interfejs. Przy jednorazowej archiwizacji bywa, że wystarczy jeden miesiąc subskrypcji — i to jest całkowicie uczciwy sposób wykorzystania takiego narzędzia.

Na co patrzę przy wyborze: czy narzędzie pozwala pobierać dane w dziennej granulacji, czy pokazuje flagę próbkowania, czy radzi sobie z wymiarami niestandardowymi i czy dane wychodzą w formie, którą po wygaśnięciu subskrypcji nadal będziesz mieć u siebie. Ten ostatni punkt jest najważniejszy. Archiwum, które żyje wyłącznie wewnątrz cudzej usługi, nie jest archiwum — to kolejna zależność, tylko z inną fakturą.

Plan minimum i pułapki

Gdybym miał sprowadzić to do listy zadań na najbliższe tygodnie, wyglądałaby tak. Sprawdzam ustawienie przechowywania danych i wypisuję widoki, z których faktycznie korzystamy. Ustalam z klientem cztery, pięć zestawów danych, które mają wartość. Robię jednorazowy eksport całej historii w dziennej granulacji, do bazy albo BigQuery. Ustawiam dokładanie kolejnych dni, żeby archiwum było kompletne aż do dnia wyłączenia. Na koniec buduję jeden raport historyczny w Looker Studio i pokazuję go klientowi — bo dane, których nikt nigdy nie otworzył, mają tendencję do cichego znikania przy kolejnej reorganizacji dysku.

Pułapki, na które trafiam najczęściej. Strefa czasowa widoku bywa inna niż strefa raportowania w innych systemach, więc granice dnia się nie pokrywają — zapisz, jaka była. Definicje celów i filtrów trzeba wyeksportować osobno, jako dokumentację, bo API raportowania zwraca liczby, nie znaczenia. Atrybucja w UA i w GA4 nie jest tym samym mechanizmem, więc porównując oba źródła po latach, ktoś na pewno zapyta o różnice — lepiej opisać je od razu, w notatce dołączonej do archiwum.

I rzecz, którą widzę na większości kont, które przejmuję: eksport robi jedna osoba, na swoim koncie, do swojego arkusza. Dopilnuj, żeby archiwum stało w miejscu należącym do firmy, z dostępem dla więcej niż jednego człowieka. Za dwa lata nikt nie będzie pamiętał, kto to pobierał, a wtedy jedynym pytaniem będzie, czy pliki jeszcze istnieją.