Tutorial: Aus einem verschachtelten dataLayer haltbare GTM-Variablen bauen

Ein Shop schiebt seine Produktdaten als ein verschachteltes Objekt hinaus, denn so hält er sie ohnehin vor. Der Tag-Manager will flache Werte, einen je Variable, und die Brücke dazwischen ist eine Schreibweise mit Punkten darin.

Diese Schreibweise erreicht alles. Was sie nicht sagt, ist, welcher der entstehenden Pfade auch im nächsten Monat noch stimmt – und ungefähr die Hälfte tut das nicht, aus einem Grund, der mit dem Tag-Manager nichts zu tun hat.

Wie ein verschachtelter Push ankommt

Ein üblicher E-Commerce-Push trägt drei Ebenen: das Ereignis, ein Objekt darunter und darunter eine Liste von Artikeln.

dataLayer.push({
  event: "add_to_cart",
  ecommerce: {
    currency: "EUR",
    value: 129.90,
    items: [
      { item_id: "SKU-42", item_name: "Stuhl", price: 64.95, quantity: 2,
        item_category: "Moebel", index: 0 },
      { item_id: "SKU-77", item_name: "Tisch", price: 219.00, quantity: 1,
        item_category: "Moebel", index: 1 }
    ]
  },
  user: { logged_in: true, segment: "b2b" }
});

Als Pfade ausgeschrieben enthält dieses Objekt einen Ereignisnamen, drei Werte unter ecommerce, zwölf innerhalb der Artikelliste und zwei unter user. Jeder davon ist ansprechbar, und die Anschrift ist die mit Punkten verbundene Kette der Schlüssel.

Version 2 und der Punkt, der ein Trenner ist

Eine Datenschichtvariable im Tag-Manager hat eine Versionseinstellung, und diese bestimmt, wie der Name gelesen wird.

Version 2:  ecommerce.currency          →  "EUR"
            ecommerce.items.0.item_id   →  "SKU-42"
            user.segment                →  "b2b"

Version 1:  ecommerce.currency          →  undefined
            (die ganze Zeichenkette gilt als ein Schluessel)

Version 2 ist bei neuen Variablen voreingestellt und fast immer die richtige Wahl. Version 1 gibt es für einen bestimmten Fall: einen Schlüssel, der tatsächlich einen Punkt im Namen trägt. Ein Push mit {"page.type": "pdp"} ist nur mit Version 1 erreichbar, denn Version 2 suchte ein type in einem page, das es nicht gibt.

Zwei Einzelheiten, die Zeit kosten, solange sie unbekannt sind. Der Pfad unterscheidet durchgehend Gross- und Kleinschreibung, Ecommerce.Items findet also nichts und meldet nichts. Und eine Variable ohne Vorgabewert liefert für einen fehlenden Pfad undefined, 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.

Listen und warum der Index der brüchige Teil ist

Der Schritt in eine Liste ist eine Zahl, und diese Zahl ist eine Position und keine Kennung.

Die zweite Zeile der unteren Hälfte erzeugt den stillen Schaden. In einem Warenkorb mit einem Artikel gibt es items.1 nicht, die Variable bleibt leer, und das Tag sendet einen Parameter ohne Wert. Nichts schlägt fehl, und der Bericht zeigt eine etwas kleinere Zahl als der Shop.

Ein Indexpfad ist in genau einer Lage vertretbar: auf einer Seite, die immer genau einen Artikel führt, etwa einer Produktdetailseite. Überall sonst – Warenkorb, Kasse, Kauf – ist die Anzahl der Artikel veränderlich und ihre Reihenfolge ebenso.

Die Zusammenführung, um die niemand gebeten hat

Die Datenschicht ist keine Liste von Nachrichten. Der Tag-Manager führt ein zusammengeführtes Modell aller bisherigen Pushes, und ein neuer Push wird hineingeführt statt es zu ersetzen.

