GA4 na Payload CMS i Next.js: jak sensownie mierzyć zdarzenia bez WordPressa

Na WordPressie GA4 wchodzi wtyczką w pięć minut. Wklejasz ID, zaznaczasz checkbox przy e-commerce, gotowe. Na stronie zbudowanej na Payload CMS i Next.js tej wygody nie ma. Nie ma pluginu, nie ma panelu „Analytics” w adminie, nie ma automatycznego trackingu kliknięć. Jest kod, który trzeba świadomie ułożyć.

To nie jest wada. To inny sposób pracy. Headless daje kontrolę nad tym, co i kiedy się mierzy - pod warunkiem, że ktoś usiądzie i to zaprojektuje, zamiast liczyć na domyślne ustawienia.

GA4 na stronie headless to inna gra niż na WordPressie

WordPress renderuje każdą podstronę od zera. Przeglądarka robi pełne przeładowanie, więc standardowy tag GA4 wystrzeliwuje page_view przy każdym kliknięciu w link. Nie trzeba nic dodatkowo programować.

Next.js działa inaczej. Nawigacja między podstronami odbywa się po stronie klienta, bez przeładowania dokumentu. Jeśli wkleisz gołego gtag.js tak, jak robi się to w statycznym HTML-u, GA4 zarejestruje tylko pierwsze wejście na stronę. Reszta ruchu użytkownika po serwisie zniknie z raportów, bo przeglądarka nigdy nie zgłosi kolejnego załadowania dokumentu.

Konsekwencja jest prosta: na Next.js trzeba ręcznie wysyłać zdarzenie page_view przy każdej zmianie trasy. Podpina się to pod router - nasłuch na zmianę ścieżki i wywołanie zdarzenia do warstwy danych. To kilkanaście linijek kodu, ale bez nich cała analityka pokazuje fałszywie niski ruch i fałszywie wysoki współczynnik odrzuceń.

Gdzie wstawić GTM w architekturze Payload + Next.js

Google Tag Manager zostaje naszym wyborem niezależnie od CMS-a. Powód jest ten sam co zawsze: zmiana tagu, dodanie piksela remarketingowego czy modyfikacja zdarzenia nie powinny wymagać wdrożenia na produkcję. Marketer robi to w GTM, programista zajmuje się kodem strony.

W projekcie na Payload i Next.js kontener GTM ląduje w głównym layoucie aplikacji - raz, na poziomie, który renderuje się dla każdej podstrony. To nie jest miejsce na eksperymenty z kolejnością skryptów. Kontener musi wejść przed treścią, żeby warstwa danych (dataLayer) była gotowa, zanim jakikolwiek inny skrypt spróbuje coś do niej wypchnąć.

Payload jako źródło konfiguracji, nie jako miejsce trackingu

Kuszące jest trzymanie ID kontenera GTM czy identyfikatora strumienia GA4 w ustawieniach globalnych Payloada, jako pole tekstowe w kolekcji „Settings”. To ma sens - klient zmienia ID bez ingerencji w kod, jeśli np. testuje inne konto. Natomiast sama logika wysyłania zdarzeń nie powinna siedzieć w CMS-ie. Payload zarządza treścią i strukturą danych, Next.js renderuje i odpowiada za warstwę zdarzeń. Mieszanie tych odpowiedzialności kończy się tym, że nikt nie wie, gdzie szukać błędu, gdy zdarzenie przestaje się wysyłać.

Consent mode: zanim zaczniesz cokolwiek liczyć

W Polsce i całej UE zgoda na cookie analityczne jest warunkiem zbierania danych w GA4. Bez niej strumień danych jest albo pusty, albo - jeśli ktoś zignorował przepisy - niezgodny z prawem. Google wymusza to też technicznie: bez sygnału zgody część danych trafia do trybu ograniczonego (consent mode), z modelowaniem zamiast realnych zdarzeń.

Na stronie headless banner zgody to osobny komponent React, renderowany przed inicjalizacją GTM albo równolegle z nim, z blokadą wysyłki tagów do momentu decyzji użytkownika. Kluczowe jest ustawienie domyślnego stanu zgody na „odmowa” zanim jakikolwiek tag analityczny się załaduje, a potem aktualizacja tego stanu po kliknięciu w bannerze.

