Analytics-Tool Migration: Eventliste, Dimensionen und der ganze Rest

Wer sein Analytics-Tool wechselt, steht vor einer Aufgabe, die überraschend wenig mit dem neuen Tool zu tun hat - und überraschend viel mit dem alten. Denn bevor man sich in die Konfiguration des Nachfolgers stürzt, braucht es eine ehrliche Bestandsaufnahme dessen, was man bisher misst, wie man es misst und ob das alles überhaupt noch Sinn ergibt. Egal ob der Wechsel von Piwik PRO auf GA4 geht, von GA4 auf Matomo, von Universal Analytics auf irgendwas oder von einer Eigenentwicklung auf ein kommerzielles Produkt: Die vorbereitenden Schritte sind im Kern die gleichen. Und wer sie überspringt, steht am Ende mit dem gleichen Mist da wie vorher - nur in einem anderen Tool. Wer noch vor der Entscheidung steht, welches Tool es werden soll, findet in der Wegbeschreibung für den Analytics-Toolwechsel eine Hilfestellung für die Auswahl.

Warum nicht einfach umziehen?

Die Versuchung ist groß, Events und Dimensionen 1:1 ins neue Tool zu schieben. Kategorie bleibt Kategorie, Label bleibt Label, fertig. Das ist der größte Fehler, den man bei einer Migration machen kann. Tracking-Setups wachsen über Jahre organisch. Was als sauberer Plan begann, ist längst ein Flickenteppich aus Sonderwünschen, vergessenen Experimenten und "das hat damals jemand so eingebaut". Eine Migration ist die seltene Gelegenheit, das aufzuräumen. Wer diese Chance nicht nutzt, verdient den Schmerz, der danach kommt.

Denn ein neues Tool bringt ein neues Datenmodell mit. GA4 kennt keine Hit-Typen mehr, alles ist ein Event. Piwik PRO unterscheidet noch zwischen Pageviews, Events und Goals. Matomo hat seine eigene Vorstellung davon, was eine "Aktion" ist. Diese Unterschiede sind nicht kosmetisch - sie bestimmen, wie man Daten strukturiert, abfragt und interpretiert. Ein stumpfes Mapping ignoriert das und produziert Daten, die in keinem der beiden Welten richtig funktionieren.

Schritt 1: Bestandsaufnahme der Dimensionen

In jedem Analytics-Tool gibt es neben den Standarddimensionen eigene, benutzerdefinierte Felder. In Universal Analytics hießen sie "Custom Dimensions" mit Scopes (Hit, Session, User, Product). In Piwik PRO gibt es Custom Dimensions auf Session- und Event-Ebene. GA4 kennt Event-Parameter und User Properties. Matomo hat Custom Dimensions und Custom Variables. Die Bezeichnungen unterscheiden sich, das Konzept ist vergleichbar.

Diese benutzerdefinierten Dimensionen gehören als erstes auf eine Liste. Und zwar mit:

• Name und Datentyp
• Scope bzw. Geltungsbereich (wo möglich)
• Herkunft des Wertes (dataLayer, Cookie, Backend, URL-Parameter...)
• Tatsächliche Nutzung: Wird die Dimension aktiv in Reports oder Segmenten verwendet?

Aufräumen: Der letzte Punkt ist der wichtigste. Erfahrungsgemäß sind ein Drittel bis die Hälfte der benutzerdefinierten Dimensionen entweder veraltet, redundant oder werden schlicht nicht genutzt. Weg damit. Was übrig bleibt, muss in das Datenmodell des Zielsystems übersetzt werden - und das ist selten eine 1:1-Abbildung.

Nicht jeder Scope existiert in jedem Tool. GA4 kennt keinen Session-Scope für benutzerdefinierte Dimensionen. Piwik PRO hat keinen Product-Scope. Was im alten Tool auf Sitzungsebene definiert war, braucht im neuen möglicherweise einen Workaround - oder man erkennt, dass die Information auf Event-Ebene genauso gut funktioniert. Manchmal sogar besser.

Tipp: Blick in die Datenschicht. Wer durch Aufräumen Platz macht, darf sich damit belohnen, ggf. etwas Neues für die freigewordene Stelle zu besorgen. Kein Aufruf, alles aus dem dataLayer blind als Parameter mitzunehmen. Aber ein Blick auf das Angebot und sorgfältige Evaluierung des Nutzens muss erlaubt sein.

Schritt 2: Naming Conventions festlegen

