Zdarzenia e-commerce w GA4: jak poprawnie wdrożyć śledzenie sklepu internetowego (14 zdarzeń z przykładami)

Audytując wdrożenia analityki w sklepach naszych klientów, regularnie trafiamy na ten sam zestaw problemów: przychód w GA4 niezgodny z panelem sklepu, dziurawy lejek zakupowy i remarketing dynamiczny, który nie ma prawa działać, bo identyfikatory produktów nie zgadzają się z feedem. Ten przewodnik przeprowadza przez poprawne wdrożenie wszystkich 14 rekomendowanych zdarzeń e-commerce GA4 — od zasad decydujących o jakości danych, przez przykłady kodu, po checklistę odbioru wdrożenia od zespołu deweloperskiego.

Po co sklepowi komplet zdarzeń e-commerce?

Zdarzenia e-commerce to ustandaryzowany przez Google „język”, którym sklep opisuje zachowania kupujących: od wyświetlenia listy produktów, przez koszyk i checkout, po zakup i zwrot. Dopiero komplet tych zdarzeń — z poprawnymi parametrami — daje cztery rzeczy, na których realnie zarabia się w e-commerce:

• Raporty monetyzacji z prawdziwym przychodem — wartości zgodne z panelem sklepu, rozbite na produkty, listy i promocje.
• Pełny lejek zakupowy — widzisz, na którym kroku (koszyk, dostawa, płatność) tracisz użytkowników, zamiast zgadywać.
• Paliwo dla Google Ads — Smart Bidding i Performance Max optymalizują na podstawie danych konwersji. Jeśli dane są zdublowane lub niekompletne, algorytm uczy się na błędach — i za to płacisz.
• Remarketing dynamiczny — działa tylko wtedy, gdy item_id w zdarzeniach jest identyczne z ID produktów w feedzie Merchant Center.

Google definiuje dokładnie 14 rekomendowanych zdarzeń e-commerce. Nazwy zdarzeń i parametrów trzeba stosować co do znaku — są case-sensitive, a zdarzenie o innej nazwie GA4 potraktuje jako niestandardowe i nie zasili nim raportów e-commerce.

Jak to działa technicznie: dataLayer + Google Tag Manager

Rekomendowany model wdrożenia to warstwa danych i GTM. Sklep publikuje zdarzenia do dataLayer, a GTM nasłuchuje ich i przekazuje do GA4. Dzięki temu kod sklepu jest oddzielony od konfiguracji pomiaru — zmiany w tagowaniu nie wymagają wdrożeń programistycznych.

Każde zdarzenie ma tę samą konstrukcję: najpierw reset obiektu, potem push z nazwą zdarzenia i danymi:

dataLayer.push({ ecommerce: null }); // reset — zawsze przed pushem
dataLayer.push({
  event: "add_to_cart",
  ecommerce: {
    currency: "PLN",
    value: 129.99,
    items: [
      { item_id: "SKU_12345", item_name: "Koszulka bawełniana", price: 129.99, quantity: 1 }
    ]
  }
});

Warunek techniczny: window.dataLayer = window.dataLayer || []; musi być zainicjalizowany przed snippetem GTM. Sklepy działające jako SPA/PWA muszą dodatkowo wysyłać zdarzenia przy nawigacji bez przeładowania strony. Alternatywą dla GTM jest gtag.js — nazwy zdarzeń i parametrów są identyczne.

14 zdarzeń e-commerce — ściąga

Siedem zasad, które decydują o jakości danych

Z naszych audytów wynika prosta prawidłowość: o tym, czy dane nadają się do użytku, nie decyduje egzotyka, tylko dyscyplina w kilku podstawach.

1. Reset przed każdym pushem. dataLayer.push({ ecommerce: null }); — bez tego GTM scala dane z poprzednich zdarzeń i do GA4 „doklejają się” produkty z wcześniejszych pushy.
2. Liczby, nie stringi. value, price, quantity, tax, shipping to liczby z kropką dziesiętną (249.99). Przecinek dziesiętny — klasyk polskich wdrożeń — potrafi wyzerować lub zafałszować przychód w raportach.
3. value = suma pozycji. Wartość zdarzenia to suma price × quantity wszystkich elementów items, po rabatach, bez kosztów dostawy.
4. item_id zgodne z feedem Merchant Center. Identyczne co do znaku. To pojedynczy najczęstszy powód, dla którego remarketing dynamiczny „nie działa, choć wszystko jest podpięte”.
5. Spójność na całej ścieżce. Ten sam produkt ma to samo item_id i item_name w każdym zdarzeniu — od view_item_list po purchase. Inaczej raporty pozycji się rozjeżdżają.
6. purchase dokładnie raz na zamówienie. Unikalny transaction_id (numer zamówienia) plus zabezpieczenie przed ponowną wysyłką po odświeżeniu strony podziękowania. Zdublowany purchase zawyża nie tylko raporty — trafia też do Google Ads i psuje optymalizację stawek.
7. Consent Mode v2. W EOG pomiar musi respektować zgody użytkownika. Pushe do dataLayer wykonujemy zawsze — o faktycznej wysyłce danych decyduje stan zgód (analytics_storage, a dla remarketingu dodatkowo ad_storage, ad_user_data, ad_personalization) skonfigurowany w GTM. Szczegóły wdrożenia opisaliśmy w przewodniku Consent Mode v2 krok po kroku.

Przykłady wdrożenia: trzy zdarzenia, które muszą być bezbłędne

Poniżej trzy zdarzenia o największym wpływie na raporty i kampanie. Pozostałe budujemy analogicznie — zmienia się nazwa zdarzenia i zestaw parametrów (patrz ściąga wyżej).

