Google Tag Manager Guidelines

Diese Richtlinien sind eine Sammlung von Dingen, die jeder Google Tag Manager (GTM) Benutzer wissen und verstehen sollte, bevor sie oder er tatsächlich mit dem Tracking beginnt.

Während viele GTM als einen einfachen WYSIWYG-Tracking-Editor verstehen, den jeder nutzen kann, ist GTM ein mächtiges Werkzeug, das seinen Benutzern uneingeschränkten Zugriff auf die gesamte Website und deren Daten und Funktionalitäten gewährt. Mit großer Macht kommt bekanntlich große Verantwortung und diese Richtlinien sollen helfen, den Dschungel der Tracking-Implementierung zu durchqueren.

Inhaltsverzeichnis

• GTM Richtlinien
  • JavaScript
    • Custom JavaScript isolieren
    • Code mit Funktionsvariablen wiederverwenden
    • Halte dich an die Browser-Support-Richtlinien deiner Website
    • Verwende kein Custom JS, wo eingebaute Lösungen ausreichen
    • Dokumentiere alle Funktionen
    • Verwende JS Fehlerberichterstattung
    • Verwende kein console.log in der Produktion
    • Blockiere Anfragen während des Testens
  • Sicherheit
    • Verwende Subresource Integrity
    • Fordere eine Content Security Policy (CSP) an
    • Frage einen (anderen) Entwickler
  • dataLayer
    • Verwende keine toolspezifische dataLayer-Benennung und -Struktur
    • Übermittle keine personenbezogenen Daten (PII) an dataLayer
    • Schiebe nichts aus Google Tag Manager selbst in den dataLayer
  • Zugriffsmanagement
  • Workflow
    • Workspaces
    • Verwende Konstanten für alle Konfigurationen
    • Aktiviere nur die Auto-Variablen, die du benötigst
    • Versionsnamen und Notizen
    • Ordner
  • Benennung
    • Tags
    • Trigger
    • Variablen
      • Beispiele für Variablen

JavaScript

JavaScript im Google Tag Manager kann auf unerwartete Weise mit dem JavaScript deiner Website interferieren. Um sicherzustellen, dass GTM-Implementierungen so wenig Einfluss wie möglich auf den reibungslosen Betrieb deiner Website haben, befolge diese grundlegenden Richtlinien:

Custom JavaScript isolieren

JS im GTM sollte nicht in den globalen Variablenraum auslaufen. Achte darauf, den Umfang deiner Implementierungen zu begrenzen, indem du deinen Code in eine anonyme Funktion einwickelst.

// gut
;(function() {
    var foo = "bar"
})()

// schlecht
var foo = "bar"

Wenn du Variableninformationen für die Dauer des Pageviews beibehalten musst oder du dieselbe Variable von mehreren Tag-Ausführungen aus zugreifen musst, verwende eine dataLayer-Variable.

// 1. Tag
;(function() {
    dataLayer.push({
        foo: "bar",
    })
})()

// 2. Tag console.log({{dl.foo}})

Code mit Funktionsvariablen wiederverwenden

Anstatt einen einfachen String oder Integer zurückzugeben, kannst du eine Funktion als Ergebnis einer GTM-Variablen des Typs Custom JavaScript zurückgeben.

// Custom JavaScript Variable: js.double
function () {
    var doubleSize = function(number) {
        return number * 2
    }
    return doubleSize
}

Deine anonyme äußere Funktion gibt eine andere Funktion zurück, in diesem Beispiel doubleSize. Du kannst dann {{js.double}} als Funktion in anderen JavaScript-basierten GTM-Tags und -Variablen verwenden:

{{js.double}}(2)
// Ausgabe: 4

Halte dich an die Browser-Support-Richtlinien deiner Website

Wisse, welche Browser deine Website / dein Unternehmen offiziell unterstützt. Leider gibt es immer noch viele JavaScript-Features, die von semi-populären Browsern nicht unterstützt werden. Wenn du diese ohne Fallbacks oder programmatische Überprüfung der Browser-Unterstützung implementierst, kann dein Tracking oder sogar die Website-Funktionalität selbst beeinträchtigt werden.

Verwende kein Custom JS, wo eingebaute Lösungen ausreichen

Custom JavaScript ist anfälliger für Fehler als die Lösungen, die Google Tag Manager von Haus aus unterstützt. Verwende die integrierten Tag-Vorlagen anstelle von JavaScript, wo du kannst.

