Pinned Post

Google Analytics 4 w PrestaShop: Jak śledzić zakupy, nie łamiąc RODO (i nie tracąc danych)



Dostałem ostatnio maila. Klient potencjalny, ale konkretny. Nie "ile kosztuje", tylko "mam taki a taki sklep, taki a taki scenariusz, czy to zadziała?". Lubię takie konkrety, bez owijania w bawełnę.

Tp były pytania techniczne. Szczegółowe. Dotyczą Measurement Protocol, consent mode, CookieScript, statusów zamówień, refundacji, licencji.

I wiesz co? To jest dokładnie ten typ pytań, które pokazują, że ktoś naprawdę chce to dobrze skonfigurować. Nie "włączyć i modlić się", że dzadziała. Tylko zrobić to zgodnie z RODO, bez duplikacji zdarzeń, z poprawnym atrybucją.

Ten artykuł jest odpowiedzią na takie pytania. Nie w formie Q&A. Tylko jako przewodnik po tym, jak właściwie ustawić GA4 w PrestaShop, żeby działało, było zgodne z prawem i nie zrujnowało Ci danych.

Scenariusz, który spotyka coraz więcej sklepów

Masz PrestaShop. Chcesz śledzić zakupy w GA4. Ale:

  • Nie chcesz duplikować zdarzeń (GTM + moduł + coś jeszcze = chaos).
  • Musisz szanować decyzję klienta o cookies (RODO, consent mode, cała ta zabawa).
  • Chcesz, żeby zakup wysyłał się dopiero po "Payment accepted", a nie przy "Awaiting bank wire".
  • Interesuje Cię, co tracisz, używając Measurement Protocol zamiast gtag.js.
  • Chcesz wiedzieć, czy refundacje działają.
  • I czy jedna licencja to production + staging, czy musisz płacić podwójnie.

Brzmi znajomo?

To nie jest hipotetyczny scenariusz. To jest rzeczywista rozmowa z klientem, który pytał o moduł Google Analytics 4 dla PrestaShop przed zakupem. I dokładnie te pytania warto zadać, zanim cokolwiek kupisz i zainstalujesz.

Tryby działania: gtag, dataLayer, Measurement Protocol

Moduł działa w trzech trybach. Ale uwaga - tylko jeden na raz.

gtag.js

Klasyczne śledzenie po stronie przeglądarki. Moduł wstrzykuje gtag.js i wysyła zdarzenia e-commerce (view_item, add_to_cart, purchase, refund, itd.).

Plusy:

  • Pełne dane o sesjach, źródłach ruchu, engagement time.
  • Google zbiera wszystko, co standardowo zbiera z gtag.

Minusy:

  • Zależne od przeglądarki (adblocki, ITP, blokowanie cookies).
  • Wymaga zgody użytkownika na cookies (jeśli masz consent banner).

dataLayer

Moduł nie wysyła nic bezpośrednio do Google. Tylko wypełnia dataLayer zdarzeniami e-commerce. Ty masz GTM, który czyta dataLayer i wysyła do GA4.

Plusy:

  • Pełna kontrola po Twojej stronie (GTM).
  • Łatwiejsza integracja z innymi tagami.

Minusy:

  • Nadal zależne od przeglądarki.
  • Wymaga poprawnej konfiguracji GTM (nie dla każdego).

Measurement Protocol (MP)

Śledzenie po stronie serwera. Moduł wysyła zdarzenia bezpośrednio do Google z poziomu PHP, bez udziału przeglądarki.

Plusy:

  • Niezależne od przeglądarki (adblocki nie blokują).
  • Możesz wysyłać zdarzenia z back office (np. zmiana statusu zamówienia).
  • Lepsze dla RODO (łatwiej kontrolować, co i kiedy wysyłasz).

Minusy:

  • Brak pełnych danych o sesjach (referrer, UTM, engagement time są ograniczone).
  • Client ID i session ID muszą być przechwycone z przeglądarki (moduł używa "ghost script" do ich zapisania).
  • Trafiłeś na problem z atrybucją przy płatnościach odroczonych (bank wire, płatność później).

Ważne: Nie możesz mieszać trybów. Nie ma opcji "browsing przez gtag, purchase przez MP". Jeden sklep = jeden tryb.

