GA4 e-commerce - jak poprawnie mierzyć sprzedaż w sklepie internetowym?

Google Analytics 4 może pokazać znacznie więcej niż liczbę użytkowników odwiedzających sklep. Poprawnie wdrożony pomiar e-commerce pozwala analizować, które produkty są oglądane, skąd użytkownicy dodają je do koszyka, na jakim etapie rezygnują z zakupu oraz jakie źródła ruchu uczestniczą w generowaniu przychodów.

Samo umieszczenie kodu Google Analytics 4 na stronie nie wystarcza jednak do mierzenia sprzedaży. Standardowa konfiguracja może rejestrować odsłony i podstawowe interakcje, ale nie zna automatycznie struktury produktów, wartości koszyka, numeru zamówienia, zastosowanych rabatów ani kolejnych etapów checkoutu.

Do uzyskania użytecznych danych potrzebne jest wdrożenie zdarzeń e-commerce wraz z właściwymi parametrami. W zależności od platformy informacje mogą być przekazywane przez gotową integrację, Google Tag Manager, warstwę danych, kod dedykowany albo połączenie kilku kontrolowanych mechanizmów.

Poprawnie zaprojektowany GA4 e-commerce pomaga odpowiedzieć między innymi na pytania:

• które produkty generują najwięcej zainteresowania,
• które listy produktów prowadzą do zakupów,
• ile osób dodaje produkt do koszyka,
• gdzie użytkownicy opuszczają checkout,
• jakie metody dostawy i płatności wybierają,
• które kanały uczestniczą w generowaniu sprzedaży,
• czy transakcje są raportowane tylko raz,
• jak zwroty wpływają na raportowane wyniki,
• czy dane w GA4 są spójne z rzeczywistym procesem sklepu.

Analityka nie zastępuje jednak systemu sklepowego, ERP ani księgowości. Google Analytics pokazuje zachowania użytkowników i przychody przypisane do zdarzeń, ale bez dodatkowych danych nie zna pełnej marży, kosztów obsługi, anulowanych zamówień, rzeczywistego kosztu zwrotów ani całkowitego wyniku finansowego.

Dlatego dobre wdrożenie GA4 nie rozpoczyna się od instalacji wtyczki. Powinno rozpocząć się od ustalenia, jakie dane są potrzebne, jak działa proces zakupowy i w którym momencie transakcja ma zostać uznana za zakup.

Czym jest GA4 e-commerce?

GA4 e-commerce to zestaw zdarzeń i parametrów opisujących zachowania użytkownika podczas procesu zakupowego.

Zamiast rejestrować wyłącznie wejście na stronę i wyświetlenie kolejnych podstron, sklep może przekazywać do Google Analytics informacje o tym, że użytkownik:

• zobaczył listę produktów,
• wybrał konkretny produkt,
• otworzył kartę produktu,
• dodał produkt do koszyka,
• usunął go z koszyka,
• rozpoczął checkout,
• wybrał sposób dostawy,
• podał informacje o płatności,
• dokonał zakupu,
• otrzymał pełny lub częściowy zwrot.

Każde takie działanie jest zdarzeniem. Zdarzenie może zawierać dodatkowe dane, na przykład:

• identyfikator produktu,
• nazwę produktu,
• wariant,
• kategorię,
• markę,
• cenę,
• ilość,
• rabat,
• walutę,
• identyfikator listy produktów,
• numer transakcji.

Dzięki temu GA4 może raportować nie tylko liczbę zakupów, ale również zachowania dotyczące konkretnych produktów, kategorii i etapów ścieżki sprzedażowej.

Czego można dowiedzieć się z poprawnego pomiaru e-commerce?

Dane powinny pomagać podejmować decyzje. Sam fakt, że w panelu znajdują się setki zdarzeń, nie oznacza jeszcze, że wdrożenie jest użyteczne.

Skuteczność list i kategorii produktowych

Zdarzenia związane z listami produktów pozwalają sprawdzić:

• które kategorie są najczęściej przeglądane,
• jakie produkty są wyświetlane,
• które pozycje użytkownicy wybierają,
• czy produkty znajdujące się wysoko na liście częściej trafiają do koszyka,
• czy rekomendacje produktowe generują zainteresowanie.

Można w ten sposób porównywać stronę kategorii, wyniki wyszukiwania, sekcję produktów powiązanych albo promowane produkty na stronie głównej.

Zainteresowanie konkretnymi produktami

Pomiar karty produktu pokazuje, które produkty generują wyświetlenia, ale nie prowadzą do dodania do koszyka.

Może to wskazywać na problem z:

• ceną,
• opisem,
• zdjęciami,
• dostępnością,
• informacją o dostawie,
• wyborem wariantu,
• komunikacją wartości produktu.

GA4 nie wyjaśni automatycznie, która z tych przyczyn jest właściwa. Pokaże jednak, gdzie warto rozpocząć dalszą analizę.

Działanie koszyka i checkoutu

Porównanie liczby użytkowników przechodzących przez kolejne etapy umożliwia zlokalizowanie miejsca, w którym pojawia się największy spadek.

Może to być:

• przejście z produktu do koszyka,
• otwarcie checkoutu,
• wybór dostawy,
• wybór płatności,
• powrót z zewnętrznej bramki,
• finalizacja zamówienia.

Skuteczność kanałów marketingowych

GA4 może przypisywać zdarzenia i przychody do kanałów, źródeł oraz kampanii.

Pozwala to porównywać między innymi:

• ruch organiczny,
• Google Ads,
• media społecznościowe,
• newsletter,
• ruch bezpośredni,
• kampanie partnerskie,
• strony odsyłające.

Nie należy jednak traktować raportowanego przychodu jako kompletnego ROI. Do obliczenia zwrotu z inwestycji potrzebne są również koszty reklam, marża, zwroty i pozostałe dane biznesowe.

Skuteczność produktów i promocji

Dzięki parametrom produktowym można sprawdzać:

• przychody z poszczególnych produktów,
• liczbę sprzedanych sztuk,
• skuteczność rabatów,
• działanie kodów promocyjnych,
• wybierane warianty,
• skuteczność bannerów i promocji.

Czego GA4 nie pokaże bez dodatkowych danych?

Google Analytics nie jest systemem księgowym ani pełnym systemem Business Intelligence.

Standardowe wdrożenie nie pokaże automatycznie:

• marży na produkcie,
• kosztu dostawy ponoszonego przez sklep,
• kosztu obsługi zamówienia,
• kosztu zwrotu,
• wynagrodzenia marketplace,
• pełnych kosztów marketingowych,
• przychodów domkniętych przez handlowca poza sklepem,
• zamówień anulowanych po kilku dniach,
• rzeczywistej wartości klienta w całym cyklu współpracy.

Część informacji można uzupełnić przez połączenie GA4 z:

• Google Ads,
• CRM,
• ERP,
• systemem magazynowym,
• platformą marketing automation,
• BigQuery,
• narzędziem raportowym.

Nadal konieczne jest jednak ustalenie wspólnych identyfikatorów i definicji. Jeżeli GA4, sklep, Merchant Center i ERP używają innych identyfikatorów tego samego produktu, połączenie danych będzie utrudnione.

Zanim rozpoczniesz wdrożenie: przygotuj plan pomiaru e-commerce

Plan pomiaru określa, jakie decyzje firma chce podejmować na podstawie danych i jakie zdarzenia są do tego potrzebne.

To znacznie lepszy punkt wyjścia niż wdrażanie wszystkich dostępnych zdarzeń bez określonego celu.

Określ najważniejsze pytania biznesowe

Przykładowe pytania mogą brzmieć:

• które kanały generują sprzedaż,
• które produkty przyciągają ruch, ale słabo się sprzedają,
• gdzie klienci opuszczają checkout,
• jak często użytkownicy korzystają z wyszukiwarki,
• czy rekomendacje produktowe prowadzą do zakupów,
• które promocje zwiększają wartość koszyka,
• jakie metody płatności są wybierane,
• jak zwroty zmieniają wyniki produktów,
• czy sprzedaż nowych i powracających klientów różni się.

Zdefiniuj moment zakupu

Trzeba ustalić, kiedy sklep powinien wysyłać zdarzenie purchase.

W zależności od modelu może to być:

• poprawne utworzenie zamówienia,
• powrót użytkownika po prawidłowej płatności,
• potwierdzenie płatności przez operatora,
• zmiana statusu zamówienia po stronie serwera.

Nie ma jednej odpowiedzi właściwej dla każdego sklepu.

Przy płatności za pobraniem oczekiwanie na faktyczne otrzymanie środków mogłoby powodować znaczne opóźnienie albo brak danych. Przy płatności internetowej wysłanie zakupu przed potwierdzeniem transakcji może natomiast zawyżać przychody o nieopłacone zamówienia.

Definicja powinna być:

• jednoznaczna,
• technicznie możliwa do wdrożenia,
• konsekwentna,
• znana osobom analizującym raporty.

Ustal wspólny identyfikator produktu

Najlepiej stosować identyfikator, który można połączyć z pozostałymi systemami.

Może to być:

• SKU,
• identyfikator produktu,
• identyfikator wariantu,
• kod używany w ERP.

W sklepie z wariantami trzeba zdecydować, czy item_id wskazuje produkt główny, czy konkretny wariant.

Należy zachować tę samą logikę w zdarzeniach:

• view_item,
• add_to_cart,
• begin_checkout,
• purchase,
• refund.

Ustal sposób raportowania wartości

Plan powinien określać:

• czy ceny są przekazywane brutto czy netto,
• w jaki sposób raportowany jest rabat,
• jak traktowana jest dostawa,
• jak przekazywany jest podatek,
• jak obsługiwane są różne waluty,
• czy zamówienie z kuponem zawiera dane o kuponie,
• jak będą mierzone zwroty częściowe.

Analitykę warto uwzględnić już podczas przygotowania wymagań projektowych. Więcej elementów, które należy zaplanować przed budową sklepu, opisujemy w poradniku dotyczącym specyfikacji sklepu internetowego.

Jak działa model zdarzeń e-commerce w GA4?

Google udostępnia zalecane nazwy zdarzeń dla sprzedaży internetowej. Korzystanie z nich umożliwia zasilanie standardowych raportów e-commerce.

Nie każdy sklep musi wdrażać wszystkie zdarzenia. Zakres powinien odpowiadać rzeczywistej ścieżce użytkownika.

Wyświetlenie listy produktów – view_item_list

Zdarzenie powinno zostać wysłane, gdy użytkownik zobaczy listę produktów.

Listą może być:

• kategoria,
• wynik wyszukiwania,
• sekcja produktów polecanych,
• bestsellerów,
• produktów promowanych,
• ostatnio oglądanych.

Zdarzenie powinno umożliwiać rozpoznanie konkretnej listy, na przykład przez:

• item_list_id,
• item_list_name.