In den meisten Tracking-Setups sieht die Benennung so aus: Ein Mix aus camelCase, ALL_CAPS, Leerzeichen, deutschen und englischen Begriffen, teilweise mit dem alten Scope oder einer laufenden Nummer im Namen. Das war nie ideal und wird es auch im neuen Tool nicht sein.

Neues Schema als Vorlage: Eine Migration ist der richtige Zeitpunkt, eine einheitliche Konvention einzuführen. Eine gute Regel, die sich an dem orientiert, was die meisten Tools selbst verwenden:

• Alles klein schreiben
• Begriffe mit Unterstrich trennen
• Englisch bevorzugen (kein Muss, aber Umlaute und Sonderzeichen unbedingt vermeiden)
• Den Namen selbsterklärend wählen

Aus User Status wird user_status, aus isLoggedIn wird logged_in, aus HitType wird - nichts, weil man das im neuen Tool vermutlich nicht mehr braucht. Dieses Format gilt idealerweise für alles: Dimensionen, Events, Parameter.

Schritt 3: Events inventarisieren

Was in den meisten Setups den größten Umfang ausmacht: Die Events. Und genau hier wird es haarig, denn die Event-Modelle der Tools unterscheiden sich fundamental.

Wer aus einem Tool mit dem klassischen Modell Kategorie / Aktion / Label kommt (Universal Analytics, Piwik PRO, Matomo), kennt das Problem: Die drei Felder werden auf die abenteuerlichste Weise befüllt. Mal ist die Kategorie eher eine Aktion. Mal ist das Label das Einzige, das Events voneinander unterscheidet. Mal heißt die Aktion schlicht "click" und nur die Kategorie verrät, worum es geht.

In einem Tool wie GA4, das nur einen Eventnamen als primäres Identifikationsmerkmal kennt, funktioniert das nicht mehr. Aber selbst beim Wechsel zwischen Tools mit ähnlichem Modell - etwa von Piwik PRO zu Matomo - ist die Versuchung groß, alles 1:1 zu übernehmen. Und genau das sollte man nicht tun.

Eventliste anlegen

Eine vollständige Übersicht aller Events ist unverzichtbar. Die kann man sich auf verschiedene Weise beschaffen:

• Aus dem Analytics-Tool selbst: Einen Report mit allen Event-Kategorien, -Aktionen und -Labels (oder dem jeweiligen Äquivalent) über einen ausreichend langen Zeitraum ziehen. Nachteil: Oft unübersichtlich und unvollständig, wenn seltene Events im gewählten Zeitraum nicht auftraten.
• Aus dem Tag Manager: Wer einen GTM, Piwik PRO Tag Manager oder Tealium nutzt, kann dort alle Event-Tags durchgehen. Das ist oft der schnellere Weg, weil man gleichzeitig sieht, woher die Werte kommen. Tool-Tipp: Der Check für GTM Container bei Analytrix erstellt unter anderem eine Event-Liste mit allen relevanten Attributen.
• Aus der Dokumentation: Falls es einen aktuellen Trackingplan gibt. Falls.

Die Liste braucht mindestens diese Spalten:

Altes Event	Kategorie / Aktion / Label (o. Ä.)	Neuer Eventname	Parameter (neu)	Anmerkungen
z. B. Klick auf Telefonnummer	Contact / click / phone	click_to_call	link_url, link_text	Auto-Event prüfen

Das Ziel: Am Ende eine fertige Übersetzungstabelle, aus der man das Tracking im neuen Tool direkt aufbauen kann.

Neue Eventnamen: Eindeutig statt generisch

Der häufigste Fehler in alten Setups: Generische Eventnamen, die nur durch ihre Attribute unterscheidbar sind. Fünf Events heißen "click" und nur Kategorie oder Label verraten, was gemeint ist. Im neuen Setup sollte jedes Event einen Namen haben, der die Aktion eindeutig beschreibt:

• click + Kategorie phone → click_to_call
• click + Kategorie download → file_download
• submit + Kategorie contact_form → form_submit_contact

Klingt nach mehr Arbeit. Ist es auch. Aber wer hier spart, baut sich die gleichen Probleme neu auf und ärgert sich in sechs Monaten darüber.

Abgleich mit dem Ziel-Tool

Die meisten Analytics-Tools bringen vordefinierte oder automatisch erfasste Events mit. GA4 hat seine empfohlenen Events und automatischen Ereignisse (Scrolls, Downloads, externe Links). Piwik PRO trackt Seitenaufrufe und Outlinks automatisch. Matomo hat ebenfalls Auto-Tracking für Downloads und externe Links.

