GA4 w PrestaShop – diagnoza w 15 minut

Diagnozę robisz w przeglądarce, nie w panelu administracyjnym PrestaShop. Otwórz trzy adresy: stronę główną, kartę produktu i koszyk z co najmniej jednym produktem. Na każdym z nich uruchom Google Tag Assistant, a w GA4 włącz tryb debug (parametr debug_mode=1 w adresie albo rozszerzenie Google Analytics Debugger).

• GA4 DebugView – czy w ciągu kilku sekund pojawiają się zdarzenia page_view, view_item, add_to_cart? Równolegle patrz w GA4 → Raporty → Realtime: sprawdź, czy widzisz swoją sesję i poprawną nazwę strony.
• Źródło strony (Ctrl+U) – wyszukaj frazę gtag oraz G-. Jedno wywołanie gtag('config', ...) to norma. Dwa różne identyfikatory G- oznaczają dublowanie tagu.
• Stary Universal Analytics – szukaj analytics.js i prefiksu UA-. Jeśli są obecne, ktoś nadal odpala dwa systemy równolegle i raporty się rozjadą.
• Podwójny GTM – sprawdź, czy skrypt gtm.js nie ładuje się dwa razy i czy w kontenerze nie ma jednocześnie tagu GA4 oraz ręcznego gtag.js w motywie.
• E-commerce – w DebugView kliknij zdarzenie i rozwiń parametry. items[] musi zawierać produkty, currency wartość PLN, a value liczbę, nie pusty string.

Zadaj sobie trzy pytania kontrolne: kto ma dostęp do usługi GA4 i na jakim poziomie uprawnień, czy istnieje konto Google Tag Manager, czy checkout jest niestandardowy (jednoetapowy, wieloetapowy, z zewnętrzną bramką płatności). Odpowiedzi decydują, czy wdrażasz kod ręcznie, czy przez GTM.

Jeśli to Twoje pierwsze wdrożenie, zacznij od materiału GA4 w PrestaShop: wdrożenie bez dublowania danych i wróć tutaj po diagnozie.

Ręczne wdrożenie kodu GA4 w PrestaShop 8 i 9 (gtag.js krok po kroku)

Snippet wklejasz do pliku themes/[motyw]/templates/_partials/head.tpl – to wciąż Smarty, mimo że pozostałe szablony motywu w PrestaShop 8 i 9 są w Twig. Kod umieść bezpośrednio przed </head>.

<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXXXXX', { send_page_view: true });
</script>

Kolejność ma znaczenie: najpierw biblioteka gtag.js, potem gtag('js', new Date()), na końcu gtag('config', ...). Identyfikator G-XXXXXXXXXX podmieniasz na własny z GA4 → Administracja → Strumienie danych. Nie wklejaj tego samego bloku drugi raz w innym pliku ani w module.

Czego nie robić. Nie wstawiaj kodu przez edytor „Kod HTML” w back office ani przez moduły typu „dodaj kod do head”. Te miejsca rzadko pokazują, czy tag już istnieje, więc właśnie tam najczęściej powstaje duplikat. Nie edytuj też motywu bazowego bez kopii.

Motyw potomny. W PrestaShop 8 i 9 skopiuj katalog motywu, w pliku config/theme.yml wskaż pole parent na motyw bazowy i ustaw kopię jako motyw aktywny. Wtedy aktualizacja motywu nadrzędnego nie usunie Twoich zmian w _partials/head.tpl.

Zdarzenia e-commerce. Widok produktu i dodanie do koszyka wstaw w szablonie karty produktu (templates/catalog/product.tpl lub partials miniaturek). Wartości pobieraj z obiektu Smarty, np. {$product.name|escape:'javascript'}, zamiast wpisywać je na sztywno – nazwy dostępnych zmiennych różnią się między motywami, więc sprawdź je w swoim szablonie.

<script>
window.dataLayer = window.dataLayer || [];
dataLayer.push({ ecommerce: null });
dataLayer.push({
  event: 'view_item',
  ecommerce: {
    currency: 'PLN',
    value: 149.00,
    items: [{ item_id: '12345', item_name: 'Nazwa produktu', price: 149.00, quantity: 1 }]
  }
});
</script>

Cache i CDN. Po edycji pliku wejdź w Parametry zaawansowane → Wydajność → Wyczyść pamięć podręczną, a następnie wyczyść warstwę CDN. Bez tego DebugView pokaże stary kod i uznasz, że wdrożenie nie działa. Struktura motywów jest opisana w dokumentacji dla deweloperów PrestaShop.

