Audyt GA4: checklista 25 punktów, żeby sprawdzić, czy Google Analytics mierzy to, co trzeba

Audyt GA4 to systematyczne sprawdzenie, czy Google Analytics 4 zbiera dane poprawnie: czy każda odsłona i każde zdarzenie liczy się raz, czy ustawienia usługi nie wypaczają raportów i czy pomiar jest zgodny ze zgodami użytkowników. Robisz go, bo GA4 nie zgłasza błędów: źle skonfigurowana usługa wygląda w raportach tak samo wiarygodnie jak dobra, a na tych liczbach opierasz budżety reklamowe. Poniżej checklista 25 punktów w czterech warstwach, którą stosujemy w naszej agencji marketingowej przy przeglądzie pomiaru.

Czym jest audyt GA4 i kiedy go robić

Audyt GA4 sprawdza trzy rzeczy: czy dane są kompletne (nic nie ginie), czy są czyste (nic nie liczy się podwójnie ani nie pochodzi od Ciebie) i czy są zgodne z prawem. Robisz go po wdrożeniu lub migracji, po każdej przebudowie strony i zmianie bannera cookies, po uruchomieniu nowej kampanii z celem sprzedażowym oraz w stałym rytmie raz na kwartał. Przed dużą kampanią sprzedażową wystarczy krótsza wersja: tag, zdarzenia lejka i waluta. Pierwszy pełny przegląd zajmuje zwykle kilka godzin.

Warstwa 1: czy tag odpala się raz na odsłonę i w dobrym miejscu

Poprawny tag GA4 wysyła jedno zdarzenie page_view na jedną odsłonę strony, z jednego identyfikatora pomiaru (G-XXXXXXXX), na adres zbierania danych Google. Najczęstszy błąd to podwójne wdrożenie: kod wklejony ręcznie w szablon i ten sam tag odpalany z Google Tag Managera, co daje dwa page_view na każdą odsłonę, zawyżone odsłony i zaniżony współczynnik odrzuceń.

• 1. Jeden page_view na odsłonę. Otwórz stronę z włączonym podglądem GTM (Tag Assistant) i w DebugView w GA4 policz page_view na jedną odsłonę. Ma być jeden.
• 2. Identyfikatory G-. W zakładce Network przeglądarki przefiltruj żądania po „collect”: sprawdź, ilu identyfikatorów G- używa strona i czy każdy jest zamierzony (stare usługi z poprzednich agencji też się zdarzają).
• 3. Martwe tagi UA-. Zwróć uwagę na identyfikatory UA-: Universal Analytics nie zbiera danych od lipca 2023 roku, więc taki tag to martwy kod, który tylko spowalnia stronę.
• 4. Adres zbierania danych. Hity z Europy trafiają zwykle na regionalny adres Google (np. region1.analytics.google.com) — to normalne i nie oznacza własnego serwera. Własny serwer (server-side) rozpoznasz po domenie pierwszej strony, o czym piszemy w artykule server-side tracking: czy się opłaca.
• 5. Nawigacja bez przeładowania. Sprawdź strony po nawigacji bez przeładowania (sklepy typu SPA): page_view musi odpalać się też przy zmianie widoku, nie tylko przy pierwszym wejściu.
• 6. Strona błędu 404. Wejdź na nieistniejący adres: strona błędu 404 powinna zawierać ten sam tag, żeby widzieć, gdzie tracisz użytkowników.

Warstwa 2: czy zdarzenia lejka sprzedażowego wysyłają kompletne dane

Zdarzenia lejka e-commerce to ścieżka view_item_list, view_item, add_to_cart, view_cart, begin_checkout i purchase, a każde z nich musi nieść parametry: listę produktów (items), walutę (currency) i wartość (value). Bez tego raport Monetyzacja jest pusty albo niekompletny, a kampanie Google Ads i Meta nie mają z czego się uczyć.

