GA4 może zbierać dane codziennie i jednocześnie dawać fałszywe poczucie bezpieczeństwa. Zielony status tagu nie potwierdza, że mierzysz właściwe zdarzenie, we właściwym momencie i z poprawnymi parametrami. Audyt jest potrzebny wtedy, gdy dane przestają wiernie opisywać proces biznesowy albo nie da się ustalić, dlaczego raport pokazuje określony wynik.
purchase lub tagi uruchamiane bez wymaganej zgody — wystarczy, aby rozpocząć audyt. Przy mniej oczywistych problemach sygnałem alarmowym jest kilka powtarzalnych rozbieżności, których zespół nie potrafi wyjaśnić na poziomie konkretnego zdarzenia.Audyt GA4 i GTM to nie lista tagów
Dobry audyt zaczyna się od pytań biznesowych, a dopiero później przechodzi do konfiguracji. Sprawdza cały łańcuch: działanie użytkownika, kod strony lub aplikacji, dataLayer, regułę w GTM, wysłane żądanie, przetwarzanie w GA4 i wykorzystanie danych w raportach oraz kampaniach.
Sam przegląd kontenera nie pokaże, że przycisk „Wyślij” uruchamia konwersję mimo błędu walidacji formularza. Sam raport GA4 nie wyjaśni, czy brakujące zakupy wynikają z odmowy zgody, przerwanego powrotu z bramki płatniczej czy błędnego zdarzenia. Potrzebne są testy scenariuszy i porównanie z systemem operacyjnym.
Sygnały 1–3: wynik biznesowy nie zgadza się z pomiarem
1. Nikt nie potrafi wyjaśnić różnicy między GA4 a sklepem
Sama różnica jest normalna. Problemem jest brak odpowiedzi na pytanie, które zamówienia występują tylko w jednym systemie i dlaczego. Jeżeli zespół porównuje wyłącznie sumy dzienne, nie wie, czy przyczyną są zgody, anulacje, duplikaty, strefa czasowa czy awaria na konkretnym urządzeniu.
Podstawowym testem jest uzgodnienie rekordów po transaction_id oraz policzenie pokrycia: jaki odsetek poprawnych, opłaconych zamówień ma odpowiadające zdarzenie purchase w danych analitycznych.
2. Zdarzenia zakupu mają puste, powtarzalne albo niestabilne identyfikatory
transaction_id powinien jednoznacznie wskazywać zamówienie w każdym systemie. Brak identyfikatora uniemożliwia rzetelną deduplikację i późniejsze uzgodnienie danych. Ponowne używanie tego samego ID dla różnych zamówień może z kolei powodować utratę zdarzeń, ponieważ GA4 ignoruje kolejne zdarzenie e-commerce z tym samym identyfikatorem.
Google zaleca weryfikację e-commerce w DebugView i zwraca uwagę zarówno na błędne nazwy zdarzeń, brak wymaganych parametrów, jak i duplikaty wynikające z jednoczesnego użycia gtag.js oraz GTM. Zobacz: Validate your ecommerce setup.
3. Konwersja uruchamia się na intencji, a nie na sukcesie
Kliknięcie przycisku „Wyślij”, „Kupuję” albo „Załóż konto” nie jest jeszcze wynikiem. Formularz może zwrócić błąd, płatność może zostać odrzucona, a rejestracja zatrzymać się na weryfikacji. Jeżeli key event uruchamia się na kliknięciu zamiast po potwierdzeniu sukcesu przez aplikację lub backend, kampanie uczą się optymalizować pozorny rezultat.
Sygnały 4–6: źródła ruchu i sesje są zniekształcone
4. W źródłach sprzedaży pojawia się operator płatności albo własna domena
Self-referrale i domeny bramek płatniczych potrafią przerwać wcześniejszą informację o źródle pozyskania. GA4 ma konfigurację „unwanted referrals”, która pozwala wskazać domeny niebędące prawdziwym źródłem ruchu. Nie należy jednak dopisywać ich mechanicznie. Najpierw trzeba sprawdzić ciągłość sesji, konfigurację między domenami i sposób powrotu użytkownika.
Google opisuje ten mechanizm w dokumentacji Identify unwanted referrals.
5. Nazwy kampanii i kanałów rozpadają się na dziesiątki wariantów
facebook, Facebook, fb i meta_ads mogą opisywać to samo źródło, ale w raporcie utworzą różne wartości. Podobny problem powodują błędne medium, brakujące UTM-y, ręczne tagowanie Google Ads mimo aktywnego auto-taggingu albo przekierowania usuwające parametry.
Jeżeli analityk co miesiąc ręcznie scala te same warianty w arkuszu, problem leży w standardzie tagowania, nie w raporcie. Google zaleca konsekwentne używanie parametrów kampanii i opisuje ich przeznaczenie w materiale Collect campaign data with custom URLs.
6. Użytkownik przechodzący między domenami staje się nowym użytkownikiem
Sklep, formularz, panel klienta albo płatność mogą działać na osobnych domenach. Bez poprawnego pomiaru cross-domain jeden człowiek zostanie rozdzielony na kilka identyfikatorów i sesji. Objawy to nagły wzrost nowych użytkowników na drugim etapie, self-referrale oraz zerwane lejki.
Cross-domain trzeba testować w realnym przejściu, sprawdzając przekazanie parametru linkera i ciągłość identyfikatora. Oficjalny przewodnik Google: Measure activity across multiple domains.
Sygnały 7–9: GTM i dataLayer działają przypadkowo
7. Ruch pracowników, agencji i testów trafia do danych produkcyjnych
Witrynę najczęściej odwiedzają osoby, które ją budują, sprawdzają i akceptują. Przy małym ruchu ich zachowanie może istotnie zmieniać współczynniki konwersji, źródła i dane urządzeń. Szczególnie niebezpieczne są testowe zakupy oraz formularze, jeśli później trafiają do raportowania leadów.
GA4 pozwala oznaczać i filtrować ruch wewnętrzny. Filtr wykluczający jest jednak trwały — Google ostrzega, że odrzucone dane nie będą dostępne ani w Analytics, ani w eksporcie BigQuery. Dlatego przed aktywacją warto użyć trybu testowego i przygotować osobny sposób kontroli. Zobacz: Filter out internal traffic.
8. Te same tagi są wdrożone kilkoma metodami
GTM w motywie, druga integracja we wtyczce, dodatkowy gtag.js z platformy sklepowej i jeszcze jeden kontener w kodzie kampanii — taki układ zdarza się częściej, niż powinien. Efektem są podwójne page_view, zdarzenia odpalane w innej kolejności oraz trudność w ustaleniu, która konfiguracja jest aktywna.
Google wprost zaleca użycie jednej metody implementacji dla zdarzeń e-commerce i wskazuje, że równoległe gtag.js oraz GTM mogą powodować podwójne zliczanie. Tag Assistant pokazuje wykryte identyfikatory, kolejność poleceń, zdarzenia i żądania sieciowe. Dokumentacja: Analyze existing tag configurations.
9. dataLayer nie jest stabilnym kontraktem
To sygnał alarmowy, jeśli ta sama informacja raz jest liczbą, raz tekstem, nazwy parametrów zmieniają się między szablonami, a GTM odczytuje wartości bezpośrednio z HTML strony. Reguły zaczynają wtedy zależeć od układu frontendu, języka lub kolejności ładowania skryptów.
dataLayer powinien opisywać zdarzenie biznesowe i jego parametry w przewidywalny sposób. Google zaleca spójne nazewnictwo, inicjalizację jednej globalnej tablicy i dodawanie danych przez dataLayer.push(). Nadpisanie window.dataLayer po starcie kontenera może prowadzić do utraty danych i braku uruchomienia tagów. Zobacz: The data layer.
Sygnały 10–12: zgody, testy i utrzymanie nie są kontrolowane
10. Consent Mode jest oceniany tylko po wyglądzie bannera
To, że banner zapisuje wybór, nie oznacza, że tagi otrzymują właściwy stan we właściwym momencie. Trzeba sprawdzić wartości domyślne przed interakcją, aktualizację po wyborze, zachowanie po zmianie decyzji i działanie wszystkich czterech parametrów używanych w Consent Mode v2: analytics_storage, ad_storage, ad_user_data i ad_personalization.
Google wymaga ustawienia stanu domyślnego przed tagami oraz aktualizacji na stronie, na której użytkownik dokonał wyboru — zanim nastąpi przejście na kolejną stronę. Szczegóły: Set up consent mode on websites i Troubleshoot consent mode with Tag Assistant.
11. Nie da się prześledzić zdarzenia od działania do raportu
Jeżeli zespół widzi liczbę w GA4, ale nie umie odtworzyć, który dataLayer.push(), trigger i request ją wygenerował, utrzymanie pomiaru opiera się na zgadywaniu. Każde kluczowe zdarzenie powinno mieć scenariusz testowy obejmujący Tag Assistant, parametry wysłanego żądania, DebugView oraz późniejszą obecność w standardowych danych.
Tryb podglądu pokazuje, które tagi uruchomiły się dla konkretnego zdarzenia, a które nie — wraz z warunkami. Google zaleca po walidacji struktury sprawdzić zdarzenie w Realtime i DebugView: Verify your implementation.
12. Zmiany są publikowane bez wersji, opisu i testów regresji
Pomiar najczęściej psuje się nie podczas pierwszego wdrożenia, lecz przy kolejnej zmianie checkoutu, formularza, CMP albo motywu. Jeżeli wersje GTM mają nazwy „test”, „poprawka2” i „final”, a firma nie ma mapy zdarzeń oraz właściciela pomiaru, awarię zauważa się dopiero w raporcie miesięcznym.
Każda publikacja powinna wskazywać zakres zmiany, autora, powód, testowane scenariusze i plan wycofania. Dla kluczowych zdarzeń warto utrzymywać prosty monitoring wolumenu i pokrycia, aby wykryć nagły spadek zanim wpłynie na raporty lub automatyczne stawki kampanii.
Szybki test: co można sprawdzić w 30 minut
- Uruchom Tag Assistant i zapisz wszystkie wykryte kontenery oraz identyfikatory Google tag.
- Wykonaj najważniejszą ścieżkę: wejście z oznaczonego linku, produkt lub formularz, sukces i powrót z zewnętrznej domeny.
- Sprawdź kolejność zdarzeń, wartości w
dataLayer, uruchomione tagi i parametry żądań. - Powtórz scenariusz po odmowie, akceptacji i zmianie zgody.
- Sprawdź scenariusz błędny: niedokończona płatność, walidacja formularza lub ponowne odświeżenie strony sukcesu.
- Porównaj ostatnie 7–14 dni zakupów albo leadów po identyfikatorze z systemem źródłowym.
- Przejrzyj źródła ruchu pod kątem własnych domen, operatorów płatności,
(not set)oraz niespójnych UTM-ów. - Sprawdź aktywne filtry, ustawienia cross-domain, unwanted referrals, key events i połączenia z platformami reklamowymi.
Ten test nie zastępuje pełnego audytu, ale pozwala szybko ustalić, czy problem dotyczy pojedynczego raportu, czy całego łańcucha pomiarowego.
Jak ustalić priorytety napraw
| Priorytet | Przykłady | Reakcja |
|---|---|---|
| Krytyczny | brak lub duplikacja zakupu, PII w danych, tagi łamiące wybór zgody, błędna konwersja używana do stawek | zatrzymanie lub naprawa przed dalszą optymalizacją |
| Wysoki | zerwane cross-domain, utrata parametrów kampanii, self-referrale, brakujące identyfikatory | naprawa w najbliższym sprincie i ponowna walidacja |
| Średni | niespójne nazwy, zbędne tagi, nieużywane parametry, brak dokumentacji | porządkowanie według wpływu i kosztu utrzymania |
Raport z audytu powinien kończyć się nie liczbą znalezionych uwag, lecz planem: opis błędu, dowód, wpływ na decyzje, rekomendacja, priorytet, właściciel oraz kryterium odbioru. Dopiero taki materiał nadaje się do przekazania deweloperom i późniejszego sprawdzenia.
Northline audytuje cały przepływ danych — od działania użytkownika i dataLayer, przez GTM oraz zgody, po GA4 i zgodność z systemem sprzedażowym.
Źródła i dokumentacja
- Google Tag Platform: Analyze existing tag configurations
- Google Analytics: Validate your ecommerce setup
- Google Tag Platform: The data layer
- Google Tag Platform: Measure activity across multiple domains
- Google Analytics Help: Identify unwanted referrals
- Google Analytics Help: Filter out internal traffic
- Google Tag Platform: Set up consent mode on websites
- Google Tag Platform: Troubleshoot consent mode with Tag Assistant
- Google Analytics: Verify your implementation