GA4 i Claude Code – analityka www wsparta przez AI

Strona bez statystyk to trochę jazda samochodem z zaklejonym licznikiem – jakoś się jedzie, ale nie wiadomo, czy szybko i czy w ogóle w dobrą stronę. Są jednak statystyki gorsze niż ich brak: takie, które pokazują nieprawdziwe liczby. Bo na ich podstawie podejmuje się decyzje, a człowiek czuje się pewnie, choć nie ma ku temu powodu.

Przekonałem się o tym na sklepie flora-art.pl (otwiera się w nowej karcie) (kwiaciarnia i pracownia florystyczna), który – jak pisałem w poprzednim wpisie – budowałem razem z Claude Code. Przez cały kwartał raport pokazywał przychód, tylko że nie dało się powiedzieć, z jakich produktów się składa. Nic tego nie zgłaszało, nikt nie zauważył. Wyszło dopiero wtedy, gdy zacząłem sprawdzać dane razem z AI.

W tym wpisie opowiem, jak to wygląda od strony praktycznej: co sklep wysyła do statystyk, na jakie pułapki trafiłem, jak podłączyć do tego Claude Code i co z tego wynika. Starałem się pisać tak, żeby dało się to czytać także bez programistycznego zaplecza – jedyny bardziej techniczny kawałek to instrukcja podłączenia, którą można spokojnie przeskoczyć.

GA4 – co to jest i po co go podłączam

GA4 to Google Analytics 4, czyli darmowe narzędzie Google do statystyk stron i sklepów. Działa na zasadzie „zdarzeń”: drobnych informacji o tym, co robi odwiedzający – wszedł na stronę, obejrzał produkt, dodał go do koszyka, zapłacił. Z tych klocków GA4 składa raporty: ilu było użytkowników, skąd przyszli, co oglądali i w którym miejscu zrezygnowali.

Mnie interesuje to z 3 powodów. Po pierwsze, ruch w sklepie jest niewielki, więc każde zamówienie coś znaczy i chcę wiedzieć, skąd się wzięło. Po drugie, dane służą do decyzji o reklamach (Google Ads). Po trzecie – do pracy nad SEO, czyli widocznością w wyszukiwarce. Poza GA4 sklep korzysta jeszcze z kilku innych narzędzi (Hotjar, Meta Pixel, Vercel Analytics, Sentry), ale dziś zostajemy przy GA4. Działa ono dopiero po zgodzie użytkownika na ciasteczka analityczne, którą zbiera CookieYes.

Jak sklep „opowiada” o zakupach

GA4 ma gotowy standard zdarzeń dla sklepów internetowych i trzymam się go ściśle – dzięki temu dostaję gotowe raporty, a nie muszę ich sam wymyślać. Zdarzenia układają się w kolejność, która dokładnie odwzorowuje drogę klienta:

1. klient przegląda listę produktów (view_item_list)
2. klika w konkretny produkt (select_item)
3. ogląda jego stronę (view_item)
4. dodaje do koszyka albo go usuwa (add_to_cart, remove_from_cart)
5. zagląda do koszyka (view_cart)
6. zaczyna zamówienie (begin_checkout)
7. wybiera dostawę (add_shipping_info)
8. wybiera płatność (add_payment_info)
9. płaci (purchase)

Dzięki temu w GA4 widać lejek – ilu klientów dotarło do każdego kroku i gdzie najwięcej odpada. Osobna historia to strona z ofertą dla firm: tam liczy się zapytanie ofertowe (generate_lead) oraz kliknięcie w telefon albo maila (contact_click) – tego drugiego GA4 w standardzie nie ma, więc to własna nazwa, którą wprowadziłem świadomie.

Jest jedna ważna różnica: ostatni krok, czyli zakup, nie jest zgłaszany przez przeglądarkę klienta. Zgłasza go serwer sklepu, w momencie gdy bramka płatnicza potwierdzi wpłatę. Dlaczego tak – wyjaśnia pierwsza z pułapek poniżej.

Pułapki, na które trafiłem

