Warstwa danych dla e-commerce GA4: specyfikacja dataLayer do przekazania programiście

Czym jest warstwa danych i dlaczego sklep potrzebuje specyfikacji

Warstwa danych to obiekt JavaScript, do którego strona dopisuje komunikaty o tym, co się wydarzyło, a GTM je odczytuje. Specyfikacja to umowa między marketingiem a programistą: określa, jakie zdarzenia, kiedy i z jakimi polami mają się pojawić.

Bez takiej umowy pomiar opiera się na odczytywaniu danych z wyglądu strony: ceny z elementu na karcie produktu, nazwy z nagłówka, kwoty zamówienia z tabeli podsumowania. Działa to do pierwszej zmiany szablonu. Warstwa danych oddziela pomiar od wyglądu – programista przekazuje dane bezpośrednio z systemu sklepu, a marketer decyduje w GTM, gdzie je wysłać. Te same komunikaty obsłużą GA4, tag konwersji Google Ads z danymi koszyka, Meta Pixel i inne narzędzia. Jeśli dopiero zaczynasz pracę z kontenerem, najpierw przeczytaj tekst Google Tag Manager od podstaw.

Lista zdarzeń e-commerce GA4 i moment ich wysyłki

GA4 ma zestaw rekomendowanych nazw zdarzeń e-commerce i tylko przy nich wypełnia raporty zakupów i produktów. Nazwy muszą być zapisane dokładnie tak jak w tabeli, małymi literami.

Minimum, bez którego raporty sprzedaży nie mają sensu, to view_item, add_to_cart, begin_checkout i purchase. Pozostałe zdarzenia pozwalają zbudować pełny lejek i sprawdzić, na którym etapie odpadają klienci. Zwroty zwykle obsługuje się nie w przeglądarce, ale z systemu sklepu, bo klient nie odwiedza wtedy strony.

Parametry produktu w tablicy items

Tablica items występuje w każdym zdarzeniu e-commerce i zawiera po jednym obiekcie na produkt. Każdy obiekt musi mieć co najmniej item_id lub item_name, ale w praktyce przekazuj oba.

Zgodność item_id z feedem produktowym ma znaczenie nie tylko dla porządku. Google Ads przy konwersjach z danymi koszyka łączy produkty z zamówienia z produktami z Merchant Center właśnie po identyfikatorze. Jak utrzymać feed bez błędów, opisujemy w artykule o najczęstszych odrzuceniach w Merchant Center.

Przykładowy kod dataLayer e-commerce: karta produktu i zakup

Każde zdarzenie e-commerce składa się z dwóch komunikatów: wyczyszczenia poprzedniego obiektu ecommerce i właściwego zdarzenia. Poniżej wzór dla karty produktu.

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({ ecommerce: null });
window.dataLayer.push({
  event: 'view_item',
  ecommerce: {
    currency: 'PLN',
    value: 129.99,
    items: [{
      item_id: 'SKU-1042',
      item_name: 'Konewka ogrodowa 5 l',
      item_brand: 'GreenLine',
      item_category: 'Ogród',
      item_category2: 'Podlewanie',
      item_variant: 'zielona',
      price: 129.99,
      discount: 20.00,
      quantity: 1
    }]
  }
});

Zakup wysyłasz na stronie potwierdzenia zamówienia. Najpewniejszym zabezpieczeniem przed duplikatami jest znacznik po stronie systemu sklepu (np. pole „zdarzenie wysłane” w zamówieniu), a jeśli to niemożliwe – blokada w przeglądarce, jak w przykładzie.

(function () {
  var orderId = 'ZAM-2026-104233';
  var key = 'purchase_sent_' + orderId;
  try {
    if (window.localStorage.getItem(key)) { return; }
    window.localStorage.setItem(key, '1');
  } catch (e) {}
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({ ecommerce: null });
  window.dataLayer.push({
    event: 'purchase',
    ecommerce: {
      transaction_id: orderId,
      currency: 'PLN',
      value: 259.98,
      shipping: 14.99,
      tax: 48.61, // VAT zawarty w cenach brutto
      coupon: 'JESIEN10',
      items: [{ item_id: 'SKU-1042', item_name: 'Konewka ogrodowa 5 l', price: 129.99, quantity: 2 }]
    }
  });
})();

Zasady, które musisz zapisać w specyfikacji dla programisty

Sam przykład kodu nie wystarczy, bo najwięcej błędów wynika z interpretacji: co to jest cena, kiedy zamówienie jest zakupem, co z rabatem. Te zasady dopisz wprost do dokumentu.

1. Kolejność komunikatów. Najpierw { ecommerce: null }, potem zdarzenie. Nigdy nie nadpisuj całego obiektu przypisaniem dataLayer = [] po załadowaniu GTM.
2. Liczby jako liczby. 129.99, a nie "129,99 zł". Kropka jako separator dziesiętny, bez spacji i symbolu waluty.
3. Waluta przy każdej wartości. Parametr currency z kodem ISO 4217, np. PLN lub EUR, zawsze gdy podajesz value.
4. Definicja value. Suma price × quantity wszystkich produktów. Nie doliczaj do niej kosztów dostawy ani podatku – przekazujesz je w shipping i tax. Przy cenach brutto tax jest informacją o VAT zawartym w cenach, a nie kwotą do dodania.
5. Brutto czy netto. Zdecyduj raz i zapisz. Ważne, żeby GA4, Google Ads i raporty finansowe używały tej samej konwencji, inaczej porównanie ROAS z danymi księgowymi będzie wymagało przeliczeń.
6. Rabaty. price to cena jednostkowa po rabacie, a discount to rabat na jedną sztukę.
7. Unikalny transaction_id. Ten sam numer co w panelu sklepu i w CRM, żeby można było łączyć dane i usuwać duplikaty.
8. Jedno zdarzenie purchase na zamówienie. Także przy odświeżeniu strony, powrocie z bramki płatności i otwarciu linku z e-maila.
9. Sklepy jednostronicowe (SPA). Zdarzenia wysyłaj po każdej wirtualnej zmianie widoku, a nie tylko przy pierwszym załadowaniu.
10. Limit produktów. Jedno zdarzenie może zawierać do 200 elementów w tablicy items.