Najkosztowniejszy błąd w tej warstwie dotyczy zdarzenia purchase. Bez unikalnego identyfikatora transakcji (transaction_id) ta sama transakcja liczy się za każdym razem, gdy klient odświeży stronę potwierdzenia lub wróci do niej z maila, a przychód w raportach rośnie sztucznie. Sprawdź w DebugView, że transaction_id jest wypełniony, a jedno zamówienie testowe daje dokładnie jedno zdarzenie purchase. Jeśli odliczasz budżet od ROAS, przeczytaj też Break-even ROAS i maksymalny CPC, bo zawyżony przychód zawyża też ROAS.

Przy okazji sprawdź, czy walutę w zdarzeniach (currency) przekazuje sklep. Raporty przychodu opierają się na tej wartości, więc brak waluty w zdarzeniu oznacza zakup bez przychodu. Przy GA4 podpiętym pod Google Ads sprawdź ponadto, czy zdarzenie kluczowe, pod które optymalizujesz kampanię, jest tym właściwym. Porównanie z konfiguracją znajdziesz w usłudze GA4.

• 7. Parametry zdarzeń. Każde zdarzenie lejka niesie listę produktów (items), walutę (currency) i wartość (value).
• 8. view_item. Odpala się przy wejściu na kartę produktu, z wypełnionym items, i nie odpala się na stronie kategorii.
• 9. add_to_cart. Odpala się przy każdym dodaniu do koszyka, także z listingu i z szuflady koszyka.
• 10. begin_checkout. Odpala się przy wejściu do kasy, także gdy kasa działa na osobnej domenie lub w płatności zewnętrznej.
• 11. purchase z transaction_id. Jedno zamówienie testowe daje dokładnie jedno zdarzenie purchase z wypełnionym transaction_id, a odświeżenie strony „dziękujemy” nie liczy zakupu drugi raz.
• 12. generate_lead (strony usługowe). Odpala się dopiero po wysłaniu formularza; samo kliknięcie przycisku i błąd walidacji go nie wywołują.
• 13. Waluta. Parametr currency przekazuje sklep w każdym zdarzeniu, bo zakup bez waluty nie ma przychodu.
• 14. Zdarzenie kluczowe pod Google Ads. Kampania optymalizuje się pod właściwe zdarzenie kluczowe.

Warstwa 3: jakie ustawienia usługi GA4 trzeba przejrzeć

Ustawienia usługi decydują o tym, jak GA4 interpretuje poprawnie wysłane dane, i to tu leży większość „cichych” błędów, bo nikt ich nie sprawdza po wdrożeniu. Najważniejsza jest retencja: domyślnie GA4 przechowuje dane zdarzeń przez 2 miesiące, a w ustawieniach przechowywania danych możesz to wydłużyć maksymalnie do 14, więc analizy rok do roku w Eksploracjach działają tylko po zmianie tego ustawienia.

Wykluczenia odesłań to ustawienie, które wprost zmienia raport źródeł. Gdy klient płaci przez zewnętrzną bramkę i wraca na stronę, GA4 może uznać bramkę za nowe źródło ruchu i przypisać do niej zakup, który naprawdę przyszedł z reklamy. Skutek to zaniżone kampanie i zawyżone „referral”. Dodaj domeny bramek płatności i logowania (np. paypal.com) do listy niechcianych odesłań.

• 15. Retencja danych zdarzeń. Ustawiona na 14 miesięcy zamiast domyślnych 2.
• 16. Ruch wewnętrzny. Zdefiniowany w ustawieniach tagu, a filtr danych jest w stanie „Aktywny”, bo dopiero ten stan wyklucza dane.
• 17. Wykluczenia odesłań. Domeny bramek płatności i logowania są na liście niechcianych odesłań.
• 18. Zdarzenia kluczowe. Oznaczone tylko te, które mają wartość biznesową (limit 30 w standardowej usłudze).
• 19. Definicje niestandardowe. Każdy parametr zdarzenia, który chcesz widzieć w raportach, ma zarejestrowaną definicję.
• 20. Strefa czasowa i waluta. Zgodne z rynkiem i ze sklepem.
• 21. Okno atrybucji. Pasuje do długości Twojego cyklu zakupowego.

Warstwa 4: czy pomiar jest zgodny ze zgodami i nie zbiera danych osobowych

