Monitoring GA4: jak wykryć awarię pomiaru zanim zauważy ją klient

Klient nie pisze, że GA4 przestało zbierać dane. Pisze, że spadły konwersje. Awaria pomiaru rzadko wygląda jak awaria: strona działa, tagi się nie wywalają, a w raportach po prostu nie ma danych albo jest ich mniej. Nikt nie wysyła wtedy alarmu, bo nikt nie wie, że coś się stało. Monitoring w GA4 to nie kolejne narzędzie, a zestaw sprawdzeń wykonywanych o stałych porach.

1 września 2026 raporty standardowe w GA4 pokazywały zero albo prawie zero ruchu w wielu niezależnych kontach. Raport czasu rzeczywistego działał normalnie, więc zbieranie danych pracowało, a problem dotyczył przetwarzania. Google nie opublikowało wtedy wpisu o incydencie. Skala była zbyt duża na awarię jednego kontenera, a brak komunikatu bywał traktowany jako dowód, że wszystko działa. Jeśli nie sprawdzałeś danych rano, o luce dowiedziałeś się z pytania klienta.

Zbieranie i przetwarzanie to dwa różne etapy

W GA4 dane przechodzą przez kilka etapów. Raport czasu rzeczywistego aktualizuje się w mniej niż minutę i odpowiada na pytanie, czy zdarzenia w ogóle docierają do Google. Dane dzienne są pełniejsze, ale pojawiają się po zakończeniu przetwarzania, które może trwać od 24 do 48 godzin, a w tym czasie liczby w raportach mogą się jeszcze zmieniać. Tak opisuje to dokumentacja Google w artykule o świeżości danych i ograniczeniach SLA.

Konsekwencja dla monitoringu jest prosta. Alert oparty na danych dziennych nie wykryje awarii w dniu, w którym się wydarzyła. Wykryje ją dzień później. Jeśli chcesz wiedzieć o problemie tego samego dnia, musisz patrzeć na dane czasu rzeczywistego, a nie na powiadomienia mailowe.

Co realnie potrafi wykrywanie anomalii w GA4

Automatyczna analiza danych w GA4 opiera się na modelu bayesowskich ciągów czasowych. Google przewiduje wartość ostatniego punktu danych i oznacza go jako anomalię, gdy rzeczywisty wynik wypada poza przedział wiarygodności. Model uczy się na historii: dla anomalii godzinowych potrzebuje dwóch tygodni danych, dla dziennych 90 dni, a dla tygodniowych 32 tygodni. Anomalie w segmentach, na przykład w konkretnym kanale albo na konkretnym typie urządzenia, są wykrywane raz w tygodniu i tylko dla segmentów obejmujących co najmniej 0,05 procent użytkowników usługi.

Te liczby wyjaśniają, dlaczego alerty na świeżej usłudze albo na stronie z małym ruchem działają słabo. Model nie ma na czym się uczyć, więc albo milczy, albo zgłasza fałszywe trafienia. Alertu nie traktuj jako dowodu, że dane są w porządku. To jeden sygnał z kilku.

Statystyki niestandardowe: zestaw na start

Statystyki niestandardowe tworzysz z sekcji Trendy na stronie głównej GA4 (Wyświetl wszystkie statystyki, potem Utwórz). Każda statystyka ma nazwę, warunek oparty na danych i wymiarach, częstotliwość oceny oraz opcjonalne powiadomienia mailowe do użytkowników usługi. Statystyki są przechowywane przez rok od wygenerowania, a do ich tworzenia potrzebujesz roli Edytujący albo Administrator.

Warunek może być oparty na wykrywaniu anomalii albo na Twoim progu, na przykład spadek sesji o ponad 30 procent względem poprzedniego okresu. Cztery statystyki, które warto ustawić od pierwszego dnia:

• Sesje, ocena codzienna, warunek wykryto anomalię. Pierwszy sygnał, że coś dzieje się z ruchem.
• Kluczowe zdarzenia, ocena codzienna, warunek wykryto anomalię. Spadek konwersji przy stabilnym ruchu to najczęściej problem z implementacją, a nie z popytem.
• Przychód i transakcje, ocena tygodniowa, próg procentowy. Dla sklepu to najważniejsza para liczb.
• Sesje z jednego źródła albo kampanii, ocena codzienna. Wychwytuje sytuację, w której pada jeden kanał, a reszta ruchu maskuje problem w sumie.

Zacznij od czterech i dopisuj kolejne tylko wtedy, gdy wiesz, co zrobisz po ich otrzymaniu. Zestaw trzydziestu alertów, których nikt nie czyta, jest gorszy niż cztery, na które ktoś reaguje.

