Wybór pomiędzy bezpośrednim modułem GA4 a Google Tag Managerem zacznij od ustalenia, kto tworzy zdarzenia, kiedy uznaje zamówienie za zakup i kto utrzymuje konfigurację. Sam identyfikator G-… lub GTM-… nie odpowiada na te pytania.

Porównujemy konkretne wersje: PD Google Analytics 4 Pro 1.4.2, PD Google Tag Manager Pro 2.3.4 i starszy PD Google Tag Manager 1.2.4. Opis wynika z ich kodu i instrukcji sprawdzonych 26 września 2026 r. To zakres tych wersji, nie deklaracja identycznego działania wszystkich modułów dostępnych dla PrestaShop.

Dwie drogi dla tego samego zdarzenia

Dwie drogi zdarzenia: moduł wywołuje Google tag albo dataLayer uruchamia tag w kontenerze GTM.
Schemat demonstracyjny zdarzenia view_item. Pokazuje podział odpowiedzialności, a nie wynik pomiaru w działającym koncie GA4.

W wariancie bezpośrednim moduł zbiera dane produktu i przygotowuje wywołanie Google tag. W wariancie GTM Pro moduł przekazuje obiekt zdarzenia do dataLayer, a opublikowany kontener decyduje o uruchomieniu tagu i jego odbiorcy. Dla obu wariantów trzeba osobno ustalić reguły zgód oraz poprawność parametrów.

dataLayer występuje również przy bezpośrednim użyciu gtag. Sama obecność tej zmiennej w przeglądarce nie dowodzi, że sklep używa kontenera GTM. Google opisuje oba zastosowania w dokumentacji warstwy danych.

Najważniejsza różnica: kiedy powstaje purchase?

Zachowanie sprawdzonych wersji modułów
Obszar GA4 Pro 1.4.2 GTM Pro 2.3.4
Zdarzenia przeglądarkowe Moduł przygotowuje wywołania Google tag, m.in. wyświetlenie produktu i rozpoczęcie checkoutu. Moduł tworzy zdarzenia w dataLayer. W kontenerze trzeba skonfigurować i opublikować odpowiednie tagi, reguły oraz zmienne.
Zakup Tor serwerowy Measurement Protocol sprawdza skonfigurowany status płatności i historię kwalifikującego opłacenia. Przeglądarkowe purchase jest w tej wersji wyłączone. Przeglądarkowe purchase powstaje przy potwierdzeniu zamówienia. Kod tego toru nie stosuje tej samej listy opłaconych statusów co GA4 Pro.
Dodatkowy tor serwerowy Obsługuje operacje finansowe przy spełnieniu wymagań identyfikacji, konfiguracji i zgody. Opcjonalna kolejka odzyskiwania zakupu wymaga konfiguracji Measurement Protocol i zadania CRON. Zapis wyrenderowania potwierdzenia wpływa na decyzję o ponownej próbie.
Zwrot Przewidziano operacje według skonfigurowanego statusu lub dokumentu korekty, z kontrolą wcześniejszego zakupu i zwrotów. Dokument korekty może zasilić kolejkę refund; wysyłka zależy od kontekstu, zgody i aktywnej automatyzacji.

Nie porównuj więc liczb purchase bez ustalenia ich znaczenia. Zamówienie utworzone, pokazane na stronie potwierdzenia i zakwalifikowane jako opłacone to trzy różne momenty. Przy przelewie oczekującym na wpłatę różnica może być szczególnie widoczna.

Macierz zdarzeń przed uruchomieniem pomiaru

Dla każdego zdarzenia zapisz źródło, odbiorcę, warunek zgody i osobę odpowiedzialną. Pobierz edytowalną macierz CSV. Zawiera przykłady demonstracyjne i pola na wynik własnej weryfikacji.

Przykład podziału odpowiedzialności do uzupełnienia dla własnego sklepu
Zdarzenie Źródło Odbiorca Zgoda i odpowiedzialność
view_item Moduł bezpośredni albo moduł dataLayer i tag GTM — wybierz jeden tor. Wskazany strumień GA4. Osoba utrzymująca analitykę sprawdza sygnały CMP i warunki tagu.
purchase Ustalony moment biznesowy i jeden właściciel emisji. Ten sam uzgodniony strumień. Właściciel integracji sprawdza kontekst klienta, zgody, identyfikator transakcji i ponowienia.
refund Wybrany status lub dokument korekty zgodnie z użytym rozwiązaniem. Strumień, w którym zarejestrowano zakup. Osoba odpowiedzialna za zwroty uzgadnia zakres pełny i częściowy oraz sposób walidacji.

Zgody i Measurement Protocol są częścią projektu

W sprawdzonej wersji GA4 Pro zaufana zgoda dla zapisu atrybucji i serwerowych operacji finansowych jest powiązana z aktywnym PD Cookie Pro, jego trybem live, Consent Mode v2 i aktualną rewizją zgody. Nie zakładaj, że zamiana tego dostawcy na dowolny inny banner zachowa cały tor serwerowy bez dodatkowej weryfikacji.

GTM Pro ma własne ustawienia Consent Mode i konkretne integracje dostawców zgód. Przy aktywnym PD Cookie Pro pozostawia mu zarządzanie zgodami. Ostateczne zachowanie zależy także od opublikowanego kontenera. Obecność bannera lub pola konfiguracji nie jest jeszcze wynikiem próby „odmowa → zgoda → wycofanie”.

Tor serwerowy nie oznacza pominięcia zgody ani automatycznego odzyskania źródła sesji. API Secret należy do konfiguracji serwera. Powiązanie z aktywnością przeglądarki wymaga właściwych identyfikatorów i kontekstu; punktem odniesienia jest dokumentacja wysyłki zdarzeń Measurement Protocol.