Trzeba również ustalić, kiedy produkt uznawany jest za rzeczywiście wyświetlony. Wysłanie informacji o wszystkich produktach znajdujących się w kodzie strony może zawyżać dane, jeżeli użytkownik nie przewinął do ich sekcji.

Wybór produktu z listy – select_item

Zdarzenie informuje, że użytkownik wybrał produkt z konkretnej listy.

Pozwala analizować:

• skuteczność kolejności produktów,
• działanie wyszukiwarki,
• skuteczność rekomendacji,
• kliknięcia w bannery produktowe,
• relację między wyświetleniem a wyborem produktu.

Należy zachować informacje o liście, z której nastąpiło przejście. W przeciwnym razie późniejsza analiza może nie pokazać, czy użytkownik wybrał produkt z kategorii, wyszukiwarki czy sekcji rekomendacji.

Wyświetlenie produktu – view_item

Zdarzenie powinno zostać wysłane po otwarciu szczegółów produktu.

Najważniejsze dane to:

• identyfikator,
• nazwa,
• wariant,
• kategoria,
• marka,
• cena,
• waluta.

Warto sprawdzić, czy zmiana wariantu produktu aktualizuje przekazywane dane. Jeżeli użytkownik wybierze inny rozmiar, kolor albo pojemność, zdarzenie powinno odpowiadać elementowi, którego faktycznie dotyczy interakcja.

Dodanie do listy życzeń – add_to_wishlist

Zdarzenie ma sens wyłącznie wtedy, gdy sklep posiada działającą wishlistę.

Może pomóc ocenić:

• produkty rozważane przez klientów,
• różnicę między zainteresowaniem a zakupem,
• potencjał kampanii przypominających,
• zachowania użytkowników zalogowanych.

Nie należy wdrażać go tylko dlatego, że znajduje się w katalogu zalecanych zdarzeń.

Dodanie do koszyka – add_to_cart

Zdarzenie powinno opisywać skuteczne dodanie produktu, a nie samo kliknięcie przycisku.

Jeżeli operacja zakończy się błędem, braknie wariantu albo produkt nie zostanie dodany, nie powinno się raportować prawidłowego add_to_cart.

Trzeba sprawdzić wszystkie miejsca umożliwiające dodanie produktu, między innymi:

• kartę produktu,
• kategorię,
• wyniki wyszukiwania,
• rekomendacje,
• szybki podgląd,
• formularz zamówienia zbiorczego.

Usunięcie produktu z koszyka – remove_from_cart

Pomiar usuwania produktów pozwala znaleźć elementy często dodawane, ale równie często usuwane przed zakupem.

Może to wskazywać między innymi na:

• niespodziewaną cenę,
• zmianę kosztów dostawy,
• błędnie wybrany wariant,
• używanie koszyka jako listy porównawczej,
• problem z dostępnością.

Wyświetlenie koszyka – view_cart

Zdarzenie opisuje wyświetlenie zawartości koszyka.

Powinno przekazywać wszystkie produkty znajdujące się w koszyku, ich ilości, ceny i wartość całego zestawu.

Pozwala odróżnić samo dodanie produktu od rzeczywistego otwarcia koszyka.

Rozpoczęcie checkoutu – begin_checkout

Zdarzenie informuje, że użytkownik rozpoczął proces finalizacji zamówienia.

Nie zawsze powinno być wysyłane po samym wyświetleniu koszyka. Moment zależy od konstrukcji sklepu:

• przejście do osobnego checkoutu,
• otwarcie pierwszego kroku,
• rozpoczęcie formularza,
• aktywacja procesu w checkout one page.

Ważne, aby definicja była konsekwentna i odpowiadała rzeczywistemu początkowi finalizacji.

Dodanie informacji o dostawie – add_shipping_info

Zdarzenie może zostać wysłane, gdy użytkownik wybierze albo zatwierdzi metodę dostawy.

Parametr shipping_tier może opisywać na przykład:

• kuriera,
• paczkomat,
• odbiór osobisty,
• dostawę ekspresową.

W sklepie posiadającym wiele zależności logistycznych warto sprawdzić, czy metoda dostawy jest prawidłowo aktualizowana po zmianie adresu lub zawartości koszyka.

Dodanie informacji o płatności – add_payment_info

Zdarzenie może opisywać wybór albo zatwierdzenie metody płatności.

Parametr payment_type może rozróżniać:

• kartę,
• szybki przelew,
• BLIK,
• płatność odroczoną,
• pobranie,
• przelew tradycyjny.

Trzeba ustalić, czy zdarzenie ma być wysłane po samym wyborze metody, czy dopiero po przejściu do kolejnego kroku.

Zakup – purchase

To najważniejsze zdarzenie sprzedażowe.

Powinno zawierać między innymi:

• unikalny transaction_id,
• wartość produktów,
• walutę,
• dane o podatku,
• koszt dostawy,
• kupon,
• tablicę produktów items.

Zdarzenie nie powinno być wysyłane:

• po każdym wyświetleniu strony podziękowania,
• dla nieudanego zamówienia,
• równocześnie przez kilka niezależnych integracji,
• bez unikalnego identyfikatora transakcji.

Zwrot – refund

Zdarzenie może opisywać:

• pełny zwrot zamówienia,
• częściowy zwrot,
• zwrot konkretnego produktu,
• zwrot kilku sztuk produktu.

Do powiązania z zakupem potrzebny jest transaction_id.

W przypadku zwrotu częściowego warto przekazać również produkty i ilości. Dzięki temu można analizować zwroty na poziomie produktu, a nie tylko całej transakcji.

