Erschienen in Apr I 2025 | Digital Analytics
Level: Advanced

Du öffnest dein GA4-Konto und suchst nach einem bestimmten Event. Nach minutenlanger Suche und Verzweiflung stellst du fest, dass für das eine Event zig verschiedene Varianten existieren, mal auf Deutsch, mal auf Englisch, mal mit Unterstrich und mal mit Leerzeichen. Kommt dir bekannt vor? Dann bist du nicht allein!
Uneinheitliche Bezeichnungen der Elemente sind der häufigste Grund für Chaos in der Webanalyse. Sie erschweren die Nutzung des Tools und führen dazu, dass wertvolle Daten übersehen oder falsch interpretiert werden.
Die Lösung liegt auf der Hand: ein klares und durchdachtes Namenskonzept. In diesem Artikel zeigen wir dir, wie eine einheitliche Benennung von Events, Parametern und anderen GA4-Elementen aussehen kann, damit du endlich Ordnung in dein Tracking kriegst.

Die Idee für diesen Artikel haben wir von MeasureSchool.

Das könnte dich interessieren: Im letzten Newsletter haben wir bereits ein Naming-Konzept für deinen Google Tag Manager erarbeitet.

Wie kommen uneinheitliche Namenskonventionen in GA4 zustande

Ein häufiger Grund für unübersichtliche GA4-Daten ist das Fehlen einer klaren Namensstrategie. Ohne feste Regeln benennt jede:r Events, Parameter und andere Elemente nach eigenem Ermessen – mal mit Bindestrichen, mal mit Leerzeichen, mal auf Englisch und mal auf Deutsch. Das mag bei einer kleinen Anzahl an Einträgen noch funktionieren, führt aber schnell zu Verwirrung, sobald sich mehr Daten ansammeln und sobald mehrere Personen im Account arbeiten.
Besonders problematisch wird es, wenn mehrere Abteilungen an der Webanalyse beteiligt sind. Entwickler:innen, Marketer:innen und Analyst:innen haben oft unterschiedliche Herangehensweisen an die Benennung und verwenden dafür verschiedene Schemata. Während die Marketing-Abteilung vielleicht ein stringentes System verfolgt, arbeiten andere Teams mit uneinheitlichen oder sogar fehlenden Konventionen. Das Ergebnis: ein GA4-Setup, das immer schwerer zu durchblicken ist.
Um das zu vermeiden, ist ein übergreifendes Namenskonzept essentiell – und zwar eines, das alle Beteiligten nicht nur verstehen, sondern auch konsequent anwenden. In diesem Artikel stellen wir dir eine Struktur vor, die dir hilft, dein GA4-Tracking sauber und einheitlich zu halten.

Namenskonventionen für Google Analytics 4

In GA4 gibt es verschiedene Elemente, die du bei einer Namenskonvention beachten solltest:

Konto
Properties
Datenstreams
Ereignisse
Parameter
Benutzerdefinierte Definitionen
Explorative Datenanalyse

1. Konto

Das Konto ist die oberste Organisationseinheit in Google Analytics 4. Dein Unternehmen sollte ein Konto haben, auch dann, wenn es mehrere verschiedene Websites betreibt. Du benennst dein Konto also einfach nach deinem Unternehmen.

Unser Konto heißt beispielsweise „001 | 121WATT Google Analytics 4“.

2. Properties

Die Properties befinden sich eine Ebene unter dem Account. Bei der Aufteilung der Properties kommt es darauf an, wie dein Unternehmen organisiert ist. Es macht Sinn, für verschiedene Websites einzelne Properties anzulegen.
Falls dein Unternehmen nur über eine Website verfügt, solltest du der Property dennoch einen eindeutigen Namen geben, falls in der Zukunft weitere Properties hinzukommen. Hier eignet sich der Unternehmensname und ein Zusatz, der die Property als Haupt-Element auszeichnet, beispielsweise:

001 | 121WATT – Master

Auch möglich wäre, statt dem Unternehmensnamen die eindeutige ID der Property zu verwenden, z. B.:

001 | G-JD736DXXXX – Master

