Wdrożenie GA4 w PrestaShop rzadko wywraca się na kodzie. Wywraca się na decyzjach podjętych przed kodem: ile usług, ile strumieni, którą metodą wgrać tag. Efekt złych decyzji widać dopiero po miesiącu, gdy raport przychodu pokazuje dwa razy więcej niż panel zamówień, a połowa konwersji ma źródło przelewy24.pl. Ten artykuł prowadzi przez wybór metody wdrożenia, konfigurację usługi i weryfikację danych, żeby nie trzeba było czyścić historii, której wyczyścić nie da się wcale.
Zasada jest prosta: jedna usługa GA4 na jedną domenę sklepu. Nie jedna na język, nie jedna na kraj, nie jedna „na testy". Usługa to granica danych — raporty e-commerce, ścieżki konwersji i modele atrybucji nie przechodzą między usługami. Jeśli rozbijesz sklep na trzy usługi, na zawsze stracisz możliwość zobaczenia jednego lejka.
Strumień danych to inna decyzja. Osobny strumień ma sens tylko wtedy, gdy masz osobną domenę i osobny właściciel raportu (inna spółka, inny budżet, inny dział). W praktyce:
Przed pierwszą linią kodu przygotuj: dostęp na poziomie Edytora do usługi GA4 (Czytelnik nie wystarczy do konfiguracji), dane FTP lub SSH, dostęp do back office z uprawnieniem SuperAdmin, opcjonalnie konto Google Tag Managera, dokładną wersję PrestaShop (1.6, 1.7 czy 8.x — to determinuje wybór metody) oraz listę bramek płatności i adresów IP biura.
Jedno ostrzeżenie, o którym klienci dowiadują się za późno: GA4 nie importuje danych historycznych z Universal Analytics. Zbieranie startuje w dniu utworzenia strumienia. Każdy tydzień zwłoki to trwała dziura w danych rok do roku. Pamiętaj też, że sprzedaż z marketplace'ów nie pojawi się w GA4 w ogóle — jeśli część obrotu robisz przez integrację Allegro z PrestaShop, te zamówienia zobaczysz wyłącznie w panelu zamówień.
Ścieżka: Administracja → Utwórz → Usługa. Nazwa niech zawiera domenę, nie nazwę firmy — przy trzech sklepach „Sklep GA4" nic nie mówi. Strefa czasowa: (GMT+01:00) Warszawa. Waluta: PLN. Waluta usługi nie jest kosmetyką — GA4 przelicza przychód z event.currency na walutę usługi po swoim kursie. Usługa w USD przy sklepie w PLN daje raport przychodu rozjechany o 3–4× i nie da się tego naprawić retroaktywnie.
Dalej: Strumienie danych → Sieć, podaj adres z HTTPS i bez końcowego slasha. Measurement ID w formacie G-XXXXXXXXXX znajdziesz na górze karty strumienia, po prawej. To jego wklejasz w moduł albo w tag GTM.
Ustawienia, które trzeba zmienić od razu, bo domyślne psują dane:
view_search_results i kliknięcia w pliki. Jeśli moduł wysyła własne search, a GA4 dokłada swoje, w raporcie masz dwa razy więcej wyszukiwań.payu.com, przelewy24.pl, paypal.com, secure.przelewy24.pl oraz domeny banków, jeśli używasz szybkich przelewów. Powrót z bramki bez tego wykluczenia zeruje pierwotne źródło i cała konwersja przypisuje się bramce — a wtedy raporty kampanii są bezwartościowe.Rekomendacja najpierw, opis potem. Sklep MŚP bez działu marketingu: dedykowany moduł GA4. Sklep z płatnymi kampaniami (Google Ads, Meta, Ceneo): GTM z data layer wypełnianym przez moduł — jedno miejsce do wpięcia kolejnych pikseli bez dotykania szablonów.
Wbudowany ps_googleanalytics zostawiaj tylko wtedy, gdy naprawdę wystarczy ci przychód i lista zdarzeń koszykowych. W wersjach dla PrestaShop 1.6 nie obsługuje protokołu GA4 w ogóle — tam wybór sprowadza się do GTM albo modułu z rynku.
Dwie pułapki techniczne. Pierwsza: własny motyw. Moduły analityczne stoją na hookach displayHeader, actionCartSave, displayOrderConfirmation i nadpisanych szablonach koszyka. Theme robiony na zamówienie regularnie wycina wywołania hooków z product.tpl albo checkout, i wtedy zdarzenie purchase nie wychodzi wcale, choć moduł jest zielony w konfiguracji. Zanim zgłosisz błąd do autora modułu, sprawdź listę hooków motywu — zakres i kolejność opisuje dokumentacja deweloperska PrestaShop.
Druga, nieprzekraczalna: jedna metoda naraz. Moduł GA4 z tym samym G-XXXXXXXXXX co tag w GTM to gwarantowane podwójne purchase — raport przychodu pokaże dokładnie 2× panel zamówień. Jeśli migrujesz z modułu na GTM, najpierw wyłącz moduł, potem publikuj kontener. Nie odwrotnie.
Jeśli po wdrożeniu planujesz feed produktowy i kampanie zakupowe, ustawienia zdarzeń warto zaplanować razem z nimi — kolejność pól w items i identyfikatory produktów muszą się zgadzać z feedem, co opisaliśmy w poradniku o reklamach produktowych w PrestaShop.
| Kryterium | ps_googleanalytics (wbudowany) | Google Tag Manager | Dedykowany moduł GA4 |
|---|---|---|---|
| Zakres zdarzeń | podstawowe e-commerce: view_item, add_to_cart, purchase | dowolny — tyle, ile sam zbudujesz | pełny zestaw GA4 + zwroty, kupony, checkout steps |
| Kontrola nad data layer | brak, struktura zaszyta w kodzie | pełna, ale trzeba źródło danych na stronie | częściowa, przez opcje w konfiguracji |
| Koszt | 0 zł | 0 zł za narzędzie, koszt w pracy | ok. 150–400 zł licencja |
| Czas wdrożenia | 1–2 h | 8–20 h przy pełnym e-commerce | 2–4 h plus testy |
| Ograniczenia | wsparcie GA4 zależne od wersji PrestaShop | wymaga osoby, która umie czytać Preview i DebugView | zależny od autora przy aktualizacjach PrestaShop |
Najkrótsza droga: Moduły → Menedżer modułów, szukasz „Google Analytics”, klikasz Konfiguruj, wklejasz identyfikator w formacie G-XXXXXXXXXX i zapisujesz. Jeśli w konfiguracji widzisz przełączniki User ID oraz anonimizacji IP, włącz User ID tylko wtedy, gdy w GA4 masz ustawioną strategię raportowania „Zaobserwowane i modelowane” lub „Zaobserwowane” — inaczej dodasz sobie tylko pole, którego nikt nie czyta. Anonimizacja IP w GA4 jest domyślna po stronie Google, więc przełącznik w starszych wersjach modułu bywa reliktem.
Co moduł zwykle wysyła sam: view_item, view_item_list, add_to_cart, remove_from_cart, begin_checkout, purchase. Czego zazwyczaj brakuje: add_to_wishlist, refund, login, sign_up, a często też add_payment_info i add_shipping_info. Brak refund boli najbardziej: przychód w GA4 nigdy nie zgodzi się z panelem zamówień, bo zwroty istnieją tylko w PrestaShop.
PrestaShop 1.6: jeśli moduł mówi jeszcze o „UA-” i „Universal Analytics”, nie kombinuj z podmianą ID. Wersje UA nie przyjmą identyfikatora G-. Realne opcje to podbicie modułu do wersji obsługującej gtag.js albo wdrożenie przez GTM z Opcji B. Warto przy tym policzyć, czy migracja sklepu nie jest tańsza niż łatanie — pomocne tło znajdziesz w przewodniku po wyborze między PrestaShop i WooCommerce.
Weryfikacja zajmuje 30 sekund. Otwórz źródło strony (Ctrl+U), poszukaj gtag/js?id=G- i policz wystąpienia. Musi być dokładnie jedno. Dwa oznaczają, że moduł i motyw (albo GTM) wgrywają tag równolegle — i właśnie tak rodzi się podwójny przychód.
| Zdarzenie GA4 | ps_googleanalytics | Trzeba dodać ręcznie |
|---|---|---|
| view_item | zwykle tak | nie |
| add_to_cart | zwykle tak | nie |
| begin_checkout | zwykle tak | nie |
| purchase | tak | nie |
| add_to_wishlist | nie | tak |
| login / sign_up | nie | tak |
| refund | nie | tak |
Kontener GTM wstawiaj z małego modułu na hookach displayHeader (snippet ) i displayBeforeBodyClosingTag lub displayAfterBodyOpeningTag (noscript). Edycja header.tpl w motywie działa do pierwszej aktualizacji motywu, potem tag znika bez ostrzeżenia. Listę hooków i ich kolejność znajdziesz w dokumentacji deweloperskiej PrestaShop.
W GTM potrzebujesz jednego tagu GA4 Configuration (wyzwalacz: All Pages) i osobnych tagów GA4 Event dla każdego zdarzenia, każdy na wyzwalaczu Custom Event o nazwie zgodnej z event w pushu. Parametry mapujesz przez zmienne typu Data Layer Variable, np. ecommerce.items, ecommerce.value, ecommerce.transaction_id.
dataLayer = window.dataLayer || [];
dataLayer.push({
event: 'view_item',
ecommerce: {
currency: 'PLN',
value: 149.00,
items: [{
item_id: 'SKU-1042',
item_name: 'Plecak Trekking 30L',
item_brand: 'Alpex',
item_category: 'Plecaki',
price: 149.00,
quantity: 1
}]
}
});dataLayer.push({
event: 'purchase',
ecommerce: {
transaction_id: '2041',
value: 149.00,
tax: 27.87,
shipping: 15.00,
currency: 'PLN',
items: [{ item_id: 'SKU-1042', item_name: 'Plecak Trekking 30L', price: 149.00, quantity: 1 }]
}
});Kolejność jest krytyczna: dataLayer.push musi znaleźć się w kodzie przed snippetem GTM. Jeśli push wykonuje się po nim, tag odpali się bez parametrów i w raporcie zobaczysz konwersje o wartości 0. W PrestaShop oznacza to priorytet hooka niższy niż hook wgrywający kontener.
GTM to przerost formy, gdy nie prowadzisz kampanii płatnych ani remarketingu i masz jedno źródło ruchu. Jeśli jednak myślisz o reklamach produktowych w PrestaShop, warstwa danych zwróci się przy pierwszej kampanii.
Opis w sklepie z modułami nie mówi nic o jakości implementacji. Oceniaj po czterech rzeczach: pełna lista zdarzeń e-commerce (łącznie z refund, add_shipping_info, add_payment_info), obsługa Consent Mode v2 z default i update, wsparcie dla server-side tagging, jeśli planujesz własny kontener, oraz zgodność z One Page Checkout. Ten ostatni punkt wykłada najwięcej modułów: przy checkoucie jednostronicowym kroki koszyka nie generują przeładowań, więc zdarzenia muszą lecieć na eventach JS, nie na hookach szablonu.
Pytania do autora modułu przed zakupem, najlepiej mailem, żeby zostało na piśmie:
value w purchase to kwota brutto czy netto, i czy da się to przełączyć?refund przy zwrocie towaru i przy anulowaniu zamówienia, czy tylko w jednym z tych przypadków?value, czy jest osobno w shipping?value, czy trafiają w coupon?Własny mikromoduł ma sens, gdy potrzebujesz 4–6 zdarzeń i nic więcej. Kilka godzin pracy dewelopera bez abonamentu wygrywa z płatną wtyczką, która i tak wymaga konfiguracji. Podejście „mały moduł na hookach zamiast kombajnu” sprawdza się też w innych obszarach, na przykład przy integracji SMS po zamówieniu.
Czerwona flaga: moduł, który wstrzykuje skrypt przez override kontrolera FrontController albo nadpisanie plików motywu, zamiast rejestrować hooki. Taki kod zderzy się z każdym innym modułem robiącym override tej samej klasy, a przy aktualizacji PrestaShop trafisz na biały ekran.
Raport Monetyzacja w GA4 nie zgaduje. Jeśli nie wyślesz zdarzenia o odpowiedniej nazwie, sekcja zostanie pusta — nawet jeśli sklep sprzedaje. Nazwy są zarezerwowane i muszą być zapisane dokładnie tak, jak w specyfikacji GA4.
Pełna lista zdarzeń e-commerce, którą warto wdrożyć w PrestaShop:
Zdarzenie purchase ma sztywny zestaw parametrów: transaction_id, value, currency, tax, shipping oraz tablica items[], w której każda pozycja zawiera item_id, item_name, price i quantity. Brak currency to najczęstszy błąd — GA4 odrzuca wtedy wartość transakcji i przychód zostaje na zerze.
Najważniejszy szczegół: item_id musi być identyczny z ID produktu w feedzie do Google Merchant Center. W PrestaShop feed często używa formatu id_product-id_product_attribute, a warstwa danych wysyła samo id_product. Skutek: Google Ads nie potrafi połączyć konwersji z produktem, raporty kampanii produktowych pokazują sprzedaż bez przypisania do SKU. Zasady budowy feedu opisaliśmy w poradniku o reklamach produktowych w PrestaShop.
Na koniec: oznacz purchase jako kluczowe zdarzenie (key event) w Administracja → Zdarzenia. GA4 nie robi tego automatycznie w każdej konfiguracji, a bez tego oznaczenia zakup nie policzy się jako konwersja ani w GA4, ani po importzie do Google Ads.
| Zdarzenie | Moment w PrestaShop | Wymagane parametry |
|---|---|---|
| view_item_list | Listing kategorii, wyszukiwarka | item_list_name, items[] |
| view_item | Karta produktu | currency, value, items[] |
| add_to_cart | Dodanie do koszyka (AJAX) | currency, value, items[] |
| view_cart | Strona koszyka | currency, value, items[] |
| begin_checkout | Start checkoutu | currency, value, items[] |
| add_shipping_info | Wybór przewoźnika | shipping_tier, currency, value, items[] |
| add_payment_info | Wybór płatności | payment_type, currency, value, items[] |
| purchase | order-confirmation | transaction_id, value, currency, tax, shipping, items[] |
| refund | Zmiana statusu na zwrot | transaction_id, value, currency, items[] |
Pierwszy: brutto czy netto. PrestaShop trzyma w tabeli orders dwa pola — total_paid (z VAT) i total_paid_tax_excl (bez VAT). Moduły GA4 wybierają jedno z nich, zwykle bez pytania. Jeśli w value wyląduje netto, a w tax kwota podatku, GA4 pokaże przychód niższy o dokładnie stawkę VAT. Przy 23% i obrocie 200 000 zł miesięcznie to 37 400 zł różnicy — co miesiąc, systematycznie. Odchylenie jest stałe, więc łatwo je rozpoznać: podziel przychód z panelu zamówień przez przychód z GA4. Wynik około 1,23 oznacza, że wysyłasz netto.
Wybierz jedną definicję i trzymaj się jej. Rekomendacja: value = brutto (total_paid), tax = total_paid_tax_incl - total_paid_tax_excl, shipping = total_shipping w tej samej konwencji co value. Ceny w items[] też muszą być brutto, inaczej suma pozycji nie zgodzi się z value.
Drugi: strona order-confirmation. Kontroler jest normalną stroną, więc F5 albo powrót z bankowości elektronicznej odpala purchase po raz drugi. Bramki płatnicze bywają tu wyjątkowo szkodliwe, bo część z nich przekierowuje na potwierdzenie dwa razy. Zabezpieczenia, które działają:
$_SESSION['ga4_sent'][$id_order] = true i sprawdzaj przed renderem$order->valid == 1, bez tego łapiesz nieopłacone koszykiorder z datą wysłania zdarzeniaTrzeci problem, formalnie poboczny, praktycznie równie kosztowny: AJAX-owy koszyk i One Page Checkout. Nasłuch przypisany przez document.querySelector przy ładowaniu strony przestaje działać po przebudowie DOM przez prestashop.on('updateCart'). Używaj delegacji zdarzeń na document albo reinicjalizuj nasłuch w handlerze tego eventu — pełna lista hooków front-endowych jest w dokumentacji dla deweloperów PrestaShop.
Consent Mode v2 to cztery sygnały przekazywane do tagów Google przed jakimkolwiek pomiarem:
_ga, czyli identyfikacja użytkownika w GA4; bez zgody sesje są anonimowe i bez ciągłościPodział basic vs advanced ma realny wpływ na liczby. W trybie basic tagi nie ładują się w ogóle do momentu zgody — brak zgody oznacza zero danych o tej wizycie. W trybie advanced tagi ładują się od razu, ale bez zgody wysyłają wyłącznie sygnały bezciasteczkowe. Google używa ich do modelowania konwersji, więc część danych wraca w raportach jako estymacja. Przy współczynniku akceptacji 60% advanced potrafi odzyskać wyraźną część brakujących konwersji, basic nie odzyskuje nic. Modelowanie wymaga jednak ruchu — małe sklepy mogą progu nie osiągnąć.
Kolejność wywołań jest krytyczna: najpierw gtag('consent', 'default', {...}) ze wszystkim ustawionym na denied, dopiero potem kontener GTM lub kod gtag.js, a po decyzji użytkownika gtag('consent', 'update', {...}). W PrestaShop najbezpieczniejszym miejscem na blok default jest szablon head.tpl motywu, powyżej hooka displayHeader — moduły wstrzykują tagi właśnie tam.
Objaw pominięcia tego kroku wygląda niewinnie: Tag Assistant świeci na zielono, zdarzenia lecą, a listy odbiorców w Google Ads stoją w miejscu i remarketing nie ma kogo wyświetlać. Google od marca 2024 wymaga Consent Mode v2 dla ruchu z EOG, a podstawą prawną są RODO i art. 173 Prawa telekomunikacyjnego — zgoda na cookies niefunkcjonalne musi być aktywna i udzielona przed ich zapisem. Domyślnie zaznaczony checkbox nie jest zgodą.
Kolejność ma znaczenie. Realtime mówi, czy tag w ogóle strzela. DebugView mówi, czy strzela poprawnie. Odwrotna kolejność kończy się grzebaniem w parametrach zdarzenia, którego GA4 nigdy nie odebrał.
Krok 1. Raport Czas rzeczywisty. Wejdź na sklep z telefonu w sieci komórkowej (nie z firmowego Wi-Fi, jeśli filtrujesz ruch wewnętrzny po IP). W GA4: Raporty → Czas rzeczywisty. Twoja sesja powinna pojawić się w 10-30 sekund. Sprawdź licznik użytkowników w ostatnich 30 minutach i kartę zdarzeń — musi być page_view i session_start. Jeśli licznik zostaje na zerze, tag się nie ładuje: sprawdzaj kolejność, nie parametry.
Krok 2. DebugView. Włącz rozszerzenie Google Analytics Debugger w Chrome albo tryb Preview w GTM (GTM automatycznie dokleja debug_mode). W GA4: Administracja → DebugView. Klikaj po zdarzeniach na osi czasu i czytaj parametry każdego z nich. To jedyne miejsce, gdzie zobaczysz zawartość items[] przed przetworzeniem.
Krok 3. Testowe zamówienie. Pełna ścieżka: view_item → add_to_cart → begin_checkout → add_payment_info → purchase. Na purchase porównaj transaction_id z numerem zamówienia w PrestaShop oraz value co do groszy. Ustal raz, czy liczysz z wysyłką i czy netto, czy brutto — i trzymaj się tego. Jeśli sprzedajesz przez wiele kanałów, sprawdź też, że zamówienia z integracji nie generują zdarzeń frontendowych; przy integracji Allegro z PrestaShop przychód z marketplace nie ma prawa trafić do GA4 tą drogą.
Krok 4. Po 24-48 h zestaw przychód w GA4 z raportem sprzedaży w PrestaShop za ten sam zakres. Rozjazd 2-5% to norma (blokery, odrzucone zgody, sesje wygasłe). Powyżej 10% to błąd wdrożenia, nie "specyfika GA4".
Pułapka: DebugView pokazuje wyłącznie urządzenia w trybie debug. Pusty ekran po wyłączeniu rozszerzenia nie oznacza awarii — oznacza, że nie masz aktywnej sesji debugowania.
Cztery objawy odpowiadają za większość zgłoszeń, które do nas trafiają. Każdy ma inną przyczynę i inne miejsce sprawdzenia.
Awaria 1: przychód w GA4 dwa razy wyższy niż w panelu zamówień. Prawie zawsze dwa źródła tagu — moduł GA4 w PrestaShop i równolegle GTM — albo purchase wywoływany dwa razy na tej samej stronie potwierdzenia (odświeżenie strony też się liczy). Sprawdzenie: Ctrl+U na dowolnej podstronie i szukaj swojego G-XXXXXXX. Więcej niż jedno wystąpienie to diagnoza. Drugie miejsce: DebugView i liczba zdarzeń purchase w jednej sesji.
Awaria 2: transakcje są, produktów nie ma. Raport "Zakupy w e-commerce" pusty, przychód widoczny. Przyczyna: brak tablicy items[] albo zły format (ceny jako string z przecinkiem, brak item_id, brak quantity). Sprawdzenie: DebugView na zdarzeniu purchase, rozwiń items. Jeśli szablon nadpisuje hooki motywu, warto zajrzeć do dokumentacji PrestaShop dla deweloperów i potwierdzić, w którym hooku faktycznie renderuje się potwierdzenie zamówienia.
Awaria 3: cały ruch jako (direct)/(none). Bramka płatności nie została dodana do listy niechcianych poleceń w ustawieniach strumienia danych, więc powrót z płatności zeruje źródło. Druga przyczyna: parametry UTM gubione przy przekierowaniu (kanoniczne przekierowanie, przepisanie URL, wymuszenie HTTPS). To boli zwłaszcza przy płatnych kampaniach — szerzej opisaliśmy to w tekście o reklamach produktowych w PrestaShop.
Awaria 4: spadek użytkowników o 30-70% zaraz po wdrożeniu banera zgody. Zwykle consent default ustawiony po update albo tag całkowicie zablokowany do momentu decyzji. Sprawdzenie: GTM Preview, karta Consent, kolejność wywołań.
| Objaw | Prawdopodobna przyczyna | Gdzie sprawdzić w 5 minut |
|---|---|---|
| Przychód ~2x wyższy niż w PrestaShop | Dwa źródła tagu (moduł + GTM) lub duplikat purchase | Źródło strony: liczba wystąpień G-ID; DebugView: liczba purchase w sesji |
| Transakcje bez produktów | Brak lub zły format items[] | DebugView → zdarzenie purchase → parametr items |
| Ruch prawie cały jako (direct)/(none) | Bramka płatności nie wykluczona z poleceń; utrata UTM przy przekierowaniu | Strumień danych → Lista niechcianych poleceń; test linku z UTM i podgląd URL po przekierowaniach |
| Nagły spadek użytkowników po banerze zgody | Zła kolejność consent default/update lub tag blokowany przed decyzją | GTM Preview → karta Consent → kolejność wywołań |
| transaction_id inny niż numer zamówienia | Szablon podaje ID koszyka lub referencję zamiast ID zamówienia | DebugView: purchase → transaction_id vs panel PrestaShop |
Moduł analityczny i kontener GTM wysyłają zdarzenia na ten sam Measurement ID.
Jak wykryć: W raporcie Realtime widać podwójne page_view na jedno wejście. W kodzie źródłowym strony szukaj frazy gtag( oraz googletagmanager.com/gtm.js — jeśli oba są obecne i mają to samo G-ID, dane są zdublowane. Porównaj liczbę transakcji GA4 z liczbą zamówień w panelu PrestaShop za ten sam dzień.
Jak naprawić: Zostaw jedną metodę. Wyłącz moduł w Moduły → Google Analytics albo usuń tag GA4 z kontenera GTM. Dane z okresu dublowania pozostaną błędne — GA4 nie pozwala usunąć ani przeliczyć zebranych zdarzeń, więc odnotuj datę naprawy i traktuj wcześniejszy okres jako niewiarygodny.
Bramki płatności nie są na liście wykluczonych źródeł poleceń, więc przejmują atrybucję konwersji.
Jak wykryć: W raporcie Traffic acquisition pojawiają się źródła typu secure.przelewy24.pl, paypal.com, secure.payu.com z wysokim współczynnikiem konwersji i prawie zerowym czasem sesji. To ta sama sesja, która wróciła z płatności i została policzona jako nowa.
Jak naprawić: Administracja → Strumienie danych → wybrany strumień → Konfiguruj ustawienia tagu → Wyklucz niepożądane odesłania. Dodaj domeny wszystkich bramek, których używa sklep, w tym subdomeny operatora. Zmiana działa od momentu zapisania, nie wstecz.
Okno przechowywania danych zostało na domyślnych 2 miesiącach.
Jak wykryć: Administracja → Przechowywanie danych. Jeśli widać „2 miesiące”, każda analiza rok do roku i każde porównanie sezonu z poprzednim sezonem jest niemożliwa. Objawia się też pustymi wynikami w Eksploracjach przy dłuższym zakresie dat.
Jak naprawić: Przełącz na 14 miesięcy (maksimum w wersji bezpłatnej) i zapisz. To pierwsza rzecz do zrobienia po utworzeniu usługi, bo dane usunięte po 2 miesiącach nie wracają.
Ruch z biura, agencji i z panelu administracyjnego wlicza się do statystyk.
Jak wykryć: Nieproporcjonalnie dużo sesji z miasta, w którym siedzi firma. Wysoka liczba wejść na karty produktów bez żadnych zdarzeń koszykowych. Filtr Internal Traffic utworzony, ale zostawiony w stanie Testing — wtedy nie wyklucza niczego, tylko oznacza ruch do podglądu.
Jak naprawić: Administracja → Strumienie danych → Konfiguruj ustawienia tagu → Definiuj ruch wewnętrzny: dodaj adresy IP biura i agencji. Potem Administracja → Filtry danych → zmień stan filtra Internal Traffic z Testing na Active. Same reguły IP bez aktywnego filtra nic nie robią.
Własny motyw nadpisuje szablony i wycina hooki, na których stoi moduł analityczny.
Jak wykryć: Moduł skonfigurowany, G-ID wklejony, a w kodzie źródłowym strony nie ma śladu gtag lub brakuje go tylko na wybranych stronach (najczęściej na potwierdzeniu zamówienia). Sprawdź, czy w katalogu motywu istnieją nadpisania szablonów odpowiedzialnych za stopkę i nagłówek.
Jak naprawić: Porównaj szablony motywu z szablonami motywu domyślnego i przywróć brakujące wywołania hooków. Jeśli motyw jest mocno przerobiony, pewniejszym rozwiązaniem jest wstawienie kontenera GTM przez własny moduł podpięty do hooka nagłówka — mniej zależności od cudzych szablonów. Zasady pracy z hookami opisuje dokumentacja dla deweloperów PrestaShop.
Waluta usługi i strefa czasowa zostały na domyślnych ustawieniach amerykańskich.
Jak wykryć: Raport Monetyzacja pokazuje przychód w USD przy sklepie sprzedającym w złotówkach, a szczyty ruchu wypadają w nocy. Sprawdź Administracja → Szczegóły usługi.
Jak naprawić: Ustaw strefę Europe/Warsaw i walutę PLN. Uwaga: zmiana waluty nie przelicza danych historycznych — wcześniejsze przychody zostaną w starej walucie, więc raporty będą mieszać jednostki na granicy zmiany.
G-XXXXXXXXXX, do znalezienia w Administracja → Strumienie danych → wybrany strumień. Nie mieszaj go z identyfikatorem kontenera GTM (GTM-XXXXXXX).Najdroższe błędy w GA4 to nie literówki w kodzie, a decyzje architektoniczne: dwie metody wdrożenia naraz, bramki płatności kradnące atrybucję i przechowywanie danych zostawione na 2 miesiącach. Wszystkie trzy mają wspólną cechę — nie da się ich naprawić wstecz, bo GA4 nie przelicza zebranych zdarzeń. Dlatego kolejność jest taka: najpierw ustawienia usługi, potem wybór jednej metody, na końcu kod. Weryfikacja przez porównanie transakcji GA4 z panelem zamówień to jedyny test, który naprawdę coś mówi.
Nie. GA4 to inny model danych — oparty na zdarzeniach, nie na sesjach — i nie ma mechanizmu importu historii z Universal Analytics. Od dnia utworzenia usługi zaczynasz zbierać od zera. Jeśli potrzebujesz starych danych do porównań, jedyna droga to wyeksportowanie ich osobno, póki jeszcze są dostępne.
Sklep MŚP bez działu marketingu i bez płatnych kampanii: wbudowany ps_googleanalytics. Wdrożenie zajmuje kilkanaście minut, a podstawowa ścieżka e-commerce zostaje zmierzona. Sklep z płatnymi kampaniami, remarketingiem albo kilkoma narzędziami analitycznymi: GTM, bo daje kontrolę nad warstwą danych i pozwala obsłużyć wszystkie tagi z jednego miejsca. Moduł dedykowany ma sens, gdy zależy Ci na pełnym zakresie zdarzeń bez pisania kodu i akceptujesz koszt licencji.
Zwykle nie. Jeden strumień na jedną usługę wystarcza, a język rozdzielisz wymiarem w raportach. Osobne strumienie mają sens tylko wtedy, gdy wersje językowe to faktycznie osobne biznesy z osobnym raportowaniem i osobnymi zespołami. Przy subdomenach sprawdź natomiast konfigurację pomiaru między domenami — bez niej przejście z pl. na de. zostanie policzone jako nowa sesja z odesłania.
Otwórz kod źródłowy strony i policz wystąpienia gtag( oraz googletagmanager.com. Sprawdź to na co najmniej trzech typach stron: głównej, karcie produktu i potwierdzeniu zamówienia. Równolegle podejrzyj raport Realtime w GA4 — dwa page_view na jedno Twoje wejście to jednoznaczny sygnał dublowania.
Trzy najczęstsze przyczyny: tag wysyłany dwiema metodami jednocześnie, zdarzenie purchase odpalane przy każdym odświeżeniu strony potwierdzenia zamówienia oraz brak deduplikacji po identyfikatorze transakcji. Zacznij od sprawdzenia, czy skrypt nie ładuje się dwukrotnie. Potem upewnij się, że każde zdarzenie zakupu przekazuje unikalny numer zamówienia.
Da się, ale nie przez dołączony moduł — w 1.6 obsługuje on Universal Analytics, którego już nie ma. Praktyczna droga to GTM wstawiony do szablonów motywu albo moduł zewnętrzny z obsługą GA4. Warto przy okazji rozważyć aktualizację: 1.6 nie dostaje poprawek bezpieczeństwa i każda kolejna integracja będzie tu droższa niż na 8.x.
Wbudowany moduł na standardowym motywie: kilkanaście minut plus czas na ustawienia usługi. GTM z własną warstwą danych i pełnym e-commerce: zwykle 1–3 dni roboczych, zależnie od tego, jak przerobiony jest motyw. Do każdego wariantu doliczaj 3–7 dni na weryfikację danych przed podejmowaniem decyzji biznesowych — pierwsze liczby prawie nigdy nie są od razu poprawne.
Jeśli chcesz mieć pewność, że dane w GA4 zgadzają się z panelem zamówień, sprawdzimy Twoją konfigurację i wskażemy, co wymaga poprawy. Napisz do nas — zaczniemy od audytu tego, co już działa.