Co dokładnie kończy się 1 lipca

Warto rozdzielić dwie rzeczy. Po pierwsze, zbieranie danych: od 1 lipca standardowa usługa UA przestanie przyjmować nowe odsłony i zdarzenia. Tag może dalej siedzieć w kodzie, ale nic z tego nie wyniknie. Każdy dzień po tej dacie istnieje wyłącznie w GA4 — jeśli konwersja nie jest tam skonfigurowana, ten dzień będzie w raportach pusty na zawsze.

Po drugie, dostęp do danych historycznych — a to nie ta sama data. Google przy ogłoszeniu wygaszenia napisał, że wcześniej przetworzone dane będą dostępne jeszcze przez co najmniej pół roku po zatrzymaniu zbierania. Konkretnej daty usunięcia nie znamy, więc traktuję ten termin jako minimum, nie obietnicę. Najpilniejsza jest konfiguracja, bo tylko ona działa w przód.

Dochodzi rzecz, o której część osób nie wie: od marca Google wdraża automatyczne tworzenie usług GA4 dla tych usług UA, których właściciele sami tego nie zrobili. Jeśli znajdziesz na koncie usługę, której nie pamiętasz z zakładania — możliwe, że powstała właśnie tak. Automat przenosi podstawowe ustawienia, ale nie cele.

Cele w UA a konwersje w GA4 to nie to samo

Z tej różnicy wynikają wszystkie późniejsze rozjazdy w liczbach.

W Universal Analytics cel jest ustawieniem widoku. Definiujesz go po fakcie — z adresu URL, czasu na stronie, liczby odsłon albo istniejącego zdarzenia. I liczy się maksymalnie raz na sesję.

W GA4 nie ma widoków ani celów w tym sensie. Jest zdarzenie, a konwersja to zdarzenie oznaczone jako konwersja w ustawieniach. Zdarzenie musi więc najpierw zostać wysłane — nie zdefiniujesz konwersji z niczego, tak jak w UA definiowałeś cel z samego adresu strony podziękowania.

Druga różnica dotyczy zliczania. GA4 domyślnie liczy konwersję przy każdym wystąpieniu zdarzenia, nie raz na sesję. Od kwietnia da się to zmienić — w ustawieniach konwersji doszedł wybór metody zliczania, w tym „raz na sesję”. To świeża opcja, więc konta konfigurowane wcześniej stoją na zliczaniu każdego zdarzenia. Jeśli GA4 pokazuje więcej konwersji niż UA, zacznij szukać właśnie tutaj.

Trzecia rzecz to pomiar zaawansowany: przewinięcia, linki wychodzące, wyszukiwanie w witrynie i pobrania plików GA4 zbiera sam. Bywa to pułapką — widzisz zdarzenia w raporcie i uznajesz, że pomiar działa, a zdarzenie odpowiadające Twojemu celowi nie jest wysyłane wcale.

Inwentaryzacja: spisz cele, których używasz

Zaczynam od kartki, nie od panelu GA4. Wchodzę do administracji każdego używanego widoku UA i przepisuję aktywne cele: nazwa, typ, dokładna definicja (adres z dopasowaniem albo kategoria, akcja i etykieta zdarzenia), wartość, ścieżka. Potem sprawdzam w raporcie konwersji, ile ten cel zebrał w ostatnich trzech miesiącach.

Ten ostatni krok jest najważniejszy, bo spora część celów okazuje się martwa. Cel na stronę, której już nie ma. Cel na czas w sesji, dodany kiedyś eksperymentalnie. Dwa cele mierzące to samo pod różnymi nazwami. Liczba zdarzeń oznaczonych jako konwersje w GA4 jest ograniczona, więc nie ma po co zajmować miejsca definicjami, na które nikt nie patrzy.

Przy tym, co zostaje, dopisuję, kto z tego korzysta: raport dla klienta, import konwersji do Google Ads, wewnętrzny arkusz. Cel zasilający optymalizację kampanii ma pierwszeństwo. W asystencie konfiguracji GA4 jest narzędzie proponujące odwzorowanie celów z UA — traktuję je jako podpowiedź, nie jako wykonaną pracę: z celami na zdarzeniach radzi sobie sensownie, z celami na adresach URL słabiej.

Odwzorowanie celu w GA4

Dla każdego celu z listy odpowiadam na jedno pytanie: czy w GA4 istnieje już zdarzenie opisujące to samo działanie użytkownika?

Jeśli tak — na przykład masz wdrożone własne zdarzenie wysyłki formularza — wystarczy w administracji, na liście zdarzeń, przestawić przełącznik oznaczający je jako konwersję. Zliczanie zaczyna się od tego momentu, nie działa wstecz.

