Google Analytics 4 dla sklepu WooCommerce — zdarzenia e-commerce

W WooCommerce widzisz 100 zamówień, ale Google Analytics 4 pokazuje 74. Google Ads raportuje jeszcze inną wartość sprzedaży, a ścieżka zakupowa w GA4 kończy się na dodaniu produktu do koszyka.

Taki wynik nie musi oznaczać, że GA4 „nie działa". Często problem polega na tym, że sklep mierzy odsłony, ale nie przekazuje prawidłowo zdarzeń e-commerce, wartości zamówienia, waluty albo informacji o kupionych produktach.

Samo wklejenie identyfikatora zaczynającego się od G- nie wystarczy. GA4 musi otrzymać informację o kolejnych etapach: wyświetleniu produktu, dodaniu do koszyka, rozpoczęciu checkoutu, wyborze dostawy, płatności, zakupie i ewentualnym zwrocie.

W tym poradniku pokazujemy, jakie zdarzenia e-commerce wdrożyć w WooCommerce, jakie dane powinien zawierać purchase, jak przetestować pomiar i dlaczego wynik GA4 nie zawsze będzie identyczny z panelem sklepu.

Odpowiedź wprost

Rozbieżność typu „WooCommerce pokazuje 100 zamówień, a GA4 74” zwykle nie oznacza, że Analytics nie działa — to znak, że sklep nie przekazuje poprawnie zdarzeń e-commerce, wartości zamówienia, waluty lub danych produktów. Poprawny pomiar wymaga skonfigurowania zdarzeń (view_item, add_to_cart, begin_checkout, purchase) z pełnymi parametrami, najlepiej przez warstwę danych i Google Tag Manager. Dopiero spójny pomiar pozwala ufać raportom i optymalizować kampanie.

W skrócie (TL;DR)

• Sam kod GA4 mierzy podstawowy ruch, ale nie gwarantuje poprawnego pomiaru produktów, koszyka i zakupów.
• Podstawowy lejek sklepu tworzą zdarzenia view_item, add_to_cart, begin_checkout i purchase.
• Dokładniejsza analiza checkoutu wymaga również add_shipping_info oraz add_payment_info.
• Zdarzenie purchase powinno zawierać unikalny transaction_id, walutę, wartość oraz tablicę items.
• Jedno zamówienie nie może zostać wysłane kilka razy po odświeżeniu strony z podziękowaniem.
• Identyfikatory produktów muszą być spójne na karcie produktu, w koszyku, zakupie, Merchant Center i systemach reklamowych.
• WooCommerce pozostaje źródłem informacji o faktycznych zamówieniach. GA4 służy przede wszystkim do analizy zachowania klientów i źródeł ruchu.
• Zdarzenia trzeba sprawdzić przez pełne zamówienie testowe, a nie tylko przez obecność kodu GA4.
• Zwroty wymagają osobnej obsługi zdarzenia refund, jeśli mają korygować dane e-commerce.

Co mierzy Google Analytics 4 w sklepie WooCommerce?

GA4 zapisuje działania użytkowników jako zdarzenia i łączy je z informacjami o produktach, źródłach ruchu oraz sesjach.

W sklepie zdarzeniem może być wyświetlenie listy produktów, kliknięcie produktu w kategorii, otwarcie karty produktu, dodanie produktu do koszyka, usunięcie produktu z koszyka, rozpoczęcie checkoutu, wybór dostawy, wybór płatności, zakup albo zwrot. Dzięki temu możesz sprawdzić nie tylko liczbę odwiedzin, ale również które produkty są oglądane, co najczęściej trafia do koszyka, na którym etapie klienci rezygnują, jakie źródła ruchu generują zakupy, które kategorie sprzedają i jak zachowują się użytkownicy telefonów oraz komputerów.

GA4 nie zastępuje WooCommerce. WooCommerce zapisuje rzeczywiste zamówienia, ich statusy, płatności, zwroty i dane operacyjne. GA4 może nie zarejestrować części sprzedaży, ponieważ użytkownik nie wyraził zgody na analitykę, przeglądarka zablokowała skrypt, klient zamknął stronę przed wysłaniem zdarzenia, wystąpił błąd JavaScript, integracja nie obsłużyła konkretnej metody płatności albo klient nie wrócił z zewnętrznej bramki płatniczej. Może również zawyżać sprzedaż, jeśli to samo zamówienie zostanie wysłane kilka razy.

