GA4 i Google Tag Manager - tagowanie e-commerce krok po kroku

GA4 i Google Tag Manager w sklepie internetowym nie są dodatkiem „dla analityka”. To fundament podejmowania decyzji o reklamach, SEO, UX, koszyku, produktach i realnej rentowności sprzedaży. Jeżeli sklep na WooCommerce albo PrestaShop nie wysyła poprawnych zdarzeń e-commerce, właściciel widzi tylko fragment rzeczywistości. Widzi wejścia, kliknięcia i czasem sprzedaż, ale nie widzi, gdzie klient odpada, które produkty interesują użytkowników, które kampanie faktycznie zarabiają, a które tylko generują ruch.

Największy błąd, jaki widzę od lat, to podejście: „wkleimy kod GA4 i będzie działać”. Nie będzie. Sam kod GA4 mierzy podstawowe interakcje, ale e-commerce wymaga dobrze przygotowanego dataLayer, poprawnych zdarzeń, zgodnych parametrów produktów, właściwego tagowania w Google Tag Managerze i przetestowania całej ścieżki zakupowej. W sklepie internetowym nie wystarczy wiedzieć, że użytkownik był na stronie. Trzeba wiedzieć, czy zobaczył produkt, dodał go do koszyka, rozpoczął checkout, wybrał dostawę, wybrał płatność i finalnie kupił.

Ten poradnik piszę z perspektywy praktyka. Bez teorii, bez obietnic, że sama analityka magicznie zwiększy sprzedaż. Dobre tagowanie nie sprzedaje za sklep - pokazuje tylko, co naprawdę dzieje się w sklepie, żebyś mógł podejmować decyzje na faktach. Dotyczy to i WooCommerce, i PrestaShop, bo problem zwykle nie leży w samej platformie, tylko w chaotycznej konfiguracji pomiaru. Tym właśnie zajmuję się w ramach analityki i tagowania konwersji.

Dlaczego poprawne tagowanie e-commerce jest ważniejsze niż sam ruch

Właściciele sklepów często zaczynają od pytania: „dlaczego mam mało sprzedaży?”. To dobre pytanie, ale bez poprawnego pomiaru odpowiedź jest zgadywaniem. Można podejrzewać cenę, reklamę, UX, produkt, koszyk, dostawę, płatności albo zaufanie do sklepu. Problem w tym, że bez zdarzeń e-commerce nie wiadomo, na którym etapie klient rezygnuje.

GA4 pozwala analizować ścieżkę użytkownika, ale tylko wtedy, gdy sklep wysyła właściwe dane. Jeżeli mierzysz wyłącznie wejście na stronę i zakup, nie widzisz środka lejka. A właśnie tam dzieje się najwięcej. Klient ogląda produkty i nie wrzuca ich do koszyka. Wrzuca do koszyka, a do checkoutu już nie przechodzi. Zaczyna checkout i odpada przy kosztach dostawy. Dochodzi do płatności i nie kończy transakcji. Każdy z tych etapów to inna przyczyna i inne działanie naprawcze.

Dobre tagowanie daje odpowiedzi na praktyczne pytania:

które produkty są najczęściej oglądane,
które produkty są dodawane do koszyka,
które produkty często oglądane nie sprzedają się,
gdzie użytkownicy odpadają w ścieżce zakupowej,
czy kampanie Google Ads sprowadzają klientów, którzy wykonują realne działania,
czy koszyk i checkout działają poprawnie,
czy warto zmieniać układ strony produktu,
czy problem leży w ruchu, ofercie, cenie, zaufaniu, dostawie czy technice.

W WooCommerce i PrestaShop bardzo często widzę sytuację, w której sklep ma uruchomiony GA4, ale nie ma sensownego pomiaru e-commerce. W panelu coś się wyświetla, są sesje, użytkownicy i pojedyncze konwersje, więc właściciel zakłada, że analityka działa. Dopiero przy głębszym sprawdzeniu okazuje się, że brakuje zdarzeń add_to_cart, begin_checkout albo purchase wysyła się kilka razy dla jednej transakcji.

To jest poważny problem. Błędne dane są gorsze niż brak danych. Brak danych przynajmniej uczciwie mówi „nie wiemy”, a błędne dane dają złudzenie kontroli. Na ich podstawie wyłączysz dobrą kampanię, zostawisz słabą, źle ocenisz produkt albo niepotrzebnie przebudujesz checkout. Dlatego poprawny pomiar to także fundament każdego sensownego prowadzenia kampanii Google Ads.

GA4, GTM i dataLayer - kto za co odpowiada

Zanim przejdziemy do tagowania, trzeba jasno rozdzielić role narzędzi. Wiele błędów wynika z tego, że ktoś myli GA4, Google Tag Managera i dataLayer.

GA4 to narzędzie analityczne. Odbiera dane, przetwarza je i pokazuje raporty. W GA4 widzisz zdarzenia, przychody, produkty, ścieżki, źródła ruchu i konwersje. GA4 nie „wie” jednak samo z siebie, że ktoś dodał konkretny produkt do koszyka, jeżeli sklep nie wyśle takiej informacji.

Google Tag Manager to system zarządzania tagami. Pozwala uruchamiać kody śledzące bez ręcznego edytowania plików strony przy każdej zmianie. W GTM ustawiasz tagi, reguły i zmienne. GTM może wysyłać dane do GA4, Google Ads, Meta Ads i innych systemów. Sam GTM nie jest jednak źródłem prawdy o produktach i transakcjach. On tylko odbiera dane ze strony i przekazuje je dalej.

