Śledzenie konwersji w sklepie internetowym - dataLayer i GTM dla e-commerce

Jak wygląda kod zdarzenia purchase w dataLayer

Zdarzenie zakupu wysyła się na stronie potwierdzenia zamówienia albo w chwili, gdy sklep zapisze zamówienie. Przed każdym zdarzeniem e-commerce przykłady Google dla Tag Managera czyszczą poprzedni obiekt ecommerce, żeby dane z wcześniejszego zdarzenia, np. lista produktów z koszyka, nie dołączyły się do następnego. Uproszczony przykład:

[#przyklad] dataLayer.push({ ecommerce: null }); dataLayer.push({ event: "purchase", ecommerce: { transaction_id: "10452", value: 234.90, shipping: 14.99, currency: "PLN", items: [{ item_id: "SKU-123", item_name: "Kurtka przeciwdeszczowa", item_brand: "Marka", item_variant: "czarna M", price: 117.45, quantity: 2 }] } });

Kilka zasad, które decydują o jakości danych. Wartości liczbowe wysyłaj jako liczby z kropką, nie jako tekst z walutą, bo tekstu nie da się zsumować. Numer transakcji musi być unikalny dla każdego zamówienia - GA4 traktuje zdarzenia purchase z tym samym transaction_id jako duplikaty. Kod zdarzenia generuje szablon sklepu z danych zamówienia zapisanych w bazie, a nie skrypt odczytujący kwoty z treści strony.

Co z odświeżeniem strony podziękowania? Klient, który wróci do niej z historii przeglądarki, nie powinien wywołać drugiego zakupu. Unikalny transaction_id pomaga w GA4, ale inne narzędzia reklamowe mają własne zasady deduplikacji. Najbezpieczniej, gdy szablon sklepu wypisuje zdarzenie purchase tylko przy pierwszym wyświetleniu strony dla danego zamówienia, np. na podstawie znacznika zapisanego w zamówieniu.

Zwróć też uwagę na rabaty i koszty dostawy. Cena produktu w tablicy items powinna być ceną, którą klient faktycznie płaci za sztukę, a koszt wysyłki trafia do osobnego parametru shipping. Jeśli sklep wlicza dostawę do value, a raz jej nie wlicza, przychód w GA4 i wartości konwersji w Google Ads przestaną być porównywalne z księgowością. Ważne, żeby zasada była jedna i opisana w dokumentacji warstwy danych - wtedy zespół reklamowy wie, co oznacza wartość konwersji, a programista przy kolejnych zmianach w sklepie nie zmieni jej przypadkiem. W sklepach B2B dochodzi jeszcze pytanie, czy wysyłać ceny netto, czy brutto, i to również trzeba ustalić raz dla wszystkich narzędzi.

Jak skonfigurować tagi GA4 w Google Tag Manager

Gdy sklep wysyła zdarzenia do dataLayer, konfiguracja w GTM jest powtarzalna. Według pomocy Google tag zdarzenia GA4 tworzy się w konfiguracji tagu, wpisując nazwę zdarzenia i parametry, a gdy zdarzenie ma się uruchamiać pod określonym warunkiem, dodaje się do tagu regułę (stan na sierpień 2026 - sprawdź aktualną pomoc Google). Proces wdrożenia od strony sklepu i GTM wygląda tak:

[#chart:wpr38b]

Dla zdarzeń z dataLayer stosuje się regułę typu zdarzenie niestandardowe, której nazwa odpowiada wartości event w dataLayer, np. purchase. Tagi Google Ads i Meta mogą korzystać z tych samych zdarzeń: konwersja Google Ads odczyta wartość i numer transakcji, a tag Meta - identyfikatory produktów i wartość. W ten sposób jedno źródło danych zasila wszystkie narzędzia.

• Zmienne warstwy danych - w GTM tworzy się zmienne odczytujące np. ecommerce.value i ecommerce.transaction_id,

• Reguły - zdarzenie niestandardowe dla każdej nazwy zdarzenia albo jedna reguła z wyrażeniem regularnym dla kilku,

• Tryb podglądu - pokazuje, jakie zdarzenia trafiły do dataLayer i które tagi się uruchomiły,

• Raport DebugView w GA4 - potwierdza, że zdarzenia dotarły do usługi z parametrami,

• Wersje kontenera - każda publikacja z opisem zmian, żeby dało się wrócić do poprzedniej.

Jak przetestować śledzenie konwersji przed publikacją

Zmiany w pomiarze warto testować tak samo starannie jak zmiany w koszyku, bo błąd w zdarzeniu purchase przez kilka tygodni psuje optymalizację kampanii. Kolejność testów, którą stosujemy:

1. Tryb podglądu GTM - przejście ścieżki od karty produktu do zakupu i sprawdzenie, czy każde zdarzenie trafia do dataLayer z kompletem danych.

2. DebugView w GA4 - potwierdzenie, że zdarzenia docierają do usługi z parametrami i tablicą items.

3. Zamówienie testowe - porównanie wartości, numeru transakcji i produktów w zdarzeniu z zamówieniem w panelu sklepu.

4. Przypadki brzegowe - kod rabatowy, kilka sztuk tego samego produktu, warianty, płatność zewnętrzna, odświeżenie strony podziękowania.

5. Kontrola po publikacji - po kilku dniach porównanie liczby i wartości transakcji w GA4 z zamówieniami w sklepie.

Osobno warto zaplanować zwroty. Zdarzenie refund z numerem transakcji pozwala GA4 pokazać rzeczywisty przychód po zwrotach, ale zwrot zwykle obsługuje się w panelu administracyjnym, a nie na stronie widzianej przez klienta. Dlatego refund często wysyła się z serwera, np. przez Measurement Protocol GA4, który przyjmuje zdarzenia wysyłane bezpośrednio z backendu. To zadanie dla programisty, bo wymaga połączenia procesu zwrotów w sklepie z GA4. Dokumentacja Google zaznacza przy tym, że Measurement Protocol ma uzupełniać pomiar przez tagi, a nie go zastępować, więc zdarzenia ze strony nadal pozostają podstawą.

Najczęstsze błędy w śledzeniu konwersji w sklepie

Większość problemów z pomiarem bierze się z danych w dataLayer, a nie z konfiguracji GTM. Objawy i poprawki, które widzimy najczęściej:

[#chart:wpr38c]

Do tego dochodzą błędy procesu: zmiana szablonu sklepu bez testu pomiaru, wtyczka pomiarowa zainstalowana obok ręcznie wdrożonego kodu, przez co zdarzenia idą podwójnie, albo płatność zewnętrzna, po której klient nie wraca na stronę podziękowania. Ten ostatni przypadek częściowo rozwiązuje pomiar po stronie serwera - kiedy ma sens, opisujemy we wpisie server-side tagging w GA4 - kiedy warto go wdrożyć w sklepie.

[#checklista] Lista kontrolna po wdrożeniu dataLayer: zdarzenia view_item, add_to_cart, begin_checkout i purchase widoczne w trybie podglądu GTM; wartości jako liczby; waluta PLN na poziomie zdarzenia; unikalny transaction_id; item_id zgodne z feedem produktowym; brak drugiego purchase po odświeżeniu strony; liczba transakcji w GA4 porównana z zamówieniami w sklepie po tygodniu.

Wtyczka do pomiaru czy własna warstwa danych

Dla popularnych platform istnieją wtyczki i aplikacje, które same budują dataLayer w formacie GA4. To dobry start, jeśli sklep ma standardowy proces zamówienia. Własna implementacja jest potrzebna, gdy sklep ma nietypowy koszyk, konfigurator produktu, sprzedaż B2B z cenami netto, zestawy albo kilka walut, a także wtedy, gdy wtyczka wysyła dane niezgodne z feedem produktowym. W praktyce często zostaje wtyczka, a programista uzupełnia ją o brakujące zdarzenia i poprawia identyfikatory. Niezależnie od wyboru, po każdej aktualizacji wtyczki lub szablonu warto powtórzyć zamówienie testowe, bo zmiana w kodzie koszyka potrafi po cichu wyłączyć jedno ze zdarzeń.

Warstwa danych przydaje się też przy pomiarze serwerowym. Zdarzenia z dataLayer można wysłać do kontenera serwerowego, a stamtąd do Conversions API Meta. Wtedy ten sam event_id z dataLayer służy do deduplikacji zdarzeń przeglądarkowych i serwerowych - szczegóły opisujemy we wpisie Conversions API dla Meta w sklepie online - po co i jak wdrożyć.

Jak Vinson pomaga ze śledzeniem konwersji w sklepie

Programiści Vinson zaczynają od audytu: sprawdzamy, jakie zdarzenia sklep wysyła do dataLayer, czy dane zgadzają się z zamówieniami i feedami produktowymi oraz jak skonfigurowany jest kontener GTM. Potem wdrażamy brakujące zdarzenia w szablonie sklepu lub module, porządkujemy tagi GA4, Google Ads i Meta, testujemy cały proces zakupu i zostawiamy dokumentację warstwy danych. Jako Google Partner i Meta Business Partner łączymy pracę nad pomiarem z obsługą kampanii. Szczegóły znajdziesz na stronie Wsparcie programistyczne dla e-commerce.

Najczęściej zadawane pytania

Co to jest dataLayer w sklepie internetowym?

DataLayer to obiekt JavaScript na stronie, w którym sklep zapisuje dane dla tagów, np. informacje o oglądanym produkcie, koszyku i zamówieniu. Google Tag Manager odczytuje te dane i przekazuje je do GA4, Google Ads czy Meta. Dzięki temu pomiar nie zależy od wyglądu strony.

Jakie zdarzenia e-commerce GA4 są najważniejsze?

Minimum dla sklepu to view_item, add_to_cart, begin_checkout i purchase, bo pozwalają zobaczyć cały proces zakupu i liczyć konwersje. Pełny zestaw obejmuje też m.in. view_item_list, view_cart, add_shipping_info, add_payment_info i refund. Nazwy zdarzeń i parametrów trzeba stosować dokładnie według dokumentacji Google.

Dlaczego GA4 pokazuje mniej transakcji niż sklep?

Najczęstsze przyczyny to blokery reklam, brak zgody na pomiar, płatności, po których klient nie wraca na stronę podziękowania, oraz błędy w kodzie zdarzenia purchase. Część różnicy jest naturalna, ale duża rozbieżność zwykle oznacza problem techniczny. Warto porównać listę numerów transakcji z GA4 z zamówieniami w sklepie.

Dlaczego zakupy w GA4 liczą się podwójnie?

Zwykle dlatego, że zdarzenie purchase wysyła jednocześnie wtyczka i ręcznie wdrożony kod albo strona podziękowania wysyła je przy każdym odświeżeniu. GA4 deduplikuje zdarzenia z tym samym transaction_id, więc brak lub zmienny numer transakcji pogarsza problem. Rozwiązaniem jest jedno źródło zdarzenia i unikalny numer zamówienia.

Czy do śledzenia konwersji potrzebny jest programista?

Przy standardowym sklepie i dobrej wtyczce marketer skonfiguruje pomiar w GTM samodzielnie. Programista jest potrzebny, gdy dane w dataLayer są niekompletne, sklep ma nietypowy proces zamówienia albo trzeba zsynchronizować identyfikatory produktów z feedami. Przydaje się też przy pomiarze serwerowym.

Dobrze zbudowana warstwa danych to fundament śledzenia konwersji w sklepie - od niej zależą raporty GA4, optymalizacja kampanii i remarketing. Jeśli chcesz wdrożyć dataLayer od nowa albo naprawić pomiar w swoim sklepie, sprawdź wsparcie programistyczne Vinson.