Co dziś obejmuje „najnowszy standard Google” w analityce

„Najnowszy standard Google” w analityce to nie jedna funkcja, a cztery elementy, które działają dopiero razem. Wdrożenie dwóch z czterech daje dane, którym nie można ufać — i zwykle nie wiadomo, który element zawinił.

• GA4 — pomiar na zdarzeniach i parametrach, nie na sesjach i odsłonach. Każde działanie użytkownika to event z nazwą i zestawem parametrów; raporty budujesz z tych danych, a nie z gotowych widoków.
• Google Tag Manager — web container, a przy sklepie z koszykiem i płatnościami także container server-side. GTM jest jedynym miejscem definiowania tagów.
• Consent Mode v2 — cztery sygnały zgody przekazywane do Google przed odpaleniem tagów analitycznych i reklamowych.
• Konwersje rozszerzone w Google Ads — przekazywanie zaszyfrowanych danych kontaktowych (e-mail, telefon) z formularzy i zamówień, żeby dopasować konwersje do kliknięć przy ograniczonym cookies.

Granica, od której liczy się „od zera”: Universal Analytics nie zbiera danych od 1 lipca 2023, a historyczne raporty były dostępne tylko do 1 lipca 2024. Zestawienie „rok do roku” ze starym UA to porównanie dwóch różnych systemów pomiaru — wyciągniesz z niego tylko błędne wnioski.

Jedno źródło prawdy: wszystkie tagi idą przez GTM. Ręcznie wklejony gtag w szablonie sklepu albo w pliku motywu to dług, który przy pierwszej zmianie CMP albo migracji wybuchnie — i nikt nie będzie wiedział, ile instancji tagu faktycznie działa na stronie.

Retencja danych: w GA4 domyślnie przechowywane są 2 miesiące danych zdarzeń, maksymalnie 14 miesięcy. Ustawiasz to świadomie w opcjach usługi (Administrator → Ustawienia danych → Przechowywanie danych). Dwa miesiące wystarczą na raport tygodniowy, nie na analizę sezonową.

Standardy są wersjonowane — Google zmienia wymagania co kilka kwartałów. Wdrożenie przeglądaj co kwartał: nowe sygnały zgody, zmiany w modelowaniu, wygaszane funkcje.

Krok 1: plan pomiaru, czyli 12 zdarzeń zamiast 200

Najczęściej pomijany etap wdrożenia to plan pomiaru. Zespół od razu siada do GTM, tworzy triggery, a po miesiącu okazuje się, że nikt nie wie, po co jest 60 z 70 zdarzeń. Zacznij od inwentaryzacji: wypisz zdarzenia, które mają konsumenta — osobę, która realnie otworzy raport i coś z nim zrobi.

Rdzeń e-commerce (nazwy zgodne ze specyfikacją GA4): view_item_list, view_item, add_to_cart, remove_from_cart, begin_checkout, add_payment_info, purchase, refund. Do tego zdarzenia niezwiązane z koszykiem: search i sign_up. To wystarczy do większości sklepów — resztę dopisujesz, gdy pojawi się konkretne pytanie biznesowe.

Parametry item — minimalny sensowny zestaw: item_id, item_name, price, quantity, item_brand, item_category. Bez item_id nie połączysz sprzedaży z katalogiem, bez item_brand nie sprawdzisz, czy promocja marki kręci sprzedaż. Parametry przekazujesz jako tablicę items nie tylko przy purchase, ale też przy add_to_cart i view_item — inaczej nie policzysz porzuceń koszyka w rozbiciu na produkty.

Konwencja nazewnicza: snake_case, bez polskich znaków i spacji, do 40 znaków (limit nazwy zdarzenia i parametru w GA4). „Dodanie_do_koszyka” i „addToCart” w jednym kontenerze to gwarancja, że raporty rozjadą się po pierwszej refaktoryzacji.

