Integracja Shoper z GA4: co wysyła, a czego w danych nie ma

Sklep na Shoperze ma włączoną integrację z GA4 od dwóch lat. W raporcie Sprzedaż e-commerce widać przychód, w panelu Shopera kwota jest wyższa o kilkanaście procent, a zwrotów nie ma nigdzie. Nikt nie zmieniał tagów. Różnica bierze się z tego, co ta integracja wysyła, a czego nie wysyła wcale.

Poniżej jest inwentaryzacja: lista zdarzeń z dokumentacji Shopera, cztery luki i sposób sprawdzenia na jednym zamówieniu, co realnie dociera do usługi.

Co dokładnie włącza się w panelu

Ścieżka w obecnym panelu to Wygląd i treści, Wygląd sklepu, Edycja szablonu graficznego, a potem Edytuj układ i styl szablonu. W edytorze wchodzisz w Integracje, w sekcji Wbudowane klikasz pozycję o nazwie Google Analytics and Google Tag Manager Analytics i w pole Identyfikator pomiaru Google Analytics wklejasz identyfikator z formatu G-. Zmiany zapisujesz.

W poprzedniej wersji panelu droga prowadzi przez Wygląd i treści, Wygląd sklepu, Obecny szablon graficzny. Sklepy na szablonie Storefront i sklepy na szablonie RWD mają osobne instrukcje, więc zanim zaczniesz szukać pola, ustal, na czym stoi dany sklep. Instrukcja Shopera była aktualizowana 11 czerwca 2026.

Nazwa bloku jest tu ważniejsza, niż wygląda. Jedno miejsce w szablonie obsługuje zarówno samo GA4, jak i kontener Menedżera tagów Google. Do tego wrócimy osobno, bo właśnie stąd bierze się najczęstsze podwójne liczenie zamówień.

Czternaście zdarzeń, które wychodzą z integracji

Dokumentacja Shopera wymienia czternaście typów zdarzeń i przypisane do nich parametry. Katalog zaczyna się od page_view, które niesie page_location i page_referrer, oraz od view_search_results z parametrem search_term i opcjonalnym q_. Dalej idą zdarzenia produktowe: view_item_list i select_item z items, item_list_name i item_list_id, a także view_item, add_to_cart, remove_from_cart, add_to_wishlist i view_cart, z których każde niesie currency, items i value.

Lejek checkoutowy to begin_checkout z coupon, currency, items i value, potem add_shipping_info z shipping_tier oraz add_payment_info z payment_type. Zamknięcie to purchase, które jako jedyne ma value oznaczone w dokumentacji jako parametr wymagany, a obok tego affiliation, coupon, currency, items, transaction_id, shipping i tax.

Ostatnie zdarzenie na liście, user_engagement z parametrem engagement_time_msec, jest opisane jako wysyłane okresowo, gdy aplikacja działa na pierwszym planie. To zdarzenie aplikacyjne i w sklepie internetowym nie ma czego mierzyć. Jego obecność pokazuje, że lista jest w dużej części kopią ogólnego katalogu GA4, a nie opisem zachowania konkretnego sklepu.

Czego na tej liście nie ma

Pierwsza luka to zwroty. Google traktuje refund jako pełnoprawne zdarzenie e-commerce, z własnym zestawem parametrów i własnym miejscem w raporcie. W katalogu Shopera tego zdarzenia nie ma. Skutek jest policzalny: klient zwraca towar, pieniądze wracają na konto, a w GA4 przychód zostaje nietknięty. Sklep, który zwraca kilka procent zamówień, przez cały rok raportuje sprzedaż, której nie było.

Druga luka to promocje. Zdarzenia view_promotion i select_promotion nie występują w katalogu, więc baner na stronie głównej i siatka rabatowa nie mają swojego pomiaru. Wiesz, ile sprzedałeś, ale nie wiesz, ile z tego sprzedał konkretny banner.

Trzecia luka dotyczy pola items. Dokumentacja opisuje parametry na poziomie zdarzenia i wymienia items jako całość, bez rozbicia na pola produktu. Google po swojej stronie wymaga w tablicy items tylko item_id albo item_name, dopuszcza do 27 parametrów niestandardowych na element i maksymalnie 200 elementów w tablicy. W praktyce oznacza to, że marka, kategoria, wariant i rabat mogą docierać albo nie docierać, zależnie od tego, co platforma wkłada do środka. Tego nie rozstrzygniesz z dokumentacji. Sprawdzasz to w DebugView na jednym zdarzeniu view_item.