Starszy GTM i GTM Pro nie są tą samą ofertą

Starszy PD Google Tag Manager 1.2.4 służy do osadzenia kontenera. Sprawdzony kod nie zawiera modelu ecommerce i kolejki Measurement Protocol opisanych wyżej dla wersji Pro. Nie traktuj nazwy „GTM” jako obietnicy gotowych zdarzeń zakupowych.

PD Google Tag Manager Pro dodaje warstwę danych i narzędzia konfiguracji. Eksport kontenera jest punktem startowym do importu, przeglądu i publikacji w GTM. Nie zastępuje odbioru konfiguracji. Pole własnego adresu serwera również nie tworzy automatycznie infrastruktury server-side GTM.

Jak wybrać wariant i uniknąć dwóch właścicieli zakupu?

  • Bezpośredni moduł: rozważ GA4 Pro, gdy chcesz utrzymywać ten tor w ustawieniach modułu i jego definicja opłaconego zakupu oraz wymagania zgód odpowiadają sklepowi.
  • Kontener GTM: rozważ GTM Pro, gdy masz osobę odpowiedzialną za tagi, reguły, środowiska oraz publikację zmian. Ustal również, kto obsługuje opcjonalną kolejkę serwerową.
  • Istniejące wdrożenie: najpierw zinwentaryzuj aktywne moduły i tagi. Nie dodawaj drugiego emitera purchase tylko dlatego, że liczba zakupów w raporcie budzi wątpliwości.

Odbiór powinien obejmować po jednym kontrolowanym przebiegu dla produktu, koszyka, właściwego momentu zakupu i zwrotu, a także odmowę i wycofanie zgody. Rozdziel dowód „zdarzenie utworzone”, „wysyłka wykonana” i „zdarzenie widoczne w GA4”. Samo dataLayer.push, wyrenderowanie strony czy odpowiedź HTTP transportu nie potwierdzają jeszcze kompletności raportu.

Jeżeli zakup już występuje, ale ma niewłaściwy host albo kanał, przejdź do poradnika o diagnozie pomiaru sprzedaży w GA4. Jeżeli dopiero wybierasz rozwiązanie, przygotuj macierz i opisz obecne moduły w zapytaniu o dobór integracji.

Powiązane produkty

Google Analytycs 4.0 moduł dla PrestaShop 1.6x oraz 1.7.x Google Analytycs 4.0 moduł dla PrestaShop 1.6x oraz 1.7.x 2
  • -20,00 zł
Reklama i analityka
Google Analytics 4 Pro moduł dla PrestaShop
PrestaDev.pl
PDGA4P
169,00 zł 137,40 złnetto 189,00 zł
4 Recenzję
Google Analytics 4 Pro – moduł GA4 dla PrestaShop Google Analytics 4 Pro to moduł PrestaShop do wdrożenia tagu Google i pomiaru zachowania użytkowników w Google Analytics 4. Rejestruje zdarzenia związane z produktami, listami produktów, koszykiem, checkoutem, wyszukiwaniem oraz kontem klienta. Zakupy i obsługiwane zwroty są wysyłane do głównego strumienia...
Google Tag Manager w PrestaShop – DataLayer Pro | PrestaDev Google Tag Manager w PrestaShop – DataLayer Pro | PrestaDev 2
  • Nowy
Reklama i analityka
Google Tag Manager Pro moduł dla PrestaShop
PrestaDev.pl
PDGTMPRO
246,00 zł 200,00 złnetto
PD Google Tag Manager Pro to rozbudowany moduł PrestaShop do wdrożenia Google Tag Manager z pełnym DataLayer e-commerce, integracją z GA4 oraz obsługą Google Consent Mode v2. Moduł automatycznie osadza kod GTM w sekcji head i w części noscript po otwarciu znacznika body, może pracować z drugim kontenerem GTM i obsługuje również adres server-side GTM. Na...
Zobacz artykuły autora
Patryk Marek

Patryk Marek — właściciel PrestaDev.pl i programista specjalizujący się w PrestaShop. Od wielu lat zajmuje się tworzeniem, rozwojem i utrzymaniem sklepów internetowych. Łączy pracę nad kodem sklepu i modułów z konfiguracją środowiska serwerowego, w którym te rozwiązania działają.

Projektuje i rozwija moduły PrestaShop, dostosowuje istniejące funkcje oraz przygotowuje integracje z hurtowniami i usługami zewnętrznymi. Pracuje nad importem i aktualizacją danych produktów, automatyzacją obsługi katalogu, przebiegiem zamówienia oraz narzędziami wspierającymi codzienną pracę właściciela sklepu.

Jego doświadczenie obejmuje również aktualizacje i migracje sklepów, diagnozowanie błędów, analizę wydajności oraz konfigurację serwerów i usług potrzebnych do działania PrestaShop. Przy rozwiązywaniu problemów uwzględnia zależności między modułami, motywem, PHP, bazą danych i ustawieniami hostingu.

Na blogu dzieli się wiedzą wynikającą z wieloletniej praktyki programistycznej i pracy z zapleczem technicznym sklepów. Poradniki skupiają się na konkretnych problemach, sposobach ich sprawdzenia i ograniczeniach opisywanych rozwiązań. Pomagają właścicielom sklepów oraz osobom technicznym przygotować zmiany, ocenić ich zakres i zweryfikować rezultat.

Komentarze (0)

Brak komentarzy w tej chwili

Nowy komentarz

Odpowiadasz na komentarz