Tutorial: Google-Tag-Manager-Änderungen mit Claude Code vorbereiten und prüfen

Änderungen im Google Tag Manager (GTM) sind im Code meist klein, in der Wirkung aber groß. Eine falsch getippte Trigger-Bedingung, ein doppelt angelegtes Tag oder ein Data-Layer-Schlüssel, der nicht zu dem passt, was die Website tatsächlich sendet, kann das Conversion-Tracking wochenlang unbemerkt lahmlegen. Claude Code, das agentische Coding-Werkzeug von Anthropic, verbindet sich nicht direkt mit GTM; eine native Google-Integration existiert nicht. Für die Arbeit rund um eine GTM-Änderung eignet es sich trotzdem gut: den exportierten Container lesen, Custom-HTML-Tags entwerfen oder prüfen, eine Data-Layer-Implementierung mit dem abgleichen, was ein Tag tatsächlich erwartet, und dokumentieren, was sich geändert hat und warum.

Der folgende Überblick zeigt, was Claude Code tatsächlich leistet, was die Desktop-Anwendung unter Windows 11 gegenüber dem Kommandozeilen-Werkzeug zusätzlich bietet, und einen konkreten Ablauf für den Einsatz rund um eine GTM-Implementierung.

Was Claude Code ist

Claude Code ist ein agentisches Coding-Werkzeug: Es liest ein lokales Codebase- oder Projektverzeichnis, bearbeitet Dateien, führt Shell-Befehle aus und ruft externe Werkzeuge über das Model Context Protocol (MCP) auf. Es existiert in mehreren Formen – als Terminal-CLI (macOS, Linux sowie Windows über PowerShell oder Git Bash), als Desktop-Anwendung für macOS und Windows, als Erweiterung für VS Code und JetBrains-IDEs sowie als browserbasierte Version unter claude.ai/code. Keine dieser Formen enthält einen nativen Google-Tag-Manager-Anschluss; jede GTM-bezogene Aufgabe läuft über allgemeine Fähigkeiten wie Dateizugriff, Skripting und Browser-Automatisierung, nicht über ein dediziertes Plugin.

Claude Code für Desktop unter Windows 11

Unter Windows 11 legt die Desktop-Anwendung eine grafische Ebene über denselben zugrunde liegenden Agenten: einen Datei-Editor, ein integriertes Terminal, eine Diff-Ansicht für jede vorgeschlagene Änderung und einen Browser-Vorschaubereich zum Testen von Seiten, ohne die Anwendung zu verlassen. Für das Bash-Werkzeug wird Git für Windows benötigt; ohne dieses greift die Anwendung auf PowerShell zurück. Für lokale Arbeit ist keine WSL-Installation nötig, eine bereits vorhandene WSL2-Distribution lässt sich aber als Umgebung einbinden.

Zwei Aspekte sind für Tracking-Arbeit besonders relevant: die Berechtigungsmodi und der Browser-Bereich. Die Berechtigungsmodi reichen von der manuellen Freigabe jeder einzelnen Dateiänderung und jedes Befehls bis zu einem Plan-Modus, der die vorgesehenen Änderungen zuerst darlegt, bevor überhaupt etwas angefasst wird – nützlich, wenn ein Skript gleich einen Container-Export verändern oder die GTM-API aufrufen soll. Der Browser-Bereich erlaubt es, eine Staging-Seite zu öffnen, Netzwerk-Anfragen und den Data Layer zu inspizieren und zu prüfen, ob ein Tag tatsächlich auslöst – alles im selben Fenster, in dem auch das Tag geschrieben wird.

Wo Claude Code in eine GTM-Änderung passt

Eine GTM-Implementierung besteht meist aus drei nur lose verbundenen Teilen: der Container-Konfiguration, dem Code, den die Website bereitstellt (Data Layer, DOM-Elemente oder ein REST-Endpunkt), und dem Ziel, an das ein Tag Daten sendet. Claude Code ist bei den ersten beiden Teilen und an der Nahtstelle dazwischen nützlich:

• Einen exportierten Container (Container.json aus der GTM-Exportfunktion oder die Antwort der GTM-API) lesen und Tags, Trigger und Variablen in Klartext zusammenfassen, was es leichter macht, Fast-Duplikate oder uneinheitliche Benennungen zu erkennen.
• Das JavaScript innerhalb eines Custom-HTML-Tags oder eines Custom Templates entwerfen oder prüfen, einschließlich Randfällen wie einem Data-Layer-Schlüssel, der noch nicht ausgelöst wurde.
• Abgleichen, was eine Trigger-Bedingung erwartet, mit dem, was der Data Layer der Website tatsächlich sendet – über den Browser-Bereich oder einen per MCP angebundenen Browser auf einer Live- oder Staging-Seite.
• Kleine Skripte gegen die GTM-API (mit einem Service-Konto) schreiben, um einen Container zu exportieren, zwei Versionen zu vergleichen oder Tags ohne passenden Trigger aufzuspüren – nichts davon ist eingebaut, das Skript selbst wird also wie jeder andere Code geschrieben und geprüft.
• Dokumentation erstellen: eine kurze Markdown-Seite, die auflistet, was ein Tag tut, von welchen Data-Layer-Schlüsseln es abhängt und warum ein Trigger so und nicht anders eingegrenzt ist – damit die nächste Person, die den Container anfasst, ihn nicht erst rekonstruieren muss.

Ein konkretes Beispiel: ein Custom-HTML-Tag prüfen

Eine häufige Aufgabe ist die Prüfung eines Custom-HTML-Tags, bevor es live geht – etwa ein Tag, das eine Data-Layer-Variable liest und nur dann an ein Ziel weiterleitet, wenn der Wert plausibel aussieht. Bei der Prüfung eines solchen Tags kann Claude Code auf genau die Art von Fehler hinweisen, die beim Kopieren eines Snippets aus einem Forenbeitrag leicht übersehen wird:

<script>
(function() {
  var dl = window.dataLayer || [];
  var lastEvent = dl[dl.length - 1] || {};
  var orderId = lastEvent.order_id;

  if (typeof orderId === 'string' && orderId.length > 0) {
    gtag('event', 'purchase_confirmed', { order_id: orderId });
  }
})();
</script>

Das Lesen des Data Layers über dl[dl.length - 1] bricht lautlos, sobald ein anderes Tag zwischen dem Kauf-Event und dem Auslösen dieses Tags ein Event pusht – dann liest das Tag das falsche Objekt. Eine Prüfung würde das auffangen und stattdessen vorschlagen, den Wert über eine in GTM konfigurierte Data-Layer-Variable zu lesen, die nicht von der Array-Position abhängt. Genau solche Annahmen über die Reihenfolge vor der Veröffentlichung abzufangen, lässt sich rund um GTM gut automatisieren, wird aber von der GTM-Oberfläche selbst nicht angezeigt.

Innerhalb der Leitplanken bleiben

Zwei Dinge ändern sich unabhängig davon, wie der Ablauf aufgesetzt ist. Erstens bleibt das Veröffentlichen eine manuelle, menschliche Handlung. Claude Code kann einen Container-Export vorbereiten, das JSON für ein neues Tag erzeugen oder das Skript schreiben, das die GTM-API aufruft. Der eigentliche Klick auf Veröffentlichen, oder der API-Aufruf, der ihn auslöst, bleibt ein bewusster Schritt der für das Konto verantwortlichen Person – idealerweise nach einer Prüfung im GTM-eigenen Vorschau-Modus. Zweitens: Alles, was Claude Code über ein konkretes GTM-Konto zu „wissen“ scheint, stammt ausschließlich aus dem, was in dieser Sitzung explizit übergeben wurde – eine exportierte Datei, ein eingefügtes Snippet oder eine im Browser-Bereich geöffnete Seite –, nicht aus einer dauerhaften Verbindung zum Konto selbst.

So eingesetzt ersetzt Claude Code weder die GTM-Oberfläche noch deren Vorschau- und Debug-Modus; es nimmt eine Schicht manuellen Nachlesens und Copy-paste-Arbeit rundherum ab – auf einem Container, den weiterhin ein Mensch prüft und veröffentlicht.