Tabela robocza to jedno miejsce prawdy przed wdrożeniem. Kolumny: zdarzenie → trigger w GTM → hook lub miejsce w kodzie → właściciel → status (do zrobienia / wdrożone / zweryfikowane). W PrestaShop miejscem w kodzie będzie kontroler lub hook modułu, w WooCommerce — hooki koszyka i zamówień opisane w dokumentacji WooCommerce. Status „zweryfikowane” wpisujesz dopiero po sprawdzeniu zdarzenia w DebugView, nie po zapisaniu tagu.

Zasada: mniej zdarzeń, ale każde z właścicielem i celem biznesowym. 200 eventów bez konsumenta to koszt utrzymania, nie wartość analityczna.

Krok 2: zgody i Consent Mode v2 — kolejność ma znaczenie

Warstwa zgód musi powstać przed tagami analitycznymi, nie po nich. Jeśli wdrożysz GTM pierwszy, a CMP dopiero za tydzień, przez ten tydzień zbierasz dane bez podstawy i po audycie możesz je stracić.

Cztery sygnały Consent Mode v2: ad_storage, ad_user_data, ad_personalization, analytics_storage. Dwa pierwsze i czwarty dotyczą zbierania danych, trzeci — wykorzystania ich do personalizacji reklam. Wszystkie ustawiasz jawnie; brak sygnału to nie to samo co „denied”.

Prawidłowa kolejność:

• Baner lub CMP ładuje się jako pierwszy i wywołuje domyślną zgodę (consent default) z wartościami denied dla wszystkich czterech sygnałów.
• GTM startuje w trybie wstrzymanym — ustawienie wait_for_update na ok. 500 ms, żeby kontener poczekał na decyzję użytkownika, zamiast odpalać tagi od razu.
• Dopiero potem odpalają się tagi GA4 i Google Ads, a po decyzji użytkownika CMP wysyła consent update.

Skutek złej kolejności: tagi startują z „granted” przed decyzją użytkownika. W praktyce kończy się to utratą danych po audycie albo zaniżonym modelem konwersji, bo Google widzi ruch bez ważnej zgody. Weryfikacja jest prosta — w DebugView i w żądaniu do collect sprawdź parametr gcs: G100 oznacza odmowę dla obu podstawowych sygnałów, G111 zgodę.

Wymóg dla EOG: przy tagach Google musisz stosować Consent Mode dla ruchu z Europejskiego Obszaru Gospodarczego. Bez tego nie dostajesz modelowania zachowań ani modelowanych konwersji — a to często kilkanaście procent brakujących danych.

Modelowanie wymaga historii ruchu ze zgodą, minimum kilku tygodni. Nie zadziała od pierwszego dnia po wdrożeniu. Szczegóły sygnałów i ich mapowanie na tagi opisujemy w artykule GA4, Google Ads, zgody i dane użytkownika: Consent Mode v2.

Krok 3: wdrożenie w PrestaShop — hooki, które naprawdę działają

W PrestaShop definicję dataLayer wstawiasz w hooku displayHeader — w pliku header.tpl szablonu, nad kodem kontenera GTM. Kolejność ma znaczenie: jeśli definicja wyląduje niżej, tagi zdarzeń odczytają undefined i wyślą puste parametry. Do tego dochodzi cała lista hooków akcji, które trzeba świadomie wybrać.

• actionCartSave — dodanie do koszyka i zmiana ilości. Musisz odróżnić jedno od drugiego, inaczej każda aktualizacja ilości nabija kolejne add_to_cart.
• actionValidateOrder — zamówienie zapisane w bazie. Dobre miejsce na zapis flagi „wysłano purchase”.
• displayOrderConfirmation — strona potwierdzenia. Tylko tutaj wysyłaj purchase, i tylko raz, sprawdzając flagę w sesji lub ciasteczku z ID zamówienia. Klient, który odświeży stronę albo wróci z bramki płatności, inaczej nabije drugą i trzecią konwersję. Widzieliśmy sklepy z 30–40% zawyżeniem liczby zakupów wyłącznie z tego powodu.

