Jak śledzić przychód, transakcje i zakupy z WordPress WooCommerce w Google Analytics 4

Wstęp

Właściciele sklepów na WooCommerce często są przekonani, że Google Analytics 4 już pokazuje im przychód, liczbę transakcji i zachowanie kupujących. W praktyce większość stron przekazuje do GA4 tylko odsłony stron — nie ma tam żadnych zdarzeń view_item, add_to_cart czy purchase. Oznacza to, że:

• w GA4 nie ma raportu „Przychód wg źródła ruchu”;
• Google Ads nie widzi realnej wartości konwersji (nie ma z czego liczyć ROAS);
• decyzje o skalowaniu reklamy podejmowane są „po omacku”.

W tym artykule — krok po kroku pokazujemy, jak zdiagnozowaliśmy i w pełni skonfigurowaliśmy śledzenie ecommerce na prawdziwym sklepie klienta na WooCommerce: od pierwszej weryfikacji „czy w ogóle coś jest wysyłane” po potwierdzone, działające zdarzenie purchase w GA4.

Krok 0. Jak sprawdzić, czy śledzenie ecommerce w ogóle działa

Zanim cokolwiek zainstalujesz, sprawdź obecny stan. Najszybszy sposób — otworzyć kod źródłowy strony produktu (Ctrl+U / Cmd+Option+U) i poszukać dataLayer.push.

Typowa pułapka: jeśli szukasz słowa add_to_cart na stronie produktu WooCommerce, niemal na pewno je znajdziesz — ale będzie to tylko klasa CSS przycisku:

<button class="single_add_to_cart_button ... add_to_cart_button ajax_add_to_cart" data-product_id="124">

To nie jest dowód, że śledzenie działa. Prawdziwe zdarzenie wygląda inaczej — to wywołanie dataLayer.push() z obiektem ecommerce:

dataLayer.push({
  "ecommerce": {
    "currency": "USD",
    "value": 358,
    "items": [{
      "item_id": 591,
      "item_name": "Nazwa produktu",
      "price": 358,
      "item_category": "Products"
    }]
  },
  "event": "view_item"
});

Jeśli na stronie produktu nie ma takiego bloku — dane ecommerce nie trafiają do GA4, nawet jeśli podstawowy gtag('config', ...) dla odsłon stron jest ustawiony i działa.

Co jeszcze warto sprawdzić na tym etapie: – ile razy na stronie ładuje się googletagmanager.com/gtm.js — powinno to być dokładnie raz. Dwa wywołania oznaczają zdublowane dane w GA4 (klasyczny problem, gdy kod GTM jest wstawiony ręcznie i jednocześnie dodany przez wtyczkę); – czy jest już zainstalowana, ale nieaktywna, wtyczka-konektor (np. Site Kit by Google) — często stoi „na wszelki wypadek”, ale w ogóle nie pełni funkcji ecommerce.

Krok 1. Instalacja GTM4WP (Google Tag Manager for WordPress)

Do śledzenia ecommerce w WooCommerce optymalnym wyborem jest bezpłatna wtyczka GTM4WP (autor Thomas Geiger, slug w katalogu WordPress.org: duracelltomi-google-tag-manager). Powody wyboru akurat tej wtyczki:

• już oficjalnie implementuje specyfikację GA4 E-commerce dla WooCommerce „z pudełka”;
• nie wymaga pisania żadnego kodu PHP ręcznie;
• dobrze współpracuje z kontenerem Google Tag Manager już obecnym na stronie.

Instalacja standardowa: Wtyczki → Dodaj nową → wyszukaj „GTM4WP” → Zainstaluj → Aktywuj.

Krok 2. Konfiguracja zakładki General

Po aktywacji wtyczki przejdź do Settings → Google Tag Manager, zakładka General.

Są tu trzy kluczowe pola:

Google Tag Manager ID