Typowy błąd, który widzimy przy audytach: banner zgody działa wizualnie poprawnie, ale technicznie nie blokuje niczego. Skrypty GA4 i tak się ładują w tle, zanim użytkownik kliknie cokolwiek. Wygląda to na zgodność z RODO, a nią nie jest.

• Domyślny stan zgody ustawiany przed załadowaniem GTM, nie po.
• Aktualizacja stanu zgody wysyłana do warstwy danych natychmiast po decyzji użytkownika, bez przeładowania strony.
• Testowanie trybu odmowy zgody osobno - wielu wdrożeniowców sprawdza tylko ścieżkę „zgadzam się”.

Zdarzenia, które mają sens na stronie opartej o kolekcje

GA4 od początku jest modelem zdarzeniowym, nie modelem odsłon. To akurat pasuje do sposobu, w jaki myśli się o treści w Payload. Każda kolekcja - formularz kontaktowy, wpis blogowy, oferta produktowa, case study - generuje własny zestaw sensownych interakcji do zmierzenia.

Zamiast kopiować gotową listę zdarzeń z dokumentacji Google, warto zadać sobie jedno pytanie przy każdej kolekcji: co użytkownik robi na tej podstronie, co realnie przybliża go do kontaktu albo zakupu?

Mechanika dobierania zdarzeń do kolekcji

1. Wypisz kolekcje w Payload, które mają realny ruch: strony ofertowe, blog, formularze, ewentualnie sklep.
2. Dla każdej kolekcji określ jedną akcję „miękką” (np. rozwinięcie FAQ, scroll do 75% treści) i jedną „twardą” (wysłanie formularza, kliknięcie w numer telefonu, dodanie do koszyka).
3. Nazwij zdarzenia konsekwentnie - jeden schemat nazewnictwa dla całej strony, np. czasownik_obiekt, żeby raporty dało się filtrować bez zgadywania.
4. Oznacz zdarzenia „twarde” jako konwersje w GA4, nie wszystkie zdarzenia po kolei - inaczej raport konwersji staje się bezużyteczny.

Formularz kontaktowy w Payload to dobry przykład. Wysyłka formularza trafia do kolekcji z submissions, a jednocześnie front-end wywołuje zdarzenie GA4 w momencie potwierdzenia wysyłki (nie w momencie kliknięcia przycisku - to różne rzeczy, bo walidacja może wysyłkę zablokować). Dzięki temu dane z CMS-a i dane z GA4 mówią to samo, zamiast się rozjeżdżać.

Jeden strumień danych czy więcej?

GA4 organizuje dane w strumienie - web, iOS, Android - zamiast w widoki znane ze starego Analyticsa. To rodzi pytanie, które słyszymy przy niemal każdym wdrożeniu: robić jeden strumień na całą domenę, czy dzielić?

Kiedy jeden strumień wystarczy

Dla zdecydowanej większości stron firmowych i sklepów na jednej domenie jeden strumień danych to właściwa decyzja. Jeśli cała witryna - blog, oferta, formularz kontaktowy - żyje pod jedną domeną i jednym frontendem Next.js, rozdzielanie strumieni tylko utrudnia analizę ścieżki użytkownika. Traci się ciągłość sesji między sekcjami serwisu.

Kiedy warto rozdzielić

• Osobna aplikacja mobilna obok strony webowej - wtedy strumień app i strumień web mają sens jako oddzielne byty, choć w tej samej usłudze GA4.
• Kilka niezależnych marek/domen zarządzanych z jednego Payloada przez multi-tenant - każda domena powinna mieć własny strumień, żeby dane się nie mieszały w jednym raporcie.
• Subdomena o zupełnie innym charakterze ruchu, np. panel klienta wymagający logowania - tu dane behawioralne odwiedzających stronę marketingową i dane zalogowanych użytkowników to dwa różne pytania biznesowe.

Rozdzielanie strumieni „na zapas”, bo tak wygląda solidniej w raporcie, to najczęstszy błąd, jaki widzimy. Efekt jest odwrotny do zamierzonego - nikt potem nie potrafi połączyć ścieżki użytkownika, który wszedł na blog, potem trafił na ofertę, a na końcu wypełnił formularz.