Jak wygląda lejek e-commerce w GA4?

Lejek powinien odzwierciedlać kolejne kroki klienta — od zobaczenia produktu do zakupu.

Etap	Zdarzenie GA4	Kiedy powinno się uruchomić?
Wyświetlenie listy	view_item_list	Po pokazaniu produktów w kategorii, wyszukiwarce lub sekcji polecanej
Kliknięcie produktu	select_item	Po wyborze produktu z konkretnej listy
Karta produktu	view_item	Po otwarciu szczegółów produktu
Dodanie do koszyka	add_to_cart	Po skutecznym dodaniu produktu
Usunięcie z koszyka	remove_from_cart	Po usunięciu produktu lub zmniejszeniu ilości
Wyświetlenie koszyka	view_cart	Po otwarciu strony albo panelu koszyka
Rozpoczęcie checkoutu	begin_checkout	Po przejściu do składania zamówienia
Wybór dostawy	add_shipping_info	Po zatwierdzeniu danych lub metody dostawy
Wybór płatności	add_payment_info	Po zatwierdzeniu metody płatności
Zakup	purchase	Po utworzeniu zakupu zgodnie z przyjętą logiką
Zwrot	refund	Po pełnym albo częściowym zwrocie

Podstawowe minimum do analizy lejka to view_item, add_to_cart, begin_checkout i purchase. Jeżeli chcesz wiedzieć, czy klienci rezygnują przez koszt dostawy albo metodę płatności, potrzebujesz także add_shipping_info oraz add_payment_info. Pusty etap w raporcie nie zawsze oznacza, że klienci niczego tam nie robią — może oznaczać, że odpowiednie zdarzenie nie zostało wdrożone.

Najważniejsze zdarzenia GA4 dla WooCommerce

view_item_list — wyświetlenie listy produktów. Zdarzenie informuje, które produkty zostały pokazane w danej sekcji. Listą może być kategoria, wynik wyszukiwania, lista bestsellerów, sekcja produktów podobnych, cross-sell w koszyku albo lista promocji. Przydatne dane to item_list_id, item_list_name, items oraz pozycja produktu zapisana jako index. Dzięki temu możesz sprawdzić, czy produkt częściej sprzedaje się po wyświetleniu w kategorii, wyszukiwarce czy sekcji polecanej.

select_item — kliknięcie produktu. Zdarzenie powinno uruchomić się po wybraniu produktu z listy. Pozwala analizować skuteczność kategorii, kliknięcia w rekomendacje, wyniki wewnętrznej wyszukiwarki i pozycję produktu na liście. select_item powinno przekazywać tę samą nazwę listy, która pojawiła się wcześniej w view_item_list.

view_item — wyświetlenie karty produktu. To jedno z najważniejszych zdarzeń górnej części lejka. Powinno zawierać między innymi item_id, item_name, cenę, walutę, kategorię, markę i wariant, jeśli jest istotny. W przypadku produktów wariantowych trzeba ustalić, czy zdarzenie raportuje produkt nadrzędny, konkretny wariant, wariant domyślny czy aktualnie wybrany kolor lub rozmiar. Najważniejsza jest konsekwencja — jeżeli view_item używa ID produktu głównego, a purchase SKU wariantu, GA4 może uznać je za dwa różne produkty.

add_to_cart — dodanie produktu do koszyka. Zdarzenie powinno wysyłać się dopiero po skutecznym dodaniu produktu. W WooCommerce dodanie może odbywać się na karcie produktu, bezpośrednio z kategorii, przez AJAX bez przeładowania, przez szybki zakup albo z sekcji produktów powiązanych — każdy mechanizm trzeba sprawdzić osobno. Typowy błąd: klient klika „Dodaj do koszyka", ale nie wybrał rozmiaru; WooCommerce pokazuje komunikat o błędzie, a GA4 mimo to zapisuje add_to_cart. W raporcie pojawia się wtedy dodanie, które faktycznie nie nastąpiło.

begin_checkout — rozpoczęcie checkoutu. Zdarzenie powinno uruchomić się po realnym przejściu do składania zamówienia — nie należy wysyłać go przy każdym otwarciu koszyka. Wartość i produkty powinny odpowiadać aktualnemu koszykowi, z uwzględnieniem ilości, wariantów, cen, kuponów i rabatów. Jeżeli wiele osób dodaje produkt do koszyka, ale nie rozpoczyna checkoutu, problem może dotyczyć kosztu dostawy, zaufania, niejasnej ceny, kodu rabatowego albo niedziałającego koszyka. Proces odzyskiwania takich użytkowników opisujemy w poradniku porzucone koszyki — jak odzyskać klienta.