Spójność wartości: ustal jedną definicję — netto czy brutto, z dostawą czy bez — i użyj jej identycznie w GA4 i w Google Ads. Jeśli GA4 dostaje brutto z dostawą, a Ads netto bez, ROAS liczysz z dwóch różnych światów i podejmujesz decyzje budżetowe na fikcji. Zapisz to jedno zdanie w dokumentacji projektu.

Moduł własny czy płatna wtyczka? Typowy zakres własnego modułu to 8–16 godzin pracy, przy migracji z Universal Analytics i testach 24–40 godzin. Płatna wtyczka bywa tańsza na start, ale przy nestandardowym checkoutcie i tak kończy się dopłatami. Pamiętaj też o wersjach: PrestaShop 1.7 i 8.x różnią się strukturą hooków i szablonami checkoutu — moduł pisany pod 1.7 bez testów na 8.x potrafi nie odpalić na stronie potwierdzenia. Testuj na kopii z prawdziwym zamówieniem, nie tylko w podglądzie. Dokumentacja hooków: PrestaShop Developer Documentation.

Krok 4: wdrożenie w WooCommerce — HPOS i checkout blokowy

W WooCommerce bazowe hooki to woocommerce_add_to_cart, woocommerce_checkout_order_processed oraz woocommerce_order_status_changed. Ostatni jest potrzebny do zwrotów i anulowań — bez niego GA4 pokazuje sprzedaż, której nie ma, a zwrot zostaje w raportach jako pełna wartość.

HPOS (High-Performance Order Storage) to zmiana, która wywala najwięcej wtyczek analitycznych. Zamówienia przestają być wpisami w wp_posts i zaczynają żyć we własnych tabelach. Wtyczka czytająca je przez get_post_meta() nie widzi nic — efekt to zero zamówień w GA4 przy rosnącej sprzedaży w panelu. Przed wdrożeniem sprawdź w WooCommerce → Ustawienia → Zaawansowane → Funkcje, czy HPOS jest włączony, i przetestuj każdą wtyczkę analityczną osobno.

Checkout blokowy (Cart/Checkout Blocks) działa w React. Klasyczne hooki PHP nie wystarczą — potrzebny jest osobny trigger po stronie frontu, np. nasłuch zdarzenia wc-blocks_place_order albo własny push do dataLayer po potwierdzeniu zamówienia. Stare snippety z forów po prostu nie odpalą.

Duplikacja przez cache i optymalizację JS: WP Rocket i LiteSpeed z opcją „delay JS” potrafią odpalić add_to_cart dwa razy, bo skrypt startuje po interakcji użytkownika, a potem przy ponownym załadowaniu strony. Wyklucz koszyk, checkout i stronę potwierdzenia z opóźniania JS oraz z cache pełnostronicowego.

Test kontrolny: złóż 5 zamówień — z dostawą, bez dostawy, z kodem rabatowym, ze zwrotem, z płatnością odroczoną. Porównaj liczbę purchase w GA4 (DebugView plus raporty czasu rzeczywistego) z backendem sklepu. Różnica większa niż jedno zdarzenie oznacza problem do naprawy przed publikacją, nie po. Punkt odniesienia: WooCommerce Documentation.

Krok 5: higiena kontenera GTM — struktura, wersje, nazewnictwo

Kontener, w którym „ktoś kiedyś coś dodał”, kosztuje więcej niż nowy. Podstawa: podział na kontener web i kontener server (gdy zbierasz dane wrażliwe albo planujesz konwersje offline) oraz osobne środowiska dev / staging / prod powiązane z domenami. Na stagingu testujesz zmiany — nie na produkcji w piątek po 16:00.

Jeden tag konfiguracyjny GA4, reszta to tagi zdarzeń. Żadnych tagów „All Pages” poza konfiguracją: jeśli widzisz trzy tagi odpalane na każdej podstronie, masz kontener do przebudowy.