Die Folge ist bestimmt und unangenehm. Eine Seite, die erst ein view_item mit einem Artikel und danach ein add_to_cart mit einem anderen schiebt, lässt die Werte des ersten Artikels überall dort stehen, wo der zweite Push sie nicht überschreibt. Auf eine Artikelliste der Länge drei folgt eine der Länge eins, und heraus kommt eine zusammengeführte Liste der Länge drei, mit zwei Einträgen aus dem vorigen Ereignis.

dataLayer.push({ ecommerce: null });   // raeumt den Zweig
dataLayer.push({
  event: "add_to_cart",
  ecommerce: { currency: "EUR", value: 64.95, items: [ /* … */ ] }
});

Der räumende Push gehört ausnahmslos vor jeden E-Commerce-Push und ist die häufigste 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ächlich lesen wird – und der Unterschied zwischen beiden ist genau dieses Problem.

Eine Variable statt zwanzig

Wo eine ganze Liste gebraucht wird, ist die Antwort nicht zwanzig Indexpfade. Sie ist eine eigene JavaScript-Variable, die die Liste liest und zurückgibt, was das Tag braucht.

function () {
  var artikel = {{DLV - ecommerce.items}};
  if (!Array.isArray(artikel) || !artikel.length) { return undefined; }

  return artikel.map(function (a) {
    return {
      item_id:       String(a.item_id || a.id || ""),
      item_name:     String(a.item_name || a.name || ""),
      price:         Number(a.price) || 0,
      quantity:      Number(a.quantity) || 1,
      item_category: String(a.item_category || "")
    };
  }).filter(function (a) { return a.item_id !== ""; });
}

Drei Dinge bringt das über die Unempfindlichkeit gegen die Reihenfolge hinaus. Es vereinheitlicht die Feldnamen, sodass ein Shop, der auf einer Seite id und auf einer anderen item_id sendet, weiter unten eine einzige Form erzeugt. Es erzwingt die Typen, womit ein Preis, der als Zeichenkette "64.95" ankommt, aufhört ein Problem zu sein. Und es verwirft Artikel ohne Kennung, die GA4 ohnehin verwerfen würde – nur eben stillschweigend.

Die Variable, die es liest, ist eine gewöhnliche Datenschichtvariable auf ecommerce.items, ohne Index. Dieser Pfad ist stabil, denn er benennt einen Schlüssel und keine Position.

In der Vorschau nachsehen

Zwei Ansichten der Vorschau klären alles bisher Besprochene, und sie lassen sich leicht miteinander verwechseln.

Die Nachrichtenansicht zeigt den Push genau so, wie die Seite ihn gesendet hat. Die Modellansicht zeigt den zusammengeführten Zustand, den eine Variable in diesem Augenblick liest. Ein Wert, der in der zweiten steht und in der ersten fehlt, ist ein Überbleibsel eines früheren Pushes – das Räumproblem -, und ein Wert in der ersten, der in der zweiten fehlt, wurde meist von einem späteren Push überschrieben.

Die dritte Ansicht, der Variablenbereich des gewählten Ereignisses, zeigt, was jede eingerichtete Variable tatsächlich zurückgab. Ein undefined dort ist die Antwort auf fast jede Frage nach einem fehlenden Parameter, und es trennt die beiden möglichen Ursachen: Der Pfad ist falsch, oder der Wert wurde nie geschoben. Der Vergleich der Variablen gegen die Modellansicht trennt das in Sekunden.

Eine letzte Gewohnheit verhindert die mühsamste Fehlerklasse. Ein Pfad aus dem Quelltext einer Seite ist kein Pfad aus der Datenschicht – ein Shop-Plugin kann Schlüssel zwischen Vorlage und Push umbenennen, und ein übersetzter Shop übersetzt sie gelegentlich mit. Der Pfad gehört aus der Modellansicht eines echten Ereignisses kopiert, nicht aus der Dokumentation abgetippt.