Zduplikowane zakupy w GA4 — jak pseudo-przychód zafałszowuje Twoje raporty e-commerce

Przychód w GA4 to jedna z metryk, na które patrzy się najczęściej i którym ufa się najmniej krytycznie — w końcu to GA4 ma po prostu zliczyć to, co faktycznie się sprzedało. Problem w tym, że event purchase potrafi wystrzelić więcej niż raz dla tej samej transakcji, a GA4 domyślnie nie ma jak tego samodzielnie wykryć. Efekt: przychód, ROAS i liczba zamówień w raportach GA4 są wyższe niż w rzeczywistości, często o kilka do kilkunastu procent, bez żadnego ostrzeżenia w interfejsie.

Czym jest zduplikowany zakup w GA4

Zduplikowany zakup to sytuacja, w której zdarzenie purchase z tymi samymi (albo bardzo podobnymi) danymi transakcji zostaje wysłane do GA4 więcej niż raz. GA4 nie ma wbudowanego mechanizmu, który automatycznie rozpozna dwa zdarzenia jako „tę samą transakcję” — chyba że parametr transaction_id jest ustawiony i spójny, a nawet wtedy GA4 i tak zlicza oba wystąpienia zdarzenia osobno w większości standardowych raportów, nie prowadząc pełnej deduplikacji po stronie interfejsu.

W praktyce duplikat oznacza, że jedno realne zamówienie o wartości, powiedzmy, 250 zł, w GA4 wygląda jak dwa zamówienia po 250 zł — 500 zł pseudo-przychodu z jednej transakcji klienta.

Najczęstsze przyczyny duplikatu

1. Odświeżenie strony potwierdzenia zamówienia. Jeśli tag purchase jest podpięty do zdarzenia Page View na stronie „Dziękujemy za zamówienie”, każde odświeżenie tej strony przez klienta (albo powrót do niej przyciskiem wstecz, a potem ponownie do przodu) wysyła zdarzenie jeszcze raz.
2. Tag wysyłany zarówno przez GTM w przeglądarce, jak i przez integrację server-side. Część sklepów wdraża jednocześnie tag w kontenerze webowym GTM i osobną integrację server-side (np. z platformy e-commerce) wysyłającą to samo zdarzenie purchase do GA4, bez wzajemnej koordynacji.
3. Dwa triggery w tym samym kontenerze GTM odpalające ten sam tag. Typowy błąd konfiguracyjny: tag purchase ma ustawiony zarówno trigger „Custom Event” nasłuchujący zdarzenia z dataLayer, jak i dodatkowy trigger „Page View” na tej samej stronie, więc odpala się dwa razy przy jednym załadowaniu.
4. Brak unikalnego i stabilnego transaction_id. Gdy identyfikator transakcji nie jest ustawiany wcale albo zmienia się między wywołaniami tego samego zamówienia, GA4 nie ma żadnego klucza, po którym dałoby się rozpoznać duplikat nawet ręcznie w raportach.
5. Aplikacje jednostronicowe (SPA) z błędną obsługą routingu. Jeśli zmiana widoku po złożeniu zamówienia wywołuje dataLayer.push z eventem purchase przy każdym re-renderze komponentu potwierdzenia, a nie tylko raz po stronie backendu, duplikaty pojawiają się praktycznie przy każdej transakcji.
6. Integracje marketingowe podpięte pod ten sam dataLayer.push. Czasem to nie sam tag GA4 się duplikuje, tylko skrypt zewnętrzny (np. recenzji produktowych albo programu lojalnościowego) wywołuje ponownie całe zdarzenie dataLayer purchase, które GTM odbiera i przekazuje dalej do GA4.

Jak sprawdzić, czy masz ten problem

