GA4 w WooCommerce: kiedy purchase nie równa się opłaconemu zamówieniu

WooCommerce domyka zamówienie, zanim pieniądze dotrą na konto sklepu. Zdarzenie purchase wysyła się na stronie podziękowania, więc w GA4 pojawia się przychód z zamówień, których klient może jeszcze nie opłacić. Przy przelewie tradycyjnym różnica potrafi sięgać kilkudziesięciu procent.

Poniżej nie ma kolejnego przewodnika po konfiguracji tagów. Chodzi o warstwę niżej: skąd purchase w WooCommerce się bierze, co wysyła wtyczka, a co kontener, i jak poukładać pomiar tak, żeby raport odpowiadał na pytanie o pieniądze, które faktycznie wpłynęły.

Trzy drogi, którymi purchase trafia do GA4

Najczęściej działają jedna lub dwie z tych ścieżek i warto wiedzieć które, bo od tego zależy, gdzie szukać błędu:

• Darmowe rozszerzenie Google Analytics for WooCommerce. Konfiguracja siedzi w panelu sklepu, w sekcji WooCommerce > Ustawienia > Integracje > Google Analytics, gdzie wkleja się identyfikator pomiaru zaczynający się od G-. Dokumentacja ostrzega, że połączenie może zacząć działać dopiero po 48 godzinach.
• DataLayer plus kontener GTM. Wtyczka albo własny kod na karcie produktu, w koszyku i na stronie podziękowania, a w kontenerze tag GA4 czytający zmienne z DataLayer.
• Rozszerzenia komercyjne albo zewnętrzny system zamówień podłączony przez REST API. Tutaj logika siedzi w kodzie, więc sprawdzenie wymaga dostępu do implementacji.

W rozszerzeniu z pierwszej ścieżki zakup jest jedną z opcji, obok dodania do koszyka, wyświetleń produktów na listach i widoków karty produktu. Pozycja "transakcje zakupowe" ma jednak wyraźne zastrzeżenie: potrzebna jest bramka płatności, która po zapłacie przekierowuje na stronę podziękowania. To zdanie opisuje większość problemów opisanych niżej.

Jedno zamówienie, dwa zdarzenia purchase

Gdy na stronie działają jednocześnie wtyczka i tag GA4 w kontenerze, to samo zamówienie wysyła dwa zdarzenia. Google radzi sobie z tym po identyfikatorze transakcji: GA4 deduplikuje purchase, jeśli dwa zdarzenia mają ten sam transaction_id. Deduplikacja działa tylko dla strumieni web, nie dla aplikacji.

Pustego identyfikatora nie wolno wysyłać, bo wszystkie zdarzenia z transaction_id="" zostaną zdeduplikowane razem i większość sprzedaży zniknie z raportu. Druga rzecz jest mniej oczywista: deduplikacja zostawia pierwsze zdarzenie i odrzuca kolejne, więc jeśli pierwszy purchase dotyczył zamówienia, które nigdy nie zostało opłacone, ponowne wysłanie zdarzenia po opłacie niczego nie naprawi.

Przed dodaniem drugiej ścieżki sprawdź więc, co już działa. Dokumentacja rozszerzenia ostrzega, że wiele instancji kodu śledzącego na jednej stronie powoduje problemy.

Status zamówienia to nie to samo co zapłata

WooCommerce ma osobne statusy dla osobnych sytuacji: oczekiwanie na płatność, wstrzymane, przetwarzanie w toku, zrealizowane, anulowane, nieudane i zwrócone. Kolejność jest tu istotna, bo zamówienie powstaje przed potwierdzeniem płatności.

• Przetwarzanie w toku ustawia się automatycznie po udanej płatności bramki, ale tylko wtedy, gdy webhooki są poprawnie skonfigurowane.
• Wstrzymane pojawia się przy sporze, który nie został jeszcze rozstrzygnięty, oraz przy autoryzacji bez pobrania środków.
• Zwrócone wymaga zwrotu płatności. Ręczna zmiana statusu na zwrócone albo anulowane pieniędzy nie zwraca.
• Anulowane obejmuje też porzucenie zamówienia w trakcie kasy.

Przelew tradycyjny, płatności rozliczane po stronie banku i bramki, które potwierdzają wpłatę po zamknięciu strony, łamią założenie z dokumentacji o przekierowaniu po zapłacie. Zdarzenie purchase leci w momencie złożenia zamówienia, czyli dla pieniędzy, których sklep jeszcze nie ma i może nigdy nie zobaczyć.

Brakujące pole usuwa całe zdarzenie z raportu

Purchase nie wybacza braków. Wymagane na poziomie zdarzenia są: waluta, identyfikator transakcji, wartość i tablica pozycji, a w każdej pozycji przynajmniej identyfikator albo nazwa produktu. Gdy któregoś z nich brakuje, zdarzenie nie jest traktowane jako zakup i nie pojawia się w raporcie sprzedaży.

