Analityka e-commerce w Google Analytics 4 – kompletny poradnik 2026

Google Analytics 4 to nie kolejna wersja starego narzędzia, lecz inny model pomiaru. Cały system opiera się na zdarzeniach (events) zamiast na podziale na sesje i odsłony. Dla e-commerce oznacza to, że każda interakcja (obejrzenie produktu, dodanie do koszyka, zakup) jest osobnym zdarzeniem z własnymi parametrami, co daje znacznie dokładniejszy obraz ścieżki zakupowej.

Najważniejsze atuty GA4 dla sklepu:

• Machine learning i predykcja – GA4 wylicza prawdopodobieństwo zakupu i prawdopodobieństwo rezygnacji, co pozwala budować listy odbiorców o wysokim potencjale.
• Integracja z ekosystemem Google – natywne połączenie z Google Ads, Search Console i BigQuery bez płatnych konektorów.
• Pomiar cross-device – jeden użytkownik na telefonie i laptopie jest sklejany w jedną ścieżkę dzięki sygnałom Google.
• Brak twardych limitów próbkowania w standardowych raportach przychodu.

Dla właściciela sklepu internetowego to fundament: bez tych danych nie da się policzyć realnego zwrotu z kampanii ani zoptymalizować lejka.

Universal Analytics zostało wyłączone w lipcu 2023 roku i od tego czasu nie zbiera danych. GA4 to obecnie jedyna oficjalna opcja, dlatego porównanie ma już głównie wartość edukacyjną, ale tłumaczy, dlaczego dane wyglądają inaczej.

Model danych. UA liczyło odsłony i sesje. GA4 liczy zdarzenia, więc raporty e-commerce trzeba budować wokół `purchase`, `add_to_cart` itd., a nie wokół celów typu odsłona strony podziękowania.

Próbkowanie. GA4 w raportach standardowych nie próbkuje danych tak agresywnie jak UA, co poprawia wiarygodność przy dużym ruchu.

Retencja danych. Dane na poziomie zdarzeń i użytkownika przechowywane są domyślnie 2 lub 14 miesięcy (ustawiane w panelu). Raporty zbiorcze nie znikają, ale eksploracje bazujące na surowych danych respektują ten okres – dlatego warto połączyć GA4 z BigQuery, jeśli potrzebujesz historii.

Prywatność. GA4 projektowano pod RODO: anonimizacja IP jest domyślna, a Consent Mode v2 jest wymagany do prawidłowego działania w UE.

Zanim cokolwiek wdrożysz, zbierz dostępy i sprawdź wymagania techniczne. Brak jednego elementu potrafi zablokować pomiar na kilka dni.

Dostępy i konta:

• Konto Google z założoną usługą Google Analytics 4 (rola Edytor lub Administrator).
• Konto Google Tag Managera (zalecane) z opublikowanym kontenerem.
• Dostęp administracyjny do CMS sklepu (WooCommerce, Shoper, PrestaShop, Shopify) – do wgrania kodu lub wtyczki.

Wymagania techniczne:

• Możliwość wstrzyknięcia kodu w sekcję `` lub przez menedżer tagów.
• Wsparcie dla warstwy danych (dataLayer) – natywne lub przez wtyczkę.
• Spójny feed produktowy (te same ID produktów, których użyjesz w zdarzeniach – muszą zgadzać się z Google Merchant Center).

Jeśli sklep ma już zainstalowany GTM, połowa pracy jest za Tobą. Jeśli nie, zacznij od niego – to inwestycja, która zwróci się przy każdej kolejnej zmianie pomiaru.

Krok 1 – usługa i strumień. W panelu GA4 wejdź w Administracja → Utwórz usługę, podaj nazwę i strefę czasową (Polska, PLN jako waluta raportowania). Następnie dodaj strumień danych typu Web, wpisując adres sklepu. GA4 wygeneruje Measurement ID w formacie `G-XXXXXXX`.

Krok 2 – wybór metody wdrożenia. Masz trzy drogi:

• gtag.js – kod wklejany bezpośrednio na stronę. Prosty na start, ale każda zmiana zdarzeń wymaga ingerencji w kod. Słaby wybór przy rozbudowanym e-commerce.
• Google Tag Manager – rekomendowany. Kod GTM wdrażasz raz, a wszystkie tagi i zdarzenia konfigurujesz w panelu bez dotykania szablonu. Daje pełną kontrolę nad warstwą danych i zgodami.
• Gotowy moduł platformy – wtyczki dla WooCommerce (np. GA4 e-commerce), moduły Shopera czy PrestaShop generują dataLayer automatycznie. Najszybsze wdrożenie, ale czasem mniej elastyczne.