Wir würden jedem Unternehmen empfehlen, zusätzlich zur Haupt-Property eine Test-Property sowie eine Backup-Property anzulegen. Die Test-Property eignet sich – wie der Name schon sagt – um Tests durchzuführen, ohne dass sie direkt auf der Website angewendet werden. Die Backup-Property hilft, wenn eine neue Test-Property eingerichtet werden muss und dient der Sicherheit. Das könnte dann so aussehen:

001 | G-JD736DXXXX – Master
002 | G-JZUE7FXXXX – Test
003 | G-USJE67XXXX – Backup

Falls du mehrere voneinander abgetrennte Websites hast, empfehlen wir eine Property pro Website:

Wofür die Zahlen vor den Namen? Wir haben festgestellt, dass uns die voranstehenden Zahlen (001, 002, etc.) bei der Organisation unseres Kontos helfen. Zum einen können wir so Prioritäten vergeben und zum anderen eignen sie sich, um die Elemente in eine bestimmte Reihenfolge zu bringen. Damit erreichen wir, dass z.B. die Haupt-Property, die mit „001“ gekennzeichnet ist, immer ganz oben erscheint.

3. Datenstreams

Ein Datenstream ist die Quelle, von der die Property ihre Daten erhält. Eine Property kann mehrere Datenstreams haben. Das macht Sinn, wenn du beispielsweise eine Website und eine zugehörige App betreibst. In dem Fall kannst du die Nutzerinteraktionen über alle Geräte hinweg tracken und in einer einzigen Property auswerten. Gleiches gilt für Websites, die eng miteinander verknüpft sind.

Bei der Benennung der Datenstreams gilt Ähnliches wie für Konto und Property: Hauptsache ist, dass du identifizieren kannst, um welche Datenquelle es sich handelt. Da GA4 dem Datenstream automatisch eine URL hinzufügt, kannst du den Namen einfach sprechend nach der Quelle wählen, z. B.:

121WATT Website
121WATT App

4. Ereignisse

Bisher konntest du die Namen für deine Elemente willkürlich wählen (Hauptsache, sie folgen dem von dir festgelegten Schema). Bei Ereignissen geht das nicht mehr ganz so einfach, da Google Analytics 4 ein paar Vorgaben macht, die du beachten musst:

Groß- und Kleinschreibung werden beachtet; das bedeutet „button_click“, „Button_click“ und „Button_Click“ wären drei verschiedene Ereignisse
Ereignisnamen müssen mit einem Buchstaben beginnen (nicht mit einer Zahl)
Du darfst Buchstaben, Zahlen und Unterstriche ( _ ) verwenden, aber keine Leer- oder Sonderzeichen

Wir haben für unsere Ereignisse beispielsweise festgelegt, dass wir nur Kleinbuchstaben und Unterstriche verwenden. Wir würden dir raten, auch eine Regel dafür festzulegen, da es ansonsten aufgrund der Beachtung von Groß- und Kleinschreibung zu Dopplungen kommen kann. Abgesehen davon empfehlen wir, Ereignisse möglichst genau danach zu benennen, was bei ihnen passiert.

Beispielsweise:

page_404 (ein Nutzer gelangt auf eine 404-Seite)
purchase (ein Nutzer tätigt einen Kauf)
survey_complete (ein Nutzer hat eine Umfrage abgeschickt)

Achtung! In GA4 gibt es bereits einige Ereignisse, die automatisch erfasst werden. Für diese Ereignisse hat Google bereits Namen reserviert, beispielsweise session_start, file_download oder scroll. Eine umfassende Übersicht findest du direkt bei Google. Diese Namen solltest du nicht für andere Ereignisse verwenden – auch nicht im GTM – da es sonst zu Dopplungen und uneinheitlichem Tracking kommt, was deine Daten verfälscht.

Wie granular soll ich vorgehen?

Bei Ereignisnamen hat Google ein Zeichenlimit von 40 Zeichen. Dieses darfst du nicht überschreiten. Generell ist es ratsam, eher generische Ereignisnamen zu verwenden, da sie in unterschiedlichen Anwendungsfällen eingesetzt werden können. Das Ereignis generate_lead wird zum Beispiel immer ausgelöst, wenn ein Lead auf der Website abgegeben wird, unabhängig davon, über welches Formular oder zu welchem Thema.