Najgorsze w analityce jest to, że nie psuje się głośno. GA4 przyjmie niemal wszystko i niemal niczego nie oprotestuje – wykresy się rysują, liczby rosną i wszystko wygląda w porządku. Oto co mi się przytrafiło:

• Przychód bez produktów. Przez ok. 90 dni każdy zakup miał w GA4 kwotę, ale zero pozycji. Wiadomo było, ile zarobiliśmy, ale nie z czego. Przyczyną nie było samo zdarzenie, tylko miejsce w sklepie, które nie dociągało listy produktów z zamówienia
• Zakup zgłaszany z przeglądarki. Pierwotnie robiła to przeglądarka klienta po powrocie z bramki płatności. Gubiła klientów, którzy po zapłaceniu zamknęli kartę, pomijała zamówienia opłacone poza bramką, a przy odświeżeniu strony liczyła zakup drugi raz. Dlatego dziś robi to serwer
• Zakupy „bez źródła”. Zakup wysyłany z serwera nie wiedział, w której sesji klient był, więc GA4 wrzucał przychód do kosza „Unassigned”. Raport pokazywał zero przychodu z wyszukiwarki, choć zamówienia z niej były
• Jeden bukiet, kilka produktów. W raportach ten sam bukiet występował pod kilkoma nazwami – inną w wyświetleniach, inną w zakupach, a angielska wersja strony dokładała jeszcze jedną. Bukiet miał wyświetlenia i zero zakupów, a jego warianty odwrotnie
• Własny ruch. Lokalne klikanie po sklepie podczas pracy lądowało w statystykach produkcyjnych – w jednym miesiącu to było ok. 17,5% odsłon. Do tego panele admina: ok. 11% odsłon w jednym miesiącu i ok. 21% w kolejnym (własny ruch jest stały, a klientów mało, więc jego udział rośnie)
• Konwersja w Google Ads, której nie było w kodzie. Jedna z akcji, na której uczą się reklamy, liczyła w praktyce odsłony koszyka, a nie dodanie produktu, i niemal połowa jej wartości pochodziła z mojego własnego ruchu. Kampanie akurat nie chodziły, więc szkody nie było – ale gdyby wróciły, reklamy uczyłyby się na odświeżaniu strony
• Cisza w odpowiedzi. Serwer GA4 potwierdza przyjęcie zdarzenia także wtedy, gdy ma ono błędy, więc zły zakup znika bez śladu. Podobnie ze zgodami: piksel Meta ładował się jeszcze przed kliknięciem w baner z ciasteczkami, a na to nic nie zwracało uwagi, dopóki nie zrobiłem audytu

Najbardziej niewygodna lekcja jest taka, że dane z okresu, w którym błąd istniał, już się nie naprawią. Poprawka działa od dziś, a nie wstecz – analityka ma swoją „datę ważności” poprawek.

Dlaczego ręczna analiza w GA bywa trudna

Teoretycznie wszystko to dałoby się wyłapać samemu, klikając po panelu GA4. W praktyce jest z tym kilka kłopotów. Interfejs jest rozbudowany, raportów jest mnóstwo, a nazwy wymiarów i metryk nie zawsze mówią to, czego się spodziewamy. Filtry działają nieintuicyjnie – na przykład filtr danych działa po adresie IP, a nie po adresie strony, więc nie da się po prostu „wyciąć” panelu admina. Raport przefiltrowany po nazwie domeny nie pokaże zakupów wysyłanych z serwera, bo serwer nie wie, na jakiej stronie klient był – i można godzinami szukać błędu, którego nie ma.

Największy kłopot jest jednak inny: GA4 nic nie wie o mojej bazie zamówień. Nie sprawdzi, czy liczba zakupów w statystykach zgadza się z liczbą opłaconych zamówień. Takie porównanie robi się ręcznie, w arkuszu, i trudno oczekiwać, że ktoś będzie to robił co miesiąc.

Rola AI w interpretacji danych