Kod klasyczny vs moduł Google Integrator – co wybrać w 2026

Rekomendacja jest jednoznaczna: podstawowy sklep B2C, jeden język, jedna waluta, standardowy checkout – bierz moduł Google Integrator i zweryfikuj go w DebugView. Sklep z niestandardową ścieżą zakupu – pisz kod ręcznie albo przez GTM.

Co integrator robi automatycznie: mapuje koszyk i zamówienia na zdarzenia GA4 (add_to_cart, begin_checkout, purchase), obsługuje kontener GTM i konwersje Google Ads z panelu, bez dotykania plików motywu. To oszczędza czas, ale tylko dopóki ścieżka zakupu wygląda standardowo.

Kiedy integrator nie wystarcza: zdarzenia niestandardowe (np. wysłanie zapytania ofertowego), wyceny B2B po zalogowaniu, checkout wieloetapowy z własnym krokiem dostawy, sklepy wielojęzyczne i wielowalutowe, gdzie currency i value trzeba przeliczać per kontekst. Wtedy moduł raportuje uśrednione dane, a Ty nie wiesz, która waluta zawyża przychód.

Dublowanie danych. Najczęstszy scenariusz to integrator plus ręczny gtag.js zostawiony w motywie po poprzednim wdrożeniu. Rozpoznasz to tak: Tag Assistant pokazuje dwa tagi GA4, w DebugView to samo purchase wpada dwa razy, a liczba konwersji w GA4 jest około dwukrotnie wyższa niż liczba zamówień w PrestaShop za ten sam dzień. Różnica 1,8–2,0× to dublowanie, nie „geografia”. Naprawa: wyłącz tag GA4 w module albo usuń ręczny snippet – nigdy nie zostawiaj obu źródeł jednocześnie.

Zanim wybierzesz, policz koszt zdarzeń, których naprawdę potrzebujesz. Przy kampaniach zakupowych sprawdź też reklamy produktowe w PrestaShop: kompletny poradnik – bez poprawnych konwersji optymalizacja budżetu działa w ciemno.

Konfiguracja Google Integrator: GA4, GTM i Google Ads w panelu PrestaShop

Cała konfiguracja to pięć kroków. Wykonaj je w tej kolejności — przestawienie kolejności zwykle kończy się dublowaniem danych.

1. W GA4: Administracja → Utwórz usługę → Właściwość. Ustaw strefę Europe/Warsaw i walutę PLN. Waluty nie zmienisz wstecz — historia zostanie przeliczona tylko pozornie.
2. Administracja → Strumienie danych → Sieć. Dodaj adres sklepu i skopiuj identyfikator pomiaru w formacie G-XXXXXXXXXX.
3. Panel PrestaShop → Moduły → Menedżer modułów → Google Integrator → Konfiguruj. W części wersji ten sam moduł występuje pod nazwą Google Analytics — sprawdź nazwę i hook, na którym pracuje.
4. Wklej G-XXXXXXXXXX w polu GA4 i zapisz.
5. Wyczyść cache (Zaawansowane → Wydajność) i sprawdź, czy w GA4 → Raporty → Realtime widzisz swoją wizytę.

Przełącznik	Ustawienie	Dlaczego
Universal Analytics	Wyłącz	UA nie przyjmuje danych, a włączony dokłada żądania i miesza z G-.
Google Analytics 4	Włącz, wklej G-	Główne źródło danych o ruchu i e-commerce.
Google Tag Manager	Tylko jeśli budujesz tagi w GTM	gtag.js w motywie plus kontener = dwa page_view.
Google Ads	Wyłącz, gdy importujesz konwersje z GA4	Osobny tag AW- plus import z GA4 = podwójne konwersje.

Kontener GTM (GTM-XXXXXXX) podłączaj tylko wtedy, gdy naprawdę w nim pracujesz. Po wklejeniu identyfikatora otwórz Tag Assistant → Preview i przetestuj koszyk oraz zamówienie, a kontener opublikuj dopiero po testach.

Konwersje w Google Ads masz w dwóch wariantach. Wariant A: import z GA4 (Google Ads → Cele → Konwersje → Import → GA4 → zdarzenie purchase) — szybki, ale dziedziczy model atrybucji i okno konwersji z GA4. Wariant B: dedykowany tag konwersji AW- przez GTM — własne okno i model, ale osobne wdrożenie i osobna zgoda. Nigdy nie włączaj obu dla purchase: konwersje policzą się podwójnie, a strategia np. tROAS uczy się na zawyżonym ROAS.