Dla większości sklepów najlepszy jest model hybrydowy: wtyczka generuje dataLayer, a GTM wysyła zdarzenia do GA4. Tak właśnie konfigurujemy pomiar w projektach sklepowych.

W panelu GA4, w ustawieniach strumienia danych, włącz Ulepszony pomiar – automatycznie zbierze scrollowanie, kliknięcia w linki wychodzące i wyszukiwania w witrynie. To jednak nie wystarcza do e-commerce: dane o sprzedaży muszą trafiać przez dedykowane zdarzenia z parametrami produktowymi.

Pełna, rekomendowana przez Google ścieżka zdarzeń e-commerce:

• view_item_list – wyświetlenie listy produktów (kategoria, wyniki wyszukiwania).
• select_item – kliknięcie produktu z listy.
• view_item – wyświetlenie karty produktu.
• add_to_cart – dodanie do koszyka.
• view_cart – wyświetlenie koszyka.
• remove_from_cart – usunięcie z koszyka.
• begin_checkout – rozpoczęcie procesu zamówienia.
• add_shipping_info – wybór metody dostawy.
• add_payment_info – wybór metody płatności.
• purchase – zakup (najważniejsze zdarzenie).
• refund – zwrot.
• view_promotion / select_promotion – wyświetlenie i kliknięcie promocji (bannery, kampanie wewnętrzne).

Nazwy zdarzeń są wielkością liter wrażliwe i muszą być zapisane dokładnie tak jak wyżej – GA4 rozpozna je jako e-commerce tylko przy zgodnym nazewnictwie.

Warstwa danych to obiekt JavaScript, który przekazuje informacje o produktach i transakcjach z sklepu do GTM. Sercem każdego zdarzenia e-commerce jest tablica items z parametrami produktowymi (id, nazwa, cena, kategoria, ilość). Parametry eventowe (np. `value`, `currency`, `transaction_id`) opisują całe zdarzenie.

Przykład add_to_cart:

dataLayer.push({ ecommerce: null });
dataLayer.push({
  event: 'add_to_cart',
  ecommerce: {
    currency: 'PLN',
    value: 199.00,
    items: [{
      item_id: 'SKU-123',
      item_name: 'Buty trekkingowe',
      item_category: 'Obuwie',
      price: 199.00,
      quantity: 1
    }]
  }
});

Przykład purchase (z transakcją):

dataLayer.push({ ecommerce: null });
dataLayer.push({
  event: 'purchase',
  ecommerce: {
    transaction_id: 'ZAM-2026-00487',
    value: 398.00,
    tax: 74.45,
    shipping: 0,
    currency: 'PLN',
    items: [{ item_id: 'SKU-123', item_name: 'Buty trekkingowe', price: 199.00, quantity: 2 }]
  }
});

Linia `ecommerce: null` przed każdym push czyści poprzednie dane – bez niej produkty z jednego zdarzenia mogą wyciec do kolejnego. item_id musi zgadzać się z ID z feedu produktowego, inaczej raporty Google Ads i GA4 się rozjadą.

Mając poprawny dataLayer, konfigurujesz przekazanie zdarzeń do GA4 w Tag Managerze.

1. Zmienne dataLayer. Utwórz zmienną typu Data Layer Variable o nazwie `ecommerce`, aby GTM odczytywał całą strukturę e-commerce. Dodatkowo przyda się zmienna na `transaction_id` (do blokady duplikatów).

2. Tag konfiguracyjny / główny. Dodaj tag Google Tag (Google Analytics: GA4 Configuration) z Twoim Measurement ID `G-XXXXXXX`, wyzwalany na All Pages. To on inicjuje pomiar.

3. Tagi zdarzeń. Dla każdego zdarzenia e-commerce utwórz tag typu GA4 Event, w polu Event Name wpisz nazwę (np. `purchase`), zaznacz opcję wysyłania danych e-commerce z warstwy danych (Send Ecommerce data → Data Layer).

4. Reguły wyzwalające. Stwórz wyzwalacz typu Custom Event dopasowany do nazwy z dataLayer (Event name równe `purchase`). Powtórz dla każdego zdarzenia.

5. Publikacja. Przetestuj w trybie Preview, potem opublikuj kontener. Każda zmiana pomiaru sprowadza się odtąd do edycji w GTM, bez ruszania kodu sklepu.

Kluczowe parametry transakcji, bez których raporty będą niepełne:

• transaction_id – unikalny numer zamówienia, klucz do eliminacji duplikatów.
• value – wartość transakcji jako liczba (kropka jako separator dziesiętny, bez spacji i symbolu zł).
• currency – kod waluty w formacie ISO, czyli PLN (nie zł, nie PLN z małej).
• items – tablica produktów z `item_id` zgodnym z feedem.