I tu wchodzi Claude Code. Jego przewaga nie polega na tym, że „zna się na analityce” – zna się tyle, ile mu opiszę i pokażę. Przewaga polega na tym, że ma pod ręką jednocześnie kod strony, dane z GA4 i bazę zamówień i potrafi je cierpliwie zestawiać:

• czy zdarzenia z kodu odpowiadają temu, co faktycznie widać w raportach
• czy liczba zakupów w GA4 zgadza się z liczbą opłaconych zamówień
• czy produkty występują pod tą samą nazwą we wszystkich zdarzeniach
• czy do statystyk nie wpada ruch deweloperski

Wiele z opisanych wyżej problemów nie dałoby się znaleźć, patrząc tylko na jedno źródło. Błąd w akcji Google Ads wyszedł dopiero z porównania ustawień z danymi, a brakujące produkty – z zestawienia GA4 z bazą. Sam kod wyglądał dobrze, same raporty też wyglądały dobrze.

Znalezienie błędu to dopiero początek. Pracuję w pętli: znalezisko, poprawka, test pilnujący, żeby błąd nie wrócił, wpis w dokumentacji z datą i sprawdzenie na produkcji po wdrożeniu. Dokumentacja jest tu kluczowa – w pliku CLAUDE.md mam krótkie reguły, a szczegóły o analityce siedzą w osobnym dokumencie: co jest wysyłane, jakie były błędy (z datą, dowodem i statusem), jakie ślepe zaułki. Zasada brzmi: dokument aktualizuje się razem ze zmianą, bo opis zeszłorocznego stanu jest gorszy niż brak opisu. Dzięki temu każda nowa sesja Claude’a zaczyna od wiedzy, a nie od zera.

Jak podłączyć Claude Code do GA4

Są 3 drogi i każda ma swoje plusy i minusy.

Przez przeglądarkę

Claude Code może pracować w przeglądarce, w której jestem zalogowany, i klikać w panelu GA4 tak jak człowiek.

• Plusy: zero konfiguracji, widzi wszystko to co ja (także ustawienia i Google Ads), działa nawet tam, gdzie żadnego API nie ma
• Minusy: wolno, bo każda odpowiedź to seria kliknięć i czytania ekranu; kruche, bo zmiana wyglądu panelu może wszystko popsuć; trudne do powtórzenia; no i działa z moimi pełnymi uprawnieniami, więc teoretycznie mógłby kliknąć coś, czego nie powinien

Przez konto serwisowe

Konto serwisowe to „użytkownik-robot” z własnym kluczem, któremu w GA4 i Search Console nadaję dostęp tylko do odczytu. Claude pisze skrypty, które pytają GA4 o dane przez oficjalne API.

• Plusy: dostęp wyłącznie do odczytu, szybko, powtarzalnie (skrypt można odpalić tak samo za pół roku), a wyniki da się porównać z bazą zamówień
• Minusy: jednorazowa konfiguracja w Google Cloud i klucz, którego trzeba pilnować jak hasła

Przez eksperymentalne MCP

Google udostępnia oficjalny serwer MCP dla GA4 – google-analytics-mcp (otwiera się w nowej karcie). Jest lokalny, tylko do odczytu i wciąż oznaczony jako eksperymentalny. Pozwala zadawać pytania do danych wprost w języku naturalnym, bez pisania skryptów.

• Plusy: gotowe narzędzie od Google, pytania po ludzku, tylko odczyt
• Minusy: eksperyment (może się zmieniać), konfiguracja w Google Cloud podobna jak przy koncie serwisowym, obejmuje tylko GA4, a nie bazę ani Search Console

Na flora-art.pl używam konta serwisowego. MCP na razie nie jest tam podpięte – jak tylko je sprawdzę w praktyce, opiszę to w osobnym wpisie.

Instrukcja: konto serwisowe w GA4 i Search Console

Tu kończy się część opowieści, a zaczyna ściąga – trochę dla Was, trochę dla mnie na przyszłość 🙂

1. Instalujemy gcloud. To narzędzie Google do zarządzania projektem w chmurze (pakiet nazywa się Google Cloud SDK). Jeśli korzystamy z Homebrew, wystarczą 2 komendy:

brew install --cask google-cloud-sdk
gcloud --version

Nie każdy ma lub chce mieć Homebrew – w takim razie można pobrać archiwum prosto od Google (osobne dla procesorów Apple Silicon i Intel), rozpakować je i uruchomić skrypt install.sh. Najlepiej skorzystać z oficjalnej instrukcji: Install the gcloud CLI (otwiera się w nowej karcie). Dla użytkowników Homebrew jest też osobna strona (otwiera się w nowej karcie). Na koniec instalacji sprawdzamy, czy narzędzie działa (gcloud --version).

2. Logujemy się i włączamy potrzebne API. Potrzebny jest projekt w Google Cloud (może być nowy, darmowy). W nim włączamy API, z którego będziemy czytać dane GA4 i Search Console:

gcloud auth login
gcloud config set project NAZWA_PROJEKTU
gcloud services enable analyticsdata.googleapis.com searchconsole.googleapis.com

3. Tworzymy konto serwisowe i klucz.

gcloud iam service-accounts create czytelnik-analityki
gcloud iam service-accounts keys create klucz.json \
  --iam-account=czytelnik-analityki@NAZWA_PROJEKTU.iam.gserviceaccount.com

Plik klucz.json przenosimy w bezpieczne miejsce poza repozytorium i ustawiamy mu prawa tylko dla nas (chmod 600). To pełnoprawne poświadczenie – samo skasowanie pliku z dysku go nie unieważnia, trzeba usunąć klucz po stronie Google.

4. Nadajemy dostęp w GA4. Wchodzimy do Analytics: Administracja → Zarządzanie dostępem do usługi → dodajemy użytkownika. Wpisujemy adres e-mail konta serwisowego (ten z końcówką iam.gserviceaccount.com) i nadajemy rolę Czytelnik. Dostęp nadaje się w samym Analytics, a nie w panelu IAM w Google Cloud – o czym łatwo zapomnieć.

5. Nadajemy dostęp w Search Console. Ustawienia → Użytkownicy i uprawnienia → Dodaj użytkownika. Ten sam adres e-mail, uprawnienia Ograniczone, czyli tylko podgląd. Przy okazji warto połączyć GA4 z Search Console w ustawieniach połączeń usług Google – dane o wyszukiwaniach pojawią się wtedy także w raportach GA4.

6. Dajemy Claude’owi znać, gdzie leży klucz. Wskazujemy ścieżkę do pliku w zmiennej środowiskowej GOOGLE_APPLICATION_CREDENTIALS, a identyfikator usługi GA4 przekazujemy w konfiguracji lokalnej. Reszta to już zwykła rozmowa: prosimy o napisanie skryptu, który zapyta o dane, i o jego uruchomienie.

Skoro mamy konto serwisowe, to czemu nie zwykłe logowanie przez gcloud auth application-default login? Bo z zakresami Analytics ono nie działa – Google blokuje wbudowanego klienta OAuth gcloud przy zakresach spoza Cloud Platform. Konto serwisowe jest po prostu prostsze.

Co dało konto serwisowe

Odkąd Claude ma dostęp do odczytu, zmieniło się kilka rzeczy:

Wykrywanie problemów. Wszystkie pułapki z początku wpisu wyszły właśnie dzięki porównaniom danych z GA4 z kodem i bazą. Bez dostępu do danych zostałyby dalej niewidoczne.

Naprawa raportowania na stronie. Na podstawie znalezisk poprawiliśmy mechanizmy: zakup wysyła serwer po potwierdzeniu płatności, razem z identyfikatorem sesji, z pełną listą produktów i z jedną, kanoniczną nazwą każdego bukietu. Dev nie trafia już do statystyk – w kolejnym miesiącu po naprawie lokalnego ruchu nie było ani razu, więc blokada działa. Każda z tych poprawek ma test i wpis w dokumentacji.