Jeśli nie, mam trzy drogi. Najlepsza: wysłać zdarzenie z warstwy danych przez Google Tag Managera, w momencie, w którym działanie faktycznie się wykonało — po odpowiedzi serwera, nie po kliknięciu przycisku. Druga: utworzyć zdarzenie w GA4 na podstawie innego, na przykład odsłony strony podziękowania z warunkiem na adres. To najbliższy odpowiednik celu URL z UA i tak przenoszę proste przypadki. Trzecia: zmodyfikować istniejące zdarzenie, jeśli problemem jest tylko nazwa albo parametr.

Przy okazji ustawiam metodę zliczania — jeśli cel w UA liczył się raz na sesję, a chcę zachować porównywalność, wybieram „raz na sesję”. I wartość: przy konwersji o zmiennej wartości zdarzenie musi wysyłać parametry wartości i waluty, bo puste wartości wyglądają w raportach tak samo jak brak konfiguracji.

Weryfikacja: czy dane naprawdę wpadają

Konfiguracja bez sprawdzenia nie jest skończona. Widzę to na większości kont, które przejmuję — ktoś kliknął przełącznik i uznał temat za zamknięty.

Sprawdzam w trzech miejscach, w tej kolejności. Najpierw tryb podglądu GTM i DebugView: wykonuję działanie na stronie i patrzę, czy zdarzenie dociera, z jaką nazwą i parametrami. Potem raport w czasie rzeczywistym, który potwierdza, że zdarzenie widzi usługa, a nie tylko narzędzie diagnostyczne. Na koniec, po dobie, raport zdarzeń i lista konwersji — dane zbiorcze przetwarzają się z opóźnieniem.

Osobno robię test negatywny: wchodzę na stronę podziękowania wprost z adresu, bez wypełniania formularza, i sprawdzam, czy zdarzenie się nie wysłało. Fałszywe konwersje z odświeżeń i wejść z historii przeglądarki to klasyk, który potem tłumaczy tajemnicze skoki w raportach.

Jeśli konwersje z GA4 mają zasilać Google Ads, sprawdzam import po tamtej stronie: czy akcja jest widoczna, czy ma poprawne zliczanie i czy nie dubluje konwersji mierzonej tagiem Google Ads. Domykam jeszcze przechowywanie danych o zdarzeniach — domyślne dwa miesiące to za mało na porównania rok do roku, a zmiana działa tylko w przód.

Rozjazd liczb między UA i GA4

Zakładam z góry, że liczby się nie zgodzą, i mam kilka wyjaśnień, które sprawdzam po kolei.

• Metoda zliczania — cel z UA liczy się raz na sesję, konwersja w GA4 domyślnie przy każdym zdarzeniu. Najczęstsza przyczyna nadwyżki w GA4.

• Inna definicja sesji — w GA4 sesja nie zaczyna się od nowa po zmianie źródła w trakcie wizyty. Przy ruchu z reklam widać to od razu.

• Filtry widoku — ruch wewnętrzny i boty odcinałeś prawdopodobnie w widoku UA. GA4 rozwiązuje to inaczej i trzeba skonfigurować od zera.

• Model atrybucji — w raportach GA4 działa dziś domyślnie last click w ujęciu międzykanałowym, więc przypisanie konwersji do kanałów będzie inne niż w UA. To nie błąd pomiaru, tylko inna reguła podziału.

• Zgody i blokowanie — jeśli zmieniałeś ostatnio banner zgód, obie usługi mogą zbierać różny podzbiór ruchu.

Umawiam się z klientem na to samo, co sam sobie ustalam: porównujemy trendy, nie wartości bezwzględne. Stabilna różnica przy tym samym kierunku to znak, że migracja się udała.

Plan na te dwa miesiące

Rozpisuję to na tygodnie, bo lista zadań bez terminu ma tendencję do przeżycia terminu.

Maj to inwentaryzacja i konfiguracja: spis celów z UA, decyzja, które przenosimy, wdrożenie brakujących zdarzeń w GTM, oznaczenie konwersji, metody zliczania i wartości. Do tego porządki do zrobienia raz — przechowywanie danych, wykluczenie ruchu wewnętrznego, powiązanie z Google Ads i Search Console.

Czerwiec to weryfikacja równoległa. Oba narzędzia zbierają jeszcze dane, więc to ostatni miesiąc, w którym da się cokolwiek porównać. Raz w tygodniu przeglądam konwersje w obu usługach i domykam rozjazdy, których nie umiem wytłumaczyć. Wtedy też ustawiam raporty i uprawnienia dla wszystkich, którzy dziś zaglądają do UA.

Eksport historii planuję na czerwiec i lipiec. Minimum: miesięczne zestawienia kluczowych metryk i konwersji za pełne lata wstecz do arkusza, plus zrzuty najważniejszych raportów.

I rzecz, którą powtarzam każdemu klientowi: nie wyłączaj tagu Universal Analytics wcześniej, niż musisz. Do 1 lipca kosztuje Cię jedno wywołanie na stronie, a daje punkt odniesienia, którego po tej dacie już nie kupisz.