Wenn du aber unterschiedliche Unternehmensbereiche hast, die du in der Analyse voneinander trennen willst, kann es Sinn machen, etwas granularer vorzugehen und die Leads der verschiedenen Bereiche voneinander zu trennen, beispielsweise durch: generate_lead_vehicle und generate_lead_insurance (wenn dein Unternehmen sowohl Fahrzeuge als auch Versicherungen dafür anbietet).
Theoretisch kannst du hier auch mit Parametern und Filtern arbeiten. In der Praxis hat sich aber ergeben, dass die direkte Abfrage der einzelnen Lead-Arten direkt aus dem Datensystem einfacher ist, besonders wenn du eine große Datenmenge mit vielen Leads verwaltest.
Vermeide dennoch zu spezifische Ereignisnamen, z. B. generate_lead_vehicle_cabrio_hybrid_hs6. Solche Ereignisse erschweren das Reporting und machen deine Berichte unübersichtlich – genau das soll die Namenskonvention ja vermeiden.

Einschränkungen bei der Erstellung von Ereignissen

Neben den vordefinierten Ereignissen und dem Zeichenlimit gibt es einige weitere Einschränkungen, die du beim Erstellen und Benennen von Ereignissen hast.

Änderungen gelten nicht rückwirkend: Wenn du ein Ereignis bearbeitest (z. B. den Namen anpasst), gilt diese Einstellung erst ab dem Zeitpunkt der Änderung. Zuvor erfasste Events werden unter dem alten Namen angegeben.
Einschränkungen bei der items-Array: Die items_array wird für E-Commerce Daten verwendet, um Produktinformationen wie item_category, item_name oder item_id zu speichern. Wenn du hier Änderungen vornehmen willst, z. B. ein Ereignis purchase_clothing auslösen, wenn item_category=“Clothing“ und item_name=“Black T-Shirt“, musst du das direkt im Google Tag Manager oder im Datenlayer umsetzen, bevor die Daten an GA4 gesendet werden können.
Max. 50 Ereignisse aus bestehenden Ereignissen: Du kannst in GA4 neue Ereignisse aus bereits bestehenden Ereignissen erstellen. Das geht allerdings nur 50 Mal.
Einschränkungen beim serverseitigen Tracking: Ereignisse, die direkt vom Server an GA4 gesendet werden, ohne dass der Nutzerbrowser involviert ist (=serverseitiges Tracking), können nicht mehr modifiziert werden, sobald sie einmal eingerichtet sind. Sie kommen beispielsweise über das Google Measurement Protocol und müssten direkt auf dem Server geändert werden, bevor die Daten an GA4 gesendet werden können.

5. Parameter

Ereignisparameter geben zusätzliche Informationen zu einem Ereignis, beispielsweise zum angesehenen Inhalt oder zum Text, der sich auf einem angeklickten Button befindet. Parameter richtest du nicht in GA4, sondern im Google Tag Manager ein. In GA4 gibt es allerdings einen Umweg: Über Verwaltung > Datenanzeige > Benutzerdefinierte Definitionen kannst du innerhalb einer benutzerdefinierten Dimension ein Ereignisparameter erstellen.

Für die Parameter gelten die gleichen Regeln wie für die Events: Groß- und Kleinschreibung werden beachtet, Parameter müssen mit einem Buchstaben beginnen und es dürfen nur Buchstaben, Zahlen und Unterstriche verwendet werden. Auch die Parameter solltest du so beschreibend wie möglich benennen.

Beispiele:

page_title (der Titel der aktuellen Seite)
coupon (verwendeter Gutscheincode)
content_category (Kategorie des Inhalts, beispielsweise Blog, Product oder Help Center)

Achtung! Auch hier gibt es von Google Analytics vordefinierte Parameter, beispielsweise gclid, Sprache oder session_id. Wie oben bereits beschrieben, dürfen Parameter nicht mit einer Zahl oder einem Unterstrich beginnen. Daneben sind Parameter nicht mit den folgenden Präfixen zu beginnen:

firebase_
ga_
google_
gtag.

6. Benutzerdefinierte Definitionen