Wklej ID Twojego istniejącego kontenera GTM, np. GTM-XXXXXXX. Używaj tego samego kontenera, który już jest na stronie — nie twórz nowego, w przeciwnym razie będziesz musiał ręcznie przenosić cały pozostały tracking (piksele reklamowe, konwersje itd.), który mógł już tam być skonfigurowany.

Container code ON/OFF — najważniejsza opcja

To pole decyduje o zdublowaniu kontenera GTM na stronie:

Sama wtyczka wprost podpowiada to w opisie pola: „This should be only used in specific cases where you need to place the container code manually or using another tool” — to oficjalnie udokumentowany scenariusz właśnie dla przypadku, gdy GTM jest już wstawiony w inny sposób.

Dlaczego to krytyczne: jeśli zostawisz On przy już istniejącym ręcznym kodzie — kontener załaduje się dwukrotnie na każdej stronie, a GA4/Google Ads zaczną liczyć dwa razy więcej zdarzeń i odsłon niż w rzeczywistości. To jeden z najczęstszych, a zarazem najmniej zauważalnych błędów w śledzeniu ecommerce — liczby wyglądają wiarygodnie, więc problem często wychodzi na jaw dopiero po kilku miesiącach, przy porównywaniu przychodu z GA4 z rzeczywistą sprzedażą.

Container code compatibility mode

Wpływa na umiejscowienie drugiej (<noscript>) części kodu GTM. Jeśli wybrano powyżej Container code = Off — to pole nie ma znaczenia (wtyczka niczego nie wstawia). Jeśli natomiast wybrano On, a strona zbudowana jest na Elementorze — oficjalna dokumentacja wtyczki wprost zaleca ustawienie „Off (no tweak, right placement)”, ponieważ Elementor jest wspierany natywnie.

Krok 3. Zakładka Integration → WooCommerce

Tutaj włącza się właściwa logika śledzenia ecommerce.

Pola obowiązkowe

Track e-commerce → włącz. To główny przełącznik: bez niego WooCommerce w ogóle nie komunikuje się z dataLayer. Sama wtyczka podpowiada to w opisie, gdy widzi aktywne WooCommerce: „strongly recommended to enable this integration”.

Clear ecommerce object before new event → włącz. To oficjalna rekomendacja Google dla implementacji dataLayer w GA4: czyści poprzedni obiekt ecommerce przed każdym nowym zdarzeniem, aby dane z poprzedniego kroku lejka (np. produkty z view_item) nie „przeciekały” do kolejnego zdarzenia (add_to_cart).

Pola, które warto zostawić domyślne

• Products per impression (10) — dzieli duże listy produktów na kilka zdarzeń, aby nie tracić odsłon przy dużej liczbie produktów na stronie kategorii.
• Only track orders younger than 30 min (experimental) — zabezpieczenie przed ponownym śledzeniem transakcji, jeśli klient ponownie otworzy stronę „Dziękujemy za zamówienie”.
• Do not flag orders as being tracked → zostaw wyłączone. Sama wtyczka ostrzega: włączać tylko jeśli naprawdę potrzeba, w przeciwnym razie rośnie ryzyko zdublowania transakcji w analityce.
• Google Ads Business Vertical → Retail, jeśli prowadzisz zwykły sklep internetowy.

Pola opcjonalne (nie krytyczne dla podstawowego śledzenia przychodu)

• Cart content in data layer, Include full category path — przydatne do personalizacji strony lub szczegółowych raportów kategorii, ale niepotrzebne wyłącznie do śledzenia przychodu/transakcji. Wtyczka wprost ostrzega, że Include full category path może wpłynąć na wydajność przy dużym ruchu.
• Customer data in data layer / Order data in data layer — to nie dotyczy podstawowego śledzenia przychodu ecommerce. To przygotowanie danych do Enhanced Conversions w Google Ads (przekazanie zahaszowanego e-maila klienta w celu dokładniejszego dopasowania konwersji). Bardzo przydatne, jeśli prowadzisz reklamę dla strony, ale to osobne zadanie — patrz sekcja poniżej.
• Exclude tax from revenue / Exclude shipping from revenue — decyzja biznesowa: czy przychód w GA4 ma zawierać podatek/dostawę (czyli odpowiadać pełnej kwocie zamówienia), czy tylko „czysty” przychód za produkty. Nie ma jednej uniwersalnie poprawnej odpowiedzi — uzgodnij to z osobą, która uzgadnia wskaźniki finansowe.