SEO. Dane z Search Console są wejściem do decyzji o treści. Tytuły i opisy kluczowych stron (kwiaciarnia, sklep, „O mnie”) dobrałem do fraz, które faktycznie wpisują ludzie, rozwiązując przy okazji kanibalizację, czyli sytuację, w której dwie strony walczą w wyszukiwarce o tę samą frazę. Do tego Search Console służy do kontroli szybkości strony, błędów 404 i pokrycia wersji językowych (PL, EN, DE) oraz do zgłoszenia sitemapy po przebudowie adresów.

Claude ma dostęp tylko do odczytu. Sam niczego w GA4 ani Google Ads nie zmienia. Część poprawek (filtr ruchu wewnętrznego, akcja konwersji w Ads) wymaga kliknięcia w panelu – wtedy Claude diagnozuje i opisuje, a klikam ja. I tak powinno zostać.

O co można zapytać – 10 przykładów

Najlepiej widać to na pytaniach, które można teraz zadać zwykłym językiem i dostać odpowiedź od ręki:

1. Ilu użytkowników odwiedziło sklep w ostatnim miesiącu i jak to wypada na tle poprzedniego?
2. Skąd przychodzą klienci – z wyszukiwarki, z social mediów, z reklam, a może wpisują adres ręcznie?
3. Które produkty są najczęściej oglądane, a które najczęściej kupowane – i czy to te same?
4. Na którym kroku klienci porzucają zakupy: w koszyku, przy wyborze dostawy czy przy płatności?
5. Czy liczba zakupów w GA4 zgadza się z liczbą opłaconych zamówień w bazie?
6. Jaki odsetek ruchu to mój własny – panel admina, lokalne środowisko, staging?
7. Z jakich urządzeń przychodzą klienci – z telefonu czy z komputera?
8. Jakie frazy wpisują ludzie w Google, zanim trafią na stronę, i na jakiej pozycji jesteśmy?
9. Które podstrony są najczęstszym pierwszym wejściem na stronę?
10. Ile osób kliknęło w telefon albo maila na stronie z ofertą dla firm?

Dodatkowo można pytać o wersje językowe, błędy 404 czy o to, które kanały przynoszą zamówienia, a nie tylko wejścia.

Plany na dalsze zmiany

Lista rzeczy, które chcę jeszcze zrobić:

• Skill do wyciągania konkretnych danych. Dziś wiedza o tym, jak zapytać o zestawienie miesiąca, udział ruchu wewnętrznego czy raport „wyświetlenie → zakup” dla produktu, leży w dokumencie. Chcę ją zamienić na gotowy, wykonywalny skill
• Cykliczny audyt. Raz w miesiącu automatyczne zestawienie GA4 z bazą i alarm, gdy liczby się rozjadą – dziś wykrywa to dopiero kontrola ręczna
• Test pilnujący nazw produktów, żeby żadne nowe zdarzenie nie rozjechało raportów
• Porządki w pomiarze: filtr ruchu wewnętrznego, poprawa albo usunięcie akcji konwersji w Google Ads przed wznowieniem kampanii, dokładniejszy moment zgłaszania rozpoczęcia zamówienia i uwzględnienie zamówień złożonych telefonicznie

Podsumowanie

Dla mnie największa zmiana to nie „AI liczy statystyki szybciej”, tylko że w końcu ktoś cierpliwie sprawdza, czy te statystyki są prawdziwe. Kontrola, która wcześniej wymagała klikania po panelu i ręcznych porównań w arkuszu, teraz sprowadza się do jednego pytania. A ponieważ na poprawnych danych można opierać decyzje – o reklamach, o ofercie, o treści strony – to właśnie poprawność jest tu najważniejsza. Ładny wykres z błędnymi liczbami jest gorszy niż brak wykresu.

Jeśli prowadzisz sklep albo stronę i Twoja analityka „po prostu działa” – a nikt jej nigdy nie sprawdził – to warto ją przejrzeć. Daj znać w komentarzach, czy któraś z tych pułapek jest Ci znajoma. A jeśli ktoś już korzysta z analytics-mcp, bardzo chętnie dowiem się, jak mu się z nim pracuje 🙂