Oznaczanie konwersji (kluczowych zdarzeń). W GA4 wejdź w Administracja → Zdarzenia i włącz przełącznik Oznacz jako kluczowe zdarzenie przy `purchase` (oraz np. `begin_checkout`, jeśli traktujesz je jako mikrokonwersję). Dopiero takie zdarzenia trafią do Google Ads jako konwersje.

Consent Mode v2 i RODO. Na rynku polskim banner cookie i zgody są obowiązkowe. Consent Mode v2 przekazuje do Google status zgód (`ad_storage`, `analytics_storage`, `ad_user_data`, `ad_personalization`). Bez niego od 2024 roku listy remarketingowe i pełne dane konwersji nie działają w UE. Wdróż CMP (np. Cookiebot, Complianz) zintegrowany z GTM tak, aby tagi GA4 i Google Ads respektowały wybór użytkownika. To nie tylko zgodność z prawem, ale też warunek poprawnego modelowania konwersji.

Weryfikacja wdrożenia. Użyj trybu Preview w GTM (Tag Assistant) razem z DebugView w GA4 (Administracja → DebugView). Przejdź pełną ścieżkę zakupu na testowym zamówieniu i sprawdź, czy każde zdarzenie pojawia się z poprawnymi parametrami: `value` jako liczba z kropką dziesiętną, `currency` = PLN, `transaction_id` obecny. Pamiętaj, że standardowe raporty wypełniają się do 24-48 godzin – brak danych zaraz po wdrożeniu nie oznacza błędu, sprawdzaj na bieżąco w DebugView i Czasie rzeczywistym.

Wykluczenia bramek płatności (referral exclusions). To specyficzny problem polskiego e-commerce. Po przekierowaniu na Przelewy24, PayU, BLIK czy stronę banku, powrót do sklepu rejestruje się jako nowe źródło odsyłające, co psuje atrybucję `purchase`. W ustawieniach strumienia danych → Konfiguracja tagów → Wyświetl wszystkie ustawienia → Wyklucz niechciane odesłania dodaj domeny bramek (przelewy24.pl, payu.pl, paynow.pl itd.). Bez tego znaczna część zakupów zostanie błędnie przypisana do bramki płatności.

Mapa raportów. Dane o sprzedaży znajdziesz w: Raporty → Generowanie przychodu → Zakupy e-commerce (wydajność produktów), Ścieżka do zakupu (lejek view_item → purchase) oraz Eksploracje, gdzie zbudujesz własny lejek, analizę ścieżek i kohorty. KPI, które warto śledzić: współczynnik konwersji (CR), średnia wartość zamówienia (AOV), przychód, ROAS, wskaźnik porzuceń koszyka oraz wydajność poszczególnych produktów.

Google Ads. Połącz GA4 z Google Ads (Administracja → Połączenia z usługami). Zyskujesz import konwersji (purchase jako konwersja Ads), listy remarketingowe oparte na zdarzeniach i odbiorcach predykcyjnych, wspólną atrybucję oraz liczenie ROAS względem realnego przychodu. Dzięki temu kampanie optymalizują się pod wartość, a nie pod kliknięcia. W KC Mobile prowadzimy obsługę Google Ads od 1000 zł/mies. w modelu abonamentowym, bez prowizji od wydatków.

Search Console i BigQuery. Połączenie z Search Console dokłada dane organiczne do GA4, a darmowy eksport do BigQuery daje surowe zdarzenia bez limitów retencji – podstawa zaawansowanej analityki i raportów custom.

Najczęstsze błędy wdrożenia (techniczne, nie ogólniki):

• Brak transaction_id lub niestabilny ID – te same zamówienie liczone wielokrotnie przy odświeżeniu strony podziękowania (podwójne zliczanie purchase). Dodaj deduplikację po `transaction_id`.
• Błędny typ danych value – wartość jako tekst lub z przecinkiem/zł zamiast liczby z kropką. GA4 zignoruje przychód.
• Wielkość liter w nazwach zdarzeń – `Purchase` zamiast `purchase` nie zostanie rozpoznane jako e-commerce.
• Brak waluty (currency) – przychód bez PLN nie zsumuje się w raportach.
• Brak filtra ruchu wewnętrznego – wizyty właściciela i pracowników zawyżają dane; dodaj filtr po IP.
• Brak wykluczeń bramek – atrybucja zakupów rozjeżdża się na przelewy24/PayU.

Jeśli liczby w GA4, Google Ads i panelu sklepu się różnią, przyczyną jest zwykle jeden z powyższych punktów – nie błąd narzędzia. Potrzebujesz audytu wdrożenia? Napisz do nas, poukładamy pomiar od podstaw.