• Wenn du gebeten wirst, Tracking-Code zu implementieren, überprüfe, ob es eine GTM-native Tag-Vorlage gibt.
• Verwende Lookup- oder RegEx-Tabellen anstelle von if…else-Konstruktionen.

Dokumentiere alle Funktionen

Wenn du eigene Funktionen schreibst, dokumentiere sie mit JSDoc3-Syntax.

/**
 * Erhöht die übergebene Zahl um eins
 * @param  {number} number Die zu erhöhende Zahl
 * @return {number}        Die um 1 erhöhte Zahl
 */
function increaseByOne(number) {
    return number + 1
}

Verwende JS Fehlerberichterstattung

Es ist schwierig, jedes Stück Code für jeden Benutzer auf jedem Gerät fehlerfrei zu machen. Du kannst deine GTM-Implementierung nicht mit jeder möglichen Konfiguration testen. Um Fehler zu finden, die nur unter Umständen auftreten, die du nicht getestet hast, verwende ein JavaScript-Fehlerberichterstattungstool wie Sentry oder New Relic.

Es erkennt, wann immer ein JavaScript-Fehler auftritt, und speichert ihn in einer Datenbank, in der du die Ursache des Problems bewerten kannst.

Verwende dein Tracking-Tool nicht zur Erkennung von JavaScript-Fehlern, da sie nichts mit deinem Geschäft zu tun haben.

Verwende kein console.log in der Produktion

Verwende console.log nicht in Produktionssystemen. Es verstopft unnötig sowohl deinen Code als auch die Browserkonsole der Benutzer. Fühle dich frei, es zu Debugging-Zwecken während der Entwicklung im Vorschau-Modus zu verwenden.

Blockiere Anfragen während des Testens

Wenn du den Traffic während des Testens nicht auf eine “Staging”- oder “Entwicklungs”-Property umleitest, solltest du auf die Tracking-Anfragen achten, die du oder andere GTM-Benutzer möglicherweise versehentlich während des Testens senden. Dies ist besonders relevant für 3rd-Party-Conversion-Pixel, bei denen dein Partner möglicherweise nicht leicht zwischen “Debug-Traffic” und echtem Traffic unterscheiden kann. Das Blockieren von Anfragen ist einfach in den Google Chrome Developer Tools.

Sicherheit

Verwende Subresource Integrity

Wenn du Drittanbieter-Skripte implementierst, verwende Subresource-Integritäts-Hashes, um sicherzustellen, dass sich die integrierte Ressource nicht ohne dein Wissen ändert. Weitere Informationen findest du unter https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity.

Fordere eine Content Security Policy (CSP) an

Eine Content Security Policy ermöglicht es dir, festzulegen, von welchen Hosts der Browser Skripte, Schriftarten, Stylesheets usw. laden darf. Weitere Details findest du unter https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP. Dies hat erhebliche technische Auswirkungen auf deine gesamte Website und die Frontend-Entwicklung, daher müssen alle anderen Entwickler an Bord sein. Aber es kann verhindern, dass Drittanbieter-Skripte aus dem Ruder laufen und plötzlich JavaScript ausführen, das du nicht genehmigt hast.

Frage einen (anderen) Entwickler

Wenn du dir nicht ganz sicher bist, was du tust, konsultiere einen oder mehrere professionelle JavaScript-Entwickler, die für das Codieren des JavaScript auf deiner Website verantwortlich sind.

dataLayer

Verwende keine toolspezifische dataLayer-Benennung und -Struktur

Stelle sicher, dass die Namen der dataLayer-Variablen immer so beschreibend wie möglich sind. Verwende keine tool-spezifischen Schlüssel, auch wenn es praktisch erscheinen mag. Die Trennung von Tool-Logik und der Website ist eines der wichtigsten Ziele bei der Verwendung von Google Tag Manager.

// gut
dataLayer.push({
    loginStatus: true,
})

// schlecht
dataLayer.push({
    dimension17: 1,
})

Verwende bei Bedarf benutzerdefinierte JavaScript-Variablen, um Daten für einzelne Tools vorzuverarbeiten.

Übermittle keine personenbezogenen Daten (PII) an dataLayer

Informationen, die von Dritten verwendet werden können, um eine Person oder ein Gerät zu identifizieren, sollten nicht in dataLayer verwendet werden. Dazu gehören E-Mail- und IP-Adressen.

Deine proprietäre Benutzer-ID kann in Ordnung sein, wenn nur du sie auf eine Person zurückführen kannst. Trotzdem solltest du dich zuerst mit einem Datenschutzexperten beraten.

