Wdrożenie GA4 eCommerce w PrestaShop wywala się najczęściej nie na kodzie, a na organizacji: brak listy zdarzeń, brak właściciela po stronie sklepu, brak środowiska testowego i publikacja prosto na produkcji. Poniżej masz część organizacyjną — błędy, które powtarzają się w każdym drugim projekcie, checklistę do odhaczenia przed startem i po nim oraz odpowiedzi na pytania, które klienci zadają najczęściej. Traktuj to jako plan prac, a nie jako opis samego kodu. Jeśli szukasz wyłącznie wtyczki do kliknięcia, ten tekst nie rozwiąże Twojego problemu.
GA4 nie mierzy odsłon i sesji jako osobnych obiektów, do których przypisujesz parametry. Mierzy zdarzenia: klik, dodanie do koszyka, wejście w checkout i zakup to osobne zdarzenia, każde z nazwą i zestawem parametrów. W Universal Analytics wysyłałeś hit typu pageview albo transaction, a raporty budowały się wokół wizyt i odsłon. W GA4 nie ma w interfejsie widoków (Views) ani raportu „Sesje” jako osobnego bytu — sesja i użytkownik to wymiary wyliczane z tych samych zdarzeń.
Drugi element słownika: sprzedaż to w GA4 osobny model danych. Raporty znajdziesz w Monetyzacja → Sklepy internetowe, a Google utrzymuje listę zdarzeń zalecanych dla sklepów: view_item_list, select_item, view_item, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_payment_info, purchase, refund. Tylko zdarzenia o dokładnie tych nazwach i poprawnej strukturze parametrów zasilają raporty sklepu.
Stąd biorą się puste raporty e-commerce przy odnotowanym ruchu. Cztery najczęstsze przyczyny: nazwa zdarzenia z wielkiej litery (Purchase zamiast purchase) i wpadnięcie do „zdarzeń innych”; brak tablicy items w zdarzeniu; purchase, który nigdy nie wystrzelił, bo potwierdzenie zamówienia przenosi użytkownika na bramkę płatności; zgody (consent) blokujące wysyłkę. GA4 zbiera też zdarzenia własne — newsletter_signup zadziała od razu — ale nie zasilą one raportów sklepu. Nazwy zdarzeń są wrażliwe na wielkość liter, więc addToCart i add_to_cart to dla GA4 dwa różne zdarzenia.
Zakres zdarzeń przekłada się wprost na pracochłonność projektu. Przy porównywaniu ofert patrz na liczbę obsłużonych zdarzeń i parametrów, nie na cenę samego modułu — to pokazuje, czy wykonawca wie, co robi. Więcej o tym, kogo wybrać i ile to kosztuje napisaliśmy osobno.
| Universal Analytics | GA4 |
|---|---|
| hit <code>pageview</code> / <code>transaction</code> | osobne zdarzenia: <code>page_view</code>, <code>purchase</code> |
| Widoki (Views) i filtry w widoku | strumienie danych i filtry danych na poziomie właściwości |
| kategoria / akcja / etykieta | nazwa zdarzenia + parametry w zapisie snake_case |
| wtyczka e-commerce i transaction ID | <code>purchase</code> z <code>transaction_id</code> i tablicą <code>items</code> |
| raport E-commerce w sekcji Konwersje | Monetyzacja → Sklepy internetowe oraz Eksploracje |
Łańcuch jest krótki, ale każde ogniwo może się zerwać: kontroler lub hook PrestaShop (PHP) → obiekt JavaScript dataLayer → tag w GTM → request do GA4. Dane o produkcie nie lecą do GA4 bezpośrednio z PHP — najpierw muszą trafić do window.dataLayer na stronie, a GTM odczyta je w momencie zdarzenia.
Masz dwa warianty źródła danych. Pierwszy to gotowy moduł (np. oficjalny moduł Google dla PrestaShop): szybki start, ale ograniczona kontrola — często brakuje item_variant, item_brand albo obsługi wielu walut i kombinacji. Drugi to własny moduł, który przez registerHook() wstrzykuje dane w konkretnych miejscach szablonu. Wtedy mapę zdarzeń trzymasz w jednym pliku JS i sam decydujesz, co idzie do warstwy danych. Jak nie zgubić się na tej drugiej drodze, opisujemy we wdrożeniu DataLayer w PrestaShop.
view_item — karta produktu, np. hook displayProductAdditionalInfo lub displayFooterProduct,add_to_cart / remove_from_cart — actionCartSave albo odpowiedź AJAX koszyka,view_cart — displayShoppingCart,begin_checkout — displayBeforeCarrier lub kontroler zamówienia,purchase — displayOrderConfirmation, po walidacji zamówienia w actionValidateOrder.Nazwy hooków różnią się między wersjami 1.7 i 8.x, więc sprawdź je w dokumentacji dla deweloperów PrestaShop, zamiast kopiować kod z bloga. Organizacja wdrożeń integracji w PrestaShop rządzi się tą samą zasadą: jedno miejsce w kodzie odpowiada za jedno zdarzenie i ma swojego właściciela.
Kolejność ma znaczenie: dataLayer.push() musi wykonać się przed tagiem GTM. Sprawdzenie jest trywialne — view-source, szukaj dataLayer i gtm.js; push musi być wyżej w kodzie. Do podglądu użyj trybu Podglądu w GTM (zakładka Warstwy danych) i filtra collect w zakładce Sieć w DevTools — zobaczysz, czy request poleciał i z jakimi parametrami.
Pułapka, która zjada najwięcej czasu, to cache i optymalizacja JS. CCC w Parametrach zaawansowanych → Wydajność skleja i minifikuje pliki, a moduły odraczające skrypty wykonują push dopiero po interakcji — zdarzenie nigdy nie wystrzeli. Cache strony potrafi też podać w warstwie danych cenę „od” zamiast ceny po zalogowaniu, przez co value w raportach nie zgadza się z PrestaShop.
Poniżej mapa pomiaru do odhaczenia. Kolumna „co musi być” to minimum — bez tego zdarzenie nie zadziała albo wpadnie niekompletne.
Trzy zasady, które najczęściej łamią projekty. items to tablica obiektów, także dla jednego produktu; w środku: item_id (w PrestaShop ustal raz, czy to id_product, czy id_product_attribute dla kombinacji), item_name, price jako cena jednostkowa po rabacie i quantity. currency w formacie ISO 4217, czyli PLN wielkimi literami — pln albo zł nie przejdzie. value zawsze jako liczba, nie string: 199.99, nigdy „199,99” — przecinek i cudzysłów to najczęstszy błąd przy polskiej lokalizacji.
value znaczy co innego w każdym zdarzeniu. W add_to_cart to wartość dodanej pozycji: 3 sztuki po 49,99 zł = 149,97. W purchase to wartość całego zamówienia, czyli produkty plus dostawa plus podatek, po odjęciu rabatów. Jeśli w jednym miejscu liczysz brutto bez dostawy, a w drugim brutto z dostawą, raporty nie zgodzą się z PrestaShop i nikt nie zaufa danym.
transaction_id to numer zamówienia. W multisklepie albo po migracji numeracja może się powtarzać — dopisz prefiks (PS-12345). GA4 odrzuca duplikat tego samego identyfikatora, więc powtórzone testowe zamówienie nie zawyży sprzedaży. Zdarzenie refund najczęściej wysyła się z backendu, bo zwroty robisz w panelu, a nie w przeglądarce klienta.
Parametry dodatkowe, które warto uzupełnić: item_brand (producent), item_category (kategoria domyślna — przy wielu kategoriach wybierz jedną i pilnuj spójności), item_variant (rozmiar, kolor), discount na poziomie pozycji, coupon (kod rabatowy z CartRule), a na poziomie zamówienia shipping i tax. Przy add_payment_info dochodzi payment_type — uzgodnij to przy organizacji wdrożenia modułu płatności w PrestaShop, bo różne bramki zwracają różne nazwy metod.
| Zdarzenie | Gdzie w PrestaShop | Co musi być w dataLayer |
|---|---|---|
| view_item_list | listing kategorii, wyniki wyszukiwania | item_list_id, item_list_name, items[] |
| select_item | klik w kafelek produktu na liście | items[], item_list_id, item_list_name |
| view_item | karta produktu, także po zmianie kombinacji | items[] z item_id, item_name, price, quantity |
| add_to_cart | potwierdzenie dodania do koszyka (AJAX) | items[], value, currency |
| remove_from_cart | usunięcie pozycji z koszyka | items[], value, currency |
| view_cart | strona koszyka | items[], value, currency |
| begin_checkout | wejście w pierwszy krok zamówienia | items[], value, currency, coupon |
| add_payment_info | wybór metody płatności | items[], value, currency, payment_type |
| purchase | strona potwierdzenia zamówienia | transaction_id, items[], value, currency, shipping, tax |
| refund | zwrot lub anulowanie, zwykle z backendu | transaction_id, items[] lub value, currency |
Krok 1 – inwentaryzacja zdarzeń. Zacznij od arkusza: zdarzenie, wyzwalacz, parametry, źródło danych, osoba odpowiedzialna. Minimalny zakres to view_item_list, select_item, view_item, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase. Przy każdym zdarzeniu podejmij trzy decyzje: zbieramy discount, coupon, shipping? W praktyce coupon i shipping dodaj od razu – siedzą w bazie PrestaShop i kosztują kilkanaście minut. Discount tylko wtedy, gdy rabaty nie są dublowane przez moduły koszyka promocyjnego, bo inaczej wartość pozycji nie zgadza się z zamówieniem.
Krok 2 – kontener GTM i tag konfiguracji GA4. Jeden kontener na domenę. Tag Google Analytics: konfiguracja GA4 z Measurement ID w formacie G-XXXXXXXXXX, wyzwalacz All Pages. Rozszerzone pomiary zostaw tylko dla zdarzeń, których nie wysyłasz ręcznie. Każdą publikację opisuj wersją kontenera: data, zakres, autor.
Krok 3 – DataLayer. Zmiany rób w child theme, nie w plikach motywu nadrzędnego – aktualizacja motywu skasuje kod. Logikę koszyka najczęściej wrzuca się przez override kontrolera lub własny moduł podpięty pod hooki displayHeader, actionCartSave i displayOrderConfirmation. Lista hooków i zasady override są w dokumentacji dla deweloperów PrestaShop, a sposób ułożenia tego w spójny plan opisujemy w materiale o wdrożeniu DataLayer w PrestaShop.
Krok 4 – tagi GA4 Event. Dla każdego zdarzenia osobny tag typu GA4 Event z mapowaniem parametrów z DataLayer i wyzwalaczem zdarzenia niestandardowego (Custom Event) o nazwie równej temu, co wypychasz do window.dataLayer. Nazwy w DataLayer i w tagach trzymaj w jednym arkuszu – to najczęstsze miejsce rozjazdu.
Krok 5 – purchase jako konwersja. W GA4: Administracja → Zdarzenia → oznacz purchase jako konwersję. Sprawdź raport Monetyzacja → E-commerce purchases oraz DebugView, czy transaction_id jest niepuste.
Krok 6 – środowisko przedprodukcyjne, publikacja, 72 godziny. Testuj na kopii sklepu z osobnym kontenerem i osobną usługą GA4. Ruch wewnętrzny wyklucz po IP. Po publikacji przez 72 godziny porównuj codziennie liczbę transakcji w GA4 z liczbą zamówień w panelu.
| Obszar | PrestaShop 1.7 | PrestaShop 8.x |
|---|---|---|
| Szablony i child theme | Smarty, modyfikacje w motywie nadrzędnym łatwo zgubić przy aktualizacji | Podobna struktura, nowsza wersja Smarty, więcej szablonów w motywie klasycznym |
| Koszyk AJAX | Moduł ps_shoppingcart, własne selektory JS przy dodaniu do koszyka | Odświeżony front, inne klasy i eventy JS – selektory trzeba potwierdzić w motywie |
| Hooki i checkout | displayOrderConfirmation, actionCartSave działają stabilnie | Te same hooki, ale więcej zmian w szablonach kroków zamówienia – wymagany test po aktualizacji |
Consent Mode ma dwa tryby. Basic oznacza, że bez zgody tagi Google w ogóle się nie ładują – od nieklikającego użytkownika nie masz nic. Advanced ładuje tagi od razu, ale z sygnałami denied, więc Google dostaje sygnał cookieless i dolicza takie wizyty do modelowania konwersji. W naszych wdrożeniach e-commerce różnica w raportowanych konwersjach między basic i advanced to zwykle kilka do kilkunastu procent – im niższy wskaźnik zgód w sklepie, tym większa różnica. To obserwacja z projektów, nie liczba gwarantowana przez Google.
Cztery sygnały wymagane w Consent Mode v2: ad_storage, ad_user_data, ad_personalization i analytics_storage. Bez dwóch środkowych tracisz funkcje reklamowe – remarketing i przekazywanie danych o konwersjach – nawet jeśli analityka działa poprawnie.
Kolejność skryptów jest sztywna. Przed snippetem GTM, w sekcji head, musi pojawić się blok gtag('consent', 'default', ...) z wartościami denied i parametrem wait_for_update: 500. Aktualizacja gtag('consent', 'update', ...) leci dopiero po decyzji użytkownika. Zamiana kolejności powoduje, że pierwsze odsłony idą bez sygnałów.
Ile tracisz? Policz dwa niezależne źródła: liczbę zamówień w PrestaShop z tabeli ps_orders za ostatnie 30 dni i liczbę transakcji w GA4. Różnica to Twój sufit błędu – część to brak zgody, część to błędy wdrożenia. Wskaźnik zgody licz jako stosunek sesji z analytics_storage: granted do wszystkich sesji.
Punkt styku z CMP: banner musi wywoływać consent update z granularnością per kategoria i to przed pierwszym odczytem skryptów, nie po. Banner, który tylko zapisuje cookie, a nie rozmawia z API Google, nie załatwia tematu – to samo dotyczy sytuacji, gdy kolejność integracji gubi się przy okazji innych zmian w sklepie, co opisujemy w tekście o organizacji integracji z PrestaShop.
| Sygnał | Co blokuje przy wartości denied |
|---|---|
| analytics_storage | Cookies pomiarowe GA4, pełne raporty o zachowaniu użytkownika |
| ad_storage | Cookies reklamowe, remarketing, dopasowanie do kampanii |
| ad_user_data | Wysyłanie danych użytkownika do usług Google Ads |
| ad_personalization | Personalizację reklam i wykorzystanie w listach odbiorców |
Diagnostyka bez wchodzenia w kod sprowadza się do trzech narzędzi: Tag Assistant (które tagi i wyzwalacze odpaliły), GA4 DebugView oraz konsola przeglądarki z window.dataLayer. Zanim zgłosisz błąd, sprawdź tabelę poniżej – większość przypadków to jedna z siedmiu sytuacji.
Dwie kwestie wymagają osobnego ustalenia. Pierwsza: brutto czy netto. PrestaShop potrafi pokazywać jedną wartość w koszyku, drugą w zamówieniu i trzecią w panelu, jeśli sklep działa na cenach netto z podatkiem doliczanym na końcu. Ustal jedno źródło prawdy – najlepiej wartość brutto z ps_orders.total_paid – i tę samą wartość wysyłaj do GA4, inaczej rozbieżność w raportach będzie rosła z każdym miesiącem. Druga: (other) i not set w raportach to nie kosmetyka, a sygnał, że parametr nie dochodzi, ma inną nazwę albo leci poza tablicą items. Przy płatnościach przekierowujących na zewnętrzny serwis zdarzenie purchase bywa odpalane na dwóch różnych stronach – warto wtedy ustalić jedną ścieżkę potwierdzenia, co opisujemy przy okazji organizacji wdrożenia modułu płatności PayPal w PrestaShop.
| Objaw | Najczęstsza przyczyna | Test w 5 minut |
|---|---|---|
| Brak transakcji w GA4, choć GTM działa | Wyzwalacz purchase ustawiony na URL potwierdzenia lub skrypt ładuje się po tagu | Tag Assistant + złożenie testowego zamówienia, sprawdź, czy wyzwalacz w ogóle się odpalił |
| Duplikaty purchase | Odświeżenie strony potwierdzenia albo tag odpalony na kilku krokach checkoutu | Odśwież stronę potwierdzenia i policz zdarzenia purchase w DebugView |
| Puste items | Parametr nie jest tablicą albo klucze inne niż w specyfikacji | W konsoli sprawdź ostatni push do dataLayer i typ wartości (Array.isArray) |
| Waluta zł zamiast PLN, value jako tekst | Wartość wstrzyknięta prosto z formatera ceny | W DebugView sprawdź typy parametrów currency i value |
| item_id jako liczba | ID produktu wzięte bez konwersji na tekst | Sprawdź typ item_id w dataLayer, wymuś String(id) przy wypychaniu |
| Rozbieżność brutto i netto | Brak ustalonego jednego źródła prawdy | Porównaj sumę ps_orders.total_paid z sumą wartości purchase w GA4 za tę samą dobę |
| (other) lub not set w raportach | Brak mapowania parametru lub przekroczenie limitów | Raport Zdarzenia, karta parametru – sprawdź, czy wartość dochodzi w ogóle |
Zanim uznasz wdrożenie za skończone, przejdź przez trzy warstwy kontroli: podgląd na żywo, porównanie liczb i audyt surowych danych. Każda wyłapuje inny typ błędu. Pominięcie którejkolwiek kończy się raportem, w który nikt nie wierzy.
Struktura zdarzeń i kolejność ich wyzwalania to temat, który rozstrzyga się wcześniej, na etapie wdrożenia DataLayer w PrestaShop — jeśli warstwa danych jest niespójna, DebugView tylko to pokaże, ale nie naprawi. Warto też zajrzeć do dokumentacji PrestaShop dla deweloperów i sprawdzić, który hook odpowiada za potwierdzenie zamówienia w Twojej wersji sklepu.
Kryterium odbioru jest liczbowe: minimum 95% zgodności liczby transakcji i zero duplikatów w BigQuery. Bez tego nie podpisujesz protokołu odbioru.
| Kontrola | Narzędzie | Kryterium zaliczenia |
|---|---|---|
| Tagowanie i kolejność zdarzeń | Tag Assistant + DebugView | Wszystkie 7 zdarzeń ścieżki zakupowej, brak podwójnego ładowania G- |
| Wartości zdarzeń | Ręczny test + koszyk PrestaShop | Zgodność co do groszowki z koszykiem, VAT i dostawa policzone |
| Zgodność transakcji | PrestaShop vs GA4, okno 24 h | 95%+ zgodności po wykluczeniu testów i zwrotów |
| Duplikaty | Eksport GA4 → BigQuery | Zero transaction_id występujących więcej niż raz |
Podstawowy pomiar to punkt startowy, nie koniec. Rozbudowa ma sens w trzech sytuacjach: tracisz zdarzenia po stronie przeglądarki, sprzedajesz poza sklepem albo potrzebujesz atrybucji na poziomie zamówienia, a nie sesji.
Opieka po wdrożeniu to monitoring, nie gwarancja. Konkretnie: alert, gdy w godzinach handlowych przez 3 h nie ma żadnego purchase, oraz kontrola spadku liczby zdarzeń tydzień do tygodnia powyżej 30%. Reakcja jest potrzebna po każdej aktualizacji szablonu (nadpisuje pliki .tpl z hookiem), po zmianie modułu płatności (zmienia adres powrotu) i po aktualizacji wersji PrestaShop.
Orientacyjne widełki z naszych projektów, żeby było jasne, co zamawiać. Pełny kontekst kosztowy po stronie agencji opisujemy w tekście o kosztach wdrożenia PrestaShop.
| Wariant sklepu | Zakres pomiaru | Czas pracy (godziny) |
|---|---|---|
| Prosty sklep, standardowy checkout, 1 waluta, motyw z rynku | GA4 eCommerce + DataLayer + testy | 8–16 |
| Sklep z modyfikowanym checkoutem, 2–3 waluty, kuponami | GA4 eCommerce + DataLayer + BigQuery + testy | 20–35 |
| Multistore, niestandardowy checkout, marketplace, server-side | Pełny pomiar + import offline + kontener serwerowy | 40–70 |
Start prac bez zatwierdzonej listy zdarzeń i parametrów. Zespół wdraża view_item i add_to_cart, a nikt nie ustalił, czy zbieramy discount, coupon i shipping.
Jak wykryć: Zapytaj dwie osoby z projektu, które zdarzenia wchodzą w zakres. Jeśli odpowiedzi się różnią albo padnie „wszystkie standardowe”, lista nie istnieje.
Jak naprawić: Zrób jednostronicowy dokument: zdarzenie, parametry, kto dostarcza dane, gdzie to sprawdzamy. Podpisz go z właścicielem sklepu przed pierwszym commitem.
Wdrożenie i testy bezpośrednio na produkcji, bez środowiska przedprodukcyjnego.
Jak wykryć: Wystarczy pytanie, gdzie będą testowane zdarzenia. Jeśli odpowiedź brzmi „na sklepie, tylko na testowym zamówieniu”, nie ma środowiska.
Jak naprawić: Postaw kopię sklepu z kopią bazy i wyłączonymi płatnościami lub w trybie piaskownicy. Testowe zdarzenia nie mogą trafiać do produkcyjnej usługi GA4.
Brak właściciela danych po stronie sklepu. Agencja oddaje wdrożenie, nikt nie sprawdza raportów i po miesiącu nikt nie wie, czy danych ubywa.
Jak wykryć: Sprawdź, kto ma uprawnienia administratora w GA4 i GTM. Jeśli tylko agencja i były pracownik, temat jest nierokowany.
Jak naprawić: Ustal jedną osobę po stronie klienta z uprawnieniami administratora i jasnym zadaniem: raz w tygodniu sprawdza raporty e-commerce. Wpisz to do umowy lub maila podsumowującego.
Brak deduplikacji purchase — odświeżenie strony potwierdzenia zamówienia generuje drugie zdarzenie zakupu.
Jak wykryć: Złóż jedno zamówienie i odśwież stronę potwierdzenia trzy razy. W debugu zobaczysz trzy zdarzenia purchase dla jednego transaction_id.
Jak naprawić: Ustaw wysyłkę purchase tylko raz przy potwierdzeniu zamówienia, nie przy każdym wejściu na stronę. Rozwiąż to po stronie modułu lub kontrolera, nie w GTM.
Consent Mode i banner cookies dołożone po zakończeniu wdrożenia, jako osobny temat „na później”.
Jak wykryć: Sprawdź w debugu, czy przed wyrażeniem zgody jakiekolwiek zdarzenia e-commerce wychodzą z parametrami zgody. Jeśli nie wychodzą, a banner był wdrażany osobno, kolejność prac była odwrotna.
Jak naprawić: Zaplanuj zgody w tym samym projekcie co GA4. Najpierw uzgodnij model zgód i sygnały, które mają płynąć do GA4, potem podpinaj zdarzenia.
Testy wyłącznie na jednej ścieżce zakupowej, z pominięciem wariantów koszyka i płatności.
Jak wykryć: Policz, ile metod dostawy i płatności ma sklep, i porównaj z tym, co zostało przetestowane. Jeśli liczba się nie zgadza, testy są niepełne.
Jak naprawić: Przejdź pełną ścieżkę dla każdej kombinacji dostawa + płatność. W PrestaShop kolejność kroków checkoutu bywa modyfikowana modułami i to tam najczęściej giną zdarzenia.
Wdrożenie GA4 eCommerce w PrestaShop to projekt organizacyjny tak samo jak techniczny. Największe ryzyko nie leży w kodzie, a w braku zatwierdzonego zakresu, środowiska testowego i osoby odpowiedzialnej za dane po stronie sklepu. Kolejność prac — lista zdarzeń, zgody, implementacja, testy, publikacja, monitoring 72 godzin — chroni przed najdroższym scenariuszem, czyli wdrożeniem dwa razy. Praktyczne rozwinięcie samej warstwy technicznej znajdziesz w artykule o DataLayer w PrestaShop.
Realistycznie od kilku dni do dwóch–trzech tygodni, licząc od zatwierdzenia listy zdarzeń do publikacji. Najwięcej czasu zajmuje nie kod, a uzgodnienia zakresu i testy na środowisku przedprodukcyjnym. Sklepy z mocno przerobionym checkoutem i wieloma metodami płatności wypadają bliżej górnej granicy.
Gotowy moduł pokrywa zdarzenia standardowe i zwykle wystarcza na start. Własny moduł wpinający się w hooki PrestaShop jest potrzebny wtedy, gdy chcesz niestandardowe parametry albo masz przerobiony koszyk i checkout. Decyzję podejmij po inwentaryzacji zdarzeń, a nie przed nią.
Tak, jeśli dataLayer ma być wyprowadzany z hooków lub szablonu. Potrzebny jest dostęp do plików sklepu i do panelu GTM. Przy pracy wyłącznie na gotowym module wystarczy panel PrestaShop i konto GTM, ale wtedy zakres pomiaru jest ograniczony tym, co oferuje moduł.
Nie. Rozsądny start to view_item, add_to_cart, begin_checkout i purchase — te cztery dają odpowiedź na większość pytań o sprzedaż. Reszta, czyli view_item_list, select_item, remove_from_cart, view_cart, add_payment_info i refund, może wejść w drugim etapie. Ważne, żeby kolejność była zaplanowana, a nie przypadkowa.
Temat zgód trzeba zaplanować razem z pomiarem, nie po nim. Kolejność prac ma znaczenie: najpierw model zgód i to, jakie sygnały płyną do GA4, potem podpinanie zdarzeń e-commerce. Jeżeli wdrożysz zdarzenia pierwsze, a zgody drugie, najczęściej wracasz do konfiguracji tagów od nowa.
Porównaj liczbę transakcji z GA4 z liczbą zamówień w panelu PrestaShop za ten sam okres. Różnica rzędu kilku procent jest normalna — wynikają z blokad, zgód i anulowanych zamówień. Skokowy spadek albo stale zaniżony wynik o kilkadziesiąt procent oznacza, że trzeba wrócić do konfiguracji, a nie do raportów.
Wykonanie może robić agencja lub wewnętrzny deweloper, ale właściciel listy zdarzeń i odbioru danych powinien być po stronie sklepu. Bez tej osoby nikt nie zauważy, że po aktualizacji modułu zdarzenia przestały wychodzić. Ustal to na piśmie jeszcze przed startem.
Jeśli chcesz przejść ten proces bez zgadywania, możemy zacząć od jednej rozmowy o zakresie i kolejności prac. Napisz do DropDigital, gdy będziesz mieć listę zdarzeń albo pytanie, od czego ją zacząć.