Samo wdrożenie purchase bez refund może prowadzić do raportowania przychodu bez uwzględnienia późniejszych zwrotów.

Wyświetlenie i wybór promocji

Zdarzenia view_promotion oraz select_promotion pozwalają mierzyć skuteczność elementów promocyjnych.

Mogą dotyczyć:

• bannerów,
• sekcji promocyjnych,
• kafelków kampanii,
• ofert sezonowych,
• akcji specjalnych.

Trzeba odróżnić samo wyświetlenie promocji od kliknięcia i późniejszego zakupu.

Jakie dane powinny zawierać zdarzenia e-commerce?

Nazwa zdarzenia to tylko część wdrożenia. Bez prawidłowych parametrów raporty mogą być niepełne albo bezużyteczne.

Parametry dotyczące transakcji

Dla purchase istotne są między innymi:

transaction_id

Unikalny identyfikator zamówienia.

Powinien:

• być inny dla każdej transakcji,
• nie zawierać danych osobowych,
• być taki sam w zdarzeniu zakupu i zwrotu,
• nie być pustym ciągiem znaków.
• currency

Waluta podana w formacie ISO 4217, na przykład:

• PLN,
• EUR,
• USD.

Waluta jest potrzebna przy przekazywaniu wartości pieniężnych.

value

Łączna wartość produktów obliczana na podstawie ceny i ilości.

Wartość nie powinna zawierać podatku i dostawy, ponieważ są one przekazywane w osobnych parametrach.

tax

Kwota podatku przypisana do zamówienia.

shipping

Kwota dostawy.

coupon

Kod rabatowy dotyczący całej transakcji.

Tablica produktów items

Tablica items zawiera dane o poszczególnych produktach.

Każdy element może posiadać między innymi:

• item_id,
• item_name,
• item_brand,
• item_category,
• item_category2,
• item_category3,
• item_variant,
• price,
• quantity,
• discount,
• coupon,
• item_list_id,
• item_list_name,
• index.

Nie wszystkie pola są obowiązkowe, ale warto przesyłać dostępne dane mające znaczenie analityczne.

item_id i item_name

Dla każdego produktu wymagany jest przynajmniej identyfikator albo nazwa. W praktyce warto stosować oba.

Identyfikator jest zwykle bardziej stabilny niż nazwa, która może zmienić się w trakcie rozwoju oferty.

Cena i rabat

Cena powinna odpowiadać jednostkowej cenie produktu po uwzględnieniu rabatu.

Wartość rabatu może zostać przekazana osobno w parametrze discount.

Należy przyjąć jedną logikę i stosować ją we wszystkich zdarzeniach.

Jak uniknąć podwójnego zliczania zakupów?

Duplikowanie purchase jest jednym z najpoważniejszych błędów we wdrożeniach GA4 e-commerce.

Może wystąpić, gdy:

• użytkownik odświeży stronę podziękowania,
• wróci do potwierdzenia zamówienia,
• zdarzenie wysyła wtyczka oraz GTM,
• zakup jest raportowany po stronie przeglądarki i serwera,
• bramka płatnicza powoduje ponowne uruchomienie tagu,
• checkout ponownie renderuje komponent z kodem zdarzenia.

Podstawową ochroną jest unikalny transaction_id. GA4 może deduplikować zakup wysłany z takim samym identyfikatorem w strumieniu internetowym.

Nie należy jednak opierać całej kontroli wyłącznie na deduplikacji. Trzeba również sprawdzić, dlaczego zdarzenie uruchamia się wielokrotnie.

Pusty transaction_id jest szczególnie niebezpieczny. Jeżeli wiele zamówień otrzyma pustą wartość, GA4 może potraktować je jak tę samą transakcję.

Google Tag Manager i dataLayer – jak zaplanować architekturę?

Google Tag Manager może oddzielić warstwę danych sklepu od konfiguracji narzędzi analitycznych.

W takim modelu sklep przekazuje informacje do dataLayer, a GTM wykorzystuje je do uruchamiania tagów GA4, Google Ads i innych systemów.

Przykładowy przepływ wygląda następująco:

• użytkownik dodaje produkt do koszyka,
• sklep potwierdza wykonanie operacji,
• do dataLayer trafia zdarzenie wraz z informacjami o produkcie,
• GTM rozpoznaje zdarzenie,
• tag wysyła dane do GA4.

GA4 e-commerce a Consent Mode i zgody użytkownika

Pomiar GA4 w europejskim e-commerce musi uwzględniać mechanizm zarządzania zgodami.

Consent Mode przekazuje do usług Google stan zgody dotyczący między innymi:

• analytics_storage,
• ad_storage,
• ad_user_data,
• ad_personalization.

Nie zastępuje banera ani platformy CMP. Reaguje na decyzję użytkownika i wpływa na zachowanie tagów.

Poprawne wdrożenie wymaga:

• ustawienia stanu domyślnego,
• powiązania kategorii CMP z właściwymi sygnałami,
• aktualizacji stanu po decyzji użytkownika,
• kontroli kolejności uruchamiania tagów,
• testowania wariantu akceptacji i odmowy,
• sprawdzenia działania po zmianie zgody.

Consent Mode nie jest automatycznie poprawny tylko dlatego, że na stronie znajduje się banner cookies.

Nie należy też oczekiwać, że liczba transakcji w GA4 będzie identyczna z panelem sklepu. Na kompletność danych wpływają między innymi:

• decyzje użytkowników,
• blokery reklam,
• ustawienia przeglądarek,
• błędy tagów,
• model Consent Mode,
• sposób wdrożenia.

Szczegółowy proces konfiguracji opisujemy w poradniku pokazującym, jak wdrożyć Consent Mode V2 krok po kroku.

Jedno źródło prawdy

Należy ustalić, który mechanizm odpowiada za dane e-commerce.

Możliwe modele to między innymi:

• integracja wysyła zdarzenia bezpośrednio do GA4,
• wtyczka lub moduł buduje dataLayer, a GTM wysyła zdarzenia,
• kod dedykowany przygotowuje dataLayer,
• frontend aplikacji wysyła zdarzenia bezpośrednio przez gtag.js.

Nie należy bez kontroli łączyć kilku mechanizmów wysyłających te same zdarzenia.

Przykładowo wtyczka może samodzielnie raportować purchase, podczas gdy drugi tag w GTM wyśle tę samą transakcję ponownie.

Nie inicjalizuj ponownie dataLayer

Na stronie powinna funkcjonować jedna, globalna warstwa danych.

Jej przypadkowe zastąpienie albo ponowne utworzenie może usunąć wcześniejsze zdarzenia i wartości oraz spowodować, że tagi nie uruchomią się prawidłowo.

Czy można wdrożyć GA4 bez Google Tag Managera?

Tak. Zdarzenia mogą być wysyłane bezpośrednio przez Google tag lub integrację platformy.

GTM nie jest obowiązkowy, ale często ułatwia:

• zarządzanie tagami,
• testowanie,
• integrację z Consent Mode,
• utrzymanie wielu narzędzi,
• modyfikację konfiguracji bez zmian w całej aplikacji.

W rozbudowanym sklepie nadal potrzebna jest współpraca z kodem źródłowym. GTM nie jest w stanie samodzielnie odgadnąć danych produktowych, numeru zamówienia i rzeczywistego wyniku operacji.

Server-side tagging i Measurement Protocol

W bardziej rozbudowanych wdrożeniach można wykorzystać tagowanie po stronie serwera albo Measurement Protocol.

Nie są to jednak zamienniki standardowej analityki przeglądarkowej.

Measurement Protocol może uzupełniać pomiar o zdarzenia:

• serwerowe,
• offline,
• pochodzące z CRM,
• związane ze zmianą statusu zamówienia,
• wykonywane poza interfejsem strony.

Wdrożenie wymaga zachowania odpowiednich identyfikatorów i ustawień prywatności. Źle zaprojektowana implementacja serwerowa może prowadzić do utraty informacji o sesji, źródle ruchu i urządzeniu.

Jak wdrożyć GA4 e-commerce na różnych platformach?

Architektura pomiaru zależy od platformy oraz stopnia modyfikacji sklepu.

WooCommerce

W sklepie WooCommerce można wykorzystać:

• gotową integrację,
• wtyczkę budującą dataLayer,
• Google Tag Manager,
• rozwiązanie dedykowane.

Gotowe rozwiązanie może działać poprawnie w standardowym sklepie. Trzeba jednak zweryfikować je szczególnie wtedy, gdy WooCommerce posiada:

• niestandardowy checkout,
• szybkie dodawanie z listy,
• dodatkowe typy produktów,
• subskrypcje,
• zestawy,
• indywidualne ceny,
• wielowalutowość,
• płatności odroczone,
• dedykowaną stronę podziękowania,
• integracje z zewnętrznymi systemami.

Każda aktualizacja checkoutu, motywu lub wtyczki sprzedażowej może zmienić zachowanie zdarzeń.

PrestaShop

W PrestaShop jakość danych zależy od:

• wykorzystywanego modułu,
• wersji platformy,
• szablonu,
• modyfikacji checkoutu,
• sposobu ładowania produktów,
• modułów płatności,
• rozwiązań wielosklepowych,
• wersji językowych i walut.

Nie należy zakładać, że instalacja modułu automatycznie zapewnia pełne i poprawne dane.

Trzeba wykonać testy dla:

• produktów prostych i wariantowych,
• kuponów,
• różnych metod dostawy,
• płatności,
• zamówień gościnnych,
• kont klientów,
• zwrotów,
• odświeżenia strony potwierdzenia.

Sklep dedykowany lub headless

W systemie dedykowanym plan pomiaru powinien być częścią specyfikacji technicznej.

Trzeba określić:

• nazwy zdarzeń,
• moment ich wysyłania,
• strukturę dataLayer,
• źródło danych produktowych,
• sposób identyfikacji wariantów,
• zachowanie w aplikacji jednostronicowej,
• obsługę błędów,
• moment potwierdzenia zakupu,
• integrację ze zgodami,
• ewentualne zdarzenia serwerowe.

W architekturze headless ważna jest koordynacja danych pomiędzy frontendem, backendem, systemem płatności i platformą e-commerce.

Płatności zewnętrzne i błędne źródła sprzedaży

Operator płatności może spowodować, że po powrocie do sklepu GA4 rozpozna nową sesję lub przypisze sprzedaż do domeny płatniczej.

W raportach jako źródło zakupu mogą wtedy pojawić się między innymi:

• operator płatności,
• bank,
• system logowania,
• domena checkoutu.

Taka informacja nie pokazuje rzeczywistego źródła pozyskania użytkownika.

W zależności od architektury trzeba sprawdzić:

• konfigurację między domenami,
• zachowanie identyfikatora klienta,
• listę niepożądanych odesłań,
• sposób powrotu do sklepu,
• moment uruchomienia purchase,
• zachowanie po anulowanej płatności.

