Zwei GTM-Container-Exporte vergleichen: Normalisieren vor dem Diff und was ein Zeilenvergleich nicht zeigt

Ein Diff ist eine Aufstellung der Unterschiede zwischen zwei Dateien. Normalisieren bedeutet hier, beide Exporte gleich zu formatieren, damit Layoutunterschiede geänderte Einstellungen nicht verdecken. Ein GTM-Exportvergleich beantwortet unterschiedliche Fragen: Unterscheiden sich die Dateien, die eingelesenen Konfigurationen oder das tatsächliche Messverhalten? Dafür sind unterschiedliche Nachweise nötig. Formatierung kann Änderungen verdecken; zu großzügiges Löschen von Feldern kann Änderungen vollständig verbergen.

Update vom 19.10.2026: Die Grenzen des Vergleichs berücksichtigen jetzt Änderungen an Googles ausgeliefertem Laufzeitcode und die optionale Containeroptimierung. Einordnung der Oktoberänderungen bei Google Tag und GTM.

Den Vergleichsumfang festlegen

Zu beiden Exporten gehören dokumentierte Angaben zu Konto, Container, Version oder Workspace, Exportzeit und Auswahlumfang. Ein Teilexport ist kein vollständiger Export. Google beschreibt, dass beim Fortsetzen eines Teilexports ohne benötigte Abhängigkeiten Verweise auf fehlende Tags und Trigger entfernt werden können, während Variablenverweise erhalten bleiben.

GTM-Objektkennungen identifizieren Elemente; eine allgemeine Neuvergabe aller IDs bei jedem Export ist nicht dokumentiert. Ein Fingerprint ist ein aus dem Element berechneter Kennwert. Laut API-Dokumentation wird dieser Wert bei Änderungen am Element neu berechnet. Daraus ergibt sich weder ein dokumentierter Zeitstempel noch ein Nachweis bestimmter Bearbeiter, Änderungszeiten oder Laufzeitfolgen. Auch bei einer ergänzenden Ansicht ohne ausgewählte Metadaten bleiben diese Felder als Nachweis relevant.

Zunächst nur formatieren und keine Werte löschen

jq -S sortiert Objektschlüssel und formatiert JSON. Listenreihenfolge und Zeichenfolgeninhalte bleiben erhalten; Leerzeichen innerhalb eines Werts sind weiterhin Daten. Das folgende Bash-Skript benötigt jq und diff, nimmt zwei Dateipfade entgegen und weist leere Dateien, mehrere Dokumente sowie Eingaben ohne containerVersion-Objekt zurück. Diese Formprüfung ersetzt keine vollständige GTM-Schemavalidierung.