Bevor man ein Event manuell implementiert, lohnt der Abgleich: Deckt das Ziel-Tool das schon ab? Wenn ja - braucht man es trotzdem manuell, weil die automatische Variante nicht differenziert genug ist? Wenn nein - auf die Liste.

Schritt 4: E-Commerce als Sonderfall

E-Commerce-Tracking hat in jedem Tool eine Sonderstellung. Eigene Schemata, eigene Reports, eigene Fallstricke. Und bei einer Migration eigene Herausforderungen:

Format-Unterschiede: Das E-Commerce-Datenformat unterscheidet sich zwischen den Tools. GA4 erwartet ein anderes dataLayer-Format als Universal Analytics es tat. Piwik PRO hat wiederum sein eigenes Schema. Wer den Tag Manager nutzt, kann die Konvertierung dort erledigen - im GTM findet man in der Community Gallery entsprechende Variablen-Vorlagen. Aber auch hier gilt: Erst planen, welche E-Commerce-Events man tatsächlich braucht, dann implementieren.

Nicht alles übernehmen: Die Transaktion ist Pflicht. Alles davor - Produktimpressionen, Klicks in Listen, Add-to-Cart, Checkout-Steps - nur dann, wenn man mit den Daten tatsächlich arbeitet. Von der Transaktion rückwärts implementieren bleibt eine gute Daumenregel. Bei einer Migration, die ohnehin Aufwand erzeugt, lohnt es sich besonders, hier ehrlich zu sein.

Trigger beachten: Im Tag Manager können bei einem Toolwechsel nicht immer die gleichen Trigger weiterverwendet werden. Speziell bei Parallel-Betrieb (altes und neues Tool gleichzeitig aktiv) gibt es meistens toolspezifische dataLayer-Events, die man als Auslöser nutzen sollte, statt sich auf generische Trigger zu verlassen.

Schritt 5: Phasenweise ausrollen

Die fertige Eventliste in einem Rutsch umsetzen? Lieber nicht. Zu schnell wird ein schwierig zu testendes Event wie der Kaufabschluss nicht ausreichend geprüft. Oder der Kaufabschluss bekommt als zentrales Ereignis alle Aufmerksamkeit und erst nach Monaten fällt auf, dass die Newsletter-Anmeldung oder die Wunschliste gar nicht funktioniert. Passiert immer und überall.

Eine bewährte Reihenfolge:

1. Basis-Tracking: Seitenaufrufe, Konfiguration, benutzerdefinierte Dimensionen
2. Kern-Events: Conversions, Formulare, die wichtigsten Interaktionen
3. E-Commerce: Transaktion zuerst, dann schrittweise die vorgelagerten Events
4. Nice-to-have: Alles, was nicht unmittelbar für Reporting oder Optimierung gebraucht wird

Jede Phase einzeln veröffentlichen, testen, validieren. Die Debug-Tools des jeweiligen Analytics-Produkts nutzen - nicht nur prüfen, was den Browser verlässt, sondern auch, was im Tool ankommt. Das ist nicht das Gleiche.

Parallelbetrieb einplanen: Wenn irgend möglich, das alte und neue Tool für einen überlappenden Zeitraum parallel laufen lassen. Nicht um die Zahlen zu vergleichen (die werden sich unterscheiden - unterschiedliche Tools, unterschiedliche Definitionen), sondern um sicherzustellen, dass nichts Wesentliches fehlt.

Faktor Mensch

Wer ein neues Tool einführt und glaubt, damit sei es getan, wird von der Realität schnell korrigiert. Menschen sind träge und das Bekannte ist der Feind des Neuen. Ein gutes Migrationskonzept beinhaltet daher auch:

• Übersetzungslisten: Wie heißt Feature X aus dem alten Tool im neuen? Wo finde ich Report Y?
• Schulungen in verschiedenen Formaten - nicht jeder lernt gleich gut aus Dokumentation
• Interne Botschafter, die das neue Tool schon kennen und Anlaufstelle für Fragen sind

Das klingt nach viel Aufwand für "nur" einen Toolwechsel. Ist es auch. Aber eine ungenutzte Analytics-Implementierung ist eine teure Analytics-Implementierung.

Checkliste

Checkliste in Zwischenablage kopieren

Wer bei der Vorbereitung und Umsetzung einer solchen Migration Unterstützung sucht - ob es um die Bestandsaufnahme, das Event-Mapping oder die Implementierung im Tag Manager geht: Meine Beratungsangebote rund um Webanalyse und Tracking sind genau dafür gemacht 😉