{"id":13139,"date":"2026-09-22T18:25:00","date_gmt":"2026-09-22T16:25:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13139"},"modified":"2026-09-09T13:25:47","modified_gmt":"2026-09-09T11:25:47","slug":"tutorial-z-zagniezdzonego-datalayer-zbudowac-trwale-zmienne-gtm","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/digital-analytics-pl\/tutorials-pl\/tutorial-z-zagniezdzonego-datalayer-zbudowac-trwale-zmienne-gtm\/","title":{"rendered":"Tutorial: Z zagnie\u017cd\u017conego dataLayer zbudowa\u0107 trwa\u0142e zmienne GTM"},"content":{"rendered":"

Sklep wypycha dane produktowe jako jeden zagnie\u017cd\u017cony obiekt, bo tak je i tak przechowuje. Mened\u017cer tag\u00f3w chce warto\u015bci p\u0142askich, po jednej na zmienn\u0105, a pomostem mi\u0119dzy nimi jest zapis z kropkami.<\/p>\n

Ten zapis si\u0119ga wszystkiego. Nie m\u00f3wi natomiast, kt\u00f3ra z powsta\u0142ych \u015bcie\u017cek b\u0119dzie poprawna tak\u017ce w przysz\u0142ym miesi\u0105cu – a mniej wi\u0119cej po\u0142owa nie b\u0119dzie, z powodu niemaj\u0105cego nic wsp\u00f3lnego z mened\u017cerem tag\u00f3w.<\/p>\n

\n\"Po
Ka\u017cda warto\u015b\u0107 jest osi\u0105galna. \u015acie\u017cki biegn\u0105ce przez indeks listy to te, kt\u00f3re staj\u0105 si\u0119 b\u0142\u0119dne, gdy tylko zmieni si\u0119 kolejno\u015b\u0107.<\/figcaption><\/figure>\n

Jak dociera zagnie\u017cd\u017cony push<\/h2>\n

Zwyk\u0142y push e-commerce niesie trzy poziomy: zdarzenie, obiekt pod nim, a pod nim list\u0119 artyku\u0142\u00f3w.<\/p>\n

dataLayer.push({\n  event: \"add_to_cart\",\n  ecommerce: {\n    currency: \"EUR\",\n    value: 129.90,\n    items: [\n      { item_id: \"SKU-42\", item_name: \"Stuhl\", price: 64.95, quantity: 2,\n        item_category: \"Moebel\", index: 0 },\n      { item_id: \"SKU-77\", item_name: \"Tisch\", price: 219.00, quantity: 1,\n        item_category: \"Moebel\", index: 1 }\n    ]\n  },\n  user: { logged_in: true, segment: \"b2b\" }\n});<\/code><\/pre>\n
Rozpisany na \u015bcie\u017cki obiekt ten zawiera jedn\u0105 nazw\u0119 zdarzenia, trzy warto\u015bci pod ecommerce<\/code>, dwana\u015bcie wewn\u0105trz listy artyku\u0142\u00f3w i dwie pod user<\/code>. Ka\u017cda z nich jest osi\u0105galna, a adresem jest \u0142a\u0144cuch kluczy po\u0142\u0105czony kropkami.<\/p>\n
Wersja 2 i kropka b\u0119d\u0105ca rozdzielnikiem<\/h2>\n
Zmienna warstwy danych w mened\u017cerze tag\u00f3w ma ustawienie wersji i to ono wyznacza spos\u00f3b odczytu nazwy.<\/p>\n
Wersja 2:  ecommerce.currency          \u2192  \"EUR\"\n           ecommerce.items.0.item_id   \u2192  \"SKU-42\"\n           user.segment                \u2192  \"b2b\"\n\nWersja 1:  ecommerce.currency          \u2192  undefined\n           (caly ciag uchodzi za jeden klucz)<\/code><\/pre>\n
Wersja 2 jest domy\u015blna dla nowych zmiennych i niemal zawsze w\u0142a\u015bciwa. Wersja 1 istnieje dla jednego przypadku: klucza faktycznie nosz\u0105cego kropk\u0119 w nazwie. Push z {\"page.type\": \"pdp\"}<\/code> jest osi\u0105galny wy\u0142\u0105cznie wersj\u0105 1, bo wersja 2 szuka\u0142aby type<\/code> w page<\/code>, kt\u00f3rego nie ma.<\/p>\n
Dwa szczeg\u00f3\u0142y kosztuj\u0105ce czas, dop\u00f3ki s\u0105 nieznane. \u015acie\u017cka rozr\u00f3\u017cnia wielko\u015b\u0107 liter w ca\u0142o\u015bci, wi\u0119c Ecommerce.Items<\/code> nic nie znajduje i nic nie zg\u0142asza. A zmienna bez warto\u015bci domy\u015blnej zwraca dla brakuj\u0105cej \u015bcie\u017cki undefined<\/code>, co w tagu staje si\u0119 pustym parametrem, a nie b\u0142\u0119dem – przekr\u0119cona \u015bcie\u017cka wygl\u0105da wi\u0119c tak samo jak warto\u015b\u0107 nigdy niewys\u0142ana.<\/p>\n
Listy i dlaczego indeks jest cz\u0119\u015bci\u0105 kruch\u0105<\/h2>\n
Krok w list\u0119 jest liczb\u0105, a ta liczba to pozycja, a nie to\u017csamo\u015b\u0107.<\/p>\n\n\n\n\n\n\n\n\n\n
\u015acie\u017cka<\/th>\nStabilna?<\/th>\nDlaczego<\/th>\n<\/tr>\n<\/thead>\n
ecommerce.currency<\/td>\ntak<\/td>\nNazwany klucz na sta\u0142ej g\u0142\u0119boko\u015bci<\/td>\n<\/tr>\n
ecommerce.value<\/td>\ntak<\/td>\nTak samo<\/td>\n<\/tr>\n
user.segment<\/td>\ntak<\/td>\nTak samo<\/td>\n<\/tr>\n
ecommerce.items.0.item_id<\/td>\nnie<\/td>\nPozycja 0 to artyku\u0142, kt\u00f3ry akurat stoi z przodu<\/td>\n<\/tr>\n
ecommerce.items.1.price<\/td>\nnie<\/td>\nBrakuje jej ca\u0142kiem w koszyku z jednym artyku\u0142em<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Drugi wiersz dolnej po\u0142owy wytwarza szkod\u0119 cich\u0105. W koszyku z jednym artyku\u0142em items.1<\/code> nie istnieje, zmienna pozostaje pusta, a tag wysy\u0142a parametr bez warto\u015bci. Nic nie zawodzi, a raport pokazuje liczb\u0119 nieco mniejsz\u0105 ni\u017c sklep.<\/p>\n
\u015acie\u017cka z indeksem da si\u0119 obroni\u0107 w dok\u0142adnie jednym po\u0142o\u017ceniu: na stronie zawsze nosz\u0105cej dok\u0142adnie jeden artyku\u0142, na przyk\u0142ad karcie produktu. Wsz\u0119dzie indziej – koszyk, kasa, zakup – liczba artyku\u0142\u00f3w jest zmienna, a ich kolejno\u015b\u0107 tak samo.<\/p>\n
Scalanie, o kt\u00f3re nikt nie prosi\u0142<\/h2>\n
Warstwa danych nie jest list\u0105 komunikat\u00f3w. Mened\u017cer tag\u00f3w prowadzi scalony model wszystkich dotychczasowych pushy, a nowy push zostaje w niego wtopiony, zamiast go zast\u0105pi\u0107.<\/p>\n
Skutek jest okre\u015blony i przykry. Strona wypychaj\u0105ca najpierw view_item<\/code> z jednym artyku\u0142em, a potem add_to_cart<\/code> z innym, zostawia warto\u015bci pierwszego artyku\u0142u wsz\u0119dzie tam, gdzie drugi push ich nie nadpisze. Po li\u015bcie artyku\u0142\u00f3w o d\u0142ugo\u015bci trzy przychodzi lista o d\u0142ugo\u015bci jeden, a wychodzi scalona lista o d\u0142ugo\u015bci trzy, z dwoma wpisami z poprzedniego zdarzenia.<\/p>\n
dataLayer.push({ ecommerce: null });   \/\/ sprzata galaz\ndataLayer.push({\n  event: \"add_to_cart\",\n  ecommerce: { currency: \"EUR\", value: 64.95, items: [ \/* \u2026 *\/ ] }\n});<\/code><\/pre>\n
Push sprz\u0105taj\u0105cy nale\u017cy bez wyj\u0105tku przed ka\u017cdy push e-commerce i jest najcz\u0119stszym pomini\u0119ciem w pod\u0142\u0105czeniu sklepu. Jego dzia\u0142anie wida\u0107 w podgl\u0105dzie: widok komunikat\u00f3w pokazuje, co zosta\u0142o wypchni\u0119te, widok modelu pokazuje, co zmienna naprawd\u0119 odczyta – a r\u00f3\u017cnica mi\u0119dzy nimi to dok\u0142adnie ten problem.<\/p>\n
Jedna zmienna zamiast dwudziestu<\/h2>\n
Tam, gdzie potrzebna jest ca\u0142a lista, odpowiedzi\u0105 nie jest dwadzie\u015bcia \u015bcie\u017cek z indeksem. Jest ni\u0105 w\u0142asna zmienna JavaScript czytaj\u0105ca list\u0119 i zwracaj\u0105ca to, czego potrzebuje tag.<\/p>\n
function () {\n  var artikel = {{DLV - ecommerce.items}};\n  if (!Array.isArray(artikel) || !artikel.length) { return undefined; }\n\n  return artikel.map(function (a) {\n    return {\n      item_id:       String(a.item_id || a.id || \"\"),\n      item_name:     String(a.item_name || a.name || \"\"),\n      price:         Number(a.price) || 0,\n      quantity:      Number(a.quantity) || 1,\n      item_category: String(a.item_category || \"\")\n    };\n  }).filter(function (a) { return a.item_id !== \"\"; });\n}<\/code><\/pre>\n
Trzy rzeczy daje to ponad odporno\u015b\u0107 na kolejno\u015b\u0107. Ujednolica nazwy p\u00f3l, wi\u0119c sklep wysy\u0142aj\u0105cy na jednej stronie id<\/code>, a na innej item_id<\/code>, wytwarza dalej jedn\u0105 posta\u0107. Wymusza typy, przez co cena przychodz\u0105ca jako ci\u0105g \"64.95\"<\/code> przestaje by\u0107 problemem. I odrzuca artyku\u0142y bez identyfikatora, kt\u00f3re GA4 i tak by odrzuci\u0142o – tyle \u017ce po cichu.<\/p>\n
Zmienna, kt\u00f3r\u0105 to czyta, jest zwyk\u0142\u0105 zmienn\u0105 warstwy danych wskazuj\u0105c\u0105 ecommerce.items<\/code>, bez indeksu. Ta \u015bcie\u017cka jest stabilna, bo nazywa klucz, a nie pozycj\u0119.<\/p>\n
Sprawdzenie w podgl\u0105dzie<\/h2>\n
Dwa widoki podgl\u0105du rozstrzygaj\u0105 wszystko om\u00f3wione powy\u017cej i \u0142atwo je ze sob\u0105 pomyli\u0107.<\/p>\n
Widok komunikat\u00f3w pokazuje push dok\u0142adnie tak, jak wys\u0142a\u0142a go strona. Widok modelu pokazuje scalony stan, kt\u00f3ry zmienna odczyta w tej chwili. Warto\u015b\u0107 stoj\u0105ca w drugim, a brakuj\u0105ca w pierwszym, to pozosta\u0142o\u015b\u0107 po wcze\u015bniejszym pushu – problem sprz\u0105tania – a warto\u015b\u0107 w pierwszym, brakuj\u0105ca w drugim, zosta\u0142a zwykle nadpisana przez push p\u00f3\u017aniejszy.<\/p>\n
Trzeci widok, obszar zmiennych wybranego zdarzenia, pokazuje, co ka\u017cda skonfigurowana zmienna faktycznie zwr\u00f3ci\u0142a. undefined<\/code> w tym miejscu jest odpowiedzi\u0105 na niemal ka\u017cde pytanie o brakuj\u0105cy parametr i rozdziela dwie mo\u017cliwe przyczyny: \u015bcie\u017cka jest b\u0142\u0119dna albo warto\u015b\u0107 nigdy nie zosta\u0142a wypchni\u0119ta. Zestawienie zmiennej z widokiem modelu rozdziela to w sekundy.<\/p>\n
Ostatni nawyk zapobiega najbardziej mozolnej klasie b\u0142\u0119d\u00f3w. \u015acie\u017cka ze \u017ar\u00f3d\u0142a strony to nie \u015bcie\u017cka z warstwy danych – wtyczka sklepu potrafi zmieni\u0107 nazwy kluczy mi\u0119dzy szablonem a pushem, a sklep przet\u0142umaczony czasem t\u0142umaczy je razem z reszt\u0105. \u015acie\u017ck\u0119 nale\u017cy skopiowa\u0107 z widoku modelu prawdziwego zdarzenia, a nie przepisa\u0107 z dokumentacji.<\/p>\n
\n
\u0179r\u00f3d\u0142a<\/h2>\n