Git-Versionierung für den Google Tag Manager: GTM CLI in CI/CD Pipelines nutzen

Wenn du in einem Unternehmensumfeld mit strengen Compliance-Anforderungen arbeitest, bist du vielleicht schon über diese Herausforderung gestolpert — ich jedenfalls schon mehrfach in der Zusammenarbeit mit großen Unternehmen:

Die Organisation muss jeden Code dokumentieren, der auf der Website läuft — einschließlich allem, was im Google Tag Manager steckt.
Auditoren wollen genau wissen, welche Tags zu einem bestimmten Zeitpunkt live waren, und “schau in die GTM-Versionshistorie” reicht da nicht immer aus. Zum Beispiel wenn Git als System of Record festgelegt wurde oder — wie es zumindest in deutschen Unternehmen ziemlich verbreitet ist — ein generelles Misstrauen gegenüber allem, das mit Google zu tun hat, herrscht.

Ein möglicher Lösungsansatz von vielen:
Automatisierte Exporte deiner GTM-Container-Konfiguration, die in dein Git-Repository committet werden — zusammen mit deinem Anwendungscode.
Natürlich können diejenigen, die im GTM arbeiten, unabhängig vom Dev-Team der Website Änderungen vornehmen und neue Versionen veröffentlichen, aber das ist ein Thema für einen anderen Blogpost.

Die Compliance-Herausforderung

Viele Organisationen — insbesondere in der Finanzbranche, im Gesundheitswesen und im öffentlichen Sektor — haben regulatorische Anforderungen, die vorschreiben:

1. Lückenlose Audit Trails für sämtlichen Code, der auf dem Produktionssystem deployed wird
2. Die Möglichkeit, jederzeit exakt nachzuvollziehen, was zu einem bestimmten Zeitpunkt live war
3. Änderungsdokumentation, die an Freigabe-Workflows geknüpft ist
4. All das vollständig automatisiert

Die eingebaute Versionshistorie des Google Tag Managers ist super, existiert aber ohne Kontext der Website an sich.
Sie ist kein Teil deiner Git-Historie, kann nicht wirklich mit Pull Requests oder Tickets verknüpft werden (von der Erwähnung von Ticket-IDs in Versionsnamen abgesehen), und taucht in keinem Compliance-Bericht auf. Für Organisationen, die eine einzige Single Source of Truth für alles brauchen, was in Produktion läuft, ist das eine Lücke.

Die Lösung: GTM CLI + GitHub Actions

Mit GTM CLI kannst du die aktuelle Live-Konfiguration deines GTM-Containers programmatisch als JSON exportieren und in deine bestehenden CI/CD-Workflows integrieren. Jedes Mal, wenn dein GTM-Container veröffentlicht wird, kann eine GitHub Action automatisch:

1. Die aktuelle Live-Container-Konfiguration abrufen
2. Sie in dein Repository committen
3. Einen nachvollziehbaren Eintrag in deiner Git-Historie erstellen

Einrichtung

Voraussetzungen

• Ein Google Cloud Service Account mit Lesezugriff auf deinen GTM-Container
• Der Service-Account-Schlüssel als GitHub Secret hinterlegt
• GTM CLI in deiner CI-Umgebung installiert

Schritt 1: Service Account erstellen

Erstelle in deiner Google Cloud Console einen Service Account und lade die JSON-Schlüsseldatei herunter. Gib diesem Service Account dann im Google Tag Manager unter Verwaltung → Nutzerverwaltung “Lesen”-Zugriff auf deinen Container. Du kannst das auf Konto- oder Container-Ebene machen — je nachdem, was für deinen Anwendungsfall passender ist.

Schritt 2: Zugangsdaten in GitHub hinterlegen

Füge deinen Service-Account-JSON-Schlüssel als Repository Secret mit dem Namen GTM_SERVICE_ACCOUNT_KEY hinzu.

Außerdem solltest du deine GTM Account ID und Container ID als Secrets oder Variablen hinterlegen:

• GTM_ACCOUNT_ID
• GTM_CONTAINER_ID

Schritt 3: GitHub Action erstellen

Erstelle die Datei .github/workflows/gtm-export.yml:

name: Export GTM Container