add_shipping_info — wybór dostawy. Zdarzenie powinno zostać wysłane po zatwierdzeniu metody dostawy albo informacji wysyłkowych. Parametr shipping_tier może zawierać np. InPost Paczkomat, kurier DPD, odbiór osobisty, dostawę paletową albo przesyłkę ekspresową. Duży spadek przed tym zdarzeniem może wskazywać na problem z formularzem adresowym; spadek po pokazaniu metod dostawy może oznaczać zbyt wysoką cenę, brak oczekiwanej opcji, długi czas dostawy albo błąd wyboru punktu odbioru.

add_payment_info — wybór płatności. Zdarzenie informuje, że klient wybrał albo zatwierdził metodę płatności. Parametr payment_type może zawierać np. BLIK, kartę, szybki przelew, płatność przy odbiorze, przelew tradycyjny albo raty. Nie przekazuj do GA4 numerów kart, rachunków ani innych poufnych danych finansowych — wystarczy nazwa metody.

purchase — zakup. To najważniejsze zdarzenie sprzedażowe. Jego błędna konfiguracja zniekształca przychód, ROAS i ocenę kampanii. Powinno zawierać transaction_id, currency, value, items oraz opcjonalnie shipping, tax i coupon. Przykład uproszczonej struktury:

gtag("event", "purchase", {
  transaction_id: "WC-15482",
  value: 1249.00,
  currency: "PLN",
  shipping: 19.99,
  coupon: "WIOSNA10",
  items: [
    {
      item_id: "BIURKO-VARIUS-120-DAB",
      item_name: "Biurko Varius 120 × 65 cm",
      item_category: "Biurka elektryczne",
      item_variant: "dąb naturalny / czarny stelaż",
      price: 1249.00,
      quantity: 1
    }
  ]
});

transaction_id powinien być unikalnym i stabilnym identyfikatorem zamówienia. Nie używaj daty zakupu, stałego tekstu order, identyfikatora sesji ani losowej liczby generowanej po każdym odświeżeniu.

refund — zwrot. Zdarzenie pozwala przekazać pełny albo częściowy zwrot. Powinno korzystać z tego samego transaction_id, który został wysłany przy zakupie. Przy zwrocie częściowym można również przekazać item_id, zwracaną ilość, wartość zwrotu i walutę. Jeżeli sklep nie raportuje zwrotów, GA4 może pokazywać sprzedaż, która ostatecznie nie została utrzymana — ma to duże znaczenie w branżach z wysokim odsetkiem zwrotów, np. w odzieży, obuwiu albo wyposażeniu zamawianym w wielu wariantach.

Co powinno znajdować się w tablicy items?

Tablica items opisuje produkty uczestniczące w danym zdarzeniu.

Parametr	Znaczenie	Przykład
item_id	Stabilny identyfikator	KOMODA-DIANA-150-BIALA
item_name	Nazwa produktu	Komoda Diana 150 cm
item_brand	Marka	Diana Home
item_category	Główna kategoria	Komody
item_category2	Kolejny poziom kategorii	Komody do salonu
item_variant	Wariant	biały połysk
price	Cena jednostkowa	899.00
quantity	Liczba sztuk	1
discount	Rabat pozycji	50.00
coupon	Kod kuponu	WIOSNA10
item_list_name	Nazwa listy	Komody do salonu
index	Pozycja na liście	3

Nie musisz wysyłać każdego dostępnego parametru. Wybierz dane, które są prawdziwe, kompletne, stabilne i przydatne w raportach. Lepiej przesłać osiem poprawnych parametrów niż kilkanaście pól wypełnionych przypadkowymi wartościami.

SKU czy ID WooCommerce jako item_id?

Najważniejsza jest spójność identyfikatora w całej ścieżce zakupowej.

ID WooCommerce ma zalety: istnieje dla każdego produktu, jest unikalne w danej instalacji i łatwo dostępne technicznie. Ograniczenia: może zmienić się po migracji albo ponownym imporcie i nie zawsze odpowiada identyfikatorowi w ERP-ie, feedzie oraz reklamach.

