Co tu znaczy „bez kodu" i gdzie jest granica

Zacznę od uczciwego zastrzeżenia, bo określenie „bez kodu” bywa nadużywane. Google Tag Manager nie zwalnia z myślenia o kodzie — pozwala tylko nie zmieniać kodu sklepu. Zdarzenie skonfigurujesz przez interfejs, ale dane produktu i tak trzeba skądś wziąć, a jedyne dostępne źródła to: to, co widać w drzewie strony, to, co jest w adresie URL, i to, co sklep sam wypycha do warstwy danych.

Granica leży dokładnie tam, gdzie kończy się widok. Nazwę produktu, cenę i identyfikator z karty produktu odczytam z treści strony. Zawartość koszyka po dwóch krokach checkoutu — już nie. Numer transakcji i realną wartość zamówienia po rabatach i wysyłce — tym bardziej nie, bo powstają po stronie serwera.

Dlatego traktuję to podejście jako etap przejściowy, nie jako docelowe wdrożenie. Daje zaskakująco dużo: sensowny obraz zachowania w lejku, dane do remarketingu i podstawę do rozmowy o tym, co jeszcze warto domierzyć. Nie daje księgowej dokładności przychodu i nie należy go w takiej roli sprzedawać klientowi.

Fundament: tag konfiguracyjny i strumień danych

Zanim cokolwiek z e-commerce, musi stać podstawa. W GA4 tworzę właściwość, w niej strumień danych dla witryny, kopiuję identyfikator pomiaru i w Google Tag Managerze dodaję tag konfiguracyjny GA4 uruchamiany na wszystkich stronach. To wszystko, czego potrzeba, żeby GA4 zaczęło zbierać odsłony.

Przy okazji zaglądam do pomiaru zaawansowanego w ustawieniach strumienia. Domyślnie zbiera przewijanie, kliknięcia w linki wychodzące, pobrania plików i wyszukiwanie w witrynie. Warto wiedzieć, że to działa, bo inaczej łatwo skonfigurować drugi raz to samo i podwoić zdarzenia. Wyszukiwanie w witrynie wymaga sprawdzenia, jaki parametr w adresie używa sklep — domyślna lista Google nie zawsze go obejmuje.

Drugi tag, którego będę używać do wszystkiego dalej, to tag zdarzenia GA4. Ma dwa istotne pola: nazwę zdarzenia i parametry. Nazwy zdarzeń e-commerce nie wymyślam — muszą być dokładnie takie, jakich oczekuje GA4, bo tylko wtedy raporty monetyzacji je rozpoznają. Własna nazwa oznacza zdarzenie, które trafi do danych, ale w raportach sprzedażowych się nie pojawi.

Które zdarzenia naprawdę są potrzebne

Dokumentacja wymienia kilkanaście zdarzeń e-commerce. Wdrażanie wszystkich naraz to najprostszy sposób, żeby utopić projekt. Kolejność, którą stosuję:

• view_item — wyświetlenie karty produktu. Podstawa całego lejka i najłatwiejsze do zrobienia bez programisty.

• add_to_cart — dodanie do koszyka. Najważniejsze mikrozdarzenie w sklepie, przydatne też jako sygnał dla kampanii.

• begin_checkout — wejście do koszyka lub pierwszego kroku zamówienia.

• purchase — zakup, z numerem transakcji i wartością. Punkt, o który cały czas się rozbijamy.

Dopiero gdy te cztery działają i zgadzają się ze sobą logicznie, dodaję resztę: view_item_list na listingach, select_item na kliknięciu w produkt, remove_from_cart, view_cart, add_payment_info. Każde kolejne zdarzenie to kolejne miejsce, które trzeba testować po każdej aktualizacji szablonu sklepu.

Skąd wziąć dane produktu bez programisty

Tu jest cała robota. Mam trzy drogi i zwykle używam ich w tej kolejności.

Pierwsza i najlepsza: sprawdzam, czy sklep już nie wypycha warstwy danych. Wiele platform i wtyczek wdrożyło kiedyś rozszerzony e-commerce dla Universal Analytics i nadal to robi. Jeśli tak, w podglądzie Tag Managera widzę gotowe obiekty z produktami — wystarczy zmienną własną przemapować na strukturę, jakiej oczekuje GA4, bo nazwy pól się różnią. To najczystsze rozwiązanie z dostępnych, bo dane pochodzą z systemu, nie z wyglądu strony.

