Dlaczego GA4 pokazuje mniej zamówień niż Shopify

Dwie liczby mogą opisywać inne rzeczy

Panel sklepu zawiera dane biznesowe zamówień. GA4 rejestruje zdarzenia według konfiguracji i dostępnych sygnałów. Raport kampanii dodatkowo przypisuje wynik do źródła ruchu według swoich zasad. Brak zakupu w konkretnym kanale nie musi oznaczać, że zdarzenia purchase w ogóle nie ma. Rozdzielenie tych problemów jest pierwszym krokiem do rozsądnej diagnozy.

Zacznij od pytania, czego szukasz: kompletności zdarzeń, poprawnej kwoty czy przypisania do kampanii. Jeśli zmieniasz integrację, aby naprawić atrybucję, możesz nie wpłynąć na rzeczywistą przyczynę. Zwiększona liczba purchase również nie musi być poprawą, gdy pochodzi z duplikatów. Potrzebujesz metody porównania na poziomie transakcji, z opisanym zakresem i ograniczeniami. Procent pokazany bez tych założeń jest zbyt uproszczony, by podejmować decyzję o zakupie narzędzia.

Ustal próbę porównawczą

Wybierz pełny okres, w którym konfiguracja była stabilna. Uzgodnij strefę czasową, walutę i datę, według której kwalifikujesz zamówienia. Zdecyduj, jak potraktować testy, ręczne zamówienia, POS, anulowania i zwroty. Nie porównuj wszystkich kanałów Shopify wyłącznie ze zdarzeniami przeglądarkowymi sklepu online. Taki zbiór od początku ma inne granice.

Definicje zapisz przed obliczeniem wyniku

Określ, czy wartość ma obejmować dostawę, podatki oraz rabaty i w którym momencie ją odczytujesz. Przy zwrotach późniejszy raport biznesowy może zmienić wynik, chociaż zdarzenie zakupu wysłano wcześniej poprawnie. Osobno wskaż opóźnienie przetwarzania. Jeśli nie można odtworzyć historycznej konfiguracji, użyj nowego okresu obserwacji i opisz brak wcześniejszej linii bazowej. Nie dopasowuj definicji po fakcie wyłącznie po to, by dwa raporty wyglądały podobnie.

Połącz dane przez identyfikator transakcji

Zamiast oceniać jedynie sumę przychodu, porównaj identyfikatory. Ustal, jaki klucz Shopify integracja przekazuje jako transaction ID. Numer widoczny dla obsługi, wewnętrzny identyfikator i wartość wysyłana do narzędzia mogą mieć różny format. Potrzebne jest jednoznaczne mapowanie. W analizie nie musisz wykorzystywać nazwisk i pełnych adresów kupujących.

Podziel wynik na zamówienia z dopasowanym zdarzeniem, bez zdarzenia oraz zdarzenia bez rozpoznanego zamówienia. Osobno oznacz duplikaty i różnice kwoty. Ta prosta struktura pozwala sprawdzić, czy problem dotyczy konkretnej waluty, metody lub urządzenia. Nie zakładaj jednak przyczyny wyłącznie na podstawie korelacji. Grupowanie wskazuje, jaki test wykonać dalej. Raport powinien zachować pochodzenie danych oraz sposób dopasowania, aby inna osoba mogła powtórzyć analizę.

Zgody, blokery i przerwana ścieżka

Nie każda wizyta dostarcza tych samych danych. Użytkownik może odrzucić zgodę, korzystać z blokera lub zamknąć kartę na końcu procesu. Sprawdź zachowanie narzędzi w różnych stanach, a nie tylko podczas pełnej akceptacji cookies. Przy odmowie oczekiwany zakres danych powinien wynikać z zatwierdzonej konfiguracji i zasad prywatności.