SKU ma zalety: może łączyć sklep z magazynem, ERP-em i Merchant Center, jest czytelniejsze biznesowo i może pozostać stabilne po migracji. Ograniczenia: nie każdy produkt ma SKU, import może tworzyć duplikaty, a warianty powinny mieć własne identyfikatory.

Co wybrać? Jeżeli sklep ma poprawne i unikalne SKU dla produktów oraz wariantów, często jest to praktyczny wybór. Jeżeli SKU są niepełne albo niespójne, lepiej wykorzystać stabilne ID niż przekazywać błędne dane. Nie mieszaj kilku systemów — view_item z ID produktu, add_to_cart z SKU wariantu, purchase z EAN i refund z innym ID z ERP-u utworzą w raportach pozornie różne produkty.

Jak liczyć wartość zdarzenia purchase?

Wartość powinna wynikać z jednej, zapisanej definicji przychodu.

Przykład zamówienia: dwa produkty po 100 zł, jeden produkt za 50 zł, rabat 20 zł, dostawa 15 zł. Trzeba ustalić, czy ceny pozycji są przed rabatem czy po rabacie, czy value zawiera dostawę, czy dostawa trafia osobno do shipping, czy raportujesz wartości brutto czy netto, jak traktujesz podatek i jak obsługujesz częściowe zwroty. Najważniejsza jest konsekwencja — jeżeli WooCommerce pokazuje brutto z dostawą, GA4 raportuje netto bez dostawy, a Google Ads otrzymuje jeszcze inną wartość, porównanie systemów będzie wprowadzać w błąd.

Jeżeli wysyłasz parametr value, przekaż również currency (np. PLN, EUR, GBP, USD). W sklepie wielowalutowym waluta powinna wynikać z konkretnego zamówienia, a nie być wpisana na stałe jako PLN.

Kiedy powinno uruchamiać się purchase?

Zdarzenie powinno zostać wysłane raz, w momencie zgodnym z przyjętym sposobem uznawania zakupu.

Po utworzeniu zamówienia. Zaleta: obejmuje również przelew tradycyjny i płatność przy odbiorze. Ryzyko: część zamówień może nigdy nie zostać opłacona, a raport obejmie transakcje później anulowane.

Po potwierdzeniu płatności. Zaleta: raportuje bardziej pewną sprzedaż internetową. Ryzyko: może pomijać przelewy i pobrania, zależy od integracji bramki płatniczej i wymaga obsługi zmian statusów zamówienia.

Po stronie serwera. Zaleta: nie zależy tylko od załadowania strony podziękowania. Ryzyko: wymaga bardziej zaawansowanej implementacji, trzeba obsłużyć zgody i duplikację, a to samo zamówienie może zostać wysłane z przeglądarki i serwera.

Nie istnieje jeden model odpowiedni dla każdego sklepu. Sposób pomiaru powinien odpowiadać metodom płatności i temu, jak firma rozumie „zrealizowany zakup".

Zdarzenie, kluczowe zdarzenie i konwersja — czym się różnią?

W GA4 wszystkie działania są zdarzeniami. Wybrane zdarzenia można oznaczyć jako ważne biznesowo, czyli kluczowe zdarzenia — w przypadku sklepu najważniejszym będzie zazwyczaj purchase. Zdarzenia takie jak view_item, add_to_cart i begin_checkout są potrzebne do analizy lejka, ale nie powinny automatycznie mieć takiej samej wartości jak sprzedaż.

W Google Ads nadal pracujesz z konwersjami głównymi i dodatkowymi. Jeżeli kampania będzie optymalizowana jednocześnie pod zakup, dodanie do koszyka i wyświetlenie produktu, algorytm może skupić się na działaniach łatwych do uzyskania, ale niewnoszących przychodu. Ma to szczególne znaczenie przy kampaniach produktowych i Performance Max. Sposób przygotowania kampanii opisujemy w artykule reklama produktowa Google — Shopping i Performance Max w praktyce.

Jak wdrożyć GA4 w WooCommerce?

Najczęściej wykorzystuje się wtyczkę, Google Tag Manager z warstwą danych albo wdrożenie dedykowane.

Wtyczka integracyjna może automatycznie przekazywać odsłony, wyświetlenia produktów, dodania do koszyka, rozpoczęcia checkoutu i zakupy. Zalety: szybkie uruchomienie, mniej kodowania, konfiguracja w panelu WordPressa. Ryzyka: ograniczony zestaw parametrów, problemy z niestandardowym checkoutem, niepełna obsługa wariantów, brak zwrotów i konflikty z innymi wtyczkami. Popularność wtyczki nie gwarantuje, że prawidłowo obsłuży konkretny sklep.