Krok 4. Weryfikacja dataLayer na żywej stronie

Po zapisaniu ustawień sprawdź wynik bezpośrednio w kodzie strony (Ctrl+U), przechodząc przez wyobrażony lejek klienta:

Strona produktu — powinno pojawić się:

dataLayer.push({"ecommerce":{"currency":"USD","value":358,"items":[{"item_id":591,"item_name":"...","price":358,...}]},"event":"view_item"});

Koszyk z produktem (view_cart) i checkout z produktem (begin_checkout) — analogiczna struktura, ale z innym event i polem quantity w produktach.

Ważny niuans: jeśli sprawdzasz koszyk/checkout bez dodanego produktu — nie będzie żadnego zdarzenia i to normalne. GTM4WP celowo nie generuje view_cart/begin_checkout dla pustego koszyka, aby nie zaśmiecać analityki fałszywymi zerowymi transakcjami. Najpierw realnie dodaj produkt do koszyka, a dopiero potem sprawdzaj kod strony.

Zdarzenia purchase w ten sposób nie da się sprawdzić — uruchamia się dopiero po realnie złożonym zamówieniu (hook woocommerce_thankyou). Najprostszy sposób testu — złożyć jedno testowe zamówienie na minimalną kwotę lub z kuponem na 100% zniżki.

Krok 5. Konfiguracja tagów w Google Tag Manager

Dane w dataLayer to tylko połowa drogi. Google Analytics 4 niczego nie otrzyma, dopóki w samym Google Tag Manager nie ma tagów, które nasłuchują tych zdarzeń i wysyłają je do GA4.

Wariant A: ręcznie przez interfejs GTM

1. Tag GA4 Configuration — typ „Google Analytics: GA4 Configuration”, podaj swój Measurement ID (G-XXXXXXXXXX). Jeśli na stronie jest już bezpośredni gtag.js dla podstawowych odsłon (poza GTM) — koniecznie wyłącz opcję „Send a page view event when this configuration loads”, inaczej otrzymasz zdublowany page_view. Wyzwalacz — All Pages.
2. Dla każdego zdarzenia (view_item, add_to_cart, view_cart, begin_checkout, purchase) utwórz: – wyzwalacz Custom Event z nazwą zdarzenia dokładnie zgodną z tym, co wysyła GTM4WP; – tag GA4 Event odwołujący się do tagu GA4 Configuration, z włączoną opcją „Send Ecommerce Data” — wtedy GTM automatycznie odczyta cały obiekt dataLayer.ecommerce, ręczne mapowanie items/value/currency nie jest potrzebne.

Wariant B: import gotowego pliku (szybciej)

Zamiast ręcznie klikać wszystkie 6 tagów i 5 wyzwalaczy, można przygotować plik JSON eksportu kontenera ze wszystkimi potrzebnymi elementami i zaimportować go jednym kliknięciem:

Admin → Import Container → wybierz plik → wybierz obszar roboczy → opcja „Merge” (NIE „Overwrite”).

⚠️ Ważne, by wybrać właśnie „Merge”, a nie „Overwrite” — Overwrite całkowicie zastępuje zawartość wybranego obszaru roboczego wyłącznie tym, co jest w pliku, kasując wszystko inne, co mogło być tam już skonfigurowane.

Po imporcie koniecznie sprawdź wynik w trybie Preview GTM przed publikacją, a nie publikuj „na ślepo”: przejdź przez stronę (produkt → koszyk → checkout) i w panelu debugowania sprawdź, czy każdy tag rzeczywiście uruchamia się przy swoim zdarzeniu.

Krok 6. Publikacja i weryfikacja końcowa