dataLayer to warstwa danych. To uporządkowane miejsce, do którego sklep wypycha informacje o zdarzeniach. Przykład: użytkownik ogląda produkt, więc sklep wypycha do dataLayer zdarzenie view_item wraz z nazwą produktu, ceną, ID produktu, kategorią i walutą. GTM odczytuje to zdarzenie i wysyła je do GA4.

W praktyce wygląda to tak:

użytkownik wykonuje akcję w sklepie,
sklep generuje odpowiednie zdarzenie w dataLayer,
GTM wykrywa to zdarzenie,
GTM uruchamia tag GA4,
GA4 odbiera zdarzenie i pokazuje je w raportach.

Jeżeli dataLayer jest źle przygotowany, GTM nie ma czego poprawnie wysłać. Jeżeli GTM jest źle skonfigurowany, dobre dane z dataLayer nie trafią poprawnie do GA4. Jeżeli GA4 jest źle skonfigurowane, zdarzenia mogą przychodzić, ale raporty będą nieczytelne albo konwersje nie będą właściwie oznaczone.

W sklepach WooCommerce i PrestaShop najczęściej spotykam trzy scenariusze:

sklep ma tylko podstawowy kod GA4 bez e-commerce,
sklep ma gotową wtyczkę/moduł, ale zdarzenia są niepełne,
sklep ma kilka narzędzi naraz i te same zdarzenia wysyłają się podwójnie.

Najbardziej niebezpieczny jest trzeci przypadek. Przykład: w sklepie działa moduł GA4, dodatkowo kod GA4 jest wklejony w motywie, a do tego GTM wysyła własne zdarzenia. Efekt? Te same zakupy mogą być mierzone kilka razy. Właściciel sklepu widzi zawyżony przychód i podejmuje decyzje na podstawie fikcyjnego obrazu sprzedaży.

Dlatego przed wdrożeniem trzeba ustalić jedną architekturę pomiaru. Najczęściej najlepszym rozwiązaniem jest: sklep wypycha dane do dataLayer, a GTM wysyła je do GA4 i innych systemów. Dzięki temu GTM staje się centralnym miejscem zarządzania tagami.

Jakie zdarzenia e-commerce trzeba mierzyć w sklepie

GA4 działa na modelu zdarzeń. To oznacza, że zamiast klasycznego patrzenia głównie na odsłony stron, mierzymy konkretne akcje użytkownika. W e-commerce najważniejsze są zdarzenia związane z produktami, koszykiem i zakupem.

Nie trzeba mierzyć wszystkiego od pierwszego dnia, ale podstawowy zestaw powinien obejmować całą ścieżkę zakupową.

view_item

Zdarzenie view_item oznacza wyświetlenie karty produktu. Powinno uruchamiać się wtedy, gdy użytkownik wejdzie na stronę konkretnego produktu. To jedno z najważniejszych zdarzeń, bo pokazuje realne zainteresowanie ofertą.

Dla view_item warto wysyłać dane produktu:

item_id,
item_name,
price,
currency,
item_category,
item_brand, jeżeli ma sens w danym sklepie,
quantity, zwykle jako jeden przy oglądaniu produktu.

W WooCommerce item_id może być ID produktu albo SKU. W PrestaShop również trzeba zdecydować, czy używany będzie identyfikator produktu, referencja produktu, czy inny stały identyfikator. Najważniejsze jest to, żeby zachować konsekwencję. Jeżeli raz wysyłasz SKU, a raz wewnętrzne ID, raporty produktowe robią się bałaganem.

view_item_list

Zdarzenie view_item_list oznacza wyświetlenie listy produktów, na przykład kategorii, wyników wyszukiwania albo sekcji „podobne produkty”. Nie każdy sklep potrzebuje tego od razu, ale przy większym katalogu jest to bardzo przydatne.

Dzięki view_item_list możesz analizować, które listy produktów generują zainteresowanie i czy użytkownicy przechodzą z kategorii na produkty. To ma znaczenie przy optymalizacji kategorii, filtrów i merchandisingu.

select_item

Zdarzenie select_item oznacza kliknięcie produktu na liście. Jeżeli użytkownik jest na kategorii i klika konkretny produkt, select_item pozwala sprawdzić, które produkty przyciągają uwagę na listach.

W praktyce to zdarzenie jest często pomijane, bo wymaga dokładniejszego wdrożenia. Nie jest tak krytyczne jak purchase czy add_to_cart, ale w sklepach z większym ruchem i większą liczbą produktów daje wartościowe informacje.

add_to_cart

Zdarzenie add_to_cart oznacza dodanie produktu do koszyka. To kluczowy moment. Użytkownik nie tylko ogląda produkt, ale wykazuje realną intencję zakupu.

W add_to_cart trzeba wysłać:

identyfikator produktu,
nazwę produktu,
cenę,
walutę,
ilość,
wariant, jeżeli produkt ma rozmiar, kolor, pojemność lub inną wersję,
kategorię.

W WooCommerce trzeba szczególnie uważać na produkty wariantowe. Jeżeli klient wybiera rozmiar albo kolor, do GA4 powinny trafić informacje o właściwym wariancie, a nie tylko o produkcie nadrzędnym. W PrestaShop podobnie: kombinacje produktów powinny być rozpoznawalne, zwłaszcza gdy różnią się ceną albo dostępnością.

remove_from_cart

Zdarzenie remove_from_cart informuje, że użytkownik usunął produkt z koszyka. Wiele sklepów tego nie mierzy, a szkoda. Jeżeli użytkownicy często usuwają konkretny produkt z koszyka, może to sugerować problem z ceną, kosztem dostawy, opisem, wariantem albo dostępnością.