Dodanie każdej domeny płatniczej do listy wykluczeń bez analizy również może powodować błędy. Konfiguracja powinna odpowiadać rzeczywistemu przepływowi.

Kiedy wysłać purchase przy płatności zewnętrznej?

Możliwe warianty to:

• utworzenie zamówienia przed przekierowaniem,
• powrót po prawidłowej płatności,
• potwierdzenie serwerowe od operatora,
• zmiana statusu zamówienia.

Wybór zależy od sposobu sprzedaży.

Kluczowe jest, aby:

• nie raportować nieudanych operacji jako sprzedaży,
• nie tracić zamówień opłacanych poza stroną,
• nie wysyłać transakcji kilka razy,
• umożliwić powiązanie zwrotu z zakupem.

Jak sprawdzić, czy GA4 e-commerce działa poprawnie?

Kontrola wdrożenia nie powinna kończyć się na sprawdzeniu, czy nazwa zdarzenia pojawiła się w DebugView.

Zweryfikuj dataLayer

Sprawdź:

• czy zdarzenie występuje w odpowiednim momencie,
• czy zawiera produkty,
• czy wartości są aktualne,
• czy identyfikatory są spójne,
• czy poprzednie dane nie pozostają w warstwie,
• czy zdarzenie nie jest wysyłane wielokrotnie.

Użyj trybu Preview w GTM

Tryb podglądu pozwala sprawdzić:

• jaki event uruchomił tag,
• jakie zmienne były dostępne,
• czy tag został zablokowany,
• czy warunki zgody zostały spełnione,
• czy nie uruchomiło się kilka tagów tego samego typu.

Sprawdź DebugView

DebugView umożliwia kontrolę:

• nazw zdarzeń,
• parametrów zdarzenia,
• parametrów produktów,
• kolejności interakcji,
• identyfikatora transakcji,
• wartości i waluty.

Wykonaj pełny zakup testowy

Test powinien obejmować:

• wejście na listę produktów,
• wybór produktu,
• zmianę wariantu,
• dodanie do koszyka,
• usunięcie produktu,
• ponowne dodanie,
• przejście do checkoutu,
• wybór dostawy,
• wybór płatności,
• zastosowanie kuponu,
• zakup,
• powrót z operatora płatności.

Przetestuj ponowne wejście na podziękowanie

Odśwież stronę i otwórz ją ponownie.

Sprawdź, czy purchase:

• nie uruchamia się ponownie,
• posiada ten sam transaction_id,
• nie dubluje przychodu.

Przetestuj różne scenariusze

W zależności od sklepu trzeba uwzględnić:

• zakup bez konta,
• zakup po zalogowaniu,
• płatność internetową,
• pobranie,
• przelew,
• darmową dostawę,
• różne stawki podatku,
• kilka walut,
• produkt z wariantami,
• częściowy zwrot,
• pełny zwrot.

Porównaj GA4 ze sklepem

Po przetworzeniu danych porównaj:

• liczbę transakcji,
• identyfikatory zamówień,
• wartość produktów,
• walutę,
• podatki,
• dostawę,
• rabaty.

GA4 nie musi być identyczny z panelem sklepu, ale różnice powinny być wyjaśnione, a nie przypadkowe.

Najczęstsze błędy we wdrożeniach GA4 e-commerce

Pomiar wyłącznie zdarzenia purchase

Dane pokazują końcowy wynik, ale nie pozwalają analizować wcześniejszych etapów.

Nie wiadomo wtedy:

• ilu użytkowników oglądało produkty,
• ilu dodało je do koszyka,
• ilu rozpoczęło checkout,
• gdzie nastąpił spadek.

Zdublowany purchase

Jedna transakcja jest wysyłana przez więcej niż jeden tag albo ponownie po odświeżeniu strony.

Skutkiem jest zawyżenie:

• liczby zakupów,
• przychodu,
• skuteczności kanałów,
• ROAS.

Brak transaction_id

Bez identyfikatora trudniej:

• deduplikować zakupy,
• powiązać zwroty,
• porównać dane z panelem sklepu,
• znaleźć konkretny błąd.

Pusty albo stały transaction_id

Stała wartość może powodować, że różne zamówienia zostaną potraktowane jako jedna transakcja.

Brak tablicy items

Zdarzenie zakupu pojawia się, ale nie zawiera produktów.

W takim przypadku można zobaczyć wartość zamówienia, lecz raporty produktowe będą niepełne.

Niespójne identyfikatory produktów

Ten sam produkt ma inny identyfikator podczas:

• wyświetlenia,
• dodania do koszyka,
• checkoutu,
• zakupu.

GA4 może traktować go jak kilka różnych produktów.

Błędna wartość transakcji

Do value trafia:

• cena z dostawą,
• cena bez rabatu,
• wartość pojedynczego produktu,
• kwota w innej walucie,
• wartość zawierająca podatek mimo osobnego parametru.

Brak waluty

Jeżeli wysyłana jest wartość, należy przekazać również walutę.

Raportowanie kliknięcia zamiast wyniku operacji

add_to_cart uruchamia się po kliknięciu, mimo że produkt nie został dodany.

Podobny problem może występować przy:

• wyborze płatności,
• przejściu do kolejnego kroku,
• wysłaniu zamówienia.

Purchase wysyłany przed potwierdzeniem właściwego etapu

W zależności od modelu może prowadzić do raportowania nieopłaconych albo niedokończonych zamówień.