view_item — wyświetlenie karty produktu

dataLayer.push({ ecommerce: null });
dataLayer.push({
  event: "view_item",
  ecommerce: {
    currency: "PLN",
    value: 129.99,
    items: [
      { item_id: "SKU_12345", item_name: "Koszulka bawełniana", item_brand: "MarkaX",
        item_category: "Odzież", item_category2: "Koszulki", item_variant: "granatowy / L",
        price: 129.99, quantity: 1 }
    ]
  }
});

add_to_cart — dodanie do koszyka

Wysyłane przy każdym dodaniu: z karty produktu, quick-add z listingu, a także przy zwiększeniu ilości w koszyku (wtedy quantity = przyrost). value to wartość dodawanych sztuk, nie całego koszyka.

dataLayer.push({ ecommerce: null });
dataLayer.push({
  event: "add_to_cart",
  ecommerce: {
    currency: "PLN",
    value: 129.99,
    items: [
      { item_id: "SKU_12345", item_name: "Koszulka bawełniana",
        item_variant: "granatowy / L", price: 129.99, quantity: 1 }
    ]
  }
});

purchase — finalizacja zakupu (z deduplikacją)

Wysyłane raz, na stronie podziękowania, z transaction_id równym numerowi zamówienia. Przy konwencji kwot brutto value zawiera VAT, tax przekazujemy informacyjnie jako kwotę VAT zawartą w value, a shipping osobno — koszt dostawy nie wchodzi do value.

dataLayer.push({ ecommerce: null });
dataLayer.push({
  event: "purchase",
  ecommerce: {
    transaction_id: "ZAM-2026-08-001234",
    currency: "PLN",
    value: 289.98,
    tax: 54.23,
    shipping: 14.99,
    items: [
      { item_id: "SKU_12345", item_name: "Koszulka bawełniana", price: 129.99, quantity: 1 },
      { item_id: "SKU_12346", item_name: "Koszulka polo", price: 159.99, quantity: 1 }
    ]
  }
});

Deduplikacja jest obowiązkowa: przed pushem sprawdzamy, czy zdarzenie dla danego transaction_id nie zostało już wysłane (np. flaga w sessionStorage), albo backend renderuje warstwę danych wyłącznie przy pierwszym wyświetleniu strony podziękowania.

Kompletną specyfikację wszystkich 14 zdarzeń — z parametrami wymaganymi i przykładami dla każdego — przygotowujemy dla zespołów deweloperskich naszych klientów jako wytyczne wdrożeniowe w ramach audytu analityki.

Kolejność zdarzeń w lejku zakupowym

Poprawna sekwencja to podstawa raportów ścieżek i eksploracji lejka w GA4:

view_item_list → select_item → view_item → add_to_cart → view_cart
    → begin_checkout → add_shipping_info → add_payment_info → purchase → (refund)

Równolegle do głównego lejka działają: view_promotion → select_promotion, add_to_wishlist oraz remove_from_cart. Warto pilnować, by item_list_id i item_list_name z listy, na której użytkownik zobaczył produkt, wędrowały z pozycją przez kolejne zdarzenia — to na tym opierają się raporty skuteczności list i rekomendacji.

Najczęstsze błędy, które znajdujemy w audytach

• Brak resetu ecommerce: null — do zdarzeń doklejają się produkty z poprzednich pushy; raporty pozycji przestają się spinać z rzeczywistością.
• Zdublowany purchase po odświeżeniu strony podziękowania — zawyżony przychód w GA4 i zawyżone konwersje w Google Ads, czyli błędne decyzje Smart Biddingu.
• Kwoty jako tekst lub z przecinkiem dziesiętnym — przychód znika z raportów albo przyjmuje absurdalne wartości.
• item_id niezgodne z feedem Merchant Center — remarketing dynamiczny nie dopasowuje produktów.
• Mieszanie kwot netto i brutto między zdarzeniami — ROAS liczony na niespójnych danych.
• Brak zdarzeń przy nawigacji w SPA — użytkownik przechodzi między podstronami, a lejek ma dziury.
• view_promotion wysyłane przy załadowaniu strony zamiast przy realnej widoczności kreacji (Intersection Observer) — CTR promocji sztucznie zaniżony.
• purchase wysyłany w różnych momentach dla różnych metod płatności (np. inaczej dla BLIK-a, inaczej dla pobrania) — dane nieporównywalne między okresami.

Jak odebrać wdrożenie od developera — checklista QA

1. W trybie podglądu GTM (Tag Assistant) każde zdarzenie wysyła się dokładnie raz, z kompletnym payloadem i we właściwej kolejności.
2. W DebugView GA4 widać parametry zdarzeń i pełne tablice items, a wartości liczbowe mają poprawne typy.
3. Odświeżenie strony podziękowania i powrót przyciskiem „wstecz” nie wysyłają drugiego purchase.
4. transaction_id w GA4 odpowiada 1:1 numerom zamówień w panelu sklepu, a item_id — identyfikatorom w feedzie Merchant Center.
5. Pełna ścieżka testowa (listing → karta → koszyk → dostawa → płatność → zakup) generuje wszystkie zdarzenia, także przy zamówieniu za pobraniem.
6. Po 24–48 godzinach raport Monetyzacja → Zakupy e-commerce jest zasilony, a rozbieżność liczby transakcji względem panelu sklepu nie przekracza ok. 5%.

FAQ — najczęstsze pytania o zdarzenia e-commerce w GA4

Źródła

• Google Analytics — specyfikacja zdarzeń rekomendowanych
• Google Analytics — przewodnik pomiaru e-commerce (GTM/gtag.js)
• Centrum pomocy GA4 — zdarzenia rekomendowane