GA4 pokazuje więcej zamówień niż sklep. Sprawdź, czy wtyczka nie wysyła zakupu dwa razy

Zanim uwierzysz w raport sprzedaży z GA4, porównaj go z liczbą opłaconych zamówień w panelu sklepu. U mnie panel jest prawdą, a analityka ma się do niej zbliżać; jeśli GA4 pokazuje więcej zamówień niż sklep, coś liczy podwójnie. W tym tygodniu agencja mbridge opisała sklep na WordPressie, w którym jedno ustawienie wtyczki wysyłało każdą transakcję do GA4 dwa razy: raz z przeglądarki klienta, raz z serwera przez Measurement Protocol. GA4 raportował zawyżone transakcje i przychody, a wyszło to dopiero przy porównaniu z CRM po identyfikatorach transakcji. Pokazuję, jak to działa od środka, dlaczego GA4 nie zawsze wyłapie duplikat i jak sprawdzić to u siebie w godzinę.

Jak GA4 rozpoznaje podwójny zakup

Mechanizm jest prosty i opisany w pomocy Google: „Google Analytics usuwa duplikaty zdarzeń purchase o tym samym identyfikatorze transakcji". Do tego trzy zastrzeżenia z tej samej strony, które robią całą różnicę. Ten sam identyfikator nie powinien pochodzić od różnych użytkowników. Deduplikacja działa tylko w strumieniach internetowych, nie w aplikacjach. I nie wolno wysyłać pustego ciągu jako identyfikatora, bo wtedy GA4 potraktuje wszystkie zakupy z pustym transaction_id jako jeden i ten sam.

W praktyce oznacza to, że klasyczny problem, czyli klient odświeżający stronę podziękowania za zamówienie, GA4 obsługuje sam. Drugie zdarzenie purchase idzie z tej samej przeglądarki, z tym samym client_id i tym samym numerem zamówienia, więc zostaje odrzucone. Zobaczysz je w raporcie czasu rzeczywistego, ale nie w raportach sprzedaży.

Inaczej wygląda sytuacja, gdy drugą kopię wysyła serwer. Measurement Protocol to interfejs, którym backend sklepu wysyła zdarzenia do GA4 bez przeglądarki. Google w dokumentacji pisze wprost, że jego celem jest uzupełnianie zbierania danych przez gtag i Tag Managera, nie zastępowanie go, a zdarzenia z obu źródeł są łączone po client_id. Jeśli wtyczka albo integracja wysyła zakup z serwera z własnym, wygenerowanym identyfikatorem klienta, GA4 widzi innego użytkownika, a ten sam numer zamówienia od innego użytkownika nie jest już duplikatem do sklejenia. Wychodzą dwie transakcje, dwa razy przychód, dwa razy sprzedane sztuki. Do tego dochodzi limit czasu: zdarzenia z protokołu, które mają być połączone z danymi z przeglądarki, muszą dotrzeć w ciągu 48 godzin od zdarzenia po stronie klienta.

Skąd bierze się druga kopia

Z audytów, które robimy w sklepach na WooCommerce, PrestaShop i Magento, wychodzą cztery typowe źródła:

• Opcja serwerowa we wtyczce. Wiele wtyczek śledzących ma pole na klucz API i przełącznik w rodzaju „wysyłaj zakupy także po stronie serwera". Włączony obok śledzenia w przeglądarce daje dokładnie przypadek z mbridge.
• Dwa narzędzia mierzące to samo. Wtyczka e-commerce plus tag GA4 w Tag Managerze plus moduł motywu. Każde z nich wysyła purchase i każde ma rację, że tak trzeba.
• Własna integracja z webhookiem płatności. Programista dopisał wysyłkę zakupu po potwierdzeniu płatności, żeby liczyć zamówienia mimo blokad reklam, ale nikt nie wyłączył wysyłki ze strony podziękowania.
• Brak lub pusty transaction_id. To odwrotny problem: bez identyfikatora GA4 nie ma czego sklejać, a z pustym skleja wszystko w jedno. Wtedy w raporcie jest za mało transakcji, nie za dużo.

Trzy pierwsze zawyżają sprzedaż. Czwarte ją zaniża. W obu wypadkach decyzje o budżecie zapadają na liczbach, których nie ma.

Co to psuje poza raportem