Google Tag Manager i dataLayer. dataLayer (warstwa danych) przekazuje uporządkowane informacje ze sklepu do Google Tag Managera. Może zawierać nazwę zdarzenia, ID produktów, wartość koszyka, walutę, listę pozycji, kupon i sposób dostawy. Przykładowy proces: WooCommerce dodaje produkt do koszyka → sklep umieszcza dane w dataLayer → GTM wykrywa zdarzenie → tag GA4 wysyła add_to_cart → te same dane mogą zostać wykorzystane w Google Ads. Zalety: większa kontrola, wspólne dane dla kilku systemów, łatwiejsze testowanie i możliwość rozbudowy. Ryzyka: błędne reguły mogą dublować zdarzenia, zmiana motywu lub checkoutu może przerwać pomiar, a warstwa danych wymaga utrzymania i dokumentacji.

Wdrożenie dedykowane lub serwerowe ma sens, gdy sklep ma niestandardowy checkout, headless frontend, wiele domen, własne integracje płatnicze, duży budżet reklamowy, potrzebę wysyłania zwrotów z backendu albo rozbudowaną integrację z ERP-em. Może łączyć zdarzenia przeglądarkowe, Google Tag Manager, server-side GTM, Measurement Protocol oraz dane WooCommerce albo ERP. Najważniejszym problemem jest deduplikacja — jedno zamówienie nie może zostać potraktowane jako dwie różne transakcje.

Wtyczka czy Google Tag Manager?

Obszar	Wtyczka	GTM i warstwa danych
Szybkość wdrożenia	Zwykle większa	Wymaga konfiguracji
Kontrola danych	Zależna od wtyczki	Większa
Obsługa niestandardowych funkcji	Ograniczona	Elastyczna
Testowanie	Zależne od rozwiązania	Podgląd GTM i DebugView
Integracja z reklamami	Czasem ograniczona	Dane mogą zasilać kilka systemów
Utrzymanie	Aktualizacje wtyczki	Utrzymanie GTM i dataLayer
Typowy sklep	Prosty, standardowy	Rozbudowany albo niestandardowy

Dla niewielkiego sklepu dobra wtyczka może wystarczyć. Przy kilku systemach reklamowych, własnym checkoutcie i dużym katalogu lepsza może być uporządkowana warstwa danych.

Zgody cookies i Consent Mode

Zgody użytkownika wpływają na zakres danych dostępnych w GA4.

Trzeba sprawdzić domyślny stan zgód, reakcję tagów na akceptację, reakcję na odmowę, możliwość zmiany decyzji oraz współpracę bannera z GTM albo Google tagiem. Typowe problemy: tag GA4 uruchamia się przed wyborem użytkownika, użytkownik akceptuje analitykę ale stan zgody nie zostaje zaktualizowany, banner blokuje wszystkie zdarzenia nawet po akceptacji albo różne wtyczki próbują jednocześnie sterować zgodami. Consent Mode nie zastępuje poprawnego bannera ani właściwej konfiguracji prawnej — jest technicznym mechanizmem przekazywania stanu zgody do tagów Google.

Jak analizować dane e-commerce w GA4?

Ścieżka zakupu. Raport pomaga sprawdzić przejście między wyświetleniem produktu, dodaniem do koszyka, rozpoczęciem checkoutu i zakupem. Jeżeli użytkownicy oglądają produkty, ale ich nie dodają, problem może dotyczyć oferty, ceny, wariantów, zdjęć, opisu albo niedopasowanego ruchu. Jeżeli sklep jest wolny, zwłaszcza na urządzeniach mobilnych, warto również przeanalizować Core Web Vitals w sklepie WooCommerce.

Ścieżka realizacji zakupu. Raport koncentruje się na końcowych etapach: begin_checkout, add_shipping_info, add_payment_info, purchase. Może ujawnić problem formularza adresowego, rezygnacje po pokazaniu kosztu wysyłki, brak oczekiwanej płatności albo awarię bramki.

Zakupy e-commerce. Raport produktów może pokazywać wyświetlenia, dodania do koszyka, zakupy, liczbę sztuk, przychód, marki, kategorie i warianty. Jakość raportu zależy od jakości tablicy items — jeżeli ten sam producent występuje jako „Samsung", „SAMSUNG", „samsung" albo puste pole, GA4 pokaże kilka osobnych wartości.