• Porównaj liczbę transakcji w GA4 z systemem sprzedażowym. Najszybszy test: zestaw liczbę zdarzeń purchase i wartość przychodu w GA4 za wybrany dzień z rzeczywistą liczbą zamówień i obrotem z panelu sklepu albo bramki płatności. Rozbieżność rzędu kilku–kilkunastu procent w górę to sygnał ostrzegawczy.
• Użyj raportu Explore z wymiarem Transaction ID. Zbuduj raport swobodny z metryką „Liczba zdarzeń purchase” rozbitą po wymiarze transaction_id. Jeśli ten sam identyfikator transakcji pojawia się z liczbą zdarzeń większą niż 1, masz potwierdzony duplikat.
• Sprawdź znaczniki czasu kolejnych zdarzeń tej samej transakcji. Duplikaty w obrębie tej samej sesji zwykle mają znaczniki czasu odległe o sekundy — to pomaga odróżnić je od dwóch odrębnych, prawdziwych zamówień złożonych przez tego samego klienta tego samego dnia.
• Włącz podgląd GTM (Preview) i złóż testowe zamówienie. Obserwuj panel podglądu krok po kroku: jeśli tag purchase odpala się więcej niż raz dla jednego przejścia przez stronę potwierdzenia, problem jest po stronie konfiguracji triggerów, nie po stronie GA4.

Jak to naprawić krok po kroku

1. Ustal jedno, jedyne miejsce w architekturze (web GTM albo server-side, nie oba naraz), które jest odpowiedzialne za wysyłkę zdarzenia purchase do GA4.
2. Nadaj każdej transakcji unikalny, stabilny transaction_id, generowany raz po stronie backendu i niezmienny przy kolejnych załadowaniach tej samej strony potwierdzenia.
3. W GTM sprawdź wszystkie triggery podpięte do tagu purchase i usuń nadmiarowe — zdarzenie powinno odpalać się przez jeden, jednoznaczny trigger (zwykle Custom Event na dedykowanym dataLayer.push), nie przez Page View.
4. Dodaj po stronie strony potwierdzenia prostą blokadę przed ponownym wywołaniem dataLayer.push przy odświeżeniu — np. flagę w sessionStorage sprawdzaną przed wysłaniem zdarzenia.
5. W aplikacjach SPA przenieś wywołanie zdarzenia purchase poza logikę renderowania komponentu, do jednorazowego efektu wywoływanego dokładnie raz po otrzymaniu potwierdzenia zamówienia z backendu.
6. Po wdrożeniu poprawki zweryfikuj w podglądzie GTM i w raporcie Explore z Transaction ID, że każda nowa transakcja pojawia się w GA4 dokładnie raz.

Jak AlertGA4 wykrywa zduplikowane zakupy

Ten rodzaj błędu jest dokładnie tym, czego Insights w GA4 nie sprawdzi — to nie jest ogólny spadek czy wzrost metryki, tylko konkretna, techniczna niespójność na poziomie pojedynczych zdarzeń i parametrów. AlertGA4 po podłączeniu usługi codziennie sprawdza udział zduplikowanych transakcji po transaction_id i, jeśli przekroczy ustalony próg, wysyła maila z konkretną diagnozą: ile transakcji się powtarza i jaki procent dziennego przychodu to realnie pseudo-przychód z duplikatów.

Dzięki codziennemu, automatycznemu sprawdzaniu problem wychodzi na jaw tego samego dnia, w którym się pojawił — zanim zdąży wpłynąć na decyzję o budżecie kampanii opartą o zawyżony ROAS.

Dla kogo ma to znaczenie

• Sklepy internetowe, dla których przychód z GA4 jest wejściem do optymalizacji kampanii — zawyżony ROAS prowadzi wprost do przelewania budżetu w kanały, które w rzeczywistości nie są tak skuteczne, jak wyglądają w raportach.
• Agencje performance marketingowe, które rozliczają skuteczność kampanii klienta na podstawie danych z GA4 i mogą nieświadomie raportować lepsze wyniki, niż miały miejsce naprawdę.
• Zespoły wdrażające nową integrację e-commerce albo migrujące na server-side tagging, czyli dokładnie w momencie, w którym ryzyko podwójnego wysłania tego samego zdarzenia jest największe.