Uprawnienia: właścicielem właściwości GA4 i konta Google Ads powinien być klient, a agencja dostaje rolę Edytor w GA4 i dostęp do Ads przez konto menedżera (MCC). Jeśli agencja zakłada konto na siebie, po zakończeniu współpracy tracisz historię i konfigurację konwersji.

Sprawdź, co integrator faktycznie wysyła. Raporty → Zaangażowanie → Zdarzenia i porównaj listę z oczekiwaną. Jeśli widzisz wyłącznie page_view, session_start i first_visit — moduł zbiera podstawowy ruch i nie wysyła e-commerce. Wtedy przechodzisz do pracy ręcznej opisanej w materiale GA4 w PrestaShop: wdrożenie bez dublowania danych.

Zdarzenia e-commerce: GA4, GTM i Ads – cztery metody konfiguracji

Minimum bez którego raporty e-commerce nie mają sensu to cztery zdarzenia: view_item, add_to_cart, begin_checkout, purchase. Każde musi nieść items[] (item_id, item_name, price, quantity), currency i value. Przy purchase dochodzi transaction_id — bez niego GA4 nie odróżni powtórzonego zdarzenia od nowego zamówienia.

Metoda	Kto utrzymuje	Zaleta	Ryzyko
1. gtag.js w motywie	deweloper	szybki start, brak GTM	ginie przy aktualizacji motywu, brak wersjonowania
2. GTM + dataLayer	marketing + deweloper	pełna kontrola, wersje kontenera	wymaga push w szablonach
3. Google Integrator	nikt (moduł)	działa z pudełka	uboższe items[], trudna edycja
4. Własny moduł	deweloper	kontrola i wersjonowanie w repo	koszt wdrożenia i utrzymania

Przykład dla metody 2 — order-confirmation.tpl w motywie:

{if isset($order)}
<script>
window.dataLayer = window.dataLayer || [];
(function () {
  var id = '{{ $order.details.reference }}';
  if (sessionStorage.getItem('ga4_purchase_' + id)) { return; }
  sessionStorage.setItem('ga4_purchase_' + id, '1');
  dataLayer.push({ ecommerce: null });
  dataLayer.push({
    event: 'purchase',
    ecommerce: {
      transaction_id: id,
      value: {{ $order.totals.total.value }},
      currency: '{{ $currency.iso_code }}',
      items: [] /* wypełnij pętlą po pozycjach zamówienia */
    }
  });
})();
</script>
{/if}

Nazwy zmiennych zależą od motywu i wersji PrestaShop. Jeśli szablon ich nie eksponuje, zbuduj dane w hooku displayOrderConfirmation i przekaż do szablonu — strukturę hooków opisuje dokumentacja dla deweloperów PrestaShop. GA4 potrafi zdeduplikować purchase po transaction_id, ale tag konwersji w Google Ads już nie, dlatego blokada po stronie sklepu jest obowiązkowa. Sama konwersja nie wystarczy też do kampanii produktowych — potrzebny jest spójny feed, o czym piszę w Reklamy produktowe w PrestaShop: kompletny poradnik.

Weryfikacja: GA4 → Administracja → DebugView, GTM → Preview, rozszerzenie Tag Assistant, DevTools → Network → filtr collect. Szukaj żądań /g/collect z tid=G-, en=purchase, ep.currency, epn.value. Jedna wizyta na potwierdzeniu zamówienia = jedno żądanie z en=purchase.

PShowConversion i inne moduły konwersji – kiedy pomagają, a kiedy mieszają

PShowConversion i podobne moduły robią jedną rzecz: liczą konwersję na podstawie koszyka i zamówienia w PrestaShop i wysyłają sygnał do kampanii płatnych — zwykle niezależnie od GA4.

Moduł ma sens w dwóch sytuacjach: nie masz GTM ani dewelopera, a kampanie płatne są głównym kanałem pozyskania; albo masz sklep na mocno zmodyfikowanym motywie, w którym wdrożenie dataLayer zajęłoby tygodnie. Jeśli masz kontener GTM i poprawny dataLayer z zdarzeniami e-commerce, płatny moduł staje się trzecim nadajnikiem, a nie ulepszeniem.

Pułapka: dwa moduły wysyłające purchase jednocześnie. Objawów nie da się przeoczyć, jeśli porównasz liczby.