Schiebe nichts aus Google Tag Manager selbst in den dataLayer

In den meisten Fällen ist es keine gute Idee, dataLayer.push in deinem Custom HTML/JS-Code innerhalb von Google Tag Manager zu verwenden, da es verwirrend sein kann, wenn Ereignisse sowohl von außerhalb als auch von innerhalb von GTM kommen.

Verwende, wo immer möglich, die integrierten Tag-Sequenzierung-Funktionen, wenn du versuchst, Abhängigkeiten zwischen Tags zu implementieren oder Rennbedingungen zu vermeiden (eine Situation, in der du Dinge in einer bestimmten Reihenfolge verarbeiten musst, diese Reihenfolge aber nicht garantieren kannst).

Zugriffsmanagement

Gib so wenigen Personen wie möglich Veröffentlichungszugriff auf Container. Jeder, der ihn nicht unbedingt benötigt, sollte Lesezugriff haben. Führe vierteljährlich Überprüfungen durch, ob Benutzer auf ein restriktiveres Zugriffslevel herabgestuft oder vollständig entfernt werden können.

Workflow

Workspaces

Halte den “Standard-Arbeitsbereich” immer für Notfälle leer. Sollte plötzlich ein Bugfix benötigt werden, solltest du nicht a) bereits geleistete Arbeit opfern müssen, nur weil du keinen leeren Arbeitsbereich mehr hast, b) durch Arbeitsbereiche mit vorhandenen Änderungen gehen müssen, weil du sicherstellen musst, was sie tun, bevor du deinen Bugfix veröffentlichst.

Verwende einen Arbeitsbereich pro Implementierung, löse nicht verschiedene Probleme in einem Arbeitsbereich.

Verwende Konstanten für alle Konfigurationen

Sobald mehr als ein Tag denselben Konfigurationswert (z. B. eine Tracking-Account-ID) verwendet, erstelle eine GTM-Variable vom Typ “Konstante” dafür und verweise von den Tags darauf.

Aktiviere nur die Auto-Variablen, die du benötigst

Aktiviere nur die, die du aktiv verwendest. Die Werte inaktiver Auto-Variablen müssen nicht berechnet werden, was Ressourcen spart.

Versionsnamen und Notizen

• Benenne jede Version. Die Änderungen der Version sollten intuitiv klar sein, allein aus dem Namen. Konzentriere dich auf die geschäftlichen Auswirkungen der Änderung und nicht auf die technischen Details. Wenn du ein Ticket- oder Aufgabensystem wie JIRA verwendest, füge die Ticket-ID in den Versionsnamen ein.
• Schreibe Versionsnotizen für jede Version. Die Notizen sollten beantworten:
  • Wer hat die Änderung angefordert?
  • Wie war das Tracking-Verhalten vor dem Release, wie ist es jetzt?
  • Gab es Website-Änderungen, von denen diese GTM-Implementierung abhängt? Wenn ja, welche?

Ordner

Verwende Ordner, um deine Elemente nach dem Ziel, das sie erreichen sollen, zu gruppieren.

Benennung

Tags

Typ Beschreibung

Trigger

Typ Beschreibung

Variablen

type.[tool.]name

type bezieht sich auf die verschiedenen Arten von Google Tag Manager-Variablen, die verfügbar sind. Da der Typ einer Variablen beim Betrachten eines Verweises wie {{myVariable}} nicht sofort sichtbar ist, ist es schwierig zu identifizieren, woher die Daten kommen.

tool ist ein optionaler Teil für Variablen, die nur für ein Werkzeug relevant sind, z. B. eine bestimmte Drittanbieter-Tool-ID als Konstante oder ein Datenumformatierungsskript, das Daten speziell für einen Tag umformatiert. Ein tool in diesem Fall kann entweder ein Produkt wie adform, hotjar, kissmetrics oder ein universelles Konzept wie Google Analytics Enhanced eCommerce sein, das die gängige Abkürzung eec hat.

name ist ein beschreibender Name für diese Variable. Halte ihn kurz, aber in Kombination mit type und tool sollte sofort verständlich sein, worauf er sich bezieht.

Beispiele für Variablen

• Eine Adform-Publisher-ID: const.adform.id
• Ein JavaScript-Umschreibungsskript, das Produktdaten in einem bestimmten Format bereitstellt, relevant nur für Yahoo: js.yahoo.productData