Measurement Protocol: co wysyła, a czego nie

To jest kluczowe. Wiele osób myśli, że MP to "to samo co gtag, tylko z serwera". Nie do końca.

Co MP wysyła (jeśli włączysz):

  • page_view
  • view_item
  • select_item
  • view_item_list
  • add_to_cart
  • remove_from_cart
  • begin_checkout
  • add_payment_info
  • search
  • sign_up
  • generate_lead
  • contact
  • purchase
  • refund

Każde zdarzenie ma swój przełącznik włącz/wyłącz. Decydujesz, co chcesz śledzić.

Czego MP nie wysyła (w porównaniu do gtag):

  • Automatyczne enhanced measurement z GA4 (scroll, outbound clicks, file downloads, video engagement).
  • Pełne raporty sesji (traffic source, referrer, UTM source/medium są ograniczone).
  • Prawdziwy engagement time (czas na stronie mierzony z poziomu przeglądarki).

Co dostajesz w zamian?

  • Wartość zakupu, walutę, transaction ID, produkty - wszystko się zgadza.
  • Niezawodność (serwer wysyła, nie zależy od przeglądarki).
  • Kontrolę nad tym, kiedy wysyłasz purchase (np. tylko po "Payment accepted").

Statusy zamówień: kiedy wysłać purchase?

To jest pytanie, które wraca jak bumerang. "Kiedy moduł wysyła zdarzenie purchase?"

Odpowiedź: to zależy od konfiguracji.

Scenariusz 1: Standardowy (purchase przy złożeniu zamówienia)

Domyślnie moduł wysyła purchase, gdy zamówienie trafi do statusu, który PrestaShop oznacza jako "paid". To może być:

  • "Payment accepted"
  • "Shipped"
  • Inny status z flagą "paid" w konfiguracji.

Jeśli używasz płatności online (karta, PayPal, BLIK) - to zazwyczaj działa od razu. Klient płaci, zamówienie trafia do "Payment accepted", purchase jest wysyłany.

Scenariusz 2: Tylko po faktycznej płatności (np. bank wire)

Tu sprawa się komplikuje. Klient składa zamówienie z płatnością "przelew tradycyjny". Zamówienie trafia do "Awaiting bank wire payment". To nie jest status "paid". Purchase nie jest wysyłany.

Klient płaci kilka dni później. Ty w back office zmieniasz status na "Payment accepted". I wtedy moduł wysyła purchase.

Ale jest haczyk.

Przy Measurement Protocol, client_id, session_id i gclid są czytane z przeglądarki w momencie wysyłki zdarzenia. Nie są zapisywane na zamówieniu.

Czyli:

  • Klient składa zamówienie w poniedziałek. Moduł zapisuje client_id i session_id z jego przeglądarki.
  • Płaci w czwartek. Ty zmieniasz status w back office.
  • Moduł wysyła purchase z back office. Ale client_id i session_id są czytane z Twojej sesji (admin), nie z sesji klienta.
  • Wynik: purchase jest wysłany, ale nie jest połączony z oryginalną sesją klienta. Atrybucja jest stracona.

Rozwiązanie? Moduł można zmodyfikować tak, żeby zapisywał client_id, session_id i gclid na zamówieniu w momencie checkoutu. Wtedy, gdy zmieniasz status w back office, moduł używa zapisanych wartości, a nie tych z Twojej sesji.

To wymaga drobnej modyfikacji. Ale jeśli masz dużo zamówień z odroczoną płatnością - warto.

Refundacje: pełne i częściowe

Moduł obsługuje refundacje. Ale:

Pełne refundacje

Działają. Gdy zamówienie trafia do statusu, który oznaczysz jako "refund/cancel" (lub statusu, którego nazwa zawiera "refund" lub "cancel"), moduł wysyła zdarzenie refund z pełną wartością zamówienia.

Jedno zdarzenie refund na zamówienie.

Częściowe refundacje

Nie działają. Jeśli wystawiasz fakturę korygującą na część zamówienia, albo refundujesz tylko niektóre produkty - moduł tego nie wyśle.

Dlaczego? Bo to wymagałoby śledzenia, które produkty zostały zrefundowane, w jakiej ilości, za jaką kwotę. To jest możliwe, ale nie jest zaimplementowane w standardowej wersji.

