Server-side tagging dla PrestaShop i sklepu na własnym silniku
Server-side tagging dla PrestaShop to sposób zbierania danych e-commerce, w którym zdarzenia ze sklepu - wyświetlenie produktu, dodanie do koszyka, zakup - trafiają najpierw do kontenera serwerowego działającego pod Twoją własną domeną, a dopiero on rozsyła je do Google Ads, GA4 czy Meta. W odróżnieniu od WooCommerce i Shopify PrestaShop oraz sklepy na własnym silniku nie mają gotowej wtyczki do tagowania po stronie serwera, dlatego warstwę danych i transport zdarzeń buduje się ręcznie: przez nadpisanie szablonów, podpięcie hooków i konfigurację kontenera w server-side Google Tag Manager (sGTM).
- Dlaczego PrestaShop nie ma gotowej wtyczki do server-side tagging?
- Jak zbudować warstwę danych e-commerce (dataLayer) w PrestaShop?
- Które zdarzenia e-commerce trzeba przekazać do kontenera serwerowego?
- Transport zdarzeń do kontenera serwerowego na własnej subdomenie
- Server-side tagging na własnym silniku bez gotowej platformy
- Jak zweryfikować, że zdarzenia docierają do serwera?
- Jakie są najczęstsze pułapki wdrożenia w PrestaShop?
- Server-side tagging a RODO i Consent Mode w sklepie na własnym silniku
- Komu opłaca się server-side tagging w PrestaShop?
- Podsumowanie
- Źródła i dokumentacja
Sklepy na PrestaShop trafiają do mnie zwykle z tym samym objawem: piksele wpięte na sztywno w motyw przestały raportować część zakupów, a Google Ads pokazuje mniej konwersji, niż realnie widać w panelu zamówień. Przez ponad 200 audytów kont Google Ads nauczyłem się, że na PrestaShop i sklepach pisanych od zera to nie przypadek. To konsekwencja braku gotowego mostu między sklepem a serwerem tagującym. Ten most trzeba zbudować samodzielnie - i wbrew pozorom nie jest to praca na jedno popołudnie.
Wnioski, które decydują o tym, czy zakupy ze sklepu na PrestaShop realnie docierają do Google Ads.
-
Tagowanie serwerowe w PrestaShop stawiasz na własnym module nasłuchującym hooków sklepu
W PrestaShop 1.7 i 8.x moduł podpięty pod hooki displayHeader, actionCartSave i hookDisplayOrderConfirmation przeżywa aktualizacje motywu, a nadpisane pliki .tpl potrafią zniknąć po update. Override zostawiaj tam, gdzie moduł nie ma dostępu do potrzebnych zmiennych.
-
Safari skraca życie cookie third-party do 7 dni przez mechanizm ITP
Apple podaje ten limit w dokumentacji WebKit dla Intelligent Tracking Prevention, a w części scenariuszy skraca go do 24 godzin (stan na 2026 rok). Cookie ustawione serwerowo z subdomeny first-party sklepu nie podlega temu skróceniu.
-
W audytach sklepów na PrestaShop rozjazd konwersji wynika zwykle z nieprzetestowanej metody płatności
Bramki BLIK, karta i przelew wracają na stronę potwierdzenia różnymi ścieżkami, więc zdarzenie purchase wypycha się tylko dla części z nich. W audytowanych sklepach cały ubytek konwersji brał się z jednej, nieprzetestowanej metody.
-
Sklep na własnym silniku wysyła zdarzenie purchase z backendu, z pominięciem przeglądarki
Żądanie server-to-server leci z systemu, który przyjął płatność, więc adblock ani ITP go nie dotykają. Kosztem jest ręczne przekazanie identyfikatora użytkownika i sygnału zgody z frontu do backendu.
-
Sygnały Consent Mode trzeba przekazać z CMP do kontenera serwerowego ręcznie
Kontener serwerowy bez sygnałów zgody nie wie, czy może przetworzyć dane użytkownika, więc pomiar zostaje bez podstawy prawnej. Consent Mode v2 wymaga świadomego wyboru trybu podstawowego lub zaawansowanego, bo różnią się tym, co dzieje się bez zgody.
Dlaczego PrestaShop nie ma gotowej wtyczki do server-side tagging?
PrestaShop nie ma oficjalnego modułu do server-side tagging, ponieważ tagowanie po stronie serwera wymaga własnego kontenera serwerowego i subdomeny first-party, których żaden uniwersalny plugin nie postawi za Ciebie. Wtyczka może wypchnąć dane do warstwy danych i osadzić snippet, ale nie wynajmie Ci serwera ani nie skonfiguruje DNS.
Na tym polega różnica wobec WooCommerce i Shopify. Tam istnieją aplikacje i wtyczki, które z pudełka pchają gotowy dataLayer e-commerce, a część z nich integruje się wprost z zewnętrznym hostingiem kontenera. PrestaShop stoi na własnym systemie hooków i szablonach Smarty, a jego marketplace pokrywa głównie warstwę webową. Serwer to infrastruktura, którą musisz uruchomić obok sklepu. Warstwa serwerowa ma znaczenie także poza sklepem: reklama programmatic rozlicza się z wielu źródeł naraz, więc niekompletny pomiar zniekształca tam optymalizację szybciej niż w pojedynczym kanale.
Uważam, że to nie wada, tylko cena elastyczności. Sklep, który nie jest zamknięty w jednym ekosystemie, daje Ci pełną kontrolę nad tym, co i jak trafia do Google. Trzeba tylko wykonać pracę, którą na innych platformach robi za Ciebie ktoś inny. W praktyce ręcznie ogarniasz trzy rzeczy:
- Warstwę danych - wypchnięcie zdarzeń e-commerce z kart produktu, koszyka i strony potwierdzenia.
- Transport - przekierowanie kontenera webowego na własną subdomenę, na której stoi kontener serwerowy.
- Rozsyłkę - konfigurację tagów serwerowych do Google Ads, GA4 i ewentualnie Meta, wraz z deduplikacją.
Czy wiesz, że…
Strona potwierdzenia zamówienia to w PrestaShop jedyny widok, który zna finalny numer transakcji. Jeśli piksel zawiesi się akurat tam - a to właśnie tam najczęściej działa One Page Checkout i przekierowania płatności - tracisz konwersje o najwyższej wartości, a nie przypadkowe wejścia. Dlatego zdarzenie purchase warto pchać równolegle przez serwer.
Jak zbudować warstwę danych e-commerce (dataLayer) w PrestaShop?
Warstwę danych w PrestaShop budujesz przez podpięcie się pod hooki sklepu i wypchnięcie zdarzeń do obiektu dataLayer, który czyta kontener webowy. Kolejność jest stała: najpierw osadzasz kontener, potem karmisz go zdarzeniami produktu i koszyka, a na końcu - najważniejszym zdarzeniem zakupu na stronie potwierdzenia. Uporządkowanie zdarzeń w takiej kolejności to podstawowa praca, jaką obejmuje analityka internetowa - bez niej zakup jest tylko jednym z wielu sygnałów, a nie punktem odniesienia.
W PrestaShop 1.7 i 8.x najczyściej robi to dedykowany moduł nasłuchujący hooków (displayHeader, actionCartSave, hookDisplayOrderConfirmation). Alternatywą jest override szablonów .tpl, ale wtedy przy każdej aktualizacji motywu ryzykujesz, że nadpisania znikną. Z mojego doświadczenia moduł jest trwalszy niż override - override zostawiam tam, gdzie moduł nie ma dostępu do potrzebnych zmiennych. Ta decyzja o miejscu nadpisania jest częścią szerszego wyboru server-side vs client-side, który przesądza, gdzie w ogóle powstaje zdarzenie.
Kliknij każdy krok, żeby rozwinąć szczegóły ręcznego wdrożenia dataLayer i transportu do serwera.
1Osadź kontener webowy GTM w motywie
2Podepnij hooki produktu i koszyka
3Przekaż zakup na stronie potwierdzenia
4Przełącz transport na kontener serwerowy
Zwróć uwagę na jedną rzecz, która psuje najwięcej wdrożeń: dane w dataLayer muszą być kompletne w momencie zdarzenia, nie sekundę później. Jeśli purchase wypycha się, zanim PrestaShop wyrenderuje transaction_id, do serwera trafi pusty numer zamówienia. To dokładnie ten typ błędu, który wychodzi dopiero w audycie, gdy porównuję liczbę zamówień w panelu z liczbą konwersji w Google Ads.
Które zdarzenia e-commerce trzeba przekazać do kontenera serwerowego?
Do odtworzenia pełnej ścieżki zakupowej po stronie serwera wystarczy sześć zdarzeń: view_item, add_to_cart, begin_checkout, add_payment_info, purchase oraz refund. Rdzeniem jest purchase - to ono niesie transaction_id i wartość, na których opiera się rozliczenie kampanii i licytacja.
Pozostałe zdarzenia nie są ozdobą. Bez add_to_cart i begin_checkout nie zbudujesz remarketingu dynamicznego ani nie zobaczysz, na którym etapie sklep traci klientów. Refund z kolei koryguje wartość konwersji w dół - bez niego Smart Bidding uczy się na zawyżonych przychodach i licytuje za wysoko za klientów, którzy i tak zwrócą towar.
Minimalny zestaw zdarzeń e-commerce, który pozwala odtworzyć pełną ścieżkę zakupową po stronie serwera.
Wyświetlenie karty produktu z item_id i ceną.
Dodanie do koszyka wraz z ilością i wartością.
Wejście do checkoutu, wartość koszyka i pozycje.
Wybór metody płatności przed złożeniem zamówienia.
Zakup z transaction_id, wartością i walutą - rdzeń pomiaru.
Zwrot lub anulowanie - koryguje wartość konwersji.
W każdym zdarzeniu pilnuj spójności nazewnictwa parametrów: to samo item_id na karcie produktu, w koszyku i w zakupie. Różne identyfikatory tego samego produktu na różnych etapach to najczęstsza przyczyna, dla której raporty produktowe w GA4 się nie składają. Jedno pojęcie, jeden parametr - trzymaj się tego przez cały sklep.
Transport zdarzeń do kontenera serwerowego na własnej subdomenie
Transport polega na tym, że kontener webowy wysyła zdarzenia nie wprost do Google, lecz na Twoją subdomenę first-party, pod którą działa kontener serwerowy. Ustawiasz to jednym parametrem: w tagu konfiguracyjnym GA4 podajesz server_container_url wskazujący adres w rodzaju sst.twojsklep.pl.
Ta subdomena musi być częścią głównej domeny sklepu, nie obcą domeną dostawcy. Na tym polega różnica między first-party a third-party. Jeśli serwer stoi pod adresem dostawcy, przeglądarka traktuje jego cookie jako obce i skraca im życie tak samo jak pikselom. Dopiero własna subdomena sprawia, że cookie wygląda jak własne cookie sklepu.
Sam kontener serwerowy hostujesz na jednej z platform - stape.io lub Google Cloud (Cloud Run). Mapowanie subdomeny to rekord A/AAAA albo CNAME plus certyfikat SSL. Techniczne szczegóły konfiguracji DNS i wyboru hostingu wykraczają poza ten wpis, tu zatrzymuję się na roli transportu.
- server_container_url w tagu GA4 - kieruje ruch na subdomenę zamiast na endpoint Google.
- Rekord DNS (A/AAAA lub CNAME) - mapuje subdomenę na kontener serwerowy.
- Certyfikat SSL na subdomenie - bez HTTPS przeglądarki odrzucą transport.
- Klient GA4 w kontenerze serwerowym - przejmuje przychodzące żądania i udostępnia je tagom.
Czy wiesz, że…
Cookie ustawione skryptem third-party w Safari żyje maksymalnie 7 dni, a przy części scenariuszy 24 godziny (mechanizm ITP). Cookie ustawione po stronie serwera z Twojej subdomeny first-party działa jak cookie własne sklepu i nie jest tak agresywnie skracane - stąd realny odzysk części zakupów z urządzeń Apple.
Server-side tagging na własnym silniku bez gotowej platformy
Na sklepie pisanym od zera masz przewagę, której nie ma na PrestaShop: pełną kontrolę nad kodem backendu. Dzięki temu możesz wdrożyć tagowanie po stronie serwera w wariancie server-to-server, w którym zdarzenie zakupu leci prosto z Twojego serwera aplikacyjnego do kontenera serwerowego, z pominięciem przeglądarki.
W praktyce łączysz dwa światy. Zdarzenia widoczne dla użytkownika - przeglądanie produktu, dodanie do koszyka - dalej najlepiej zbierać po stronie klienta, bo tylko przeglądarka wie o tych interakcjach. Ale zakup, który potwierdzasz w bazie danych, wysyłasz z backendu. To najpewniejszy sygnał, jaki masz, bo pochodzi z systemu, który faktycznie przyjął płatność.
- Wariant hybrydowy: lekki dataLayer w przeglądarce dla zdarzeń pośrednich, plus server-to-server dla zakupu.
- Wariant w pełni serwerowy: wszystkie kluczowe zdarzenia wysyła backend, przeglądarka odpowiada tylko za identyfikator sesji i zgodę.
- Measurement Protocol: gdy nie chcesz stawiać kontenera serwerowego, backend może słać zdarzenia do GA4 protokołem pomiarowym - to jednak węższe rozwiązanie niż pełny sGTM.
Uczciwie: server-to-server nie jest darmowym obiadem. Musisz sam zadbać o przekazanie identyfikatora użytkownika i sygnału zgody z frontu do backendu, inaczej serwer nie połączy zakupu z wcześniejszą sesją i klikiem w reklamę. To właśnie ta część, która na gotowej platformie jest ukryta, a na własnym silniku spoczywa na Tobie.
Czy wiesz, że…
Na sklepie pisanym od zera możesz w ogóle pominąć przeglądarkę. Backend po zapisaniu zamówienia w bazie wysyła zdarzenie purchase bezpośrednio z serwera do kontenera serwerowego (server-to-server). Adblock ani ITP nie mają tu nic do powiedzenia, bo żądanie nigdy nie przechodzi przez przeglądarkę użytkownika.
Jak zweryfikować, że zdarzenia docierają do serwera?
Weryfikację robisz w trybie Preview kontenera serwerowego: składasz testowe zamówienie i sprawdzasz, czy zdarzenie purchase pojawiło się w podglądzie z poprawnym transaction_id, wartością i walutą. Jeśli tam go nie ma, do Google też nie dotrze. To pierwszy i najważniejszy test.
Drugim krokiem jest liczbowa kontrola spójności. Bierzesz liczbę zamówień z panelu PrestaShop za daną dobę i zestawiasz ją z liczbą zdarzeń purchase odebranych przez serwer. Rozjazd to sygnał, że gdzieś gubisz transport - najczęściej na One Page Checkout albo przy płatnościach z przekierowaniem, gdzie klient wraca na stronę potwierdzenia inną ścieżką.
Panel kontroli zdrowia transportu zdarzeń ze sklepu PrestaShop do kontenera serwerowego w ciągu doby.
Trzeci test dotyczy zgody. Sprawdź, czy zdarzenia niosą sygnały Consent Mode i czy serwer respektuje brak zgody. Zdarzenie, które dociera do serwera mimo odmowy w banerze, to nie sukces pomiaru, tylko problem prawny. To jeden z pierwszych punktów, które kontroluję podczas audytu konfiguracji pomiarowej sklepu.
Jakie są najczęstsze pułapki wdrożenia w PrestaShop?
Najczęstsze pułapki w PrestaShop to zgubione zdarzenie purchase na One Page Checkout, cache nadpisujący warstwę danych oraz override szablonu, który znika po aktualizacji motywu. Każda z nich daje ten sam efekt: konwersje są w panelu zamówień, ale nie ma ich w Google Ads.
W mojej codziennej praktyce widzę, że najbardziej podstępny jest cache. PrestaShop chętnie serwuje stronę potwierdzenia z pamięci, przez co dataLayer dostaje dane poprzedniego zamówienia albo pusty obiekt. Efekt: te same transaction_id powtarzają się między klientami, a deduplikacja po stronie serwera słusznie je odrzuca jako duplikaty. Wygląda, jakby sklep sprzedawał mniej, niż sprzedaje.
- One Page Checkout: moduły jednostronicowego checkoutu zmieniają moment potwierdzenia zamówienia - hook zakupu trzeba przepiąć pod ich zdarzenie, nie pod standardowe.
- Cache strony potwierdzenia: wyklucz ten widok z pełnego cache albo generuj dataLayer po stronie serwera przy renderze, nie ze statycznego szablonu.
- Override po aktualizacji motywu: nadpisania .tpl potrafią zniknąć po update - trwalej trzymać logikę w module niż w szablonie.
- Płatności z przekierowaniem: gdy klient wraca z bramki płatniczej inną ścieżką, zdarzenie zakupu może się nie wypchnąć - testuj każdą metodę płatności osobno.
- Podwójne tagowanie: pozostawiony stary piksel webowy obok serwera bez wspólnego transaction_id zawyża konwersje.
Rekomenduję podejście testowania per metoda płatności. Każda bramka - BLIK, karta, przelew, płatność odroczona - potrafi wracać na stronę potwierdzenia inaczej. Jeśli sprawdzisz tylko jedną, wdrożenie wygląda na poprawne, a w tle gubisz konwersje z pozostałych. Wielokrotnie obserwowałem sytuację, w której cały rozjazd danych brał się z jednej, nieprzetestowanej metody płatności.
Server-side tagging a RODO i Consent Mode w sklepie na własnym silniku
Server-side tagging nie zwalnia sklepu z obowiązków RODO ani z uzyskania zgody, ale daje realne narzędzie do minimalizacji danych: na serwerze możesz odfiltrować lub zahaszować dane osobowe, zanim opuszczą Twoją infrastrukturę. To jego przewaga wobec pomiaru wyłącznie przeglądarkowego, gdzie surowe dane lecą wprost do dostawców.
Podstawą pozostaje jednak zgoda. Potrzebujesz CMP zbierającego zgodę i mechanizmu, który przekazuje sygnały Consent Mode do kontenera serwerowego - inaczej serwer nie wie, czy może przetwarzać dane danego użytkownika. Na własnym silniku ten most między banerem a backendem budujesz samodzielnie, co jest zaletą i odpowiedzialnością jednocześnie.
- Minimalizacja na serwerze: usuwaj z parametrów adresy e-mail w postaci jawnej, pełne IP czy identyfikatory, których Google nie potrzebuje.
- Region UE: hostuj kontener serwerowy w regionie europejskim, jeśli chcesz ograniczyć transfer danych poza EOG.
- Sygnały zgody: tryb podstawowy i zaawansowany Consent Mode różnią się tym, co dzieje się bez zgody - decyzję podejmij świadomie, nie domyślnie.
- Rola przetwarzającego: ustal, kto jest administratorem, a kto podmiotem przetwarzającym dane w całym łańcuchu tagowania.
Szczegóły działania samego Consent Mode i architektury zgodnej z RODO rozwijam w materiale o server-side tagging - tu wystarczy zapamiętać zasadę: serwer to punkt, w którym egzekwujesz zgodę i tniesz nadmiarowe dane, a nie sposób na ominięcie zgody.
Komu opłaca się server-side tagging w PrestaShop?
Server-side tagging opłaca się sklepom PrestaShop, które trwale tracą część konwersji przez ITP, adblocki i krótkie życie cookies, i których skala sprawia, że odzyskane zakupy przewyższają koszt hostingu oraz wdrożenia. Im większy udział ruchu z Safari i iOS oraz im mocniej sklep opiera się na Enhanced Conversions i licytacji wartościowej, tym szybciej inwestycja się zwraca.
Rzędy wielkości z audytów sklepów na PrestaShop po przejściu z pomiaru wyłącznie przeglądarkowego na serwerowy.
Po stronie kosztów warto rozdzielić dwie rzeczy, które często się myli. Hosting kontenera serwerowego to wydatek techniczny: stape.io zaczyna się od ok. 20 USD/mies. (z planem darmowym do ok. 10 tys. żądań miesięcznie), a Google Cloud w wariancie Cloud Run przy realnym ruchu zwykle od ok. 90-120 USD/mies. To nie to samo co budżet reklamowy na kampanie, który u mnie startuje od 2500 zł netto/mies.
Na składniki kosztu wdrożenia składa się kilka pozycji, które trzeba policzyć razem:
- Hosting kontenera serwerowego - stape.io od ok. 20 USD/mies. lub Google Cloud zwykle od ok. 90-120 USD/mies.
- Subdomena i SSL - zwykle w cenie hostingu lub domeny sklepu.
- Czas wdrożenia - ręczne zbudowanie dataLayer i transportu w PrestaShop, plus testy per metoda płatności.
- Utrzymanie - kontrola po każdej aktualizacji motywu i modułów checkoutu.
Jestem przekonany, że dla małego sklepu z niewielkim ruchem i znikomym udziałem iOS server-side tagging jeszcze nie jest priorytetem - lepiej najpierw poukładać podstawowy pomiar. Ale dla sklepu, który realnie skaluje wydatki w Google Ads i widzi rozjazd między zamówieniami a konwersjami, to jeden z nielicznych ruchów, który zwraca się policzalnie. Jeśli rozpoznajesz ten wzorzec u siebie, to sygnał, że warto policzyć wartość odzyskanych konwersji, zanim odrzucisz temat jako zbyt techniczny.
Podsumowanie
Przestań traktować brak wtyczki jak ścianę. Na PrestaShop i własnym silniku server-side tagging to nie gotowy przycisk, tylko zestaw trzech decyzji: jak zbudujesz warstwę danych, jak przetransportujesz zdarzenia na własną subdomenę i jak zwalidujesz, że zakupy realnie docierają do serwera. Każda z nich jest wykonalna, jeśli podejdziesz do niej metodycznie.
Najważniejsze zdarzenie to purchase na stronie potwierdzenia - jeśli tylko ono działa poprawnie i deduplikuje się po transaction_id, masz fundament. Reszta, od remarketingu po korekty zwrotów, dobudowuje się na tym rdzeniu. Na własnym silniku dodatkowo możesz sięgnąć po server-to-server i w ogóle ominąć przeglądarkę dla kluczowego sygnału.
Zamiast pytać, która wtyczka to za mnie zrobi, zacznij pytać, gdzie dzisiaj gubię zakupy i ile realnie są warte. Kiedy zobaczysz tę liczbę, decyzja o wdrożeniu przestaje być techniczna, a staje się po prostu rachunkiem opłacalności - i wtedy PrestaShop przestaje być platformą drugiej kategorii w pomiarze.
Źródła i dokumentacja
PrestaShop i sklep na własnym silniku nie mają gotowej wtyczki do tagowania serwerowego, więc każdy element wdrożenia trzeba oprzeć na specyfikacji, a nie na domyśle. Wybrałem dokumentację zdarzeń e-commerce i weryfikacji pomiaru, praktyczny opis budowy warstwy danych oraz pomiar tego, ile śledzenia dzieje się bez zgody użytkownika.
Warstwa danych GA4 krok po kroku
Przewodnik pokazuje ręczne wypchnięcie zdarzeń purchase i view_item do dataLayer bez gotowej wtyczki, wraz z tworzeniem zmiennych i reguł w Menedżerze tagów oraz ostrzeżeniem, że nazwa zdarzenia musi się zgadzać co do wielkości liter. Punkt odniesienia do sekcji o budowaniu warstwy danych e-commerce w PrestaShop, gdzie dataLayer składasz z hooków sklepu.
Specyfikacja zdarzeń e-commerce
Oficjalna lista rekomendowanych zdarzeń sprzedażowych - view_item, add_to_cart, begin_checkout, add_payment_info, add_shipping_info, purchase i refund - z kompletem parametrów, gdzie dla zakupu wymagane są transaction_id, value, currency oraz tablica items z item_id lub item_name. Podstawa do sekcji o tym, które zdarzenia trzeba przekazać do kontenera serwerowego i w jakim formacie.
Weryfikacja pomiaru przez Measurement Protocol
Dokumentacja opisuje trzy warstwy sprawdzenia wysyłki server-to-server: serwer walidacyjny badający strukturę zdarzenia przed wysłaniem, raport czasu rzeczywistego pokazujący ruch w kilka sekund oraz DebugView, który wymaga dodania parametrów debug_mode i engagement_time_msec. Techniczna podstawa sekcji o tym, jak zweryfikować, że zdarzenia realnie docierają do serwera.
Śledzenie mimo odrzucenia zgody
Badanie zespołu Papadogiannakisa pokazuje, że ponad 75 procent aktywności śledzącej działo się zanim użytkownik zdążył wybrać opcję w banerze zgody albo mimo odrzucenia wszystkich plików cookie, a witryny sięgały po wyciek identyfikatora first-party, synchronizację ID i fingerprinting. Materiał dowodowy do sekcji o RODO i Consent Mode, która tłumaczy, dlaczego sygnał zgody trzeba świadomie przekazać do kontenera serwerowego.
Pytania i odpowiedzi (FAQ)
Wdrożenie w PrestaShop: potrzeba gotowej wtyczki, właściwy hook zakupu i praca na starszej wersji 1.6.
Czy aktualizacja PrestaShop skasuje wdrożony pomiar?
Który hook w PrestaShop przekazuje dane o zakupie?
Czy tagowanie serwerowe zadziała na starym PrestaShop 1.6?
Czy server-side tagging zadziała w sklepie bez dataLayer?
Czy przejście na serwer grozi dublowaniem lub gubieniem konwersji?
Czy server-side tagging na PrestaShop jest zgodny z RODO?