Konwencja nazw: [GA4] – purchase, [Ads] – konwersja zakup. Nawiasy kwadratowe na początku sortują listę, więc audyt kontenera zajmuje minuty, nie dni. Wersjonowanie z komentarzem przy każdej publikacji to 60 sekund pracy, które ratują przy debugowaniu spadku danych po miesiącu. „Podmiana tagu purchase” to za mało — napisz, co zmieniłeś i po co.

Zakaz wysyłania danych osobowych (e-mail, telefon, imię i nazwisko) w parametrach zdarzeń. Adresy URL potrafią zawierać e-mail w query stringu, więc włącz redakcję parametrów w ustawieniach tagu i w Google Analytics. Kolejność zgód i przekazywanie sygnału do Google Ads to szerszy temat — opisujemy go w tekście GA4, Google Ads, zgody i dane użytkownika: Consent Mode v2.

Podgląd w GTM (Preview) i Tag Assistant to domyślny tryb pracy, nie „wdrożymy i zobaczymy za tydzień”. Każda zmiana przechodzi przez podgląd, każda publikacja ma wersję i komentarz.

Krok 6: server-side tagging — kiedy ma sens, a kiedy to koszt bez zysku

Server-side tagging nie jest „nowszym GA4”. To zmiana miejsca, w którym wykonuje się kod. Zamiast kilkunastu skryptów w przeglądarce klienta, przeglądarka wysyła jedno żądanie na Twoją subdomenę (np. sgtm.twojadomena.pl), a kontener po stronie serwera decyduje, co dalej trafi do GA4, Google Ads czy Meta. Cookies ustawiane są wtedy przez nagłówki HTTP na Twojej domenie, a nie przez domenę dostawcy — stąd bierze się efekt „first-party”.

Zanim ktoś w firmie powie „robimy server-side, bo tak trzeba”, sprawdź cztery rzeczy:

• ruch — od ok. 100 tys. sesji miesięcznie w górę; przy 10 tys. oszczędność czasu ładowania trudno zmierzyć w wynikach,
• liczba odbiorców danych — GA4 + Google Ads + Meta + TikTok + CRM; przy jednym odbiorcy centralna kontrola niewiele daje,
• czas ładowania — jeśli tagi realnie odpowiadają za część LCP na mobile, mniej JS w przeglądarce pomoże,
• blokada skryptów — gdy GA4 pokazuje wyraźnie mniej sesji niż logi serwera, przeniesienie wysyłki na własną subdomenę ma sens.

Do policzenia po stronie kosztów: hosting kontenera (Cloud Run albo App Engine — sprawdź aktualny cennik Google Cloud, przy małym ruchu mieści się w darmowych limitach, przy większym płacisz za żądania i CPU), subdomena first-party z certyfikatem SSL i rekordem CNAME w DNS, czas wdrożenia (samo podniesienie kontenera to kilka godzin, migracja tagów i testy — zwykle kilkanaście) oraz utrzymanie: aktualizacje szablonów, monitoring, kwartalne przeglądy.

Najważniejsze: server-side nie zwalnia z obowiązku zgód. Consent Mode obowiązuje tak samo, a kontener serwerowy nie jest obejściem RODO ani blokerów — jeśli ma służyć „przemycaniu” tagów bez zgody, to problem prawny, nie techniczny. Zysk jest inny: mniej JS w przeglądarce, jedno miejsce kontroli nad tym, co wychodzi do dostawców, łatwiejsza anonimizacja i hashowanie danych przed wysyłką. Mechanikę zgód i sygnałów opisujemy szerzej w artykule o Consent Mode v2 w GA4 i Google Ads.

Dla sklepu z kilkoma–kilkunastoma tysiącami sesji miesięcznie poprawnie zbudowany kontener web prawie zawsze wystarczy. Te godziny lepiej wydać na jakość zdarzeń i testy — zobacz krok 7.

Krok 7: jak sprawdzić, że dane są prawdziwe — 5 testów i tolerancje