Nie jest to pierwsze zdarzenie, od którego zaczynałbym wdrożenie, ale w dopracowanym pomiarze warto je mieć.

view_cart

Zdarzenie view_cart oznacza wyświetlenie koszyka. Pomaga sprawdzić, ilu użytkowników po dodaniu produktu faktycznie przechodzi do koszyka. Jeżeli dużo osób dodaje produkty, ale mało otwiera koszyk, warto sprawdzić UX, komunikat po dodaniu produktu, mini koszyk i widoczność przycisku przejścia do zamówienia.

begin_checkout

Zdarzenie begin_checkout oznacza rozpoczęcie procesu składania zamówienia. To bardzo ważny etap. Jeżeli użytkownicy dodają produkty do koszyka, ale nie rozpoczynają checkoutu, problem może leżeć wcześniej: w koszyku, kosztach dostawy, braku zaufania, zbyt słabym przycisku, problemach mobilnych albo niejasnych warunkach zakupu.

W WooCommerce begin_checkout zwykle uruchamia się na stronie zamówienia. W PrestaShop zależy to od wersji, szablonu i modułu checkoutu. Przy niestandardowych checkoutach trzeba sprawdzić, czy zdarzenie uruchamia się tylko raz i w odpowiednim momencie.

add_shipping_info

Zdarzenie add_shipping_info oznacza podanie lub wybranie informacji o dostawie. Nie każdy sklep wdraża je od razu, ale jest bardzo przydatne, jeżeli masz kilka metod dostawy albo podejrzewasz, że użytkownicy odpadają przez koszty lub warunki dostawy.

Warto przekazywać parametr shipping_tier, czyli wybraną metodę dostawy. Nie po to, żeby budować rozbudowane raporty na pokaz, tylko żeby wiedzieć, czy konkretne formy dostawy wspierają sprzedaż, czy ją blokują.

add_payment_info

Zdarzenie add_payment_info oznacza wybór metody płatności. Ma znaczenie szczególnie w sklepach, gdzie dostępnych jest kilka metod: szybkie płatności, karta, przelew, płatność przy odbiorze, raty albo portfele elektroniczne.

Jeżeli użytkownicy wybierają metodę płatności, ale nie kończą zakupu, trzeba sprawdzić działanie operatora płatności, komunikaty błędów, przekierowania, wersję mobilną i zgodność z przeglądarkami.

purchase

Zdarzenie purchase to finalizacja zakupu. To najważniejsze zdarzenie e-commerce. Musi być mierzone bardzo ostrożnie, bo błędy tutaj niszczą całą analizę sprzedaży.

Purchase powinno zawierać:

transaction_id,
value,
currency,
tax, jeżeli dane są dostępne i potrzebne,
shipping, jeżeli dane są dostępne,
coupon, jeżeli użyto kodu rabatowego,
items z pełnymi danymi produktów.

Najważniejszy jest transaction_id. Bez niego trudniej kontrolować duplikaty. Zdarzenie purchase powinno uruchamiać się na stronie potwierdzenia zamówienia, ale tylko raz dla danej transakcji. Tu psuje się to najczęściej. Ktoś wysyła purchase ponownie po odświeżeniu strony „dziękujemy za zakup”. Ktoś inny odpala je już na wejściu do bramki płatności, zanim płatność w ogóle przejdzie. Bywa też, że brakuje wartości zamówienia albo waluta jest błędna.

refund

Zdarzenie refund jest przydatne, jeżeli chcesz analizować zwroty i korekty. W wielu sklepach nie jest wdrażane na początku, bo wymaga połączenia danych analitycznych z procesem obsługi zamówień. Warto jednak wiedzieć, że GA4 przewiduje takie zdarzenie. Przy większej sprzedaży i realnej analizie rentowności samo purchase nie wystarcza, bo nie pokazuje, co stało się później z zamówieniem.

Jak powinien wyglądać poprawny dataLayer

dataLayer to miejsce, w którym sklep przekazuje dane do GTM. W praktyce jest to tablica JavaScript dostępna na stronie. Dobrze zbudowany dataLayer powinien być czytelny, konsekwentny i zgodny z logiką zdarzeń GA4.

Przykładowe zdarzenie view_item może wyglądać logicznie tak:

dataLayer.push({
  event: "view_item",
  ecommerce: {
    currency: "PLN",
    value: 199.00,
    items: [
      {
        item_id: "SKU-123",
        item_name: "Nazwa produktu",
        item_category: "Kategoria",
        price: 199.00,
        quantity: 1
      }
    ]
  }
});

Przykładowe zdarzenie add_to_cart:

dataLayer.push({
  event: "add_to_cart",
  ecommerce: {
    currency: "PLN",
    value: 199.00,
    items: [
      {
        item_id: "SKU-123",
        item_name: "Nazwa produktu",
        item_category: "Kategoria",
        price: 199.00,
        quantity: 1
      }
    ]
  }
});

Przykładowe zdarzenie purchase:

dataLayer.push({
  event: "purchase",
  ecommerce: {
    transaction_id: "ORDER-12345",
    value: 249.00,
    tax: 0,
    shipping: 0,
    currency: "PLN",
    items: [
      {
        item_id: "SKU-123",
        item_name: "Nazwa produktu",
        item_category: "Kategoria",
        price: 199.00,
        quantity: 1
      }
    ]
  }
});

To są przykłady struktury, a nie gotowy kod do wklejenia w każdy sklep. Wdrożenie zależy od platformy, szablonu, modułów, wariantów produktów, checkoutu i metod płatności. Najważniejsze jest zrozumienie logiki.