Objaw	Prawdopodobna przyczyna	Jak sprawdzić
Przychód w GA4 wyższy niż w PrestaShop o 30–100%	dwa nadajniki purchase	DevTools → Network → filtr collect, policz żądania z en=purchase na stronie potwierdzenia
Brak transaction_id w zdarzeniach	moduł wysyła uproszczone zdarzenie	GA4 → DebugView, obecność transaction_id
Konwersje w Ads ok. dwa razy większe niż liczba zamówień	import z GA4 plus osobny tag AW-	Google Ads → Cele → Konwersje → źródło konwersji
Liczba purchase większa niż liczba zamówień	zdarzenie odpalane w koszyku, nie na potwierdzeniu	otwórz koszyk i podejrzyj żądania w DevTools

Koszt: roczna licencja modułu kontra jednorazowe wdrożenie dataLayer. Policz uczciwie — licencja plus czas na konfigurację i późniejszy debug dwóch nadajników, kontra 3–6 godzin pracy przy zdarzeniach w GTM, zrobionych raz i wersjonowanych. Aktualnych cen modułów nie zgaduj — sprawdź je w PrestaShop Marketplace dla swojej wersji sklepu.

Porównanie liczb: PrestaShop pokazuje wszystkie złożone zamówienia, także nieopłacone przelewy. GA4 tylko te, które dotarły na stronę potwierdzenia — blokery reklam, odmowa zgody w Consent Mode i ograniczenia przeglądarek zjadają część zdarzeń. Typowy, zdrowy rozrzut to 5–15% na niekorzyść GA4. Akceptowalna tolerancja między GA4 a PrestaShop to ±5%. Różnica powyżej 5% w drugą stronę (GA4 wyżej niż sklep) to nie rozjazd, a błąd pomiaru. Konwersje w Ads rozliczasz po kliknięciach w oknie konwersji, więc zwykle jest ich mniej niż w GA4; dane do rozliczeń wyciągniesz przez Google Ads API.

Najczęstsze problemy ze śledzeniem w PrestaShop i jak je wykryć

Większość problemów z GA4 w PrestaShop sprowadza się do czterech objawów. Każdy ma inne przyczyny i inny test diagnostyczny.

1. Brak zdarzenia purchase. Otwórz DebugView i sprawdź, czy w ogóle dochodzi session_start. Jeśli tak, a purchase nie ma, problem prawie zawsze leży na stronie potwierdzenia zamówienia — w PrestaShop 8 i 9 to kontroler order-confirmation w katalogu motywu (order-confirmation.tpl, order-confirmation.php, pliki w _partials/). Drugi scenariusz: bramka płatności wraca innym adresem niż /order-confirmation, a tag czeka na konkretny URL. Trzeci: blokada skryptu przez adblocka — przetestuj w trybie prywatnym bez rozszerzeń, bo to najczęstsza fałszywa diagnoza.

2. Zawyżone przychody. Jeśli GA4 pokazuje 140 zamówień, a panel PrestaShop 112, sprawdź dwie rzeczy: czy przekazujesz transaction_id (np. numer zamówienia z reference) i czy strona potwierdzenia nie odświeża się automatycznie. Bez transaction_id GA4 nie odrzuci duplikatu i policzy zakup dwa razy.

3. Puste zdarzenia. items[] bez product_id i item_name wpadnie do raportów jako kwota bez rozbicia na produkty. Brak currency potrafi wyzerować wartość, a value wysłane jako tekst (249,99 w cudzysłowie) zamiast liczby (249.99) również da zero.

4. GTM plus tag w motywie. Dwa tagi konfiguracyjne, nakładające się triggery (All Pages razem z History Change) albo tag doklejony przez moduł — każdy z tych przypadków to podwójne odsłony.

Test w 30 sekund: Ctrl+U na stronie sklepu, wyszukaj G- i policz wystąpienia. Więcej niż jeden identyfikator albo inny wynik niż liczba tagów w GTM = konflikt. Dokumentację struktury motywu znajdziesz w dokumentacji dla deweloperów PrestaShop.

Eskaluj do dewelopera, gdy: po 24 godzinach w DebugView nie ma żadnych zdarzeń, rozbieżność liczby zamówień przekracza 5%, albo po aktualizacji motywu w konsoli (F12 → Console) sypią się błędy JS.

Lista kontrolna wdrożenia GA4 w PrestaShop i co dalej

Poniższą listę skopiuj do notatek i przejdź punkt po punkcie. Każdy pozycja to jedno miejsce do sprawdzenia, nie teoria.

