GA4 nie zgaduje, że sklep sprzedaje — trzeba mu to powiedzieć zdarzeniami o ściśle określonych nazwach i parametrach. Jeśli wdrożenie odbiega od schematu, raporty monetyzacji pokazują zera lub bzdury, a kampanie optymalizują się na złych danych. Poniżej minimalny, poprawny szkielet e-commerce — plus błędy, które psują go najczęściej.
Szkielet zdarzeń: lejek w sześciu krokach
| Zdarzenie | Kiedy | Bez niego tracisz |
|---|---|---|
| view_item | wejście na kartę produktu | analizę zainteresowania produktami |
| add_to_cart | dodanie do koszyka | pierwszy próg lejka i listy remarketingowe |
| begin_checkout | start finalizacji | diagnozę porzuceń koszyka |
| add_shipping_info / add_payment_info | kroki checkoutu | widok, który krok checkoutu odsiewa |
| purchase | potwierdzenie zamówienia | wszystko: przychód, ROAS, wartości konwersji |
| refund | zwrot | urealnienie przychodu |
Nazwy muszą być dokładnie takie (rekomendowany schemat Google, snake_case) — zdarzenie „zakup” czy „Purchase” nie zasili raportów monetyzacji.
Parametry: tu umiera większość wdrożeń
Każde zdarzenie handlowe niesie tablicę items (item_id, item_name, price, quantity), a purchase dodatkowo: transaction_id, value, currency. Trzy żelazne zasady: transaction_id unikalny (bez niego odświeżenie strony podziękowania dubluje przychód), value spójne z sumą pozycji i w jednej konwencji (z podatkiem lub bez — byle zawsze tak samo), item_id zgodny między zdarzeniami (ten sam produkt = ten sam identyfikator w view_item i purchase, inaczej lejki produktowe się rozjeżdżają).
Skąd GA4 bierze te dane — warstwa danych
Sklep (platforma lub wtyczka) wypycha zdarzenia do warstwy danych, a GTM przekazuje je do GA4. Praktyczne konsekwencje: jakość wdrożenia zależy od jakości wtyczki — po każdej aktualizacji platformy warto przetestować lejek na nowo; a dwie wtyczki e-commerce naraz to niemal gwarantowane duble (purchase ×2 = przychód ×2 w raportach i przekłamane ROAS). Zdarzenia lejka są też fundamentem list remarketingowych z wpisu o remarketingu i wartości koszyka dla strategii tROAS.
Test poprawności w kwadrans
- DebugView: przejdź pełną ścieżkę testową (produkt → koszyk → checkout → zakup testowy) i sprawdź, czy każde zdarzenie odpala raz i niesie items z cenami — ogólna metodyka jak w checkliście weryfikacji GA4.
- Zgodność z kasą: raport Monetyzacja → Zakupy e-commerce za wczoraj vs panel sklepu. Rozjazd do kilkunastu procent to normalność pomiaru webowego; 30%+ to usterka do znalezienia.
- Duplikaty: w eksploracji policz transaction_id — powtórzenia oznaczają brak deduplikacji na stronie podziękowania.
Kolejność napraw, gdy jest źle
Najpierw purchase (na nim stoi każda decyzja budżetowa), potem add_to_cart i begin_checkout (lejek i remarketing), na końcu detale items. Sklep z poprawnym purchase i dziurawym view_item da się prowadzić; odwrotnie — nie. Kompletny schemat e-commerce w GA4 przez GTM stawiam w ramach wdrożenia analityki; a jeśli sklep „ma GA4 od zawsze” i nikt nigdy nie robił testu z kwadransa powyżej — to pierwsze, co robię w audycie, bo od tego zależy wiarygodność wszystkich pozostałych liczb.