Dobry dataLayer powinien spełniać kilka warunków:

zdarzenie powinno uruchamiać się w odpowiednim momencie,
nazwy zdarzeń powinny być zgodne z GA4,
dane produktów powinny być kompletne i konsekwentne,
waluta powinna być przekazywana poprawnie,
value powinno odpowiadać wartości zdarzenia,
purchase powinno mieć unikalny transaction_id,
zdarzenia nie powinny dublować się przy odświeżaniu strony,
produkty wariantowe powinny być rozpoznawalne,
dane nie powinny zawierać informacji osobowych.

Ostatni punkt jest bardzo ważny. Do GA4 nie należy wysyłać danych osobowych klientów, takich jak adres e-mail, numer telefonu, imię i nazwisko czy pełny adres. W e-commerce czasem ktoś próbuje dodać takie informacje „dla lepszej analizy”. To zły kierunek. Analityka powinna mierzyć zachowania, produkty, transakcje i źródła ruchu, ale nie powinna wysyłać danych osobowych do miejsc, do których nie powinny trafiać.

W WooCommerce dataLayer można przygotować przez dobrą wtyczkę, własne wdrożenie albo integrację po stronie motywu. W PrestaShop najczęściej wykorzystuje się moduł albo własną integrację. Niezależnie od metody trzeba sprawdzić realny wynik w trybie podglądu GTM i w DebugView GA4. Sama informacja, że „moduł obsługuje GA4”, niczego jeszcze nie gwarantuje.

Konfiguracja Google Tag Managera krok po kroku

Gdy dataLayer jest przygotowany, można przejść do GTM. W Google Tag Managerze konfiguracja e-commerce opiera się na trzech elementach: zmiennych, regułach i tagach.

Krok 1: uporządkuj kontener GTM

Na początku trzeba sprawdzić, czy sklep ma jeden główny kontener GTM. Częsty bałagan wygląda tak: jeden kontener jest wklejony przez szablon, drugi przez moduł, trzeci przez wtyczkę, a do tego gdzieś w kodzie siedzi bezpośredni skrypt GA4.

Takie wdrożenie trzeba uporządkować. W sklepie powinno być jasne:

gdzie wstawiony jest kod GTM,
czy kod GTM ładuje się na wszystkich ważnych stronach,
czy nie ma kilku kontenerów bez potrzeby,
czy GA4 nie jest wysyłane równolegle poza GTM,
czy stare tagi Universal Analytics zostały usunięte lub przynajmniej nie przeszkadzają,
czy narzędzia reklamowe nie dublują zdarzeń.

Nie chodzi o to, żeby usuwać wszystko w ciemno. Chodzi o audyt. Najpierw sprawdzasz, co działa, a dopiero potem decydujesz, co zostaje.

Krok 2: utwórz tag konfiguracji GA4

W GTM trzeba dodać tag Google Analytics GA4. Obecnie konfiguracja może być oparta o tag Google tag lub tag zdarzenia GA4, zależnie od sposobu wdrożenia i interfejsu GTM. Najważniejsze, żeby tag bazowy ładował się poprawnie i korzystał z właściwego identyfikatora pomiaru GA4.

Ten tag powinien uruchamiać się na stronach, na których pomiar jest dozwolony zgodnie z ustawieniami zgody użytkownika. W praktyce oznacza to, że trzeba uwzględnić consent mode i baner zgody.

Krok 3: przygotuj reguły dla zdarzeń dataLayer

Dla zdarzeń e-commerce tworzy się reguły typu Custom Event. Reguła dla view_item nasłuchuje zdarzenia view_item. Reguła dla add_to_cart nasłuchuje add_to_cart. Reguła dla purchase nasłuchuje purchase.

Przykładowe reguły:

Custom Event: view_item,
Custom Event: add_to_cart,
Custom Event: remove_from_cart,
Custom Event: view_cart,
Custom Event: begin_checkout,
Custom Event: add_shipping_info,
Custom Event: add_payment_info,
Custom Event: purchase.

Nie należy uruchamiać zdarzeń e-commerce wyłącznie na podstawie adresu URL, jeżeli można tego uniknąć. Przykład: tag purchase uruchamiany tylko dlatego, że adres zawiera „order-confirmation” albo „thank-you”, jest ryzykowny. Lepiej, gdy purchase wynika z dataLayer i zawiera transaction_id oraz dane zamówienia. URL może być dodatkowym zabezpieczeniem, ale nie powinien zastępować danych transakcyjnych.

Krok 4: utwórz tagi zdarzeń GA4

Dla każdego zdarzenia tworzysz tag GA4 Event. Nazwa zdarzenia w tagu powinna odpowiadać nazwie zdarzenia GA4, na przykład add_to_cart albo begin_checkout.

W tagu trzeba przekazać dane e-commerce. W nowszych wdrożeniach zwykle korzysta się z danych dostępnych w dataLayer. Ważne jest, żeby GTM nie tworzył przypadkowych parametrów, których GA4 nie zrozumie w raportach e-commerce. GA4 ma określoną strukturę parametrów i listy items. Trzeba się jej trzymać.

Dla purchase trzeba szczególnie dopilnować parametrów:

transaction_id,
value,
currency,
items.

Bez transaction_id raportowanie zakupów będzie mniej odporne na problemy. Bez value nie będzie sensownej wartości przychodu. Bez items raporty produktowe będą ubogie. Bez currency mogą pojawić się nieporozumienia, szczególnie w sklepach wielowalutowych.

Krok 5: oznacz konwersje w GA4