Brak obsługi zwrotów

Raportowany przychód nie jest później korygowany.

Operator płatności jako źródło sprzedaży

Pierwotny kanał zostaje zastąpiony przez domenę bramki płatniczej.

Kilka niezależnych integracji

GA4 jest wdrożony jednocześnie przez:

• wtyczkę,
• motyw,
• GTM,
• moduł reklamowy,
• kod dedykowany.

Bez audytu trudno ustalić, który element wysyła dane.

Niepoprawny Consent Mode

Tagi:

• uruchamiają się przed zgodą,
• nie uruchamiają się po zgodzie,
• otrzymują niewłaściwy stan,
• nie reagują na zmianę decyzji.

Brak testów po aktualizacji sklepu

Zmiana checkoutu, motywu lub modułu płatności może usunąć zdarzenie albo zmienić strukturę danych.

Ruch pracowników i zamówienia testowe

Testy zespołu mogą trafiać do danych produkcyjnych i wpływać na raporty.

Jak analizować dane GA4 w sklepie internetowym?

Samo wdrożenie zdarzeń nie poprawi sprzedaży. Potrzebna jest regularna analiza i łączenie danych z wiedzą o sklepie.

Analiza lejka zakupowego

Można porównać liczbę użytkowników, którzy:

• zobaczyli produkt,
• dodali go do koszyka,
• rozpoczęli checkout,
• wybrali dostawę,
• wybrali płatność,
• dokonali zakupu.

Warto analizować lejek również według:

• urządzenia,
• kanału,
• kraju,
• kategorii produktu,
• typu użytkownika,
• kampanii.

Duży spadek nie wyjaśnia automatycznie przyczyny. Pokazuje miejsce wymagające dalszych testów.

Problemy dotyczące samej finalizacji szerzej opisujemy w artykule o tym, co blokuje sprzedaż w checkoutcie sklepu internetowego.

Analiza list produktów

Porównuj:

• wyświetlenia list,
• wybory produktów,
• dodania do koszyka,
• zakupy.

Może się okazać, że produkt generuje sprzedaż, ale jest rzadko widoczny, albo odwrotnie — pojawia się często, lecz niemal nikt go nie wybiera.

Analiza produktów

Warto sprawdzać:

• wyświetlenia,
• dodania do koszyka,
• zakupy,
• ilość,
• przychód,
• zwroty,
• warianty,
• kategorie.

Produkt z dużą liczbą wyświetleń i małą liczbą dodań do koszyka może wymagać sprawdzenia oferty albo prezentacji.

Produkt często dodawany i usuwany może mieć problem ujawniający się dopiero w koszyku.

Analiza kanałów

Przychody należy analizować razem z:

• liczbą użytkowników,
• jakością ruchu,
• kosztem kampanii,
• udziałem w ścieżce,
• liczbą nowych klientów,
• zwrotami.

Kanał generujący wysoki przychód może równocześnie mieć niski wynik po uwzględnieniu kosztów i marży.

Analiza metod dostawy i płatności

Dane mogą pokazać:

• najczęściej wybierane metody,
• różnice między urządzeniami,
• spadki po wyborze określonej opcji,
• problemy z konkretną bramką,
• wpływ kosztu dostawy na finalizację.

Analiza zwrotów

Jeżeli zwroty są przekazywane do GA4, można porównywać produkty i kategorie pod względem:

• wartości sprzedaży,
• liczby zwrotów,
• wartości zwróconych produktów,
• sprzedaży po korekcie.

Do pełnej analizy marżowości potrzebne będą jednak dane z systemu sprzedażowego albo ERP.

Zdarzenia kluczowe i konwersje Google Ads

W GA4 działania szczególnie ważne dla biznesu można oznaczyć jako zdarzenia kluczowe.

Nie każde zdarzenie e-commerce powinno mieć taki status.

Zazwyczaj kluczowym zdarzeniem będzie purchase. W zależności od modelu mogą nim być również inne działania, ale oznaczenie wszystkich etapów lejka jako równie ważnych utrudnia interpretację.

Schemat wygląda następująco:

• zdarzenie rejestruje działanie,
• ważne zdarzenie można oznaczyć jako kluczowe w GA4,
• zdarzenie istotne dla kampanii może zostać wykorzystane jako konwersja Google Ads.

Trzeba również ustalić, czy zakup jest raportowany do Google Ads:

• bezpośrednio przez tag Google Ads,
• przez import z GA4,
• przez inne rozwiązanie.

Uruchomienie kilku równoległych konwersji może prowadzić do podwójnego raportowania.

Dlaczego liczba zakupów w GA4 różni się od sklepu?

Niewielka różnica nie musi oznaczać błędu.

Wpływ mogą mieć:

• brak zgody,
• blokowanie skryptów,
• zamknięcie strony przed wysłaniem zdarzenia,
• opóźnienie przetwarzania,
• strefa czasowa,
• ruch wewnętrzny,
• zamówienia telefoniczne,
• zamówienia utworzone przez administratora,
• anulowania,
• nieopłacone zamówienia,
• zwroty,
• inna definicja wartości,
• deduplikacja.

Niepokojące są przede wszystkim:

• duże, systematyczne różnice,
• przychód równy zero,
• powtarzające się identyfikatory,
• brak określonych produktów,
• gwałtowna zmiana po aktualizacji,
• operator płatności jako dominujące źródło,
• wielokrotne raportowanie jednej transakcji.