Pozyskiwanie ruchu. Raport pozwala porównać m.in. organiczne wejścia Google, Google Ads, newsletter, social media, porównywarki, strony odsyłające i ruch bezpośredni. Nie traktuj atrybucji jako bezbłędnej historii całej podróży klienta — użytkownik może zobaczyć reklamę, wejść później z Google, wrócić z wiadomości e-mail i kupić bezpośrednio, a różne systemy mogą przypisać zakup do innego punktu tej ścieżki.

Przykład analizy lejka

Załóżmy, że GA4 pokazuje:

Etap	Użytkownicy	Przejście dalej
Wyświetlenie produktu	10 000	—
Dodanie do koszyka	800	8%
Rozpoczęcie checkoutu	400	50%
Zakup	200	50%

Największy spadek występuje pomiędzy kartą produktu a koszykiem. Warto wtedy sprawdzić cenę, dostępność, warianty, opis, zdjęcia, koszt dostawy i dopasowanie źródła ruchu. Inny sklep może mieć taki wynik:

Etap	Użytkownicy	Przejście dalej
Wyświetlenie produktu	10 000	—
Dodanie do koszyka	1500	15%
Rozpoczęcie checkoutu	1100	73%
Zakup	220	20%

Tutaj problem znajduje się bliżej końca procesu. Możliwymi przyczynami są formularz, obowiązkowe konto, koszt wysyłki, brak BLIK-a, błąd płatności albo niedziałający wybór Paczkomatu. Szerszy model pracy nad wynikiem opisujemy w artykule jak zwiększyć sprzedaż w sklepie internetowym — 4 dźwignie.

Dlaczego GA4 i WooCommerce pokazują inne wyniki?

Niewielka różnica jest normalna. Duży albo niestabilny rozjazd trzeba przeanalizować.

GA4 może pokazywać mniej zakupów przez brak zgody, blokowanie skryptów, błędy JavaScript, brak powrotu z płatności, inną strefę czasową, nieobsługiwaną metodę płatności albo inny moment uznania zakupu. Może pokazywać więcej zakupów przez kilka kodów GA4, dwie wtyczki analityczne, równoległy pomiar w GTM, powtórne wysłanie po odświeżeniu strony albo inne transaction_id dla tej samej transakcji.

Porównując systemy, sprawdź ten sam zakres dat, tę samą strefę czasową, tę samą walutę, definicję wartości, statusy zamówień, sposób obsługi zwrotów i zamówienia testowe. Celem nie musi być identyczny wynik co do jednego zamówienia — ważne, aby różnica była stabilna, zrozumiała, monitorowana i uwzględniana przy podejmowaniu decyzji.

Najczęstsze błędy we wdrożeniu GA4

Najwięcej szkody robią: brak zdarzeń e-commerce, dublujące się integracje, podwójny purchase i niespójne identyfikatory.

• 1. Sam kod GA4 bez e-commerce — sklep mierzy odsłony, ale nie przekazuje produktów, koszyka ani zakupów.
• 2. Kilka integracji wysyłających te same dane — motyw, wtyczka i GTM raportują jedno zdarzenie równolegle.
• 3. Podwójny purchase — odświeżenie strony podziękowania albo drugi tag powoduje ponowne zapisanie zamówienia.
• 4. Brak spójnych identyfikatorów — karta produktu, koszyk i zakup wykorzystują różne ID dla tej samej pozycji.
• 5. Błędna wartość albo waluta — GA4 raportuje kwotę niezgodną z przyjętym sposobem liczenia przychodu.
• 6. Brak testów wariantów, dostaw i płatności — pomiar działa dla prostego produktu i jednej bramki, ale pomija inne ścieżki.
• 7. Wszystkie etapy lejka jako główne konwersje — kampanie optymalizują się pod dodania do koszyka zamiast pod rzeczywistą sprzedaż.

Co możesz sprawdzić samodzielnie?

Poniższa checklista zastępuje osobne, nakładające się listy testowe.