Samo wysłanie purchase do GA4 nie oznacza jeszcze, że wszystko w raportach jest idealnie gotowe do pracy. W GA4 warto sprawdzić listę zdarzeń i oznaczyć najważniejsze jako kluczowe zdarzenia, jeżeli mają być traktowane jako konwersje w analizie.

W sklepie podstawowym zdarzeniem konwersyjnym jest purchase. W niektórych przypadkach jako ważne zdarzenia pomocnicze można obserwować begin_checkout albo add_to_cart, ale nie należy mieszać ich ze sprzedażą. Dodanie do koszyka to nie zakup. Rozpoczęcie checkoutu to nie zakup. W raportach i reklamach trzeba to jasno rozdzielać.

Krok 6: publikuj dopiero po testach

Najgorsze wdrożenia powstają tak: ktoś dodaje tagi, klika „Opublikuj” i dopiero po kilku dniach sprawdza, czy działa. To proszenie się o problemy. GTM ma tryb podglądu po to, żeby testować przed publikacją.

Przed publikacją trzeba przejść realną ścieżkę:

wejście na stronę główną,
wejście na kategorię,
wejście na produkt,
dodanie produktu do koszyka,
usunięcie produktu z koszyka,
ponowne dodanie,
przejście do koszyka,
rozpoczęcie checkoutu,
wybór dostawy,
wybór płatności,
zakup testowy,
odświeżenie strony potwierdzenia,
powrót do sklepu po płatności.

Na każdym etapie trzeba sprawdzić, czy uruchamia się właściwe zdarzenie, czy dane są kompletne i czy nic się nie dubluje.

WooCommerce - na co uważać przy tagowaniu

WooCommerce jest popularny, elastyczny i wygodny, ale właśnie ta elastyczność powoduje problemy z analityką. Sklep WooCommerce może działać na różnych motywach, różnych builderach, różnych wtyczkach checkoutu i różnych systemach płatności. Każda taka warstwa może wpływać na tagowanie.

Produkty proste i wariantowe

W WooCommerce trzeba sprawdzić, jak dataLayer obsługuje produkty proste i wariantowe. Produkt prosty jest łatwiejszy: ma jedną cenę, jedno ID, jedną nazwę. Produkt wariantowy może mieć rozmiary, kolory, różne ceny i różne SKU.

Błąd polega na tym, że do GA4 trafia tylko produkt nadrzędny, bez informacji o wybranym wariancie. Właściciel sklepu widzi, że sprzedaje się „Koszulka”, ale nie widzi, czy chodzi o rozmiar M, L, czarną, białą czy inną wersję. Przy małym sklepie to może być do przeżycia. Przy większym katalogu zaczyna przeszkadzać w analizie.

AJAX add to cart

Wiele sklepów WooCommerce używa dodawania do koszyka bez przeładowania strony. Użytkownik klika „Dodaj do koszyka”, produkt trafia do koszyka, ale strona się nie odświeża. Dla UX to może być dobre, ale dla analityki oznacza, że nie wystarczy nasłuchiwać załadowania strony. Trzeba wykryć realną akcję dodania produktu.

Jeżeli wtyczka lub motyw obsługuje AJAX add to cart, trzeba sprawdzić, czy add_to_cart pojawia się w dataLayer w momencie kliknięcia i czy zawiera właściwe dane produktu. Samo kliknięcie przycisku nie zawsze wystarczy, bo kliknięcie może się nie udać. Lepsze jest mierzenie skutecznego dodania do koszyka, a nie samego zamiaru kliknięcia.

Checkout WooCommerce

Checkout w WooCommerce może być standardowy albo mocno zmodyfikowany. Jeżeli działa klasyczny checkout, begin_checkout zwykle da się uruchomić po wejściu na stronę zamówienia. Jeżeli sklep korzysta z niestandardowego checkoutu, one page checkoutu albo dodatkowych wtyczek, trzeba testować dokładniej.

Warto sprawdzić:

czy begin_checkout uruchamia się tylko raz,
czy add_shipping_info uruchamia się po wyborze dostawy,
czy add_payment_info uruchamia się po wyborze płatności,
czy purchase wysyła się dopiero po potwierdzeniu zamówienia,
czy purchase nie powtarza się po odświeżeniu strony,
czy bramka płatności nie przerywa lub nie dubluje pomiaru.

Strona „thank you”

W WooCommerce strona podziękowania jest częstym miejscem wysyłania purchase. To logiczne, ale trzeba uważać. Jeżeli użytkownik odświeży stronę, wróci do niej z historii przeglądarki albo kliknie ponownie link z maila, purchase może wysłać się jeszcze raz, jeżeli wdrożenie nie ma zabezpieczeń.

Dobre wdrożenie powinno korzystać z transaction_id i nie powinno bezmyślnie wysyłać nowego zakupu przy każdym wyświetleniu tej samej strony. W praktyce zabezpieczenie może być po stronie sklepu, modułu, GTM albo logiki deduplikacji, ale trzeba je przetestować.

Wtyczki do GA4

W WooCommerce istnieją wtyczki, które obiecują szybkie wdrożenie GA4 i e-commerce. Nie twierdzę, że są złe. Część z nich jest bardzo pomocna. Problem polega na tym, że właściciel sklepu często instaluje wtyczkę i uznaje sprawę za zamkniętą.

Każdą wtyczkę trzeba sprawdzić:

jakie zdarzenia wysyła,
czy korzysta z dataLayer,
czy wysyła produkty wariantowe,
czy obsługuje purchase poprawnie,
czy nie dubluje tagów z GTM,
czy jest zgodna z aktualnym checkoutem,
czy respektuje zgodę użytkownika,
czy nie wysyła danych osobowych.