Czego alerty w GA4 nie wykryją

• Brak modelu na nowej usłudze. Dane są zbierane od pierwszego dnia, ale wykrywanie anomalii dziennych potrzebuje pełnej historii, więc przez pierwsze tygodnie jest mało czułe.
• Błędy, które generują stabilne dane. Jeśli od miesięcy zamówienia liczą się podwójnie, szereg czasowy jest równy i model nie ma czego wykryć.
• Rozjazd z systemem sprzedaży. GA4 może rosnąć, gdy zamówienia w sklepie spadają. Anomalia w jednym źródle nie mówi, co dzieje się w drugim.
• Zmiany, które sam wprowadziłeś. Nowa wersja strony, zmieniony baner zgód albo kolejny skrypt potrafią przesunąć dane w górę lub w dół, a nie są awarią, tylko skutkiem wdrożenia.
• Zniekształcenia w raportach, na przykład progi danych przy małym ruchu albo próbkowanie w eksploracjach.

Dlatego alerty to pierwsza warstwa. Drugą jest porównanie z zewnętrznym źródłem prawdy, które nie zależy od tego samego modelu danych.

Pięć kontroli, które łapią to, czego alerty nie widzą

1. Raport czasu rzeczywistego rano i po każdym wdrożeniu. Minuta pracy, a odpowiada na pytanie, czy dane w ogóle docierają.
2. Obecność kontenera na kluczowych szablonach stron po deployu. Test w kodzie strony wychwytuje sytuację, w której wdrożenie usunęło fragment odpowiedzialny za ładowanie tagów.
3. Eksport do BigQuery, jeśli go masz. Liczba zdarzeń na dzień to twardy dowód, że dane przeszły przez cały łańcuch. Brak wierszy za dany dzień widać szybciej niż lukę w raporcie. Eksport dzienny jest dostępny około 24 godzin po północy w strefie czasowej usługi.
4. Search Console i GA4 obok siebie. Kliknięcia organiczne i sesje organiczne liczone co tydzień. Trwała rozbieżność powyżej kilkunastu procent oznacza problem z jednym ze źródeł.
5. System sprzedaży i GA4 w jednym zestawieniu, raz w miesiącu. Zapisz tolerancję, na przykład 5 procent, i traktuj jej przekroczenie jako sygnał do sprawdzenia, a nie jako błąd do natychmiastowej naprawy.

Jeśli część tych kontroli wykonuje agencja, ustal jedną osobę odpowiedzialną i termin. Zadanie przypisane do wszystkich znika z kalendarza po pierwszym zajętym tygodniu.

Co robić po alercie

1. Ustal skalę. Otwórz raport czasu rzeczywistego i sprawdź, czy problem dotyczy jednej strony, jednego kanału czy całej witryny.
2. Przejrzyj ostatnie 48 godzin wdrożeń. Nowy skrypt, zmiana w banerze zgód i aktualizacja wtyczki to najczęstsze przyczyny po stronie witryny.
3. Sprawdź, czy problem dotyczy innych kont i czy Google go potwierdza. We wrześniu 2026 potwierdzenia nie było, a awaria obejmowała wiele kont, więc brak komunikatu nie oznacza, że po stronie Google wszystko działa.
4. Nie zmieniaj tagów bez dowodu. Jeśli objawy wskazują na platformę, modyfikacje we właściwości rozjadą historię zmian i utrudnią późniejszą diagnozę.
5. Zapisz zdarzenie. Data, objaw, przyczyna, podjęte działanie i zakres danych, które mogły zostać zniekształcone.

Adnotacje i rozmowa z klientem

Dodaj adnotację do wykresu w GA4 z datą zdarzenia i krótkim opisem. Za pół roku nikt nie będzie zgadywał, czy spadek w pierwszym tygodniu września to awaria, czy skutek wdrożenia.

W raporcie dla klienta oznacz dotknięty zakres i nie porównuj zniekształconego okresu z poprzednim tygodniem tak, jakby nic się nie stało. Przygotuj drugie źródło: Search Console dla ruchu organicznego, eksport do BigQuery dla zdarzeń, system sprzedaży dla zamówień. Trzy zdania wyjaśnienia na początku raportu kosztują mniej niż tydzień tłumaczenia liczb, które klient znalazł sam.

Monitoring to cztery alerty, pięć kontroli i jeden dokument, w którym zapisujesz zdarzenia. Cała praca zajmuje kilkadziesiąt minut w miesiącu. Jeśli nie wiesz, jak szybko zauważyłbyś brak danych w GA4, znasz już odpowiedź na pytanie, od czego zacząć.