• Jeden Measurement ID (G-...) w całym serwisie — bez wyjątków dla podstron kampanijnych.
• Tag GA4 tylko w GTM albo tylko w motywie. Nigdy w obu.
• Trigger All Pages podpięty wyłącznie do tagu konfiguracyjnego, nie do zdarzeń e-commerce.
• purchase odpalany na stronie potwierdzenia zamówienia, po załadowaniu dataLayer.
• items[] z product_id, item_name, price, quantity dla każdej pozycji zamówienia.
• currency zgodna z walutą sklepu (PLN), value jako liczba, nie tekst.
• transaction_id ustawiony na numer zamówienia z PrestaShop.
• Test na zamówieniu kontrolnym za 1 zł — pełna ścieżka od koszyka do potwierdzenia.
• Wersja kontenera GTM opublikowana, nie tylko zapisana.

Kontrola po 7 dniach. Zestaw liczbę zdarzeń purchase w GA4 (Raporty → Zaangażowanie → Zdarzenia) z liczbą zamówień w PrestaShop za ten sam okres. Tolerancja to ±3–5% — różnica wynika z adblocków i porzuconych sesji. Wynik powyżej 5% oznacza, że trzeba wrócić do diagnozy z poprzedniej sekcji.

Kontrola po 30 dniach. Sprawdź stabilność: czy dzienna liczba purchase nie skacze o 20% bez zmian w kampaniach. Zobacz, czy nie spadł ruch branded (objaw podwójnego tagowania). Zweryfikuj jakość danych w Google Ads — konwersje importowane z GA4 kontra tracking po stronie Google Ads.

Ruch wewnętrzny. W GA4: Admin → Zbieranie danych → Wykluczenia ruchu wewnętrznego, reguła na stałe IP biura i zakres VPN. Domyślnie filtr działa w trybie testowym — trzeba go ręcznie przełączyć na aktywny. Kolejne kroki po stronie sprzedaży opisujemy w poradniku o reklamach produktowych w PrestaShop, a pełny proces wdrożenia krok po kroku w materiale o wdrożeniu GA4 w PrestaShop bez dublowania danych.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Test w GA4 DebugView — Włącz rozszerzenie DebugView, wejdź na stronę główną, kartę produktu i do koszyka. Sprawdź, czy zdarzenia pojawiają się w czasie rzeczywistym.
• Test w GA4 Realtime — Otwórz raport czasu rzeczywistego i wykonaj kilka akcji w sklepie. Sprawdź, czy widać Twoją sesję i aktywność.
• Google Tag Assistant — Uruchom rozszerzenie na stronie głównej, karcie produktu i w koszyku. Sprawdź, czy tag GA4 odpala się raz na stronę.
• Liczba wystąpień „gtag” i „G-” w źródle strony — Ctrl+U na trzech kluczowych podstronach. Więcej niż jedno wystąpienie oznacza duplikat do usunięcia.
• Obecność starych tagów — W źródle strony szukaj „analytics.js” i „UA-”. Każde wystąpienie to pozostałość do usunięcia.
• Liczba kontenerów GTM — Policz wystąpienia frazy „GTM-” na stronie. Powinien być dokładnie jeden identyfikator.
• Kompletność items[] w zdarzeniach — Sprawdź w DebugView, czy view_item, add_to_cart i purchase mają wypełnione items[], currency i value.
• Dostęp do GA4 — Ustal, kto ma uprawnienia administratora i edytora. Bez tego nie zweryfikujesz konfiguracji ani nie naprawisz błędów.
• Istnienie konta GTM — Sprawdź, czy sklep ma konto GTM i kto nim zarządza. To determinuje, czy wdrażasz tagi przez kontener, czy bezpośrednio w motywie.
• Niestandardowy checkout — Sprawdź, czy koszyk i zamówienie przechodzą przez standardowe szablony PrestaShop, czy przez modyfikację. Od tego zależy zakres ręcznego kodu.
• Motyw potomny — Przed edycją plików potwierdź, że masz skonfigurowany child theme, który przetrwa aktualizację.
• Cache i CDN — Po każdej zmianie w motywie wyczyść cache PrestaShop i warstwę CDN, zanim zaczniesz testy.

Najczęściej zadawane pytania

Źródła i materiały

• PrestaShop – dokumentacja dla deweloperów
• Google Ads – dokumentacja API
• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• Google Search Central – Core Web Vitals