Baner zgód i sposób działania tagów trzeba analizować razem. Sam fakt pokazania banera nie dowodzi, że wszystkie instalacje respektują tę samą decyzję. Consent Mode v2 wymaga prawidłowego przekazania stanów, ale nie jest obietnicą odtworzenia każdej transakcji w każdym raporcie. Reguły prawne potwierdź ze specjalistą. Celem testu jest zgodne z założeniami zachowanie, a nie wymuszenie większej liczby zdarzeń bez względu na wybór użytkownika. Tę granicę należy zachować również w pomiarze serwerowym.

Sprawdź, kto wysyła purchase

Sporządź listę kanałów Google, app pixels, custom pixels, kontenerów GTM i skryptów pozostawionych w motywie. Każdy może mieć własne ustawienia oraz historię instalacji. Przy przejętym sklepie często brakuje informacji, która integracja jest nadal potrzebna. Najpierw dokumentuj, potem wyłączaj elementy w kontrolowanym teście. Przypadkowe usuwanie skryptów w produkcji może przerwać inną ważną funkcję.

Ograniczenia środowiska pikseli

Kod działający w motywie nie ma automatycznie identycznych możliwości w checkout lub piaskownicy custom pixel. Korzystaj z aktualnej dokumentacji Shopify i sprawdzaj odbiór zdarzeń, nie tylko obecność kodu. Podgląd GTM i Tag Assistant pomagają diagnozować, ale nie stanowią samodzielnego dowodu poprawności całej sprzedaży. Ważne są parametry, odbiorca i zachowanie przy różnych zgodach. Instalacja nowego kontenera bez analizy istniejących wysyłek może powiększyć problem.

Duplikaty, waluty i wartości

Dwie instalacje mogą wysłać purchase dla jednego zamówienia. Inny problem wystąpi, gdy ta sama kwota zostanie opisana niewłaściwą walutą albo gdy w jednej integracji obejmuje dostawę, a w drugiej jej nie zawiera. Takie zdarzenia mogą zwiększyć lub zmniejszyć różnicę w sumie, ukrywając rzeczywiste braki. Dlatego liczba zdarzeń i wartość powinny być sprawdzane oddzielnie.

Przetestuj produkt z rabatem, koszyk z dostawą, inną walutę oraz powrót na ekran potwierdzenia. Sprawdź stabilność transaction ID i spójność listy pozycji. Powtórne otwarcie strony nie powinno tworzyć niezależnego nowego zakupu w konfiguracji. Nie rozwiązuj problemu przez ręczne podwojenie wysyłki „na wszelki wypadek”. Właściwa naprawa określa źródło zdarzenia i sposób kontroli powtórzeń, z uwzględnieniem zachowania używanej integracji oraz odbiorcy.

Atrybucja nie jest rejestrem księgowym

Platformy reklamowe i analityczne mogą przypisywać sprzedaż według innych reguł. Różne okna, modele i źródła sygnałów powodują, że jedna transakcja może być przypisana odmiennie. Nie sumuj bezpośrednio przychodów raportowanych przez kilka platform jako niezależnych sprzedaży. Najpierw sprawdź, czy ten sam zakup występuje w danych, a dopiero potem oceń jego źródło.

Jeśli purchase istnieje, ale kampania nie otrzymała przypisania, analizuj linki, parametry, przekierowania i zgodność ścieżki. Samo ponowne wysłanie zdarzenia nie musi naprawić atrybucji. Przy zmianie domen, rynków lub operatora płatności sprawdź także powrót klienta do sklepu. Zapisz przyjętą metrykę dla oceny marketingu i oddziel ją od zestawienia zamówień do rozliczeń. Oba raporty mogą być użyteczne, ale odpowiadają na inne pytania.

Czy Stape lub inny server-side rozwiąże problem?

Najpierw ustal, jaki problem ma rozwiązać nowa architektura. Server-side może dawać inne możliwości kontroli wysyłki, ale wymaga źródła zdarzeń, utrzymania i konfiguracji odbiorców. Nie naprawia automatycznie złych identyfikatorów, nieuzgodnionych definicji przychodu ani braku właściwych zgód. Porównuj konkretne funkcje integracji, nie samą etykietę „serwerowe”.