on:
  # Allow manual triggers from GitHub UI
  workflow_dispatch:
  # Run when pushing to or merging into main
  push:
    branches:
      - main

jobs:
  export-gtm:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      # Install GTM CLI - replace 1.5.6 with the latest version or the one you want to use
      - name: Install GTM CLI
        run: npm install -g @owntag/gtm-cli@1.5.6

      - name: Authenticate with GTM
        run: |
          echo '${{ secrets.GTM_SERVICE_ACCOUNT_KEY }}' > /tmp/sa-key.json
          gtm auth login --service-account /tmp/sa-key.json

      - name: Export live container version
        run: |
          gtm versions live \
            --account-id ${{ vars.GTM_ACCOUNT_ID }} \
            --container-id ${{ vars.GTM_CONTAINER_ID }} \
            --output json > gtm/container-live.json

      - name: Extract version metadata
        id: version
        run: |
          VERSION_ID=$(jq -r '.containerVersionId' gtm/container-live.json)
          VERSION_NAME=$(jq -r '.name' gtm/container-live.json)
          echo "version_id=$VERSION_ID" >> $GITHUB_OUTPUT
          echo "version_name=$VERSION_NAME" >> $GITHUB_OUTPUT

      - name: Commit changes
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"
          git add gtm/container-live.json

          # Only commit if there are changes
          if git diff --staged --quiet; then
            echo "No changes to GTM container"
          else
            git commit -m "Update GTM container export (v${{ steps.version.outputs.version_id }}): ${{ steps.version.outputs.version_name }}"
            git push
          fi

      - name: Cleanup credentials
        if: always()
        run: rm -f /tmp/sa-key.json

Was das Ganze macht

Immer wenn du auf den main-Branch pushst (oder in ihn mergst) — oder den Workflow manuell über die GitHub Actions UI auslöst — passiert Folgendes:

1. Authentifizierung beim Google Tag Manager über deinen Service Account
2. Export der aktuellen Live-Container-Konfiguration als JSON
3. Commit aller Änderungen in dein Repository mit einer aussagekräftigen Commit-Nachricht, die die GTM-Versionsnummer und den Namen enthält

Das Ergebnis ist eine Git-Historie, die in etwa so aussieht:

a]4f2e1d Update GTM container export (v27): Using Meta Pixel ID as constant
b]8c3a9f Update GTM container export (v26): Added scroll tracking triggers
c]1e7d4b Update GTM container export (v25): GDPR consent mode updates

Jeder Commit entspricht einer veröffentlichten GTM-Version und bildet so einen lückenlosen Audit Trail.

Änderungen mit Git Diff nachvollziehen

Einer der größten Vorteile dieses Ansatzes ist die Möglichkeit, Tag-Änderungen mit Standard-Git-Tools zu überprüfen. Wenn jemand eine neue GTM-Version veröffentlicht, siehst du genau, was sich geändert hat:

git diff HEAD~1 gtm/container-live.json

Nicht so schön wie die GTM-Web-Oberfläche, aber darum geht es hier ja auch nicht. Oder du reviewst die Änderungen in einem Pull Request vor dem Merge. Damit bringst du dieselben Code-Review-Praktiken, die du für deinen Anwendungscode nutzt, auch in dein Tag Management.

Ausblick

Für Organisationen, die lückenlose Audit Trails brauchen, können automatisierte GTM-Exporte eine echte Compliance-Lücke schließen.
Wie nützlich oder notwendig diese Exporte im Alltag auch sein mögen — es ist schön, compliant zu sein, ohne das Rad neu zu erfinden und einen Haufen Dev-Aufwand reinzustecken.

GTM CLI macht das Ganze unkompliziert — was sonst eine aufwändige Eigenentwicklung wäre, wird zu ein paar Zeilen in einer GitHub Action.

Wenn du mit Compliance-Anforderungen rund um Tag Management zu tun hast, probier diesen Ansatz gerne mal aus.
Das funktioniert natürlich sowohl für deine GTM-Web-Container als auch für den Server Side Google Tag Manager, wo es sogar noch nützlicher ist, weil externe Auditoren den Code, den du serverseitig ausführst, von außen gar nicht einsehen können.