Weryfikację robisz przed pierwszym raportem dla zarządu, nie po nim. Pięć testów, które w praktyce wyłapują 90% błędów:

1. DebugView (GA4 → Administracja → DebugView, uruchamiane podglądem tagów) — sprawdź, czy purchase ma value, currency, transaction_id i listę items. Osobno testuj na wyczyszczonych cookies (przed zgodą) i po akceptacji.
2. Realtime — czy zdarzenia dochodzą w 30–60 sekund i czy widać je z różnych źródeł, nie tylko Direct.
3. Tag Assistant — czy tagi odpalają się zgodnie z wyzwalaczami i czy nie ma duplikatu (klasyka: gtag w szablonie motywu plus ten sam tag w GTM).
4. Raport zdarzeń w GA4 — czy zdarzenia mają komplet parametrów i czy nie ma (not set) w źródle/medium.
5. Porównanie z backendem sklepu — liczba zamówień w GA4 vs panel PrestaShop lub WooCommerce w tym samym okresie i tej samej strefie czasowej.

Tolerancja: różnica zamówień GA4 vs backend powinna mieścić się w ok. ±2–3%. Większa oznacza duplikację (tag odpalany i przez moduł, i przez GTM) albo blokadę tagu. Inaczej jest między GA4 a Google Ads: 5–15% różnicy to norma, bo inne są modele atrybucji i okna konwersji. To nie powód, żeby od razu przepinać kontener.

Sygnały złych danych, które widzimy najczęściej: (not set) w kluczowych wymiarach, duży udział (other)/Unassigned, nagły skok ruchu Direct i spadek konwersji dokładnie w dniu wdrożenia. Zanim opublikujesz raporty, ustaw filtr ruchu wewnętrznego (Administracja → Definicje ruchu wewnętrznego), dodaj IP biura i VPN oraz znane boty — i sprawdź, czy IP biura nie siedzi już w danych.

Rytm utrzymania: przegląd kontenera i zgodności co kwartał, a przy każdej publikacji wpis w dzienniku zmian (wersja kontenera, data, co zmieniono, kto zatwierdził). Jeśli w GA4 widzisz dużo (other), wróć do tematu zgod, sygnałów i modelowania w Consent Mode v2 — zwykle problem siedzi w kolejności odpalania tagów.

Ile to trwa i ile kosztuje — widełki bez cennika z sufitu

Nie podamy stawek złotówkowych, bo różnią się między zespołami i zależą od stawki godzinowej. Podajemy godziny — to dane, które możesz porównać w ofertach.

Typowe zakresy: audyt i plan pomiaru 4–8 h; wdrożenie GA4 + GTM na małym sklepie 12–24 h; e-commerce z Consent Mode v2 i server-side 32–60 h; utrzymanie 2–4 h miesięcznie. Widełki są szerokie, bo „mały sklep” z domyślnym checkoutem i sklep z rozbudowanym koszykiem to dwie różne prace.

Co podnosi nakład: niestandardowy checkout i kroki koszyka, checkout blokowy w WooCommerce, HPOS i inne nietypowe miejsca składania zamówienia, integracja z ERP (statusy zamówień, zwroty, zamówienia telefoniczne), migracja lub porządkowanie danych historycznych, a także wiele źródeł danych do zunifikowania. Każdy z tych punktów potrafi dodać kilka–kilkanaście godzin.

Wycena z liczby godzin, nie z pakietu. Po audycie wiadomo dokładnie, co jest w zakresie, a co nie — i za co płacisz dodatkowo. To chroni obie strony: Ty nie płacisz za funkcje, których nie użyjesz, a wykonawca nie dokłada pracy „w cenie”.

Utrzymanie to nie dodatek, tylko warunek, żeby dane po pół roku nadal były prawdziwe: aktualizacje szablonów tagów, weryfikacja kluczowych zdarzeń, drobne zmiany w kontenerze, przegląd zgodności. Warto zapisać to jako osobną pozycję z jasnym SLA reakcji — np. „zgłoszenie błędów w pomiarze: reakcja w 1 dzień roboczy”. Bez tego pierwszy błąd w purchase zostanie zauważony przy zamknięciu miesiąca, kiedy dane są już bezużyteczne.