1. Sprawdź liczbę integracji. Ustal, czy GA4 jest wysyłane przez wtyczkę, GTM, motyw czy kilka narzędzi jednocześnie.
2. Uruchom DebugView lub podgląd GTM. Nie testuj wyłącznie w standardowych raportach.
3. Otwórz kategorię i produkt. Zweryfikuj view_item_list, select_item oraz view_item.
4. Przetestuj produkt prosty i wariantowy. Sprawdź ID, nazwę, wariant, cenę i walutę.
5. Dodaj produkt do koszyka. Upewnij się, że add_to_cart wysyła się raz i dopiero po skutecznym dodaniu.
6. Zmień ilość i usuń produkt. Sprawdź aktualne wartości koszyka.
7. Użyj kuponu. Zweryfikuj, czy rabat jest uwzględniony w produktach i wartości zamówienia.
8. Rozpocznij checkout. Sprawdź begin_checkout i zawartość tablicy items.
9. Wybierz dostawę i płatność. Zweryfikuj shipping_tier oraz payment_type.
10. Złóż zamówienie testowe. Porównaj transaction_id, wartość, walutę, produkty, ilości i dostawę z WooCommerce.
11. Odśwież stronę z podziękowaniem. purchase nie powinien zostać zapisany ponownie jako nowy zakup.
12. Powtórz test dla drugiej płatności. Przetestuj np. BLIK oraz przelew tradycyjny albo pobranie.
13. Sprawdź zgody. Wykonaj test po akceptacji i odmowie analityki.
14. Porównaj kilka dni danych. Zestaw WooCommerce, GA4 i Google Ads według tej samej daty, waluty i definicji wartości.
15. Sprawdź zwrot. Ustal, czy pełny albo częściowy zwrot wysyła zdarzenie refund.

Po zakończeniu zapisz listę wdrożonych zdarzeń, źródło danych, używany identyfikator produktu, definicję wartości, moment wysyłania purchase, sposób obsługi zwrotów oraz listę tagów i wtyczek. Taka dokumentacja ogranicza ryzyko, że kolejna aktualizacja albo zmiana wykonawcy ponownie zepsuje pomiar.

Kiedy warto zlecić to specjaliście?

Pomoc jest potrzebna, gdy dane GA4 i WooCommerce się rozjeżdżają, purchase zapisuje się kilka razy albo sklep ma niestandardowy checkout i wiele integracji.

Rozważ wsparcie, gdy GA4 pokazuje znacznie mniej lub więcej zakupów niż WooCommerce, purchase zapisuje się kilka razy, raporty produktów są puste, sklep korzysta z niestandardowego checkoutu, działa kilka bramek płatności, sklep obsługuje kilka walut, dane produktów pochodzą z ERP-u, potrzebny jest pomiar zwrotów, wdrożono server-side tracking, system zgód nie współpracuje z tagami, Google Ads optymalizuje się na błędnych konwersjach albo po aktualizacji WooCommerce zdarzenia przestały działać.

Dobre wdrożenie powinno obejmować plan pomiaru, listę zdarzeń, strukturę items, definicję wartości, konfigurację GA4 i GTM, zgody, testy, porównanie z WooCommerce oraz dokumentację. W ramach analityki i pomiaru konwersji można uporządkować GA4, GTM, zdarzenia WooCommerce, Consent Mode i połączenie z Google Ads.

---

Najpierw wiarygodny pomiar, potem decyzje

Google Analytics 4 dla WooCommerce powinien mierzyć całą drogę klienta: wyświetlenie listy, wybór produktu, kartę produktu, dodanie do koszyka, rozpoczęcie checkoutu, wybór dostawy, wybór płatności, zakup i ewentualny zwrot.

Najważniejszym elementem pozostaje purchase — musi zostać wysłany raz i zawierać poprawny identyfikator, wartość, walutę oraz produkty. Nie oceniaj wdrożenia na podstawie komunikatu „GA4 jest podłączone": złóż prawdziwe zamówienie testowe, sprawdź warianty, kupon, dostawę, płatność, odświeżenie strony i porównaj wynik z WooCommerce. Błędny pomiar wpływa nie tylko na raport — jeżeli Google Ads otrzymuje podwójne zakupy albo nieprawidłową wartość sprzedaży, algorytm może kierować budżet do niewłaściwych produktów i użytkowników.

Jeżeli chcesz sprawdzić, czy obecne dane są wiarygodne, możemy przeanalizować cały proces — od view_item do zakupu i zwrotu. W ramach wdrożenia analityki i pomiaru konwersji uporządkujemy zdarzenia, GTM, zgody, integrację z Google Ads i dokumentację wdrożenia.