Ein Tag liefert seit ein paar Tagen falsche Werte, und im Team fällt die Frage: Was hat sich geändert? Ich öffne dann die Versionen im Google Tag Manager und finde eine Liste aus „Version 46“, „Version 47“, „Version 48“, ohne eine einzige Notiz. Ab diesem Moment beginnt die Archäologie.

Nach diesem Artikel wissen Sie, wie Sie GTM-Versionen so dokumentieren, dass ein Rollback im Fehlerfall eine Sache von Minuten ist.

Warum undokumentierte GTM-Versionen ein Risiko sind

Die Versionierung ist im GTM eingebaut, sie hilft aber nur, wenn sich die Versionen unterscheiden lassen. Laut der Google-Hilfe zu Veröffentlichung und Versionen zeichnet der GTM bei jedem Veröffentlichen automatisch eine Version auf, also einen Schnappschuss der Container-Konfiguration zu diesem Zeitpunkt. Wer veröffentlicht hat und wann, steht dabei. Was geändert wurde und warum, steht dort nur, wenn es jemand einträgt.

Fehlt diese Information, traut sich niemand, eine Version zurückzurollen. Unklar ist ja, welche andere Änderung dabei mit verschwindet. Also wird der Fehler im laufenden Container gesucht, oft über Tage, während die Daten weiter falsch einlaufen.

Woran Sie es erkennen

Öffnen Sie im GTM den Bereich Versionen und prüfen Sie:

  1. Tragen die Versionen nur Nummern oder Standardnamen, oder beschreibt der Name die Änderung?
  2. Ist das Feld für die Beschreibung ausgefüllt?
  3. Können Sie für die letzten fünf Versionen sagen, was jede geändert hat, ohne sie einzeln zu öffnen?
  4. Verweist die Notiz auf ein Ticket oder eine Anfrage, aus der der Grund hervorgeht?

Wenn Sie bei Frage 3 raten müssen, fehlt Ihnen im Ernstfall die Grundlage für einen Rollback.

Lösung: Jede Version mit Namen und Notiz veröffentlichen

Geben Sie beim Veröffentlichen jeder Version einen Namen, der die Änderung beschreibt, und zwei Sätze Notiz zum Grund. Google selbst empfiehlt Namen, an denen sich die Änderung ablesen lässt. Bewährt hat sich bei mir ein festes Muster: was geändert wurde, für welches Tool, auf wessen Anfrage. Ein Beispiel ist „LinkedIn Insight Tag an Consent gekoppelt“ mit der Notiz, welche Trigger betroffen sind und wer die Änderung angefordert hat.

Der Aufwand liegt bei wenigen Sekunden pro Veröffentlichung. Im Fehlerfall sehen Sie dann sofort, welche Version den Fehler eingeführt hat. Über das Aktionsmenü in der Versionsübersicht machen Sie eine frühere Version wieder zum Arbeitsstand, prüfen sie in der Vorschau und veröffentlichen sie erneut.

Arbeiten mehrere Personen oder eine Agentur im Container, ist die Notiz außerdem die einfachste Form der Übergabe. Dass Änderungen überhaupt erst mit dem Veröffentlichen live gehen, beschreibe ich im Artikel GTM-Container veröffentlichen.

Nächster Schritt

Diese Punkte können Sie selbst prüfen:

  • Versionsnamen: Beschreiben die Namen Ihrer letzten Versionen, was geändert wurde?
  • Notizen: Steht bei jeder Version, warum die Änderung nötig war?
  • Rollback: Wissen Sie, wie Sie eine frühere Version wiederherstellen, bevor Sie es brauchen?
  • Team-Regel: Nutzen alle, die im Container veröffentlichen, dasselbe Muster?

Wie ein Container insgesamt sauber aufgebaut wird, beschreibe ich im Ratgeber zum Google Tag Manager. Wenn Sie Ihren Container prüfen lassen wollen, können Sie ein Erstgespräch buchen.

Dieser Beitrag ist keine Rechtsberatung. Benjamin Juling ist kein Rechtsexperte für Datenschutz. Wir empfehlen, die Umsetzung vor dem Einsatz mit einem Datenschutz-Experten oder einem Datenschutz-Anwalt zu prüfen.