Na koniec: w artykule znajdziesz listę kontrolną do odklikania przed startem kampanii i przed każdym większym wdrożeniem. Przejdź ją punkt po punkcie — taniej jest sprawdzić pozycję „zgody i filtrowanie ruchu wewnętrznego” niż tłumaczyć się z zaniżonych konwersji.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Inwentaryzacja zdarzeń e-commerce — Przed kodem wypisz listę rdzeniową: view_item_list, view_item, add_to_cart, remove_from_cart, begin_checkout, add_payment_info, purchase, refund, plus search i sign_up, jeśli mają sens w Twoim sklepie.
• Minimalny zestaw parametrów item — item_id, item_name, price, quantity, item_brand, item_category — sprawdź, czy każdy z nich ma źródło danych w koszyku lub katalogu, zanim zaczniesz mapować tagi.
• Konwencja nazewnicza — snake_case, bez polskich znaków i spacji, do 40 znaków. Zapisz ją w jednym miejscu i stosuj także do parametrów zdarzeń, nie tylko nazw.
• Tabela robocza wdrożenia — Kolumny: zdarzenie → trigger w GTM → hook lub miejsce w kodzie → właściciel → status (do zrobienia / wdrożone / zweryfikowane). Bez właściciela zdarzenie zwykle nie powstaje.
• Jeden kanał tagowania — Sprawdź szablony pod kątem ręcznie wklejonego gtag i usuń go. Wszystkie tagi mają iść przez GTM.
• Retencja danych w GA4 — Administracja → Ustawienia danych → Retencja danych zdarzeń: ustaw 14 miesięcy. Sprawdź też ustawienia na poziomie usługi, nie tylko usługi GA4 w GTM.
• Cztery sygnały Consent Mode v2 — ad_storage, ad_user_data, ad_personalization, analytics_storage — wszystkie cztery muszą być ustawiane przez CMP, nie tylko analytics_storage.
• Kolejność: consent → GTM → tagi — Zweryfikuj w Tag Assistant, że default consent jest przed inicjalizacją kontenera, a GTM czeka z wait_for_update ok. 500 ms.
• purchase na potwierdzeniu zamówienia — Trigger tylko na displayOrderConfirmation, plus flaga w sesji lub ciasteczku blokująca ponowne wysłanie po odświeżeniu. Testuj odświeżeniem strony.
• Test w podglądzie GTM i Tag Assistant — Przejdź ścieżkę: lista → produkt → koszyk → checkout → zamówienie. Każde zdarzenie musi się pojawić raz, z poprawnymi parametrami.
• Porównanie transakcji z backendem — Zestaw liczbę transakcji i przychód z GA4 z danymi z panelu sklepu za ten sam okres. Różnica powinna być niewielka i wytłumaczalna.
• Konwersje rozszerzone w Google Ads — Sprawdź, czy przekazujesz hash e-maila i czy tag konwersji odpala się po zdarzeniu purchase, a nie na samym wejściu na stronę potwierdzenia.
• Dokumentacja wdrożenia — Jeden plik: lista zdarzeń, parametry, triggery, hooki, właściciele, data ostatniego przeglądu. Bez tego każda zmiana personelu zaczyna projekt od zera.
• Kwartalny przegląd — Wpisz w kalendarz co trzy miesiące: nowe tagi, zmiany standardów, poprawność zgód i konwersji. Wdrożenie to proces, nie jednorazowy projekt.

Najczęściej zadawane pytania

Źródła i materiały

• PrestaShop – dokumentacja dla deweloperów
• WooCommerce – dokumentacja
• MDN Web Docs – HTTP
• Google Ads – dokumentacja API
• Google Search Central – tworzenie treści dla ludzi