Eksport do BigQuery - kiedy to nie jest fanaberia

Darmowy plan GA4 ogranicza dostęp do surowych danych na poziomie zdarzeń do kilkunastu miesięcy wstecz, a przy większym ruchu w eksploracjach pojawia się próbkowanie danych. Dla małej strony firmowej to żaden problem - raporty standardowe wystarczą.

Eksport do BigQuery zaczyna mieć sens, gdy potrzebujesz łączyć dane GA4 z innymi źródłami - danymi z CRM, z Google Ads, z własnej bazy zamówień - albo gdy analiza wielodotykowej ścieżki konwersji (kilka sesji, kilka urządzeń, zanim ktoś kupi) jest dla biznesu istotna, a nie tylko ciekawostką. Konfiguracja eksportu jest darmowa, płaci się wyłącznie za przechowywanie danych w Google Cloud, co przy typowym ruchu jest kosztem pomijalnym.

Warto pamiętać o jednym ograniczeniu technicznym: eksport nie działa wstecz. Dane zaczynają płynąć do BigQuery od dnia włączenia integracji, nie wcześniej. Jeśli planujesz kiedykolwiek analizować dane historyczne w BigQuery, im szybciej włączysz eksport, tym lepiej - nawet jeśli na razie nikt z tych danych korzystać nie będzie.

Kiedy ta cała architektura nie ma sensu i jaki budżet jest realny

Rozbudowana struktura zdarzeń, osobne strumienie, eksport do BigQuery - to wszystko ma sens przy stronie, która generuje ruch wart analizowania i przy biznesie, gdzie decyzje marketingowe faktycznie opierają się na danych, nie na przeczuciu właściciela. Dla wizytówki firmowej z kilkoma podstronami i formularzem kontaktowym wystarczy jeden strumień, kilka zdarzeń konwersji i poprawnie działający consent mode. Cała reszta to nadmiarowa inżynieria, za którą nikt nie zapłaci sobie zwrotem z inwestycji.

Realny budżet na porządne wdrożenie GA4 z GTM i consent mode na stronie headless to zwykle kilkanaście godzin pracy programisty znającego Next.js plus konsultacja co do zdarzeń biznesowych. Rozbudowa o eksport do BigQuery i własne raporty to osobny, dodatkowy zakres - nie warto go kupować „razem z pakietem”, jeśli nikt w firmie nie ma czasu ani kompetencji, żeby z tych danych realnie korzystać. Dane, których nikt nie czyta, są kosztem, nie aktywem.

FAQ

Czy da się wdrożyć GA4 na Payload CMS bez pomocy programisty?

Samo podpięcie kontenera GTM da się zrobić bez programisty, jeśli deweloper wcześniej przygotował dla niego miejsce w layoucie. Ale wysyłka zdarzeń przy zmianie trasy w Next.js i logika consent mode wymagają pracy w kodzie - to nie jest konfiguracja z poziomu panelu, bo takiego panelu w Payload po prostu nie ma.

Czy Payload CMS ma wbudowaną integrację z GA4, tak jak wtyczki w WordPressie?

Nie i nie powinien mieć. Payload to CMS do zarządzania treścią i strukturą danych, nie warstwa trackingu. Rozdzielenie tych odpowiedzialności - treść w Payload, zdarzenia w warstwie frontendowej Next.js - jest świadomym wyborem architektonicznym, nie brakiem funkcji.

Ile zdarzeń GA4 warto skonfigurować na start?

Mniej niż się wydaje. Kilka zdarzeń „twardych” oznaczonych jako konwersje - formularz, telefon, e-mail, ewentualnie dodanie do koszyka - i tyle wystarczy na pierwsze miesiące. Rozbudowę o zdarzenia „miękkie” (scroll, czas na stronie, kliknięcia w FAQ) dokłada się dopiero, gdy pierwszy zestaw danych zacznie być realnie analizowany.

Czy consent mode jest obowiązkowy, jeśli strona ma mało ruchu?

Tak, obowiązek prawny nie zależy od liczby odwiedzin. Mała strona z niepoprawnie działającym bannerem zgody ryzykuje tyle samo, co duża - różnica jest tylko w skali potencjalnych konsekwencji, nie w samym obowiązku.