Najdroższy skutek nie siedzi w GA4, tylko w Google Ads. Jeśli zdarzenie purchase z GA4 jest zaimportowane do Google Ads jako główna konwersja, Smart Bidding uczy się na zamówieniach, które istnieją tylko w analityce. ROAS w koncie wygląda lepiej, niż jest, rekomendacje podpowiadają wyższy budżet, a agencja pokazuje wzrost, którego kasa sklepu nie widzi. Przed czwartym kwartałem, gdy stawki idą w górę u wszystkich, to jest najgorszy moment na taki rozjazd.

Dalej idą wszystkie liczby pochodne: współczynnik konwersji sklepu, wyniki testów A/B, atrybucja kanałów, wartość klienta w czasie. Sprzedaję tonery od dwudziestu lat i wiem, że przy powtarzalnych zakupach jeden podwojony klient w danych potrafi zmienić całą ocenę tego, który kanał przynosi zamówienia wracające. Analityka, która liczy dwa razy, nie jest dwa razy lepsza. Jest bezużyteczna, dopóki nie wiesz, o ile.

Jak sprawdzić w godzinę

1. Panel sklepu kontra GA4. Policz opłacone zamówienia z ostatnich 30 dni bez anulowanych i nieudanych płatności. Zestaw z liczbą transakcji w GA4 w raporcie zakupów e-commerce za ten sam okres. GA4 zwykle pokazuje trochę mniej niż sklep, bo część klientów odrzuca zgodę na śledzenie albo blokuje skrypty. Jeśli pokazuje więcej, masz duplikaty. Jeśli pokazuje dużo mniej, sprawdź zgody i pusty transaction_id.
2. Eksploracja po numerze zamówienia. W eksploracjach dodaj wymiar Transaction ID i liczbę zdarzeń z filtrem na purchase, posortuj malejąco. Każdy wiersz z wartością 2 albo wyższą to duplikat, którego GA4 nie skleiło. Osobno obejrzyj wiersze „(not set)".
3. Ustawienia wtyczki i tagów. Przejrzyj wtyczkę śledzącą pod kątem pól z kluczem API, opcji „server-side" i „Measurement Protocol". W Tag Managerze wypisz wszystkie tagi, które odpalają się na zdarzeniu zakupu. Sprawdź, czy motyw albo wtyczka do integracji z Google nie ma własnego modułu e-commerce.
4. Zamówienie testowe w DebugView. Złóż zamówienie testowe i policz zdarzenia purchase w DebugView. Odśwież stronę podziękowania i zobacz, co się dzieje. Jedno zamówienie ma dać jedno zdarzenie w raportach.
5. BigQuery, jeśli jest podpięte. Policz wszystkie zdarzenia purchase i zdarzenia z unikalnym transaction_id w tym samym okresie. Różnica to Twoje duplikaty, co do sztuki.
6. Google Ads. W celach i konwersjach sprawdź, które działania dotyczące zakupu są główne. Ma być jedno źródło zakupu w roli głównej, a nie import z GA4 obok tagu Google Ads.

Co zrobić w najbliższym tygodniu

• Zostaw jedną ścieżkę wysyłki zakupu. Jeśli ścieżka serwerowa ma zostać, bo ratuje zamówienia klientów z blokadą skryptów, musi przekazywać ten sam client_id i ten sam transaction_id co przeglądarka. To praca integracyjna, nie przełącznik. Jeśli nikt nie umie tego zagwarantować, wyłącz ją.
• Zapisz datę zmiany i przez kolejne 30 dni codziennie porównuj zamówienia z panelu z transakcjami w GA4. Rozjazd ma zmaleć do kilku procent i się ustabilizować.
• Poinformuj osobę prowadzącą Google Ads, że historia konwersji sprzed naprawy była zawyżona, i ustalcie, od której daty porównujecie wyniki. Inaczej pierwszy miesiąc po naprawie będzie wyglądał jak spadek sprzedaży.
• Dopisz ten test do listy kontrolnej przed każdą aktualizacją wtyczki śledzącej i przed sezonem. Duplikaty wracają po aktualizacjach częściej, niż ktokolwiek się spodziewa.

Jeśli liczby w GA4 i w panelu sklepu nie chcą się spotkać, a przed sezonem trzeba wiedzieć, na czym naprawdę stoi sprzedaż, porozmawiajmy o tym. Godzina nad Twoimi danymi zwykle wystarcza, żeby wiedzieć, komu wierzyć.

Decyzje

• 2026-09-08 13:46 — U01EDFDH8G2: zaakceptowany — Slack 2026-09-08: publikuj