Wtyczka nie zwalnia z testowania. Wtyczka tylko przyspiesza wdrożenie, jeżeli jest dobrze dobrana i poprawnie skonfigurowana.

PrestaShop - najczęstsze problemy z pomiarem e-commerce

PrestaShop ma inną logikę niż WooCommerce, ale problemy analityczne są podobne: moduły, szablony, checkout, kombinacje produktów i bramki płatności. W PrestaShop szczególnie ważne jest sprawdzenie, czy moduł analityczny dobrze współpracuje z wersją sklepu i używanym motywem.

Moduły i szablon

W PrestaShop dużo zależy od modułu GA4/GTM i od motywu. Jeżeli sklep korzysta z mocno zmodyfikowanego szablonu, standardowy moduł może nie łapać wszystkich zdarzeń. Bywa, że view_item działa, a add_to_cart już nie. Albo purchase się odpala, tylko bez pełnych danych produktów. Koszyk standardowy mierzy się dobrze, a niestandardowy checkout wypada z pomiaru.

Dlatego nie wystarczy sprawdzić, czy moduł jest zainstalowany. Trzeba przejść ścieżkę użytkownika i zobaczyć, co faktycznie trafia do dataLayer.

Kombinacje produktów

PrestaShop często wykorzystuje kombinacje produktów: rozmiary, kolory, pojemności, warianty techniczne. Przy tagowaniu trzeba zadbać, żeby wybrana kombinacja była rozpoznawalna w danych. Jeżeli użytkownik kupuje konkretną kombinację, raport powinien dawać możliwość jej identyfikacji.

Nie zawsze trzeba tworzyć przesadnie szczegółowe raporty dla każdej kombinacji, ale przy produktach, gdzie wariant wpływa na cenę, dostępność albo marżę, jest to istotne.

Koszyk i checkout

PrestaShop może mieć różne układy checkoutu w zależności od wersji, szablonu i modułów. Niektóre sklepy mają checkout jednoetapowy, inne wieloetapowy. To wpływa na moment uruchomienia zdarzeń.

Trzeba ustalić realne punkty:

kiedy użytkownik faktycznie zaczyna checkout,
kiedy wybiera dostawę,
kiedy wybiera płatność,
kiedy zamówienie jest złożone,
kiedy płatność jest potwierdzona,
kiedy użytkownik wraca do strony potwierdzenia.

W idealnym świecie purchase powinno odpowiadać realnie złożonemu zamówieniu i mieć komplet danych. W praktyce trzeba też uwzględnić specyfikę płatności. Niektóre metody płatności tworzą zamówienie przed opłaceniem, inne po opłaceniu, a jeszcze inne wymagają powrotu z zewnętrznej bramki.

Duplikaty zamówień w GA4

W PrestaShop duplikaty purchase mogą pojawić się przez odświeżenie strony potwierdzenia, powrót z bramki płatności albo równoległe działanie kilku modułów. To trzeba sprawdzić testowo.

Objawy problemu:

jedna transakcja pojawia się kilka razy,
przychód w GA4 jest wyższy niż w panelu sklepu,
purchase uruchamia się przy samym wejściu na stronę płatności,
tag purchase odpala się z GTM i z modułu jednocześnie,
dane produktów różnią się między zdarzeniami.

Rozwiązaniem jest uporządkowanie źródła danych i wybranie jednej metody wysyłania zdarzeń. Jeżeli używasz GTM, to najlepiej, żeby inne moduły nie wysyłały niezależnie tych samych zdarzeń do GA4.

Tagowanie e-commerce nie może być oderwane od zgód użytkownika. W praktyce oznacza to, że baner cookies, tryb zgody i tagi analityczne muszą ze sobą współpracować. Nie chodzi tylko o „ładny pasek cookies”. Chodzi o to, czy tagi uruchamiają się zgodnie z decyzją użytkownika.

Consent Mode pozwala przekazywać do Google informacje o stanie zgody dla różnych typów przechowywania i przetwarzania danych. W kontekście sklepu najczęściej mówimy o zgodach związanych z analityką i reklamą. Wdrożenie powinno być zgodne z przyjętą polityką prywatności i realnym działaniem banera zgody.

W praktyce trzeba ustalić:

jakie kategorie zgód ma sklep,
co dzieje się przed udzieleniem zgody,
co dzieje się po zaakceptowaniu zgód,
co dzieje się po odrzuceniu zgód,
czy GTM otrzymuje aktualizację zgody,
czy tagi GA4 i reklamowe respektują stan zgody,
czy baner zgody nie jest tylko atrapą wizualną.

Klasyka: sklep ma baner cookies, a tagi i tak uruchamiają się od razu. Użytkownik jeszcze niczego nie zaakceptował, a GA4, Google Ads, Meta Pixel i inne skrypty już pracują. Inny wariant: użytkownik akceptuje zgodę, ale GTM nie dostaje aktualizacji, więc tagi dalej zachowują się tak, jakby zgody nie było. Bywa też, że każda wtyczka działa po swojemu i nie ma jednego spójnego systemu zgód.

Consent Mode trzeba testować tak samo jak zdarzenia e-commerce. W trybie podglądu GTM można sprawdzić stan zgody i zachowanie tagów. Trzeba przetestować wariant akceptacji, odrzucenia i zmiany preferencji. Bez tego nie wiadomo, czy wdrożenie działa realnie, czy tylko wygląda poprawnie w panelu.