GA4 powinien być traktowany jako system analityczny, a panel sklepu jako podstawowe źródło informacji o rzeczywiście utworzonych zamówieniach.

Kiedy warto wykorzystać BigQuery?

BigQuery pozwala eksportować surowe zdarzenia z GA4 i analizować je przy użyciu zapytań.

Może być przydatny, gdy firma potrzebuje:

• łączenia GA4 z ERP lub CRM,
• własnego modelu marżowości,
• analizy danych na poziomie zdarzeń,
• własnych segmentów,
• zaawansowanej retencji,
• niestandardowej atrybucji,
• długoterminowego przechowywania danych,
• automatycznego zasilania raportów.

Samo włączenie eksportu nie tworzy jednak gotowego systemu analitycznego.

Potrzebne są:

• spójne identyfikatory,
• model danych,
• zapytania,
• kontrola kosztów,
• walidacja,
• warstwa raportowa.

Standardowe usługi GA4 posiadają limit dziennego eksportu do BigQuery wynoszący milion zdarzeń. Przy dużych sklepach trzeba kontrolować wolumen albo rozważyć inny wariant usługi.

Looker Studio i dashboardy

Looker Studio może uporządkować najważniejsze wskaźniki w jednym raporcie.

Dashboard może obejmować:

• sprzedaż,
• liczbę transakcji,
• średnią wartość zamówienia,
• lejek,
• produkty,
• kanały,
• kampanie,
• urządzenia,
• zwroty.

Raport nie naprawi jednak błędnych danych. Najpierw trzeba zweryfikować pomiar, a dopiero później projektować dashboard.

GA4 e-commerce wymaga utrzymania

Tracking nie jest konfiguracją wykonywaną raz na zawsze.

Na jego działanie mogą wpłynąć:

• aktualizacja sklepu,
• zmiana checkoutu,
• nowy operator płatności,
• nowa metoda dostawy,
• zmiana CMP,
• przebudowa motywu,
• modyfikacja danych produktowych,
• nowy system walut,
• nowa wersja językowa,
• zmiana integracji.

Dlatego warto ustalić:

• kto odpowiada za tracking,
• kiedy wykonywane są testy,
• jak dokumentowane są zdarzenia,
• kto akceptuje zmiany,
• jak szybko wykrywany jest brak danych.

Minimum stanowi kontrola po każdej istotnej zmianie w ścieżce zakupowej.

Jak Webtom.pl wdraża GA4 e-commerce?

W Webtom.pl traktujemy analitykę jako część procesu sprzedażowego i technologicznego sklepu, a nie jako pojedynczy kod dodany do nagłówka strony.

Zakres wdrożenia może obejmować:

Audyt obecnej konfiguracji

Sprawdzamy:

• kontenery GTM,
• Google tag,
• integracje,
• zdarzenia,
• parametry,
• źródła danych,
• Consent Mode,
• duplikaty,
• zgodność wartości ze sklepem.

Plan pomiaru

Ustalamy:

• pytania biznesowe,
• zakres zdarzeń,
• identyfikatory produktów,
• moment raportowania zakupu,
• obsługę zwrotów,
• potrzebne parametry niestandardowe.

Implementację dataLayer

Przygotowujemy albo porządkujemy warstwę danych odpowiadającą rzeczywistym działaniom użytkownika i procesom sklepu.

Konfigurację GA4 i GTM

Mapujemy zdarzenia i parametry, konfigurujemy tagi oraz kontrolujemy ich uruchamianie.

Integrację ze zgodami

Łączymy narzędzia analityczne z CMP i Consent Mode oraz sprawdzamy działanie dla różnych decyzji użytkownika.

Testy ścieżki zakupowej

Weryfikujemy listy, produkty, koszyk, checkout, płatności, stronę potwierdzenia, identyfikatory zamówień i zwroty.

Raportowanie

W zależności od potrzeb przygotowujemy konfigurację raportów, eksploracji albo dashboardu Looker Studio.

Dokumentację i dalszą kontrolę

Dokumentujemy zdarzenia oraz wskazujemy elementy wymagające ponownego testowania po zmianach sklepu.

W przypadku WordPressa i WooCommerce szczegółowy zakres przedstawiamy w usłudze wdrożenia Google Analytics 4 i Google Tag Manager.

Przy większych projektach łączymy analitykę z UX, technologią, integracjami i rozwojem procesu sprzedażowego. Takie podejście realizujemy jako agencja e-commerce Webtom.pl.

GA4 e-commerce – podsumowanie

Poprawnie wdrożony GA4 e-commerce pozwala analizować całą ścieżkę zakupową, a nie wyłącznie końcową sprzedaż.

Dobre wdrożenie powinno obejmować:

• plan pomiaru,
• zalecane zdarzenia,
• właściwe parametry produktowe,
• spójne identyfikatory,
• unikalny transaction_id,
• kontrolę wartości i waluty,
• obsługę zwrotów,
• integrację ze zgodami,
• testy płatności zewnętrznych,
• walidację danych,
• dalsze utrzymanie.

Największym błędem jest założenie, że sama obecność GA4 albo wtyczki oznacza poprawnie działającą analitykę.

Dane mogą wyglądać wiarygodnie, a jednocześnie:

• dublować transakcje,
• pomijać produkty,
• raportować błędną wartość,
• tracić źródło ruchu,
• ignorować część checkoutu,
• działać niezgodnie ze stanem zgody.

Dopiero po zweryfikowaniu jakości danych warto wykorzystywać raporty do oceny kampanii, produktów i doświadczeń użytkownika.