Czwarta luka to rejestracja konta. Zdarzenia sign_up i login nie są wysyłane, więc przyrost bazy klientów widać w GA4 tylko przez zdarzenie niestandardowe po stronie GTM.

Ten sam blok ustawień obsługuje GTM

Wracamy do nazwy z panelu. Skoro jedno pole przyjmuje identyfikator GA4 i obsługuje też kontener Menedżera tagów, w wielu sklepach wpisano tam oba identyfikatory, a w kontenerze dodatkowo stoi tag GA4 z e-commerce. Wtedy purchase leci dwa razy, z tej samej strony potwierdzenia, w tej samej sekundzie.

Zasada jest jedna: zdarzenie purchase ma mieć jedno źródło. Albo integracja, albo tag w kontenerze. Jeśli potrzebujesz zdarzeń, których integracja nie wysyła, dodawaj w GTM wyłącznie te brakujące i nie duplikuj zakupu.

Drugi mechanizm, który częściowo maskuje problem, to transaction_id. Google usuwa duplikaty purchase o tym samym identyfikatorze transakcji, ale tylko dla strumieni internetowych. Działa to też w drugą stronę: jeśli integracja wyśle purchase z pustym transaction_id, wszystkie takie zdarzenia zostaną potraktowane jako jedno. Pusty ciąg w tym polu jest gorszy niż brak integracji.

Zakup: co musi być w zdarzeniu

Dokumentacja Shopera oznacza value jako parametr wymagany. Po stronie Google dochodzą trzy warunki: currency ustawiona na poziomie zdarzenia, gdy wysyłasz value, items z co najmniej item_id albo item_name oraz liczba, nie tekst, w polach kwotowych. Zdarzenie, któremu brakuje wymaganego parametru, jest traktowane jako zdarzenie niestandardowe i nie pojawia się w raporcie Sprzedaż e-commerce wcale. Nie pojawia się z błędem, po prostu nie ma go w tabeli.

Osobna sprawa to kwoty. shipping i tax są w zdarzeniu osobnymi polami, a value powinno być kwotą towarów. Kto w value wpisuje sumę z dostawą, ten porównuje w raporcie dwie różne rzeczy i przez resztę roku tłumaczy różnicę księgowości.

Jak sprawdzić, co realnie dociera

Test na kodzie nic nie daje. Potrzebne jest jedno prawdziwe zamówienie, najlepiej najtańszy produkt w sklepie, z pełną ścieżką od karty produktu do potwierdzenia.

• W GA4 otwórz Administracja, Wyświetlanie danych, DebugView i przejdź ścieżkę na telefonie z włączonym trybem debugowania.
• Sprawdź, czy w purchase są transaction_id, value, currency i items, a w środku items czy jest item_id.
• Sprawdź, czy item_category i item_brand w ogóle się pojawiają. Jeśli nie, raporty kategorii będą puste i nie naprawi tego żadne ustawienie w GA4.
• Odrzuć zgodę w banerze i powtórz przejście. Sprawdź, czy zdarzenia nadal lecą z parametrami zgody ustawionymi na denied. Integracja, która po odmowie wysyła pełne dane, jest problemem prawnym, nie technicznym.
• Porównaj liczbę zamówień i kwotę z panelem Shopera za jeden dzień, nie za miesiąc.

Zgody i polskie przepisy

Zapisywanie informacji na urządzeniu i odczytywanie ich reguluje art. 399 Prawa komunikacji elektronicznej, a standard zgody art. 400 tej ustawy, czytany razem z RODO. W praktyce pytanie brzmi, czy integracja platformy respektuje decyzję z banera, czy tylko ją omija. Odpowiedź daje test z odrzuceniem zgody, opisany wyżej, i podgląd żądań w narzędziach deweloperskich przeglądarki.

Druga warstwa to informacja w polityce prywatności. Jeśli zwroty i reklamacje mają być mierzone osobnym zdarzeniem, trzeba to opisać, zanim ktoś wdroży tag.

Co zrobić w tym tygodniu

• Ustal, czy purchase wysyła integracja, czy tag w GTM. Nie oba.
• Dodaj zdarzenie refund, jeśli sklep przyjmuje zwroty. Bez niego przychód w GA4 jest zawyżony o wartość zwrotów.
• Sprawdź w DebugView, czy items niesie item_category. Jeśli nie, zaplanuj uzupełnienie po stronie platformy albo w kontenerze.
• Zablokuj pusty transaction_id, zanim ktoś przypadkiem go wyśle.
• Powtórz test po każdej zmianie szablonu i po każdej zmianie metody płatności.