Alle Parameter, die du in Standardberichten verwenden willst, müssen als benutzerdefinierte Definition registriert werden. Dazu zählen Dimensionen, Metriken oder Nutzer-Eigenschaften. Das gilt auch für automatisch erfasste Parameter.

Die Benennung an sich beeinflusst nicht das Reporting, sondern nur die Darstellung im Bericht. Du hast deswegen zwei Möglichkeiten, benutzerdefinierte Definitionen zu benennen.

Entweder nach der gleichen Konvention wie Ereignisse und Parameter, beispielsweise:

form_type (gibt die Art des Formulars wieder, etwa „Newsletter-Anmeldung“ oder „Support Ticket“)
scroll_depth (enthält Informationen über die Scrolltiefe, bspw. 20 %, 75 % oder 100 %)
preferred_language (enthält Informationen zur Sprachversion einer Website)

Oder aber du gibst sie in Standard-Schrift ohne Unterstriche an:

Form type oder Formulartyp
Scroll depth oder Scrolltiefe
Preferred language oder Primäre Sprache

Hinweis: Abhängig vom Scope und der Art deines GA4-Accounts ist die Anzahl der Parameter und benutzerdefinierten Dimensionen und Metriken, die du anlegen kannst, limitiert.
Wir empfehlen deswegen, Parameter so zu benennen, dass sie für mehrere Ereignisse verwendet werden können, statt für jedes Ereignis spezifische Parameter anzulegen. Der Parameter page_section kann beispielsweise für die Ereignisse scroll, click oder form_submit verwendet werden. Ein weiteres Beispiel ist der Parameter button_text, der unter anderem bei den Ereignissen button_click oder menu_click zum Einsatz kommen kann. So sparst du benutzerdefinierte Dimensionen und Parameter ein.

Unter Verwaltung > Datenanzeige >Benutzerdefinierte Definitionen > Kontingentinformationen findest du Informationen darüber, wie viele Dimensionen und Messwerte du noch erstellen kannst.

7. Explorative Datenanalyse

Wenn du in der Explorativen Datenanalyse viele Berichte mit dem Namen „Unbenannte explorative Datenanalyse“ hast, bist du damit nicht alleine. Das passiert, wenn Berichte erstellt werden, aber nicht mit einem Namen versehen werden. Oft passiert das, wenn man „nur schnell etwas analysieren“ will, ohne dass man den Bericht später nochmal verwenden möchte.
Wir möchten an dieser Stelle aber dafür appellieren, Berichte immer zu benennen, auch wenn sie nur einmal verwendet werden. Ansonsten verlierst du schnell den Überblick, besonders, wenn du nicht allein im Account arbeitest. Deswegen ist es auch wichtig, dass du die Regeln zur Namenskonvention an deine Kolleginnen und Kollegen weitergibst.

Um eine einheitliche Struktur zu haben und Berichte leicht auffindbar zu machen, empfehlen wir folgende Namenskonvention:

Art des Berichts – Was analysiert wird

Beispiele:

Freies Format – CTA-Klicks auf der Startseite
Funnel – Anmeldeformular

Falls dein Team GA4 mit ihren eigenen E-Mail-Adressen nutzt, wird hinter dem Bericht angezeigt, wer ihn erstellt habt. Falls ihr einengemeinsamen Login verwendet, macht es Sinn, im Titel des Berichts noch den Namen des Erstellers bzw. der Erstellerin anzugeben.
Art des Berichts – Was analysiert wird – Name des Erstellers / der Erstellerin (optional)

Beispiel:

Freies Format – CTA Klicks auf der Startseite – Eva S.
Funnel – Anmeldeformular Newsletter – Alexander H.

Wenn deine Property Web- und App-Datenstreams enthält, kannst du zusätzlich die Plattform angeben, um Klarheit zu schaffen:

Freies Format – CTA Klicks auf der Startseite (web) – Eva S.
Funnel – Anmeldeformular Newsletter (app) – Alexander H.

Wie du Namenskonventionen in deinem Unternehmen etablierst, haben wir die bereits im Artikel zu Namenskonventionen im Google Tag Manager erklärt. Das kannst du 1:1 auf GA4 übertragen.

Quelle: MeasureSchool