Jeśli potrzebujesz częściowych refundacji - trzeba to dopracować indywidualnie.

Consent i RODO: czy moduł szanuje decyzję klienta?

To jest pytanie numer jeden w 2024 i 2025 roku. "Czy moduł wysyła dane, jeśli klient nie zgodził się na cookies?"

Odpowiedź: to zależy od konfiguracji.

Opcja "Require marketing / analytics consent"

Jeśli włączysz tę opcję w module:

  • gtag, dataLayer i Measurement Protocol nie wysyłają nic, dopóki klient nie wyrazi zgody.
  • Odmowa zgody = zero danych do Google. W żadnym trybie.
  • Nie ma opcji "MP omija consent". Jeśli consent jest wymagany, MP też czeka na zgodę.

Jak moduł sprawdza consent?

  • W trybie gtag/dataLayer: czyta sygnały Google Consent Mode v2 z przeglądarki.
  • W trybie MP: czyta cookie modułu (ustawiane, gdy klient wyraża zgodę) oraz kilka popularnych cookie z CMP (Consent Management Platform).

CookieScript i inne bannerki

Moduł nie wykrywa CookieScript automatycznie. Ale to nie znaczy, że nie działa.

Jeśli masz CookieScript skonfigurowany z Google Consent Mode v2:

  • Consent Mode aktualizuje zgodę dla tagów przeglądarkowych (gtag, GTM).
  • Measurement Protocol nie czyta Consent Mode - on czyta cookie modułu.
  • Z włączoną opcją "Require consent", domyślnie wszystko jest zablokowane, dopóki klient nie zaakceptuje.

Żeby moduł wiedział, kiedy klient wyraził zgodę przez CookieScript, musisz dodać w konfiguracji CookieScript:

// Gdy klient akceptuje:
document.dispatchEvent(new CustomEvent('myanalytics.consent', { detail: { grant: 1 } }));

// Gdy klient odrzuca:
document.dispatchEvent(new CustomEvent('myanalytics.consent', { detail: { grant: 0 } }));

To powiadamia moduł o zmianie zgody. Moduł wtedy (lub nie) zaczyna wysyłać dane.

Co z Google Ads w GTM?

Moduł nie zarządza tagami Google Ads w GTM. To jest poza nim.

Jeśli trzymasz Google Ads w GTM - ich consent musisz obsłużyć w CookieScript / GTM. Moduł nie interfere'uje z tym.

Licencja: production + staging

Pojedyncza licencja pokrywa:

  • Jeden sklep produkcyjny.
  • Jedną kopię lokalną / stagingową tego samego sklepu.

Nie pokrywa drugiego sklepu produkcyjnego (nawet jeśli należy do tej samej firmy).

Jeśli potrzebujesz licencji na drugi sklep - można dostać 50% zniżki na każdą kolejną licencję.

Kompatybilność i kod

Moduł działa na:

  • PrestaShop 1.7.x (w tym 1.7.8.1).
  • PrestaShop 8.x.
  • PrestaShop 9.x.

Kod jest czystym PHP. Bez ionCube. Bez encoderów. Możesz zajrzeć, zmodyfikować, dostosować do swoich potrzeb.

Podsumowanie: czy warto?

Jeśli szukasz sposobu na:

  • Właściwe śledzenie GA4 w PrestaShop.
  • Zgodność z RODO i consent mode.
  • Uniknięcie duplikacji zdarzeń (GTM + moduł = ból).
  • Śledzenie purchase po "Payment accepted", a nie przy złożeniu zamówienia.
  • Obsługę refundacji (przynajmniej pełnych).
  • Elastyczność (gtag, dataLayer, MP - wybierasz, co pasuje).

...to moduł Google Analytics 4 jest wart rozważenia - dla większości sklepów e-commerce w PrestaShop - to solidne, sprawdzone rozwiązanie.

A jeśli masz specyficzne wymagania (jak klient z maila powyżej) - jako autor modułu jestem otwarty na modyfikacje i dostosowanie do Twojego scenariusza. To się rzadko zdarza. Warto wykorzystać.

Komentarze

Prześlij komentarz