{"id":13137,"date":"2026-09-22T12:45:00","date_gmt":"2026-09-22T10:45:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13137"},"modified":"2026-09-09T13:25:45","modified_gmt":"2026-09-09T11:25:45","slug":"tutorial-aus-einem-verschachtelten-datalayer-haltbare-gtm-variablen-bauen","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/digital-analytics-de\/tutorials-de\/tutorial-aus-einem-verschachtelten-datalayer-haltbare-gtm-variablen-bauen\/","title":{"rendered":"Tutorial: Aus einem verschachtelten dataLayer haltbare GTM-Variablen bauen"},"content":{"rendered":"

Ein Shop schiebt seine Produktdaten als ein verschachteltes Objekt hinaus, denn so h\u00e4lt er sie ohnehin vor. Der Tag-Manager will flache Werte, einen je Variable, und die Br\u00fccke dazwischen ist eine Schreibweise mit Punkten darin.<\/p>\n

Diese Schreibweise erreicht alles. Was sie nicht sagt, ist, welcher der entstehenden Pfade auch im n\u00e4chsten Monat noch stimmt – und ungef\u00e4hr die H\u00e4lfte tut das nicht, aus einem Grund, der mit dem Tag-Manager nichts zu tun hat.<\/p>\n

\n\"Links
Jeder Wert ist erreichbar. Die Pfade, die \u00fcber einen Listenindex laufen, sind die, die falsch werden, sobald sich die Reihenfolge \u00e4ndert.<\/figcaption><\/figure>\n

Wie ein verschachtelter Push ankommt<\/h2>\n

Ein \u00fcblicher E-Commerce-Push tr\u00e4gt drei Ebenen: das Ereignis, ein Objekt darunter und darunter eine Liste von Artikeln.<\/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
Als Pfade ausgeschrieben enth\u00e4lt dieses Objekt einen Ereignisnamen, drei Werte unter ecommerce<\/code>, zw\u00f6lf innerhalb der Artikelliste und zwei unter user<\/code>. Jeder davon ist ansprechbar, und die Anschrift ist die mit Punkten verbundene Kette der Schl\u00fcssel.<\/p>\n
Version 2 und der Punkt, der ein Trenner ist<\/h2>\n
Eine Datenschichtvariable im Tag-Manager hat eine Versionseinstellung, und diese bestimmt, wie der Name gelesen wird.<\/p>\n
Version 2:  ecommerce.currency          \u2192  \"EUR\"\n            ecommerce.items.0.item_id   \u2192  \"SKU-42\"\n            user.segment                \u2192  \"b2b\"\n\nVersion 1:  ecommerce.currency          \u2192  undefined\n            (die ganze Zeichenkette gilt als ein Schluessel)<\/code><\/pre>\n
Version 2 ist bei neuen Variablen voreingestellt und fast immer die richtige Wahl. Version 1 gibt es f\u00fcr einen bestimmten Fall: einen Schl\u00fcssel, der tats\u00e4chlich einen Punkt im Namen tr\u00e4gt. Ein Push mit {\"page.type\": \"pdp\"}<\/code> ist nur mit Version 1 erreichbar, denn Version 2 suchte ein type<\/code> in einem page<\/code>, das es nicht gibt.<\/p>\n
Zwei Einzelheiten, die Zeit kosten, solange sie unbekannt sind. Der Pfad unterscheidet durchgehend Gross- und Kleinschreibung, Ecommerce.Items<\/code> findet also nichts und meldet nichts. Und eine Variable ohne Vorgabewert liefert f\u00fcr einen fehlenden Pfad undefined<\/code>, was in einem Tag zu einem leeren Parameter wird statt zu einem Fehler – ein vertippter Pfad sieht damit genauso aus wie ein Wert, der nie gesendet wurde.<\/p>\n
Listen und warum der Index der br\u00fcchige Teil ist<\/h2>\n
Der Schritt in eine Liste ist eine Zahl, und diese Zahl ist eine Position und keine Kennung.<\/p>\n\n\n\n\n\n\n\n\n\n
Pfad<\/th>\nStabil?<\/th>\nWarum<\/th>\n<\/tr>\n<\/thead>\n
ecommerce.currency<\/td>\nja<\/td>\nEin benannter Schl\u00fcssel in fester Tiefe<\/td>\n<\/tr>\n
ecommerce.value<\/td>\nja<\/td>\nEbenso<\/td>\n<\/tr>\n
user.segment<\/td>\nja<\/td>\nEbenso<\/td>\n<\/tr>\n
ecommerce.items.0.item_id<\/td>\nnein<\/td>\nPosition 0 ist der Artikel, der zuf\u00e4llig vorn steht<\/td>\n<\/tr>\n
ecommerce.items.1.price<\/td>\nnein<\/td>\nFehlt vollst\u00e4ndig in einem Warenkorb mit einem Artikel<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Die zweite Zeile der unteren H\u00e4lfte erzeugt den stillen Schaden. In einem Warenkorb mit einem Artikel gibt es items.1<\/code> nicht, die Variable bleibt leer, und das Tag sendet einen Parameter ohne Wert. Nichts schl\u00e4gt fehl, und der Bericht zeigt eine etwas kleinere Zahl als der Shop.<\/p>\n
Ein Indexpfad ist in genau einer Lage vertretbar: auf einer Seite, die immer genau einen Artikel f\u00fchrt, etwa einer Produktdetailseite. \u00dcberall sonst – Warenkorb, Kasse, Kauf – ist die Anzahl der Artikel ver\u00e4nderlich und ihre Reihenfolge ebenso.<\/p>\n
Die Zusammenf\u00fchrung, um die niemand gebeten hat<\/h2>\n
Die Datenschicht ist keine Liste von Nachrichten. Der Tag-Manager f\u00fchrt ein zusammengef\u00fchrtes Modell aller bisherigen Pushes, und ein neuer Push wird hineingef\u00fchrt statt es zu ersetzen.<\/p>\n
Die Folge ist bestimmt und unangenehm. Eine Seite, die erst ein view_item<\/code> mit einem Artikel und danach ein add_to_cart<\/code> mit einem anderen schiebt, l\u00e4sst die Werte des ersten Artikels \u00fcberall dort stehen, wo der zweite Push sie nicht \u00fcberschreibt. Auf eine Artikelliste der L\u00e4nge drei folgt eine der L\u00e4nge eins, und heraus kommt eine zusammengef\u00fchrte Liste der L\u00e4nge drei, mit zwei Eintr\u00e4gen aus dem vorigen Ereignis.<\/p>\n
dataLayer.push({ ecommerce: null });   \/\/ raeumt den Zweig\ndataLayer.push({\n  event: \"add_to_cart\",\n  ecommerce: { currency: \"EUR\", value: 64.95, items: [ \/* \u2026 *\/ ] }\n});<\/code><\/pre>\n
Der r\u00e4umende Push geh\u00f6rt ausnahmslos vor jeden E-Commerce-Push und ist die h\u00e4ufigste Auslassung in einer Shop-Anbindung. Seine Wirkung ist in der Vorschau sichtbar: Die Nachrichtenansicht zeigt, was geschoben wurde, die Modellansicht zeigt, was eine Variable tats\u00e4chlich lesen wird – und der Unterschied zwischen beiden ist genau dieses Problem.<\/p>\n
Eine Variable statt zwanzig<\/h2>\n
Wo eine ganze Liste gebraucht wird, ist die Antwort nicht zwanzig Indexpfade. Sie ist eine eigene JavaScript-Variable, die die Liste liest und zur\u00fcckgibt, was das Tag braucht.<\/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
Drei Dinge bringt das \u00fcber die Unempfindlichkeit gegen die Reihenfolge hinaus. Es vereinheitlicht die Feldnamen, sodass ein Shop, der auf einer Seite id<\/code> und auf einer anderen item_id<\/code> sendet, weiter unten eine einzige Form erzeugt. Es erzwingt die Typen, womit ein Preis, der als Zeichenkette \"64.95\"<\/code> ankommt, aufh\u00f6rt ein Problem zu sein. Und es verwirft Artikel ohne Kennung, die GA4 ohnehin verwerfen w\u00fcrde – nur eben stillschweigend.<\/p>\n
Die Variable, die es liest, ist eine gew\u00f6hnliche Datenschichtvariable auf ecommerce.items<\/code>, ohne Index. Dieser Pfad ist stabil, denn er benennt einen Schl\u00fcssel und keine Position.<\/p>\n
In der Vorschau nachsehen<\/h2>\n
Zwei Ansichten der Vorschau kl\u00e4ren alles bisher Besprochene, und sie lassen sich leicht miteinander verwechseln.<\/p>\n
Die Nachrichtenansicht zeigt den Push genau so, wie die Seite ihn gesendet hat. Die Modellansicht zeigt den zusammengef\u00fchrten Zustand, den eine Variable in diesem Augenblick liest. Ein Wert, der in der zweiten steht und in der ersten fehlt, ist ein \u00dcberbleibsel eines fr\u00fcheren Pushes – das R\u00e4umproblem -, und ein Wert in der ersten, der in der zweiten fehlt, wurde meist von einem sp\u00e4teren Push \u00fcberschrieben.<\/p>\n
Die dritte Ansicht, der Variablenbereich des gew\u00e4hlten Ereignisses, zeigt, was jede eingerichtete Variable tats\u00e4chlich zur\u00fcckgab. Ein undefined<\/code> dort ist die Antwort auf fast jede Frage nach einem fehlenden Parameter, und es trennt die beiden m\u00f6glichen Ursachen: Der Pfad ist falsch, oder der Wert wurde nie geschoben. Der Vergleich der Variablen gegen die Modellansicht trennt das in Sekunden.<\/p>\n
Eine letzte Gewohnheit verhindert die m\u00fchsamste Fehlerklasse. Ein Pfad aus dem Quelltext einer Seite ist kein Pfad aus der Datenschicht – ein Shop-Plugin kann Schl\u00fcssel zwischen Vorlage und Push umbenennen, und ein \u00fcbersetzter Shop \u00fcbersetzt sie gelegentlich mit. Der Pfad geh\u00f6rt aus der Modellansicht eines echten Ereignisses kopiert, nicht aus der Dokumentation abgetippt.<\/p>\n
\n
Quellen<\/h2>\n