W WooCommerce i PrestaShop często używa się gotowych modułów do zgód. To może być dobre rozwiązanie, ale znowu: moduł trzeba sprawdzić. Najważniejsze jest, czy integruje się z GTM i czy poprawnie aktualizuje zgody. Sam napis „zgodne z RODO” w opisie wtyczki nie jest dowodem poprawnego działania w konkretnym sklepie.

Testowanie wdrożenia - bez tego nie ma sensu publikować

Tagowanie e-commerce bez testów to loteria. Można mieć pięknie nazwane tagi, poprawnie wyglądające reguły i elegancki kontener GTM, a mimo to wysyłać złe dane. Dlatego testowanie jest osobnym etapem pracy, a nie dodatkiem na końcu.

Tryb podglądu GTM

Pierwsze miejsce testowania to Preview Mode w Google Tag Managerze. Pozwala zobaczyć, jakie zdarzenia pojawiają się na stronie i jakie tagi uruchamiają się przy każdym zdarzeniu.

Podczas testu trzeba sprawdzić:

czy view_item pojawia się na stronie produktu,
czy add_to_cart pojawia się po skutecznym dodaniu produktu,
czy remove_from_cart pojawia się po usunięciu produktu,
czy view_cart pojawia się na koszyku,
czy begin_checkout pojawia się przy rozpoczęciu checkoutu,
czy add_shipping_info pojawia się przy wyborze dostawy,
czy add_payment_info pojawia się przy wyborze płatności,
czy purchase pojawia się po zakupie,
czy dane produktów są kompletne,
czy value i currency są poprawne,
czy transaction_id istnieje i jest unikalny,
czy zdarzenia nie odpalają się podwójnie.

Nie testuj tylko jednej ścieżki. Klienci zachowują się różnie - jeden doda pojedynczy produkt, drugi kilka, ktoś zmieni ilość w koszyku, użyje kuponu, wybierze inną dostawę albo wróci z bramki płatności. Trzeba sprawdzić najważniejsze realne scenariusze.

DebugView w GA4

Drugie miejsce to DebugView w GA4. GTM pokazuje, że tag się uruchomił, ale GA4 pokazuje, czy zdarzenie dotarło do właściwej usługi. To są dwie różne rzeczy. Tag może się uruchomić, ale dane mogą być niepełne, źle nazwane albo niewidoczne w oczekiwany sposób.

W DebugView sprawdzasz:

czy zdarzenia pojawiają się w GA4,
czy nazwy zdarzeń są poprawne,
czy parametry są widoczne,
czy items zawierają produkty,
czy purchase ma transaction_id,
czy value i currency są wysyłane,
czy kolejność zdarzeń ma sens.

Nie należy oceniać wdrożenia tylko po raportach standardowych od razu po publikacji. Raporty mogą mieć opóźnienia, mogą agregować dane i nie zawsze pokazują wszystko natychmiast. DebugView jest lepsze do testowania technicznego.

Testowe zamówienie

W sklepie e-commerce trzeba zrobić testowe zamówienie. Nie ma drogi na skróty. Jeżeli sklep ma różne metody płatności, warto przetestować najważniejsze z nich. Szczególnie trzeba sprawdzić płatności zewnętrzne, bo przekierowania często powodują problemy z sesją, źródłem ruchu i powrotem na stronę potwierdzenia.

Przy testowym zamówieniu sprawdź:

czy purchase wysłało się tylko raz,
czy wartość zamówienia jest poprawna,
czy waluta jest poprawna,
czy koszty dostawy są przekazane zgodnie z założeniem,
czy kupon rabatowy jest widoczny, jeżeli był użyty,
czy lista produktów zgadza się z zamówieniem,
czy produkty wariantowe są poprawnie opisane,
czy transaction_id odpowiada numerowi lub identyfikatorowi zamówienia.

Po teście warto porównać dane z panelem sklepu. GA4 nie musi być systemem księgowym i nie zawsze będzie identyczne z panelem zamówień, ale rażące różnice są sygnałem problemu. Jeżeli jedno zamówienie w sklepie daje kilka zakupów w GA4, wdrożenie jest błędne. Jeżeli zakup w sklepie nie pojawia się w GA4, też trzeba szukać przyczyny.

Najczęstsze błędy, które psują dane w GA4

Po latach pracy ze sklepami widzę, że błędy powtarzają się bardzo regularnie. Platforma może być inna, branża inna, budżet inny, ale problemy są podobne.

Podwójne tagowanie - GA4 jest wklejone w kodzie strony, dodane przez wtyczkę, uruchamiane przez GTM i jeszcze zintegrowane przez moduł reklamowy. Każde narzędzie wysyła coś osobno. Efekt: zdarzenia są dublowane, raporty zawyżone. Rozwiązanie: jedna architektura pomiaru.
Brak transaction_id - purchase bez identyfikatora transakcji utrudnia rozróżnianie zamówień i kontrolę duplikatów. Rozwiązanie: purchase musi pobierać ID zamówienia ze sklepu.
Złe value - czasem zawiera cenę jednego produktu zamiast całego zamówienia, raz z podatkiem, raz bez, czasem tekst zamiast liczby. Rozwiązanie: jedna logika wartości zamówienia.
Brak currency - „przecież wiadomo jaka waluta”. Analityka nie powinna opierać się na domysłach. Rozwiązanie: przekazywać currency przy zdarzeniach z wartością.
Brak items - purchase bez listy produktów ubożeje raporty produktowe. Rozwiązanie: wysyłać tablicę items.
Mieszanie ID produktu i SKU - ten sam produkt występuje jako kilka pozycji. Rozwiązanie: jeden standard identyfikacji.
Zdarzenia na kliknięcie zamiast na skuteczną akcję - kliknięcie „Dodaj do koszyka” nie zawsze oznacza dodanie. Rozwiązanie: add_to_cart po skutecznym dodaniu.
Brak testów po aktualizacjach - tagowanie, które działało, może przestać działać po zmianie wtyczek, modułów, motywu czy checkoutu. Rozwiązanie: test ścieżki po większych aktualizacjach.

