Uzgadnianie przychodów e-commerce w GA4: dlaczego liczby się nie zgadzają

Zamykasz miesiąc, otwierasz raport e-commerce w GA4 i porównujesz go z panelem sklepu. Liczby się nie zgadzają. Czasem różnica jest niewielka, a czasem taka, że nikt nie chce jej pokazać klientowi. Pierwszy odruch to szukanie błędu w tagu. Zwykle błąd jest gdzie indziej.

GA4 nie jest księgą przychodów i nie będzie. To narzędzie pomiarowe, które liczy to, co udało się zebrać z przeglądarki użytkownika, po odjęciu tego, co zablokowała wtyczka, odrzuciła zgoda albo zgubił podział na domeny. Sklep liczy zamówienia i zwroty. Te dwa zbiory nigdy nie będą identyczne. Różnica powinna być natomiast znana i w miarę stabilna.

Skąd biorą się różnice

Wypisz wszystkie źródła rozjazdu. W praktyce wracają cztery grupy: brakujące zdarzenia (zgoda, blokery, błąd w tagu), zdarzenia policzone dwa razy (podwójny tag, powtórzone purchase), różnice w kwotach (podatek, dostawa, rabaty, waluta) i czas (opóźnienie przetwarzania oraz przesuwanie zasług przy konwersjach).

Najpierw liczba zamówień, potem identyfikatory, na końcu kwoty

Ta kolejność oszczędza godziny. Jeśli liczba transakcji się zgadza, a kwoty nie, problem dotyczy wartości. Jeśli nie zgadza się liczba, problem dotyczy zbierania albo duplikacji. Jeśli zgadza się jedno i drugie, a różni się przypisanie do kanałów, problem siedzi w sesjach i domenach, nie w pieniądzach.

Do porównania identyfikatorów wyeksportuj z GA4 listę transaction_id i zestaw ją z listą zamówień ze sklepu, w obie strony. Braki po stronie GA4 to problem zbierania. Nadwyżka po stronie GA4 to najczęściej duplikat.

Identyfikator transakcji robi więcej, niż myślisz

Identyfikator transakcji nie jest ozdobą. Google wymaga go przy każdym zdarzeniu e-commerce z dwóch powodów: żeby odrzucić duplikaty od tego samego użytkownika i żeby poprawnie rozliczyć zwroty.

Uwaga na dwa szczegóły, które psują statystyki w sposób widoczny dopiero po fakcie. Deduplikacja działa tylko dla danych zbieranych przez strumienie webowe, nie przez aplikacje. Nie wysyłaj pustego tekstu. GA4 potraktuje wszystkie zdarzenia purchase z pustym transaction_id jako jedno zdarzenie i policzy je raz.

Stały identyfikator wstawiany do każdego zamówienia przez szablon zaniża liczbę konwersji tak, że w raporcie nie widać niczego podejrzanego. Identyfikator musi być unikalny dla każdego zamówienia. Może zawierać cyfry, litery, myślniki i spacje, a nie może zawierać danych, które pozwalają zidentyfikować klienta.

Czy zdarzenie purchase w ogóle istnieje

Zdarzenie purchase, któremu brakuje wymaganego parametru, nie pojawi się w raporcie e-commerce. Google traktuje je wtedy jak zdarzenie niestandardowe. Nie ma ostrzeżenia ani błędu, zdarzenia po prostu nie ma na liście.

Wymagane na poziomie zdarzenia są cztery parametry: transaction_id, value, currency oraz items. Na poziomie pozycji potrzebny jest przynajmniej item_id albo item_name. Do tego wartość musi być liczbą, nie tekstem. Bez cudzysłowów, bez symbolu waluty, zapisana małymi literami. Jeśli w value trafia kwota ze znakiem złotego, GA4 nie policzy z tego przychodu.

Kwota w value to suma iloczynów ceny i ilości dla wszystkich pozycji, bez podatku i bez kosztu dostawy. Przychód na poziomie pozycji liczony jest jako cena razy ilość i tak samo nie zawiera podatku ani dostawy. Jeśli do value wpisujesz kwotę brutto z przesyłką, GA4 pokaże więcej niż sklep, a różnica będzie rosła razem z kosztem dostawy. currency jest wymagane zawsze, gdy ustawiasz value, w formacie ISO 4217.

Zwroty, które nigdy nie dotarły

Przychód całkowity w GA4 to suma zakupów e-commerce, zakupów w aplikacji, subskrypcji i przychodu reklamowego, pomniejszona o zwroty. Kluczowe słowo: pomniejszona. Jeśli sklep nie wysyła zdarzenia refund z identyfikatorem transakcji i pozycjami, GA4 o zwrocie nie wie.

