7 powodów, dla których Twój purchase event nie strzela

Scenariusz, który widzimy co miesiąc: budżet reklamowy rośnie, ROAS spada, agencja od kampanii rozkłada ręce. Klient jest przekonany, że "reklamy przestały działać". A potem otwieramy GTM i okazuje się, że sklep od tygodni nie wysyła poprawnych danych o zakupach — kampanie uczą się na szumie. Oto siedem powodów, które znajdujemy najczęściej, w kolejności od najbardziej banalnych.

1. Consent mode blokuje wszystko — albo nic

Po wejściu Consent Mode v2 połowa polskich sklepów ma jedną z dwóch skrajności: baner zgód, który przy odmowie ubija tracking całkowicie (zamiast wysyłać pingi bez cookies), albo tagi odpalane przed zgodą, co jest prostym naruszeniem RODO. W obu wypadkach dane w GA4 są dziurawe, tylko z różnych powodów. Sprawdź w podglądzie GTM, co się dzieje przy odmowie zgody — to pierwszy test, jaki robimy na audycie.

2. Event strzela przed załadowaniem dataLayer

Klasyka WooCommerce i customowych checkoutów: tag purchase odpala się na page view strony podziękowania, zanim ecommerce.value i transaction_id trafią do dataLayer. Efekt: konwersja jest, wartości nie ma. Kampanie na tROAS dostają zakupy o wartości 0 zł i optymalizują się w stronę śmieciowego ruchu.

3. Strona podziękowania nie zawsze się ładuje

Płatności redirectowe (BLIK, PayU, Przelewy24) potrafią zgubić 10–30% użytkowników w drodze powrotnej do sklepu — zamknięta karta, timeout, powrót do aplikacji banku. Jeśli purchase mierzysz wyłącznie na thank you page, systematycznie zaniżasz konwersje. Rozwiązanie: webhook po stronie serwera albo przynajmniej weryfikacja rozjazdu zamówienia vs. GA4.

4. Duplikacje: jedna transakcja, trzy konwersje

Użytkownik odświeża stronę podziękowania albo wraca do niej z maila — i purchase strzela drugi raz. Do tego GTM4WP + ręcznie wklejony gtag + plugin od płatności, każdy wysyła swoje. Widzieliśmy sklep, w którym "konwersji" było 2,4x więcej niż zamówień. Deduplikacja po transaction_id to nie opcja, to obowiązek.

5. Meta Pixel dostaje inne dane niż GA4

Purchase w GA4 z wartością brutto, w Meta netto, w Google Ads bez waluty. Każda platforma "widzi" inny biznes i każda optymalizuje do czegoś innego. Jedno źródło prawdy w dataLayer, z niego wszystkie tagi — inaczej porównywanie wyników między kanałami nie ma sensu.

6. Blokery, przeglądarki i brak server-side

Safari z ITP, Brave, adblocki — realnie 15–30% ruchu nie wysyła client-side'owych eventów. Przy małej skali można z tym żyć; przy budżetach 50k+/msc server-side tagging (sGTM) to różnica między optymalizacją na 70% a na ~95% danych.

7. Nikt tego nie monitoruje

Tracking psuje się cicho: aktualizacja theme, nowy plugin, zmiana checkoutu, podmiana banera zgód. Bez alertu (choćby prostego: dzienna liczba purchase w GA4 vs. zamówienia w sklepie, odpalane automatem) dowiesz się o problemie po miesiącu, z raportu, który już skłamał.

Jak to sprawdzić w 15 minut

1. GTM Preview → przejdź pełną ścieżkę zakupu na produkcji (płatność testowa) i patrz, co strzela i z jakimi wartościami.
2. GA4 → porównaj liczbę i wartość purchase z ostatnich 7 dni z panelem zamówień sklepu. Rozjazd powyżej ~5% = problem.
3. Odmów zgody w banerze i powtórz zakup — zobacz, co się dzieje.

Jeśli którykolwiek punkt wyszedł czerwony — to dokładnie te rzeczy naprawiamy najczęściej i zwykle w kilka dni roboczych.