Dwie usterki wracają w audytach częściej niż inne: wartość przekazana jako tekst, z cudzysłowami albo z symbolem waluty, oraz waluta zapisana w innym formacie niż trzyliterowy kod ISO 4217. Osobno sprawdź przychód z produktów, bo liczy się on z ceny pozycji, a nie z wartości zamówienia. Poprawna wartość i brak ceny dają zamówienie w raporcie bez przychodu z produktów.

Jak liczyć tylko opłacone zamówienia

Masz trzy realne warianty. Wybór zależy od tego, co jest ważniejsze: prostota czy zgodność z księgowością.

1. Zostaw purchase na stronie podziękowania i uzgadniaj liczby raz w miesiącu, odejmując anulowane oraz nieopłacone zamówienia z panelu sklepu.
2. Przenieś sygnał zakupu na serwer. Zdarzenie wysyła system sklepu w momencie zmiany statusu na opłacone, przez Measurement Protocol albo Data Manager API. Warunek: wcześniej nie może polecieć purchase z przeglądarki, bo deduplikacja odrzuci drugie zdarzenie.
3. Wysyłaj korektę. Jeśli pierwsze zdarzenie już poszło, dla nieopłaconych zamówień wyślij zwrot z tym samym identyfikatorem transakcji, zamiast liczyć na to, że drugi purchase nadpisze pierwszy.

W wariancie serwerowym potrzebujesz sekretu API utworzonego w GA4 na karcie strumienia danych, identyfikatora pomiaru w adresie żądania i identyfikatora klienta w treści, najlepiej tego samego, który wygenerował tag na stronie. Zdarzenia można wysłać z opóźnieniem do 72 godzin. Sekret zostaje na serwerze, bo w kodzie przeglądarki pozwala wstrzyknąć dowolne dane do twojej usługi.

Measurement Protocol jest dziś w fazie utrzymania bez daty wyłączenia, a Google wskazuje Data Manager API jako drogę dla nowych integracji serwerowych.

Test na jednym zamówieniu, nie na kodzie

1. Złóż zamówienie w trybie testowym bramki i przejdź całą ścieżkę do strony podziękowania.
2. Sprawdź zdarzenie purchase w Tag Assistant albo DebugView: identyfikator transakcji, liczbę pozycji i wartość bez symbolu waluty.
3. Porównaj liczbę pozycji z koszykiem. Rabat, produkt dodany jako propozycja i pozycja usunięta w kasie to najczęstsze źródła rozjazdu.
4. Zmień status zamówienia na opłacone i sprawdź, czy nie pojawiło się drugie zdarzenie o tym samym identyfikatorze.
5. Powtórz test dla przelewu tradycyjnego, żeby zobaczyć, w którym momencie powstaje zdarzenie.
6. Wyklucz własny adres IP z ruchu wewnętrznego, żeby testy nie wchodziły do danych produkcyjnych.

Dane w raportach pojawiają się w ciągu 24 do 48 godzin, a przypisanie do kanałów przesuwa się jeszcze przez kilkanaście dni.

Zgoda, RODO i dane osobowe w zamówieniu

Zapisanie informacji w urządzeniu klienta wymaga zgody, która musi być dobrowolna, konkretna, świadoma i jednoznaczna. Rozszerzenie WooCommerce nie dostarcza banera, tylko integruje się z WP Consent API, więc interfejs zgody pochodzi z wtyczki CMP.

Jest tu pułapka techniczna: rozszerzenie ustawia własne domyślne wartości trybu zgody i potrafi nadpisać to, co ustawiła wtyczka cookie. Dokumentacja wskazuje filtr, którym można to wyłączyć, a wynik warto sprawdzić w kodzie strony.

Druga sprawa dotyczy samego zdarzenia. Do GA4 nie wysyła się danych osobowych, a identyfikator transakcji nie powinien zawierać informacji identyfikujących klienta. Numer zamówienia jest bezpieczny, numer zamówienia z adresem e-mail już nie.

Co sprawdzić w tym tygodniu

1. Ustal, która ścieżka wysyła purchase: wtyczka, kontener czy obie.
2. Policz zamówienia w sklepie i zdarzenia purchase w GA4 za ten sam tydzień.
3. Zestaw nieopłacone zamówienia z przychodem w raporcie.
4. Zdecyduj, czy przenosisz sygnał zakupu na serwer, czy uzgadniasz ręcznie co miesiąc.

W skrócie

Purchase w WooCommerce mierzy złożone zamówienie, a nie wpłatę. Przy bramkach z natychmiastowym przekierowaniem różnica jest mała, przy przelewie tradycyjnym i płatnościach rozliczanych po zamknięciu strony potrafi być duża. Deduplikacja po identyfikatorze transakcji chroni przed podwójnym liczeniem, ale nie poprawi zdarzenia, które już poszło.

Najprostszy audyt to zestawienie trzech liczb za ten sam okres: zamówień w sklepie, zdarzeń purchase w GA4 i zamówień opłaconych. Rozjazd między nimi wskazuje, gdzie szukać problemu.