Po testach w Preview — Submit → Publish w Google Tag Manager. W sekcji Versions widać pełną listę tego, co trafiło do nowej wersji:

Ostateczna weryfikacja to upewnienie się, że opublikowane zmiany są rzeczywiście serwowane na stronie właśnie teraz. Najszybszy sposób — pobrać publiczny skrypt kontenera bezpośrednio:

curl -s "https://www.googletagmanager.com/gtm.js?id=GTM-XXXXXXX" | grep -oE "gaawc|gaawe|view_item|add_to_cart|purchase" | sort | uniq -c

Jeśli w odpowiedzi widzisz gaawc (GA4 Configuration) i gaawe (GA4 Event) obok nazw Twoich zdarzeń — tagi są rzeczywiście aktywne i serwowane odwiedzającym stronę, a nie tylko zapisane w wersji roboczej.

Ostatni krok, który może zweryfikować wyłącznie właściciel konta GA4, to otwarcie GA4 → Raporty czasu rzeczywistego lub DebugView, przejście przez stronę jako zwykły odwiedzający i upewnienie się, że zdarzenia view_item/add_to_cart/purchase rzeczywiście docierają z polami value, currency, items.

W naszym przypadku dokładnie tak się stało — kilka minut po publikacji w standardowym raporcie GA4 „Liczba zdarzeń wg nazwy zdarzenia” pojawiły się nowe zdarzenia z oczekiwanymi parametrami:

To ostateczny dowód: dane przeszły cały łańcuch od WooCommerce do raportów GA4.

Bonus: jeśli prowadzisz reklamę Google Ads dla strony

Podstawowe śledzenie ecommerce rozwiązuje problem „widzenia przychodu w raportach GA4”. Ale jeśli agencja lub właściciel sklepu dodatkowo prowadzi reklamę w Google Ads, warto osobno skonfigurować Enhanced Conversions — to znacząco podnosi dokładność atrybucji konwersji, co jest szczególnie ważne w warunkach ograniczeń dotyczących third-party cookies.

Krótko, co jest do tego potrzebne (osobny etap, nie mieszać z podstawową konfiguracją): 1. Włączyć opcję „Order data in data layer” w GTM4WP — dodaje ona do dataLayer na stronie podziękowania obiekt orderData, który zawiera już zahaszowany e-mail klienta. 2. Włączyć Enhanced Conversions w samym koncie Google Ads klienta. 3. Dodać w GTM tag Google Ads Conversion Tracking w trybie Enhanced Conversions, powiązany z polami orderData. 4. Upewnić się, że ten tag uruchamia się wyłącznie przy zgodzie na ad_storage/ad_user_data (Consent Mode) — ponieważ przekazywane są dane osobowe, nawet w postaci zahaszowanej.

Typowe błędy — krótka checklista

• ❌ Mylenie klas CSS przycisków (add_to_cart_button) z prawdziwymi zdarzeniami dataLayer.push.
• ❌ Pozostawienie ręcznego kodu GTM włączonego jednocześnie z automatycznym wstawianiem przez wtyczkę → zdublowanie danych.
• ❌ Sprawdzanie koszyka/checkoutu bez realnie dodanego produktu i wyciąganie wniosku „nie działa”.
• ❌ Wybór „Overwrite” zamiast „Merge” przy imporcie kontenera do GTM.
• ❌ Publikowanie zmian w GTM od razu, bez sprawdzenia w trybie Preview.
• ❌ Mylenie podstawowego śledzenia ecommerce z Enhanced Conversions — to różne zadania o różnych celach.

Podsumowanie

Pełny łańcuch „WooCommerce → dataLayer → GTM → GA4” składa się z trzech niezależnych warstw i każdą trzeba sprawdzać osobno: czy WordPress generuje poprawne dane, czy GTM poprawnie je przechwytuje i wysyła oraz czy GA4 rzeczywiście je otrzymuje. Pominięcie któregokolwiek z trzech kroków — i w raportach zamiast przychodu będzie cisza, przy czym będzie się wydawać, że „wszystko niby jest skonfigurowane”.