Jak utrzymać porządek w analityce sklepu

Wdrożenie tagowania to nie jednorazowy projekt, po którym można zapomnieć o temacie. Sklep żyje. Dochodzą nowe produkty, moduły, płatności, promocje, zmiany checkoutu, nowe kampanie i nowe narzędzia reklamowe. Jeżeli nikt nie pilnuje analityki, po kilku miesiącach znowu robi się bałagan.

Dokumentacja wdrożenia

Każdy sklep powinien mieć prostą dokumentację pomiaru. Nie musi to być wielka księga techniczna. Wystarczy uporządkowany opis: jaki kontener GTM jest używany, jaka usługa GA4 jest podpięta, jakie zdarzenia e-commerce są wdrożone, skąd pochodzi dataLayer, jakie wtyczki lub moduły odpowiadają za dane, które tagi wysyłają dane do GA4, które do Google Ads, jak działa consent mode i kiedy ostatnio testowano wdrożenie.

Oddzielenie analityki od reklam

GA4 i Google Ads są powiązane, ale nie należy mylić analityki z optymalizacją reklam. GA4 ma pokazywać możliwie rzetelny obraz zachowania użytkowników. Google Ads wykorzystuje konwersje do optymalizacji kampanii. Jeżeli do Google Ads wysyłasz źle skonfigurowane konwersje, algorytm będzie optymalizował pod złe sygnały. Najpierw upewnij się, że purchase jest poprawne w GA4, a dopiero potem świadomie zdecyduj, jak konwersje mają trafiać do Google Ads.

Regularny audyt

Raz na jakiś czas trzeba przejść ścieżkę zakupową i sprawdzić tagowanie. Szczególnie po: aktualizacji WooCommerce lub PrestaShop, zmianie motywu, wdrożeniu nowego checkoutu, zmianie bramki płatności, dodaniu modułu cookies, zmianie w GTM, uruchomieniu nowych kampanii i zmianie struktury produktów. Traktuj analitykę jak część technicznego utrzymania sklepu, a nie jak jednorazową konfigurację - podobnie jak przy audycie SEO sklepu.

Od czego zacząć

Jeżeli masz sklep WooCommerce albo PrestaShop i nie jesteś pewien, czy GA4 oraz GTM działają poprawnie, nie zaczynaj od dokładania kolejnej wtyczki. Zacznij od sprawdzenia obecnego stanu. W analityce e-commerce najpierw trzeba zatrzymać bałagan, a dopiero potem budować dokładniejszy pomiar.

Najpierw sprawdź, czy w sklepie nie ma kilku równoległych wdrożeń GA4. Zobacz, czy kod GA4 jest w GTM, w motywie, w module, we wtyczce albo w kilku miejscach naraz. Jeżeli jest kilka źródeł, zanotuj je i ustal, które powinno zostać. Bez tego każdy kolejny krok może tylko pogorszyć dane.

Następnie sprawdź dataLayer. Wejdź na produkt, dodaj go do koszyka, przejdź do checkoutu i wykonaj testowe zamówienie. Zobacz, czy pojawiają się zdarzenia view_item, add_to_cart, begin_checkout i purchase. To podstawowy szkielet. Jeżeli te cztery zdarzenia nie działają poprawnie, nie ma sensu rozbudowywać analityki o bardziej szczegółowe elementy.

Potem sprawdź purchase. To zdarzenie musi być najczystsze. Musi mieć transaction_id, value, currency i items. Musi odpalać się raz dla jednej transakcji. Nie może wysyłać danych osobowych. Nie może uruchamiać się przed faktycznym złożeniem zamówienia.

Kolejny krok to test consent mode. Sprawdź zachowanie tagów przed zgodą, po akceptacji i po odrzuceniu. Baner cookies nie może być tylko dekoracją.

Praktyczna kolejność pracy powinna wyglądać tak:

Sprawdź, gdzie obecnie jest wpięty GA4 i GTM.
Usuń lub wyłącz duplikujące się źródła pomiaru.
Ustal, że GTM jest głównym miejscem zarządzania tagami.
Przygotuj lub popraw dataLayer.
Wdróż podstawowe zdarzenia e-commerce.
Przetestuj wszystko w Preview Mode GTM.
Sprawdź zdarzenia w DebugView GA4.
Wykonaj testowe zamówienie.
Sprawdź consent mode.
Opublikuj kontener dopiero po testach.
Udokumentuj wdrożenie i wracaj do testów po większych zmianach.

Dobre tagowanie e-commerce nie polega na tym, żeby „coś się zbierało”. Polega na tym, żeby dane były na tyle rzetelne, aby właściciel sklepu mógł podejmować decyzje bez zgadywania. Jeżeli masz dziś w GA4 tylko ruch i pojedyncze zakupy, to nie jest jeszcze analityka e-commerce - to początek. Prawdziwa wartość zaczyna się wtedy, gdy widzisz całą ścieżkę: produkt, koszyk, checkout, dostawę, płatność i zakup. Wtedy dopiero można uczciwie ocenić, czy problemem jest reklama, oferta, UX, cena, koszyk, płatność czy techniczne błędy sklepu.