#!/usr/bin/env bash
set -euo pipefail
if (( $# != 2 )); then
  printf 'Usage: bash compare-gtm.sh old.json new.json\n' >&2
  exit 2
fi
work_dir=$(mktemp -d)
trap 'rm -rf -- "$work_dir"' EXIT
normalise() {
  jq -e -S -s '
    if length != 1 then error("Expected one JSON document")
    elif (.[0] | type) != "object" then error("Expected an object")
    elif (.[0].containerVersion | type) != "object"
      then error("Expected a GTM container export")
    else .[0] end
  ' "$1"
}
normalise "$1" > "$work_dir/old.json"
normalise "$2" > "$work_dir/new.json"
if diff -u -- "$work_dir/old.json" "$work_dir/new.json"; then
  printf 'No differences in this parsed, formatted view.\n'
else
  diff_status=$?
  exit "$diff_status"
fi

Als compare-gtm.sh gespeichert lautet der Aufruf bash compare-gtm.sh old.json new.json. Status 0 bedeutet keinen Unterschied in dieser Ansicht; 1 bedeutet von diff gefundene Unterschiede. Ein Lese- oder Befehlsfehler ist ein Fehler, keine Gleichheit. Nacheinander geschriebene temporäre Dateien stellen die erfolgreiche Normalisierung vor dem Vergleich sicher. Eine Prozesssubstitution wie diff <(norm old.json) <(norm new.json) reicht allein nicht aus, um jeden Erzeugerfehler im Rückgabewert von diff sichtbar zu machen.

Diese Ansicht enthält weiterhin Zeitangaben, Fingerprints und Versionskontext. Eine zusätzliche reduzierte Ansicht braucht ausdrücklich erlaubte Feldpfade, einen dokumentierten Zweck und den unveränderten Export daneben. Rekursives Löschen nach Namen wie accountId oder fingerprint kann fachlich relevante verschachtelte Daten entfernen. Gleichheit nach dem Löschen bedeutet nur Gleichheit der beibehaltenen Felder.

Auch das Verhalten des JSON-Parsers zählt: Doppelte Objektschlüssel und sehr große Zahlen benötigen festgelegte Regeln. Die Zahlenbehandlung von jq hängt von Version und Build ab. Das Beispiel ist weder ein bytegenaues Archivformat noch ein allgemeiner Nachweis gleicher Bedeutung.

Geänderte Werte neben neuen Schlüsseln zeigen

Eine Differenz der Schlüsselmengen zeigt Ergänzungen und Löschungen, aber keinen geänderten Wert unter einem vorhandenen Schlüssel. Diese getrennte Übersicht erfasst alle drei Fälle auf oberster Ebene:

jq -n --slurpfile a old.json --slurpfile b new.json '
  if ($a|length) != 1 or ($b|length) != 1 then
    error("Expected one JSON document per file")
  elif ($a[0]|type) != "object" or ($b[0]|type) != "object" then
    error("Expected objects")
  else
    $a[0] as $old | $b[0] as $new
    | ($old|keys) as $ka | ($new|keys) as $kb
    | {removed: ($ka - $kb), added: ($kb - $ka),
       changed: [$ka[] as $key
         | select($new|has($key))
         | select($old[$key] != $new[$key]) | $key]}
  end'

Eine Änderung tief innerhalb eines Tags erscheint in dieser Übersicht möglicherweise nur als containerVersion. Details liefert der formatierte Diff oder ein Vergleich mit Kenntnis des Schemas. Die Zeichenfolge "1" und die Zahl 1 sind unterschiedliche Werte; ähnliche Darstellung und wenige geänderte Zeichen machen den Unterschied nicht unbedeutend.

Objektzuordnung und Listenreihenfolge bewusst behandeln

Innerhalb eines Containers helfen Element-IDs beim Vergleich verschiedener Versionen; Löschen und Neuanlegen oder Import können jedoch ein anderes Element erzeugen. Zwischen Containern dürfen Kennungen und Kontext nicht einfach verschwinden. Ein Namensvergleich braucht eindeutige Zuordnungen sowie Regeln für Umbenennungen, doppelte Namen und nicht auflösbare Verweise.

Die Zuordnung muss auslösende und blockierende Trigger, Ordner, Tag-Sequenzen, Templates und weitere relevante Beziehungen erhalten. Setup- und Teardown-Verweise verwenden laut API Tagnamen. Variablenverweise stehen häufig als {{name}} im Text; daraus folgt weder die Vollständigkeit einer globalen Textersetzung noch einer reinen Triggerzuordnung. Eingebaute Triggerkennungen benötigen eine ausdrücklich unterstützte Behandlung statt einer blinden Suche in der exportierten Triggerliste.

jq -S sortiert keine Listen. Sortierte Elementlisten können eine zusätzliche Prüfansicht verbessern, sobald die Identität geklärt ist. Beliebige verschachtelte Listen zu sortieren kann dagegen die Bedeutung ändern, etwa bei geordneten Tabellenzeilen. Die erste Ansicht lässt deshalb alle Listen unverändert.

Textunterschiede belegen keine Laufzeitwirkung

Zeilen-, Wort- und Zeichenansichten liefern unterschiedliche Details. Ein Zeilenvergleich kann Textgleichheit feststellen und typändernde Anführungszeichen zeigen. Manche Werkzeuge erkennen auch Verschiebungen. Der Diff zeigt die Änderung, erklärt aber meist weder den Grund noch die Folgen für die Messung.

Identisches JSON belegt keine identische Messung. Googles Release Notes vom 8. Oktober 2026 beschreiben Initialisierung beim Containerladen und sichtbare gtag.config-Ereignisse, die breite Custom-Event-Trigger treffen können. Die am 12. Oktober angekündigte optionale Optimierung betrifft außerdem zentrale Einstellungen und Ziel-Tags. Vorschau prüft Ausführung, Netzwerkanalyse prüft Anfragen, Zielberichte prüfen Verarbeitung; eine Browseranfrage allein belegt weder korrekte Attribution noch endgültige Berichte. Rechte werden nicht versioniert und benötigen eine getrennte Aufzeichnung.