Policz wdrożenie, hosting, wolumen i późniejsze aktualizacje. Ustal, kto odpowiada za błędy po zmianie API. Narzędzia takie jak Littledata, Elevar lub inne konektory powinny mieć określoną rolę; równoległe testowanie kilku bez kontroli może utrudnić ocenę. Żądaj raportu na porównywalnych danych, zamiast uniwersalnego procentu poprawy. Jeżeli konfiguracja podstawowa jest niepoprawna, najpierw ją uporządkuj. Inaczej trudno ustalić, która zmiana przyniosła efekt i czy rezultat jest trwały.

Jak przygotować raport przed i po?

Zachowaj tę samą metodę kwalifikowania zamówień i dopasowania identyfikatorów. Zapisz datę wdrożenia oraz inne istotne zmiany w sklepie. Porównuj okresy z uwzględnieniem liczby transakcji, źródeł i stanów zgody. Jeśli w jednym tygodniu trwała duża promocja, surowa różnica nie opisuje wyłącznie jakości analityki. Wynik musi zawierać komentarz do takich zależności.

Przedstaw liczbę zakwalifikowanych zamówień, dopasowane transakcje, duplikaty, braki i rozbieżności wartości. Dołącz wyniki kontrolowanych testów. Nie pokazuj pojedynczego wskaźnika bez informacji, co weszło do mianownika. Jeżeli efektu nie można przypisać jednoznacznie wdrożeniu, napisz to wprost. Dobrze przygotowany raport pozwala podjąć decyzję o dalszych działaniach, nawet jeśli nie obiecuje spektakularnego wzrostu liczby zdarzeń. To bardziej użyteczne niż zapewnienie o „100% dokładności” bez definicji.

Zapis konfiguracji razem z wynikiem

Do raportu dodaj listę aktywnych integracji, identyfikatory usług i wersję konfiguracji zgód. Nie dołączaj sekretów ani pełnych danych użytkowników. Ten zestaw pozwala później odróżnić zmianę pomiaru od zmiany sposobu raportowania. Bez niego powtórny audyt może zaczynać się od odtwarzania historii zamiast sprawdzenia znanych założeń.

Warto zapisać także elementy wyłączone podczas naprawy oraz powód. Pozostawiona aplikacja może zostać przypadkowo ponownie aktywowana przez inną osobę. Prosty dziennik zmniejsza ryzyko powrotu duplikatów. Przy przekazaniu sklepu nowemu wykonawcy dołącz definicję próby oraz metodę porównania, aby nie uznał różnicy po zmianie filtrów za sukces techniczny. To pozwala rozmawiać o rezultacie na tych samych danych, niezależnie od wybranego panelu lub osoby prowadzącej analizę.

Kiedy zamówić audyt analityki?

Pomoc jest uzasadniona, gdy nie da się odtworzyć mapy instalacji, występują powtarzalne braki albo raporty służą do istotnych decyzji reklamowych. Przygotuj listę narzędzi, datę ostatniej zmiany i zanonimizowane przykłady rozbieżności. Do pierwszego briefu nie są potrzebne pełne eksporty kupujących ani hasła. Zakres dostępów ustala się po rozpoznaniu zadania.

W ramach analityki Shopify możemy przygotować mapę zdarzeń, test zgód, poprawki oraz raport porównawczy. Jeżeli problem obejmuje też dane produktowe, osobno sprawdzamy Google Merchant Center. Jakość feedu i kompletność purchase to różne obszary. Ustal, czy chcesz jednorazowej diagnozy, wdrożenia czy kontroli po aktualizacjach. Efektem powinny być zrozumiałe definicje i powtarzalny sposób sprawdzania, a nie uzależnienie od jednego panelu bez dokumentacji.

Lista kontrolna

• Porównywalny okres i kanał
• Uzgodnione daty, waluty i wartości
• Mapa transaction ID
• Lista wszystkich wysyłek purchase
• Test zgód i ścieżek zakupu
• Osobna analiza atrybucji
• Raport ograniczeń i utrzymania