Druga: zmienne odczytujące elementy strony. Nazwa produktu z nagłówka, cena z elementu z ceną, identyfikator z atrybutu. Działa, ale jest kruche — zmiana szablonu potrafi to zepsuć bez żadnego ostrzeżenia. Dlatego przy cenie zawsze dodaję czyszczenie wartości, żeby usunąć symbol waluty i zamienić przecinek na kropkę. Cena jako tekst „129,00 zł” nie jest liczbą i GA4 nic z nią nie zrobi.

Trzecia: adres URL. Kategoria z fragmentu ścieżki, identyfikator z parametru — uzupełnienie, rzadko główne źródło.

Przy każdej z tych dróg pilnuję dwóch rzeczy: żeby wartości liczbowe faktycznie były liczbami i żeby waluta była podana jawnie. Brak waluty przy wartości to najczęstsza przyczyna tego, że przychód nie pokazuje się w raportach.

Zakup — jedyne zdarzenie, którego nie da się dobrze podrobić

Powiem wprost: kliknięcia w przycisk „Zamawiam” nie liczę jako zakupu. Nie wiem, czy płatność się udała, nie znam numeru zamówienia, nie znam kwoty po rabatach. Konto, na którym zakup jest liczony z kliknięcia, systematycznie zawyża sprzedaż i nikt nie wie, o ile.

Najlepsze, co potrafię bez kodu, to zdarzenie na stronie podziękowania — jeśli sklep ma osobny adres potwierdzenia, a numer zamówienia i kwota są na niej wypisane. Wtedy odczytuję je z treści strony, przekazuję jako identyfikator transakcji i wartość, a wyzwalacz opieram na adresie potwierdzenia. Identyfikator transakcji jest kluczowy, bo GA4 na jego podstawie odrzuca duplikaty przy odświeżeniu strony.

Jeśli strony podziękowania nie ma albo płatność wraca na stronę główną, to jest granica tej metody. Wtedy mierzę cały lejek do begin_checkout, a przy transakcji wpisuję do dokumentacji projektu, że brakuje wdrożenia po stronie sklepu — i tę jedną rzecz zgłaszam jako zadanie dla programisty. Jedna dobrze uzasadniona prośba przechodzi znacznie częściej niż lista dwudziestu.

Testowanie, zanim ktokolwiek zobaczy te dane

Kolejność jest zawsze taka sama i nie skracam jej.

Najpierw tryb podglądu w Tag Managerze: przechodzę ścieżkę zakupową i sprawdzam, czy tagi odpalają się tam, gdzie mają, oraz jakie wartości mają zmienne. Interesują mnie nie tylko odpalenia, ale i te nadmiarowe — add_to_cart wyzwalany na każdym kliknięciu w kartę produktu na listingu to klasyk.

Potem DebugView w GA4. Tam widzę zdarzenia z parametrami tak, jak dotarły do właściwości, i mogę potwierdzić, że tablica produktów przyszła w całości.

Na końcu odczekuję dobę i porównuję liczby z panelem sklepu. Nie oczekuję zgodności co do sztuki — pomiar w przeglądarce zawsze zaniża. Oczekuję stabilnej, wyjaśnialnej różnicy. Skok z dnia na dzień oznacza błąd konfiguracji, nie zmianę zachowania klientów.

Czego nie zobaczysz w raportach od razu

Dwie rzeczy zaskakują przy pierwszym wdrożeniu i obie warto ustawić na starcie.

Pierwsza: domyślny okres przechowywania danych o użytkownikach wynosi dwa miesiące. Jeśli chcesz porównywać rok do roku w eksploracjach, trzeba to zmienić na czternaście miesięcy w ustawieniach właściwości. Ta zmiana nie działa wstecz, więc każdy tydzień zwłoki to bezpowrotnie utracone dane.

Druga: raporty standardowe GA4 są ubogie i to jest celowe. Zestawienia, które w Universal Analytics były gotowe, tutaj składa się samodzielnie w eksploracjach. Zanim uznasz, że pomiar nie działa, sprawdź, czy po prostu nie patrzysz w niewłaściwe miejsce.

I rzecz na koniec, którą powtarzam każdemu klientowi: skoro Universal Analytics przestanie zbierać dane w połowie przyszłego roku, to równoległy pomiar w obu narzędziach ma sens już teraz. Nie po to, żeby liczby się zgadzały — nie będą, bo modele danych są różne — ale po to, żeby w lipcu 2023 mieć w GA4 rok historii, a nie pusty wykres.