Osobny problem to płatności przez bramki, np. szybkie przelewy czy BLIK. Część klientów nie wraca na stronę podziękowania, więc zdarzenie w przeglądarce się nie wykona. Rozwiązaniem jest wysłanie zakupu z serwera w momencie potwierdzenia płatności – to jeden z głównych powodów, dla których sklepy przenoszą pomiar na własny serwer tagowania. Na serwerze możesz też bezpiecznie dopisać do transakcji marżę, której nie powinno się ujawniać w przeglądarce; opisujemy to w tekście o wzbogacaniu zdarzeń po stronie serwera.

Dane klienta i Enhanced Conversions w warstwie danych

Jeśli korzystasz z rozszerzonych konwersji Google Ads, na stronie potwierdzenia zamówienia przekaż też dane klienta w osobnym obiekcie. GTM odczyta je zmienną danych przekazywanych przez użytkownika i zahaszuje algorytmem SHA-256 przed wysłaniem.

window.dataLayer.push({
  event: 'user_data_ready',
  user_data: {
    email: '[email protected]',
    phone_number: '+48600100200',
    address: { first_name: 'Jan', last_name: 'Kowalski', postal_code: '00-001', city: 'Warszawa', country: 'PL' }
  },
  new_customer: true
});

Telefon przekazuj w formacie międzynarodowym z kodem kraju, a e-mail małymi literami i bez spacji. Pole new_customer przyda się, jeśli chcesz raportować pozyskanie nowych klientów w Google Ads – jak z niego korzystać, wyjaśniamy w artykule o raportowaniu nowych klientów w Google Ads. Konfigurację tagu krok po kroku opisuje poradnik o Enhanced Conversions przez GTM.

Dane osobowe w warstwie danych są widoczne dla każdego skryptu na stronie, dlatego wysyłaj je wyłącznie na stronie potwierdzenia, nie umieszczaj ich w parametrach produktów i przekazuj tylko wtedy, gdy pozwala na to stan zgód. Zakres i podstawę prawną takiego przetwarzania w konkretnym sklepie warto omówić z prawnikiem.

Jak odebrać dane w GTM i przetestować wdrożenie

Po stronie GTM potrzebujesz niewiele: w tagu zdarzenia GA4 włącz w sekcji „Więcej ustawień” wysyłanie danych e-commerce i jako źródło wskaż warstwę danych. Tag sam odczyta items, value i currency.

Wiele kontenerów obsługuje wszystkie zdarzenia e-commerce jednym tagiem GA4, w którym nazwa zdarzenia to zmienna wbudowana {{Event}}, a regułą jest „Zdarzenie niestandardowe” z wyrażeniem regularnym. Użyj zamkniętej listy nazw zamiast .*, bo od października 2026 roku ogólne wyrażenie łapie też zdarzenie gtag.config – szczegóły znajdziesz w omówieniu zmian w GTM w 2026 roku.

Reguła: Zdarzenie niestandardowe, dopasowanie do wyrażenia regularnego
^(view_item_list|select_item|view_item|add_to_cart|remove_from_cart|view_cart|begin_checkout|add_shipping_info|add_payment_info|purchase)$
Tag: Google Analytics: zdarzenie GA4, nazwa zdarzenia: {{Event}}

Testuj w trzech miejscach. W podglądzie GTM, na karcie warstwy danych, sprawdź treść każdego komunikatu. W GA4 otwórz DebugView i potwierdź, że zdarzenia mają parametry i produkty; najczęstsze przyczyny braku zdarzeń opisujemy w tekście o problemach w DebugView. Po 24–48 godzinach porównaj liczbę transakcji i przychód w raporcie zakupów e-commerce z panelem sklepu. Przy większej skali kontrolę ułatwia eksport do BigQuery i gotowe zapytania do danych GA4.

Najczęstsze błędy w implementacji dataLayer e-commerce

Większość problemów z danymi e-commerce w GA4 sprowadza się do kilku powtarzalnych błędów. Każdy z nich da się wykryć w podglądzie albo w raportach.

• Brak czyszczenia obiektu ecommerce. Zdarzenie view_item_list zawiera produkty z poprzedniego view_item. Widać to w podglądzie na karcie warstwy danych.
• Wartości jako tekst z przecinkiem. Przychód w GA4 wynosi zero albo jest zaniżony, choć transakcje są liczone.
• Zakup przy każdym odświeżeniu. Liczba transakcji rośnie szybciej niż w panelu sklepu, a w raporcie pojawiają się powtórzone identyfikatory; procedurę naprawy zawiera artykuł o duplikatach transakcji w GA4.
• Stary format z Universal Analytics. Struktury typu ecommerce.purchase.actionField i products nie są automatycznie odczytywane przez tagi GA4 – trzeba je przepisać na items.
• Zakup przed potwierdzeniem płatności. Jeśli zdarzenie wysyłasz dla zamówień nieopłaconych, ustal, jak raportować anulowane transakcje, np. przez zdarzenie refund.

Kolejne poradniki o konfiguracji tagów znajdziesz w podtemacie Google Tag Manager.