Efekt jest przewidywalny i ma sezonowy rytm. W styczniu, po świątecznych zwrotach, GA4 pokazuje przychód wyższy niż rzeczywisty. Ten sam mechanizm wraca przy każdej fali zwrotów, jeśli odzyskiwanie zwrotów nie zostało zautomatyzowane.

Nie uzgadniaj miesiąca, który wciąż się przetwarza

Przetwarzanie danych w GA4 trwa od 24 do 48 godzin i w tym czasie raporty się zmieniają. To nie awaria, tak działa potok danych.

Dane intraday, czyli te widoczne w ciągu dnia, bywają niekompletne. Mogą w nich występować chwilowe luki w wymiarach źródła ruchu: source, medium, kampania, domyślna grupa kanałów. Dane dzienne są pełniejsze, bo korzystają z większej liczby źródeł. Dopiero na nich porównanie ma sens.

Zasługi przy konwersjach kluczowych mogą się zmieniać nawet do 12 dni po zdarzeniu, bo modelowanie Google poprawia przypisanie. Uzgadniając miesiąc, którego ostatnie dni są świeższe niż dwa tygodnie, porównujesz dwa różne stany tych samych danych.

Wskaźnik jakości danych w raporcie powie ci, czy do wyniku zastosowano progowanie albo próbkowanie. Sprawdź go, zanim zaczniesz tłumaczyć różnicę klientowi.

Płatności i kasa na obcej domenie

Polskie sklepy często kończą zamówienie na domenie operatora płatności. Klient przechodzi na witrynę zewnętrzną, wraca po zapłacie i dopiero wtedy odpala się purchase. Bez pomiaru między domenami sesja kończy się na wyjściu ze sklepu, a zamówienie dopisuje się do witryny operatora albo do kanału direct.

Skutek jest podstępny: suma przychodu się nie zmienia, zmienia się przypisanie. Kampania, która dowiozła klienta, wypada z raportu, a przychód wędruje do direct. Audyt, który porównuje tylko sumy, tego nie złapie. Trzeba porównać przypisanie zamówień do kanałów.

To samo dzieje się przy każdym innym rozłamaniu koszyka: wersja mobilna, aplikacja, subdomena sklepu, osobna domena pod kampanię. Każde przejście wymaga pomiaru między domenami i sprawdzenia, czy łańcuch sesji się nie urywa.

Zgoda, blokery i cisza, która nie jest błędem

Użytkownik, który odmówił zgody analitycznej, nie trafia do raportów jako użytkownik. Część ruchu zniknie też z powodu wtyczek blokujących. To nie jest błąd do naprawienia, to zakres, który trzeba znać.

Policz odsetek odmów w CMP i zestaw go z różnicą, którą widzisz w raportach. Jeśli różnica rośnie po zmianie banera albo po wdrożeniu nowej wersji sklepu, masz odpowiedź.

Jak prowadzić uzgadnianie miesiąc po miesiącu

1. Ustal jedną definicję przychodu, którą porównujesz. Najczęściej jest to kwota zamówień bez podatku i bez dostawy, czyli to samo, co GA4 liczy w value. Zapisz to ustalenie razem z walutą.
2. Zamknij okres z zapasem. Bierz miesiąc zakończony co najmniej 48 godzin temu, a przy analizie przypisania do kanałów odczekaj kilkanaście dni na ustabilizowanie modelowania.
3. Porównaj liczbę zamówień, potem listy identyfikatorów w obie strony, a na końcu kwoty. Każdy etap wskazuje inną przyczynę.
4. Sprawdź, czy purchase przechodzi walidację i czy w GA4 nie ma zdarzenia purchase zapisanego jako zdarzenie niestandardowe. To najszybszy dowód braku wymaganego parametru.
5. Zweryfikuj, czy sklep wysyła zwroty. Zestaw liczbę zwrotów z systemu sprzedaży z liczbą zdarzeń refund.
6. Zapisz różnicę jako odsetek i porównaj z poprzednimi miesiącami. Cel nie brzmi zero procent. Cel brzmi: ta sama różnica co zwykle, z wyjaśnieniem.

Czego nie da się uzgodnić

GA4 nie odtworzy zamówień złożonych przez użytkowników, którzy odmówili zgody. Nie zobaczy ruchu zablokowanego na poziomie sieci. Nie przypisze zamówienia, jeśli łańcuch sesji pękł na obcej domenie. Nie policzy zwrotu, którego nikt nie wysłał.

Dlatego różnica nigdy nie zejdzie do zera. Ustal z klientem akceptowalny zakres, na przykład od trzech do siedmiu procent, i wypisz luki, których nie da się domknąć. Uzgodnienie to nie jednorazowa naprawa tagu. To procedura powtarzana co miesiąc, żeby wiedzieć, kiedy liczba przestaje być wiarygodna.