Poprawny pomiar uwzględnia zgodę użytkownika: bez zgody tagi nie zbierają identyfikatorów, a z Consent Mode v2 przekazują same sygnały bez ciasteczek. Druga część tej warstwy to dane osobowe: Google zabrania wysyłania do GA4 adresów e-mail, numerów telefonu i imion, a zdarza się to częściej, niż zakładasz, choćby przez adres strony z parametrem ?email= albo wartość pola formularza przesłaną jako parametr zdarzenia.

• 22. Dane osobowe w adresach. Przejrzyj w raporcie Strony i ekrany adresy z parametrami: jeśli widzisz w nich e-maile, imiona lub numery zamówień powiązane z osobą, trzeba je zredagować lub przestać wysyłać.
• 23. Formularze i wyszukiwarka w serwisie. W DebugView sprawdź parametry zdarzeń formularza i wyszukiwarki w serwisie: pole wyszukiwania bywa miejscem, gdzie klient wpisuje swoje dane.
• 24. Trzy stany zgody. Przetestuj stronę w trzech stanach: przed wyborem w bannerze, po akceptacji i po odrzuceniu. Skrypty nie powinny wysyłać hitów z identyfikatorem klienta przed zgodą.
• 25. Ponowny page_view po zmianie zgody. Po zmianie zgody gtag wysyła page_view ponownie, żeby hit niósł stan „granted”. To zachowanie zgodne z działaniem gtag; odróżnij je od dwóch hitów z dwóch tagów.

Szczegóły konfiguracji i wpływ na dane opisujemy w artykule Consent Mode v2: ile danych tracisz; działanie bannera sprawdzisz darmowym Consent Mode Checkerem.

Co sprawdzisz sam w godzinę, a co wymaga dostępu do kontenera i konta

Z zewnątrz da się zweryfikować tylko to, co widać w ruchu sieciowym przeglądarki: liczbę tagów, identyfikatory pomiaru, wysyłane zdarzenia, parametry i adresy żądań. Wnętrze usługi (retencja, zdarzenia kluczowe, powiązania, filtry) i konfigurację kontenera GTM widzi tylko osoba z dostępem, dlatego pełny audyt łączy oba podejścia.

• Sprawdzisz sam w godzinę: DebugView i Tag Assistant (tag, page_view, zdarzenia lejka na zamówieniu testowym), adresy z danymi osobowymi w raporcie Strony i ekrany, retencję i ruch wewnętrzny w ustawieniach.
• Szybki skan z adresu: nasz bezpłatny audyt GA4 wchodzi na stronę, klika zgodę i sprawdza tagi oraz zdarzenia (do pierwszego kroku kasy), a zamówienia ani formularza nie wysyła.
• Wymaga dostępu: reguły wyzwalaczy w GTM, deduplikacja z przeglądarką i serwerem, powiązania z Google Ads, własne definicje i wiarygodność przychodu względem systemu sklepu.

Co zrobić z wynikami audytu GA4

Po audycie ułóż poprawki według wpływu na decyzje, a nie według kolejności na liście: najpierw to, co zniekształca przychód i konwersje (podwójny page_view, purchase bez transaction_id, brak waluty), potem to, co zniekształca źródła (wykluczenia odesłań, ruch wewnętrzny), na końcu porządki (nazwy zdarzeń, martwe tagi, definicje). Każdą poprawkę zweryfikuj w DebugView i odnotuj datę wdrożenia, bo od tego dnia dane w raportach przestają być porównywalne z wcześniejszymi.

Gdy pomiar przechodzi przez przeglądarkę i tracisz część zdarzeń przez blokery oraz Safari, kolejnym krokiem bywa przeniesienie tagów na własny serwer. Jeśli to rozważasz, zacznij od oferty server-side GTM i artykułu o opłacalności, a wcześniej napraw podstawy z tej checklisty, bo server-side powiela błędy konfiguracji zamiast je naprawiać. Utrata danych bez ciasteczek ma też swoją skalę, opisaną w tekście Konwersje bez ciasteczek.

FAQ: audyt GA4