--- type: "product" id: 215 url: "https://prestadev.pl/pl/google-analytics-4-pro-modul-dla-prestashop.html" markdown_url: "https://prestadev.pl/pl/markdown/product/215.md" title: "Google Analytics 4 Pro moduł dla PrestaShop" description: "Wdróż GA4 w PrestaShop: zdarzenia e-commerce, pomiar zakupów i Google Ads. Korzystaj ze śledzenia JavaScript oraz przesyłania transakcji Measurement Protocol." image: "https://prestadev.pl/1304/google-analytics-4-pro-modul-dla-prestashop.jpg" sku: "PDGA4P" brand: "PrestaDev.pl" price: 169.00 regular_price: 189.00 discount_percent: 10.58 discount_amount: 20.00 price_tax_excluded: 137.40 currency: "PLN" tax_included: true availability: "in_stock" is_pack: false customization_required: false condition: "new" categories: ["Główna", "Integracje Google", "Integracje PrestaShop", "Moduły PrestaShop", "Reklama i analityka"] language: "pl" updated: "2026-10-15" --- # Google Analytics 4 Pro moduł dla PrestaShop **Google Analytics 4 Pro** dodaje pomiar Google do PrestaShop dla zdarzeń produktów, koszyka, checkoutu, wyszukiwania i konta. Wersja 1.4.2 wysyła kwalifikujące zakupy i zwroty do głównego strumienia GA4 przez Measurement Protocol, wymagając API Secret, zapisanej atrybucji oraz aktywnego PD Cookie Pro w trybie live z Consent Mode v2 i zgodą analityczną. Opcje obejmują drugi identyfikator GA4, User ID, dane przekazywane przez użytkownika i dynamiczny remarketing Google Ads. Moduł nie konfiguruje kont Google ani nie gwarantuje kompletności raportów. ## Description Wersja 1.4.2 wymaga co najmniej PHP 7.2.5 ze względu na dołączone biblioteki HTTP; wersja PHP musi także spełniać wymagania używanej wersji PrestaShop. Serwerowe zakupy i zwroty wymagają dodatkowo aktywnego PD Cookie Pro w trybie live z Consent Mode v2, zgodnej rewizji zgody, zgody analitycznej oraz zapisanej atrybucji klienta i sesji. Sam API Secret nie wystarcza. ## Najważniejsze cechy i funkcjonalności - **15 nazwanych zdarzeń e-commerce i konta:** `view_item`, `view_item_list`, `select_item`, `add_to_cart`, `remove_from_cart`, `view_cart`, `begin_checkout`, `add_shipping_info`, `add_payment_info`, `purchase`, `refund`, `search`, `view_search_results`, `sign_up` i `login`. - **Opcjonalny `page_view`:** administrator może pozostawić automatyczny pomiar odsłon w module albo wyłączyć go, gdy obsługę odsłon prowadzi Google Tag Manager lub inne rozwiązanie. - **Zakup po skonfigurowanym statusie:** wersja 1.4.2 wysyła purchase z serwera po zapisaniu w historii zamówienia statusu wybranego przez administratora jako potwierdzający zapłatę i spełnieniu pozostałych warunków. Moduł nie weryfikuje samodzielnie rozliczenia u operatora płatności. - **Measurement Protocol dla operacji finansowych:** do wysłania `purchase` i `refund` potrzebne są: główny Measurement ID, API Secret, zapisane dane atrybucji/sesji oraz aktualna zgoda analityczna. - **Kontrolowane zwroty:** moduł obsługuje pełny zwrot po wybranym statusie oraz nowe korekty PrestaShop, w tym korekty częściowe, wyłącznie gdy wcześniej zarejestrowano kwalifikujący zakup. - **Dziennik operacji finansowych:** trwały rejestr i blokada dla zamówienia kontrolują własne zakupy i zwroty modułu; panel udostępnia widok tylko do odczytu z filtrowaniem, sortowaniem i stronicowaniem. Nie usuwa to duplikatów zdarzeń wysyłanych niezależnie przez GTM lub inne moduły. - **Dwa identyfikatory Measurement ID:** można skonfigurować główny oraz opcjonalny drugi identyfikator GA4 dla zdarzeń wysyłanych z tagu w przeglądarce. - **Pięć sposobów budowania `item_id`:** ID produktu, ID produktu z ID kombinacji rozdzielone myślnikiem, ID produktu z ID kombinacji rozdzielone podkreśleniem, referencja albo EAN. - **Dane katalogowe przy zdarzeniach:** moduł przekazuje m.in. identyfikator, nazwę, wariant, markę, kategorie, cenę, rabat, ilość, walutę oraz dane listy produktów, jeśli są dostępne w PrestaShop. - **Kupony rabatowe:** obsługiwane zdarzenia przeglądarkowe mogą zawierać nazwę i kod zastosowanej reguły koszyka. W wersji 1.4.2 serwerowy purchase wysyłany przez Measurement Protocol nie zawiera kodów kuponów. - **User ID dla zalogowanego klienta:** po włączeniu opcji moduł przekazuje techniczny identyfikator klienta do GA4 przy zgodzie `analytics_storage`; nie zastępuje to danych kontaktowych. - **Dane przekazywane przez użytkownika:** po włączeniu opcji i przy aktualnej zgodzie `ad_user_data` moduł może przekazać e-mail oraz dostępny telefon lub adres w formacie wymaganym przez Google; dane identyfikujące normalizuje i hashuje SHA-256. - **Dynamiczny remarketing Google Ads:** po włączeniu funkcji i podaniu identyfikatora Google Ads tag otrzymuje identyfikatory produktów, typ strony oraz wartość koszyka. - **DebugView i diagnostyka:** tryb debugowania zapisuje zdarzenia przeglądarkowe w konsoli i dodaje do nich flagę debug\_mode dla GA4 DebugView. Nie dodaje tej flagi do serwerowych purchase i refund. Panel pokazuje stan konfiguracji i ostatni zakup z odpowiedzią HTTP 2xx; zdarzenia finansowe należy sprawdzać w dzienniku oraz raportach GA4. - **PrestaShop 1.7.x, 8.x i 9.x:** taki zakres deklaruje wersja 1.4.2, ale nie jest to gwarancja działania na każdej wersji PHP, motywie lub checkoutcie. Kod zawiera ścieżki standardowego checkoutu i wybranych modułów one-page checkout; sprawdzenia wymaga rzeczywisty proces zamówienia w danym sklepie. ## Jakie etapy sprzedaży mierzy moduł GA4 dla PrestaShop? | Etap w sklepie | Zdarzenia przekazywane przez moduł | Zakres danych | | --- | --- | --- | | Listy i karta produktu | view\_item\_list, select\_item, view\_item | Produkt, wariant, marka, kategorie, cena, rabat i pozycja na liście. | | Koszyk | add\_to\_cart, remove\_from\_cart, view\_cart | Pozycje koszyka, ilości, wartości, waluta i dostępny kupon. | | Checkout | begin\_checkout, add\_shipping\_info, add\_payment\_info | Skład koszyka i informacje wybierane podczas procesu zamówienia. | | Zakup i zwrot | purchase, refund | Zapis danych transakcji lub zwrotu spełniających warunki wysyłki przez Measurement Protocol. | | Wyszukiwanie i konto | search, view\_search\_results, sign\_up, login | Wyszukiwane hasło, wyniki wyszukiwania lub zdarzenie utworzenia konta i logowania. | ## Pomiar zakupów i zwrotów przez Measurement Protocol W aktualnym trybie finansowym moduł nie uznaje kliknięcia przycisku ani samej strony potwierdzenia za dowód zapłaty. Zdarzenie `purchase` powstaje po zapisaniu w historii zamówienia jednego z wybranych statusów płatności. Dla zwrotu moduł najpierw sprawdza, czy dla tego zamówienia istnieje wcześniejszy zakup zapisany jako wysłany w dzienniku; następnie rozlicza wyłącznie pozostałą, niezwróconą wartość. Pełny zwrot może uruchamiać wybrany status, a nowe korekty PrestaShop są obsługiwane niezależnie, także częściowo. Stan `sent` w dzienniku oznacza odpowiedź HTTP 2xx, czyli przyjęcie żądania przez endpoint Measurement Protocol. Nie jest to potwierdzenie, że zdarzenie zostało już przetworzone lub pokazane w raportach Google Analytics. Moduł nie odtwarza historycznych zakupów ani zwrotów po aktualizacji i nie ma automatycznej kolejki, CRON-a ani przycisku wymuszającego ponowienie niepewnej wysyłki. ## GA4, Google Ads, zgody i dane użytkownika Moduł może inicjować tag GA4 dla jednego lub dwóch Measurement ID. Dla dynamicznego remarketingu Google Ads wymaga dodatkowo identyfikatora w formacie `AW-…`. W obecnym trybie zakupu po statusie płatności zdarzenia `purchase` i `refund` trafiają do GA4 przez Measurement Protocol; moduł nie wysyła w tym trybie bezpośredniej przeglądarkowej konwersji zakupu do Google Ads. Opcja danych przekazywanych przez użytkownika wymaga aktywnego PD Cookie Pro z Consent Mode v2 i bieżącej zgody `ad_user_data`. Dodatkowo właściciel sklepu musi włączyć zbieranie takich danych w usłudze GA4 oraz w ustawieniach tagu Google; konfiguracja konwersji rozszerzonych w Google Ads jest odrębnym zadaniem po stronie konta Google. Cofnięcie zgody usuwa dane identyfikujące z konfiguracji tagu, a serwerowa wysyłka operacji finansowych ponownie sprawdza aktualną zgodę przed wysłaniem. User ID i dane przekazywane przez użytkownika również wymagają aktywnego PD Cookie Pro w trybie live, Consent Mode v2 i aktualnej wersji zgody. Cofnięcie analytics\_storage zeruje User ID w tagu, a cofnięcie ad\_user\_data zeruje user\_data. Nie usuwa to danych już przesłanych do Google. ## Konfiguracja i weryfikacja wdrożenia 1. Wpisz główny Measurement ID GA4, a drugi identyfikator tylko wtedy, gdy jest potrzebny. 2. Dla zakupów i zwrotów podaj API Secret Measurement Protocol oraz wybierz statusy, które rzeczywiście potwierdzają opłacenie i pełny zwrot zamówienia w danym sklepie. 3. Dobierz format `item_id` do identyfikatora stosowanego w katalogu lub feedzie produktowym. 4. Włącz tylko potrzebne funkcje Google Ads, User ID i danych przekazywanych przez użytkownika, po sprawdzeniu ustawień oraz zgód w narzędziach Google. 5. Do testu użyj trybu debugowania i GA4 DebugView, a dla operacji finansowych sprawdź dziennik modułu. Test należy wykonać na rzeczywistej ścieżce zakupu i właściwym statusie zamówienia. ## Zakres modułu i ważne ograniczenia - Moduł przekazuje dane do skonfigurowanych usług Google; nie zakłada ani nie administruje kontem GA4, Google Ads, Merchant Center czy kampaniami reklamowymi. - Nie zastępuje konfiguracji zgód ani analizy prawnej sklepu. Właściciel sklepu odpowiada za podstawę przetwarzania danych, treść zgód i ustawienia kont Google. - Blokowanie skryptów, brak zgody, brak zapisanej atrybucji, błędne identyfikatory lub ustawienia Google mogą ograniczyć pomiar. Moduł nie deklaruje gwarancji kompletności danych. - Wysłanie danych z API Secret wymaga poprawnej konfiguracji GA4. Odpowiedź HTTP 2xx należy traktować jako potwierdzenie odbioru żądania, a nie jako dowód widoczności transakcji w raportach. ### Wymagania toru serwerowego w wersji 1.4.2 Serwerowe purchase nie jest wysyłane dla zamówień z płatnym pakowaniem, ponad 200 wierszami produktów lub pustą referencją/EAN, gdy wybrano taki format item\_id. Korekty muszą mieć spójne kwoty i pozycje; odrzucane są rekordy z partial != 0 oraz typy bonów. Typ 2 jest obsługiwany tylko jako jednoznaczny zwrot samej dostawy. Częściowy zwrot ilości produktów nie jest tym samym co techniczna flaga partial. Przed połączeniem źródeł zdarzeń przeczytaj [porównanie architektury GA4 przez moduł i GTM](https://prestadev.pl/pl/blog/baza-wiedzy/ga4-modul-czy-google-tag-manager-prestashop). Gdy zakup lub jego przypisanie budzi wątpliwości, skorzystaj z [poradnika diagnozy sprzedaży w GA4](https://prestadev.pl/pl/blog/baza-wiedzy/ga4-prestashop-brak-zakupow-pomiar-sprzedazy). Zasady licencji, kopii testowej i aktualizacji znajdziesz w [§7 Regulaminu sklepu](https://prestadev.pl/pl/content/7-regulamin-sklepu#licencje). ## Zanim porównasz raport z zamówieniami Ustal definicję zakupu, źródło zdarzenia oraz warunki zgód. Przy jednoczesnym GTM sprawdź, czy drugi tag nie tworzy tego samego purchase. Porównanie rozwiązań znajdziesz w [poradniku GA4 czy GTM](https://prestadev.pl/pl/blog/baza-wiedzy/ga4-modul-czy-google-tag-manager-prestashop). ### Co sprawdzić przed uruchomieniem? - Sprawdź konfigurację identyfikatora pomiaru i wymagań toru serwerowego wymienionych w opisie oraz FAQ. - Dla kontrolowanego zdarzenia porównaj transaction\_id, walutę, wartość i pozycje. Potwierdzenie wysyłki z modułu nie jest jeszcze dowodem poprawnego przypisania w raportach GA4. - Sprawdź odmowę zgody, ponowne otwarcie potwierdzenia i przewidziany proces zwrotu w środowisku testowym. ## Features | Feature | Value | | --- | --- | | Obsługa Prestashop 9.x | Tak | | Obsługa Prestashop 8.x | Tak | | Obsługa Prestashop 1.7.x | Tak | | Tłumaczenia modułu | PL, EN | | Darmowe wsparcie (30 dni) | Tak | | Darmowe aktualizacje (1 rok) | Tak | | Łatwa instalacja | Tak | | Wymaga modyfikacja silnika | Nie | ## Variants | Variant | SKU | Price | Availability | Variant ID | | --- | --- | --- | --- | --- | | Typ licencji / aktualizacja: Pełna wersja / licencja dożywotnia | ` PDGA4P-FULL ` | 169.00 | ` in_stock ` | ` 598 ` | | Typ licencji / aktualizacja: Tylko aktualizacja (przedłużenie dostępu o kolejne 12 mc-y) | ` PDGA4P-UPD ` | 84.50 | ` in_stock ` | ` 599 ` | ## Categories - Główna - Integracje Google - Integracje PrestaShop - Moduły PrestaShop - Reklama i analityka ## Related products - [Google Remarketing Dynamiczny Pro dla PrestaShop](https://prestadev.pl/pl/markdown/product/102.md) - [Google Shopping Pro / Google zakupy dla PrestaShop](https://prestadev.pl/pl/markdown/product/128.md) - [Google Tag Manager Pro moduł dla PrestaShop](https://prestadev.pl/pl/markdown/product/329.md) - [Moduł Google AdWords śledzenie konwersji sprzedaży Pro dla PrestaShop](https://prestadev.pl/pl/markdown/product/57.md) ## Questions and answers ### Do czego służy moduł Google Analytics 4 Pro dla PrestaShop? Language: pl Google Analytics 4 Pro dodaje do sklepu tag Google oraz przekazuje do Google Analytics 4 zdarzenia związane z produktami, koszykiem, checkoutem, wyszukiwaniem i kontem klienta. Osobna część modułu wysyła kwalifikujące zakupy i obsługiwane zwroty do głównego strumienia GA4 przez Measurement Protocol. Moduł nie tworzy konta GA4 ani nie zarządza kampaniami Google Ads. ### Z jakimi wersjami PrestaShop jest zgodny moduł? Language: pl Wersja 1.4.2 deklaruje zgodność z liniami PrestaShop 1.7.x, 8.x i 9.x. Dołączone biblioteki HTTP wymagają co najmniej PHP 7.2.5; trzeba równocześnie spełnić wymagania PHP używanej wersji PrestaShop. Nie oznacza to zgodności z PHP 7.0 lub 7.1 ani potwierdzenia całej macierzy wersji. Przed wdrożeniem należy sprawdzić konkretny sklep, motyw i checkout, ponieważ inne moduły oraz HTML i JavaScript strony wpływają na zdarzenia przeglądarkowe. ### Jakie dane trzeba przygotować do konfiguracji GA4? Language: pl Podstawą jest główny GA4 Measurement ID w formacie G-XXXXXXXX. Dla serwerowego wysyłania zakupów i zwrotów trzeba podać API Secret Measurement Protocol oraz wybrać statusy zamówienia, które rzeczywiście potwierdzają opłacenie i pełny zwrot. Funkcje Google Ads wymagają osobnego identyfikatora AW-XXXXXXXXX, a opcja danych przekazywanych przez użytkownika wymaga także właściwych ustawień i zgód po stronie Google. W wersji 1.4.2 serwerowe purchase i refund wymagają także aktywnego PD Cookie Pro w trybie live z Consent Mode v2, aktualnej rewizji zgody analitycznej i zachowanego kontekstu klienta. ### Ile zdarzeń obsługuje moduł? Language: pl Kod modułu wymienia 15 nazwanych zdarzeń e-commerce i konta: view\_item, view\_item\_list, select\_item, add\_to\_cart, remove\_from\_cart, view\_cart, begin\_checkout, add\_shipping\_info, add\_payment\_info, purchase, refund, search, view\_search\_results, sign\_up i login. Niezależnie można włączyć lub wyłączyć automatyczny page\_view. Dlatego nie należy nazywać samych 15 wymienionych zdarzeń „16 zdarzeniami e-commerce”. ### Jakie zdarzenia są wysyłane na listach i kartach produktów? Language: pl Na obsługiwanych listach produktów moduł wysyła view\_item\_list, a po kliknięciu produktu select\_item. Na karcie produktu wysyła view\_item, również po zmianie wariantu w obsługiwanym interfejsie. Przy zdarzeniach może przekazać identyfikator produktu, nazwę, wariant, markę, kategorie, cenę, rabat oraz pozycję na liście. ### Jak moduł mierzy działania w koszyku i checkoutcie? Language: pl Moduł obsługuje add\_to\_cart, remove\_from\_cart i view\_cart, a po wejściu w obsługiwany proces zamówienia begin\_checkout. Szablony dla checkoutu przekazują również add\_shipping\_info oraz add\_payment\_info. Zdarzenia zawierają pozycje koszyka, ilości, ceny, walutę i dostępny kupon, jeżeli dane są dostępne w PrestaShop. ### Czy moduł mierzy wyszukiwanie, rejestrację i logowanie? Language: pl Tak. Wykaz funkcji modułu obejmuje zdarzenia search, view\_search\_results, sign\_up i login. Dla wyszukiwania kod pobiera frazę wyszukiwania oraz przygotowuje dostępne wyniki produktów; działanie konkretnego zdarzenia warto sprawdzić w DebugView na używanym motywie. ### Kiedy moduł wysyła zdarzenie purchase do GA4? Language: pl Od wersji 1.4 purchase jest wysyłane z serwera dopiero po zapisaniu w historii zamówienia statusu wybranego w konfiguracji jako potwierdzający opłacenie lub pobranie należności. Samo kliknięcie przycisku płatności i sama strona potwierdzenia nie są uznawane za potwierdzenie płatności. Dodatkowa próba na stronie potwierdzenia może obsłużyć tylko niewysłane zamówienie, które spełnia te same warunki. ### Jakie warunki są potrzebne do serwerowego wysłania zakupu lub zwrotu? Language: pl Wersja 1.4.2 potrzebuje głównego Measurement ID, API Secret, wybranego statusu zakupu, zapisanej atrybucji z client\_id i session\_id oraz aktualnej zgody analitycznej. Pełny zwrot uruchamiany statusem wymaga osobnej konfiguracji statusów zwrotu. Zapis zgody pochodzi z aktywnego w sklepie PD Cookie Pro w trybie live z Consent Mode v2 i aktualną wersją zgody; inny CMP nie spełnia automatycznie tego warunku. Dla danych użytkownika sprawdzana jest osobno zgoda ad\_user\_data. Zakup nie jest wysyłany przy płatnym pakowaniu, ponad 200 wierszach produktów lub pustej referencji/EAN przy takim formacie item\_id. Kwoty i pozycje także wymagają walidacji. ### Czy odpowiedź HTTP 2xx oznacza, że zakup jest już widoczny w raportach GA4? Language: pl Nie. W dzienniku modułu stan sent oznacza, że endpoint Measurement Protocol zwrócił odpowiedź HTTP 2xx, czyli przyjął żądanie. Nie jest to potwierdzenie przetworzenia zdarzenia ani jego widoczności w raportach Google Analytics. Odbiór trzeba weryfikować we właściwej usłudze i strumieniu Google. ### Czy Measurement Protocol gwarantuje pomiar, gdy klient używa ad-blockera? Language: pl Nie ma takiej gwarancji. Serwerowa wysyłka zakupu wymaga wcześniej zapisanej atrybucji, w tym danych sesji, oraz aktualnej zgody analitycznej. Blokowanie skryptów, brak zgody, błędna konfiguracja lub ograniczenia po stronie Google mogą uniemożliwić albo ograniczyć pomiar. ### Jak moduł obsługuje pełne zwroty? Language: pl Dla pełnego zwrotu administrator wybiera osobne statusy uruchamiające refund. Moduł wymaga wcześniejszego zakupu zarejestrowanego jako sent w swoim dzienniku i wcześniejszego statusu opłacenia. Ponowne ustawienie tego samego statusu nie wysyła kolejnego pełnego zwrotu, a rozliczana jest wyłącznie wartość pozostała po wcześniejszych zwrotach. ### Czy moduł obsługuje częściowe zwroty i korekty PrestaShop? Language: pl Moduł obsługuje kwalifikujące nowe korekty PrestaShop z zapisanymi pozycjami, w tym zwrot części ilości produktów, jeśli wcześniej zapisano zakup jako sent i istnieje kwalifikujący status zakupu. Nie obejmuje to każdej korekty: odrzucane są rekordy z techniczną flagą partial != 0 i typy inne niż 0 lub 2; typ 2 jest obsługiwany tylko jako jednoznaczny zwrot samej dostawy. Odrzucane są też niejednoznaczne kwoty arbitralne i niespójne pozycje. Częściowy zwrot ilości nie jest tym samym co flaga partial. Historyczne korekty sprzed uruchomienia tej obsługi nie są odtwarzane. ### Czy po instalacji lub aktualizacji moduł wyśle stare zakupy i zwroty? Language: pl Nie ma automatycznego odtwarzania historii. Aktualizacja zapisuje granice istniejących zamówień, historii statusów i korekt oraz nie resetuje zachowanych flag wysyłki. Dla starszego zamówienia najwcześniejszy kwalifikujący wpis statusu zakupu musi być nowszy od zapisanej granicy historii; wymagany jest też zachowany wpis koszyka z order\_send=0 i brak wcześniejszego wysłania. Samo ponowne ustawienie statusu nie wystarcza, gdy wcześniejszy kwalifikujący wpis jest sprzed tej granicy. ### Czy moduł automatycznie ponawia nieudaną lub niepewną wysyłkę? Language: pl Nie ma automatycznej kolejki, CRON-a ani przycisku wymuszającego ponowienie operacji finansowej. Niewysłana operacja w stanie pending może wrócić do próby przy kolejnym właściwym wyzwoleniu, np. kwalifikującym statusie lub stronie potwierdzenia, jeśli spełni wszystkie warunki. Stan sending po przerwaniu oraz unknown przy niepewnym wyniku transportu blokują automatyczne ponowienie, aby ograniczyć ryzyko duplikatów. Nie są traktowane tak samo jak niewysłane pending. ### Jak moduł zapobiega podwójnemu wysłaniu purchase i refund? Language: pl Moduł kontroluje własne operacje finansowe przez trwały dziennik z jednym kluczem operacji oraz blokadę współbieżności dla zamówienia. Zakup i zwrot mają zapisywany stan kwot, waluty i pozycji, a zwroty są ograniczane do wartości wcześniej wysłanego zakupu. Stan niepewny nie jest automatycznie traktowany jako niewysłany. Te mechanizmy nie usuwają duplikatów wysyłanych niezależnie przez GTM lub inne moduły. ### Czy można wpisać dwa identyfikatory Google Analytics 4? Language: pl Tak. Konfiguracja zawiera główny Measurement ID oraz opcjonalny drugi Measurement ID. Tag przeglądarkowy inicjuje oba skonfigurowane identyfikatory, co może służyć na przykład równoległemu pomiarowi w drugiej usłudze GA4. Serwerowe purchase i refund są wysyłane do głównego strumienia używanego do atrybucji. ### Jak można skonfigurować identyfikator produktu item\\\_id? Language: pl Do wyboru są: ID produktu, ID produktu z ID kombinacji rozdzielone myślnikiem, ID produktu z ID kombinacji rozdzielone podkreśleniem, referencja produktu oraz EAN. Wariant referencja lub EAN wykorzystuje wartość kombinacji, jeżeli jest dostępna. Wybrany format powinien odpowiadać identyfikatorowi stosowanemu w katalogu lub feedzie produktowym. ### Czy moduł przekazuje kody rabatowe do GA4? Language: pl W obsługiwanych zdarzeniach przeglądarkowych moduł może przekazać nazwę i kod zastosowanej reguły koszyka jako informację o kuponie. W wersji 1.4.2 serwerowy purchase wysyłany przez Measurement Protocol nie zawiera pola coupon ani kodów kuponów przy pozycjach. Moduł nie tworzy rabatów, reguł koszyka ani kodów promocyjnych w PrestaShop. ### Do czego służy opcja User ID? Language: pl Po włączeniu User ID moduł przekazuje techniczny identyfikator zalogowanego klienta w przeglądarce i identyfikator klienta zamówienia przy zdarzeniach serwerowych. Wersja 1.4.2 wymaga zgody analytics\_storage z aktywnego w danym sklepie PD Cookie Pro w trybie live z Consent Mode v2 i zgodną aktualną wersją zgody. User ID jest niezależny od danych przekazywanych przez użytkownika, nie jest hashem e-maila i nie zastępuje danych kontaktowych. ### Jakie dane użytkownika może przekazać moduł do tagu Google i Measurement Protocol? Language: pl Po włączeniu odpowiedniej opcji moduł może użyć zapisanego w PrestaShop e-maila, a opcjonalnie telefonu oraz danych adresowych. Sam prawidłowy e-mail wystarcza; telefon i adres są dodatkowymi danymi, jeśli spełniają warunki walidacji. Moduł nie odczytuje niezapisanych pól wpisywanych w formularzu ani adresów e-mail z treści strony. ### Czy dane identyfikujące klienta są hashowane? Language: pl Tak. E-mail, telefon, imię i nazwisko są przed przekazaniem normalizowane i hashowane SHA-256. Dla wysyłki Measurement Protocol obsługiwany jest również hash ulicy, a kod pocztowy, kraj i opcjonalne miasto mają format wymagany przez Google. Dane i hashe nie są dopisywane do dziennika transakcji ani konfiguracji modułu. ### Jakie zgody są wymagane do przekazywania danych użytkownika? Language: pl Dane przekazywane przez użytkownika wymagają bieżącej zgody ad\_user\_data od aktywnego w danym sklepie PD Cookie Pro w trybie live z Consent Mode v2 i zgodną aktualną wersją zgody. User ID i serwerowa wysyłka Measurement Protocol wymagają zgody analytics\_storage. Cofnięcie analytics\_storage zeruje User ID w tagu, a cofnięcie ad\_user\_data zeruje user\_data; nie usuwa to danych już przesłanych do Google. Przed wysyłką finansową moduł ponownie odczytuje zapisany stan zgody i jej wersję, nie opiera się na cookies callbacku płatności. ### Czy włączenie opcji w module wystarcza do użycia danych przekazywanych przez użytkownika lub konwersji rozszerzonych? Language: pl Nie. Właściciel sklepu musi włączyć zbieranie danych przekazywanych przez użytkownika w usłudze GA4 i w ustawieniach jej tagu Google. Konwersje rozszerzone wymagają osobnej konfiguracji po stronie Google Ads. Moduł nie ma dostępu do ustawień konta Google i nie może ich włączyć automatycznie. ### Jak działa dynamiczny remarketing Google Ads? Language: pl Po włączeniu funkcji i skonfigurowaniu Google Ads Conversion ID moduł przekazuje do tagu dane remarketingowe na stronach sklepu: identyfikatory produktów, typ strony i wartość koszyka. Dane te mogą być wykorzystane w konfiguracji dynamicznego remarketingu Google Ads. Moduł nie tworzy kampanii, odbiorców ani reklam w panelu Google Ads. ### Czy moduł wysyła bezpośrednią konwersję zakupu do Google Ads? Language: pl W aktualnym trybie zakupu po statusie płatności purchase i refund są wysyłane do GA4 przez Measurement Protocol. Kod modułu nie wysyła w tym trybie bezpośredniej przeglądarkowej konwersji zakupu Google Ads. Identyfikator Google Ads jest używany m.in. do konfiguracji tagu i dynamicznego remarketingu. ### Czy zakupy i zwroty trafiają do drugiego strumienia GA4? Language: pl Nie. W wersji 1.4.2 drugi Measurement ID służy do równoległego działania tagu w przeglądarce. Serwerowe purchase i refund są wysyłane przez Measurement Protocol tylko do głównego strumienia powiązanego z zapisaną atrybucją. API Secret musi należeć do tego głównego strumienia. Skonfigurowanie drugiego Measurement ID nie powiela serwerowych zakupów i zwrotów w drugiej usłudze GA4. ### Do czego służy tryb debugowania i GA4 DebugView? Language: pl Tryb debugowania zapisuje zdarzenia przeglądarkowe w konsoli i ustawia dla nich debug\_mode, wykorzystywany przez GA4 DebugView. W wersji 1.4.2 przełącznik nie dodaje tej flagi do serwerowych purchase i refund i nie uruchamia endpointu walidacyjnego Measurement Protocol. Zdarzenia finansowe należy sprawdzać osobno w dzienniku modułu oraz właściwej usłudze i raportach GA4; odpowiedź HTTP 2xx nie potwierdza przetworzenia zdarzenia. Tryb należy wyłączyć po zakończeniu diagnostyki. ### Co pokazuje panel statusu i dziennik finansowy modułu? Language: pl Panel statusu pokazuje, czy skonfigurowano GA4, Google Ads i Measurement Protocol, czy działa tryb debugowania oraz ostatni zakup z odpowiedzią HTTP 2xx. Dziennik finansowy jest tylko do odczytu i udostępnia filtrowanie, sortowanie oraz stronicowanie zapisów purchase i refund. Nie udostępnia sekretów API, identyfikatorów przeglądarki ani surowych payloadów. ### Czy moduł działa z one-page checkout? Language: pl Kod modułu obsługuje standardową stronę zamówienia oraz ścieżki używane przez popularne rozwiązania one-page checkout, a w opisie konfiguracji wskazano m.in. TheCheckout, SuperCheckout i STEasyCheckout. Ponieważ zdarzenia przeglądarkowe zależą od faktycznego HTML i JavaScript checkoutu, po instalacji należy wykonać test całej ścieżki koszyk–płatność–status zamówienia w używanym motywie. ### Czy można wyłączyć automatyczne page\\\_view? Language: pl Tak. W konfiguracji znajduje się przełącznik automatycznego page\_view. Można go wyłączyć, gdy odsłony są już obsługiwane przez Google Tag Manager lub inne narzędzie, aby nie tworzyć podwójnego pomiaru odsłon. Wyłączenie page\_view nie usuwa pozostałych funkcji zdarzeń modułu. ### Czy moduł zapewnia zgodność prawną, kompletność danych i wyniki kampanii? Language: pl Nie. Moduł technicznie przekazuje skonfigurowane dane do usług Google, ale nie zastępuje wdrożenia zgód, analizy prawnej ani konfiguracji kont GA4 i Google Ads. Właściciel sklepu odpowiada za podstawę przetwarzania danych, treść zgód i ustawienia usług Google. Kompletność danych oraz wyniki kampanii zależą także od zgód użytkowników, przeglądarki, motywu, checkoutu i systemów Google. ## Customer reviews - Average rating: 4.50/5 - Public reviews: 4 - Source: iqitreviews