Design wechseln

GA4 erweitert: Event-Tracking und Conversion-Funnels

Easton editorial illustration: large event token, configurable conversion funnel, BigQuery warehouse block

Am 1. Juli 2023 stellte Google Universal Analytics die Datenerfassung endgültig ein. Morgens im Backend – die UA-Kurve brach ab – und eine Frage blieb: Wie nutzt man GA4 wirklich?

Wenn Sie wie ich von UA kamen, nur Basis-Tracking eingebaut haben und die GA4-Oberfläche verwirrt: Sie sind nicht allein. Viele Sites „laufen nackt“: Seitenaufrufe ja – aber welche Buttons, wie viel gelesen, wo Nutzer abspringen – fehlt.

Dieser Artikel erklärt nicht „was GA4 ist“, sondern Praxis: Event-Tracking für echtes Verhalten, Conversion-Funnels für Abbruchstellen und bei Bedarf BigQuery mit SQL. Wir starten mit den drei Event-Typen.

1. Drei Event-Typen in GA4

GA4 denkt anders als UA. UA: Session + Seitenaufruf. GA4: alles ist ein Event.

Konkret: Seitenaufruf, Klick, Video, Scroll bis 90 % – jedes Verhalten ist ein Event-Datensatz. Events sind aber nicht beliebig – Google unterteilt in drei Klassen.

1. Automatische Events (Enhanced Measurement)

Das „Gratis-Paket“ von GA4. Beim Datenstream ist Enhanced Measurement standardmäßig an und trackt 7 Interaktionen:

  • Seitenaufruf (page_view)
  • Scroll (scroll) – nur bei 90 % Scrolltiefe
  • Outbound-Klicks (click)
  • Interne Suche (search)
  • Video (video_start, video_progress, video_complete)
  • Dateidownload (file_download)
  • Formulare (form_start, form_submit)

Klingt vollständig – aber: Scroll nur bei 90 %. Für „Artikel zu Ende gelesen“ oder 50 % / 75 % brauchen Sie GTM.

Empfehlung: Enhanced Measurement an lassen, aber nicht überschätzen. Es liefert Basisdaten; wertvolles Verhalten konfigurieren Sie selbst.

2. Empfohlene Events

Google definiert branchenspezifische empfohlene Events – E-Commerce: add_to_cart, purchase; Content: sign_up, login, share.

Vorteil: korrekter Name + Parameter → passende GA4-Berichte. Sie triggern nicht automatisch – Code oder GTM nötig, Namen/Parameter strikt nach Doku.

Blog-Beispiele:

EventSzenarioSchlüsselparameter
sign_upRegistrierung/Abomethod
loginLoginmethod
shareTeilencontent_type, item_id

Ich tracke Abos mit sign_up. Einmal signUp (CamelCase) – GA4 ignoriert es. Empfohlene Events: snake_case, exakt.

3. Benutzerdefinierte Events

Nicht in der Google-Liste? Eigene Events – z. B. article_read_complete.

Freiheit mit Grenzen:

  1. Parameter-Limit: max. 25 Custom-Parameter pro Event. Simo Ahava: darüber hinaus in BigQuery, in GA4-UI oft ignoriert.

  2. Naming: Buchstaben, Ziffern, Unterstrich; mit Buchstabe starten; snake_case.

  3. Verzögerung: Berichte können 24–48 h brauchen – nicht sofort „kaputt“ annehmen.

25
Max. benutzerdefinierte Parameter pro Event
Source: Simo Ahava, Praxistest

Priorität: einfache Entscheidungsfolge

  1. Enhanced Measurement – wenn es reicht, nichts Neues bauen
  2. Empfohlene Events – Spezifikation einhalten, Berichte gratis
  3. Custom – nur bei echtem Mehrbedarf (höherer Pflegeaufwand)

Für viele Blogs reichen Enhanced Measurement + wenige empfohlene Events. Custom ist für tiefe Analyse.

2. Event-Tracking in der Praxis

Zwei Wege: Google Tag Manager (GTM) oder gtag.js im Seitencode. Ich empfehle GTM – Trigger ändern ohne Redeploy.

GA4-Event per GTM: vier Schritte

Beispiel: „Artikel vollständig gelesen“.

Schritt 1: GA4-Event-Tag

GTM → neues Tag → Google Analytics: GA4 Event, Measurement ID, Event-Name article_read_complete.

Schritt 2: Trigger

Wann feuern? Hier: Scroll 90 %. Trigger-Typ Scroll Depth, Vertical Scroll Depths = 90 %.

Detail: Fortschrittsbalken oben kann Scroll-Events spammen. Lösung: pro Nutzer und Artikel nur einmal triggern.

Schritt 3: Event Parameters

Welcher Artikel, Kategorie, Autor?

ParameterWertHinweis
article_title{{Page Title}}Seitentitel
article_category{{Custom JS Variable}}per JS aus DOM/Meta
reading_time{{Custom JS Variable}}geschätzte Lesezeit

Typen konsistent: reading_time immer Zahl – nicht mal 5, mal "5 Minuten".

Schritt 4: Debug

Vor Publish: GTM Preview, Seite scrollen, in GA4 Configure > DebugView prüfen. Kein Event → Trigger; Event ohne Parameter → Variablen.

Alternative: gtag.js direkt

Statische Sites (Astro, Hugo) ohne GTM:

// Nach Seitenload
window.addEventListener('load', function() {
  window.addEventListener('scroll', function() {
    var scrollPercent = (window.scrollY / (document.body.scrollHeight - window.innerHeight)) * 100;
    if (scrollPercent >= 90 && !window.articleReadTracked) {
      window.articleReadTracked = true;
      gtag('event', 'article_read_complete', {
        'article_title': document.title,
        'article_category': document.querySelector('meta[name="category"]')?.content || 'unknown',
        'reading_time': parseInt(document.querySelector('meta[name="reading-time"]')?.content || 0)
      });
    }
  });
});

Gleiche Logik wie GTM – Änderungen erfordern Deploy.

Typische Fehler (aus Erfahrung)

Fehler 1: inkonsistente Event-Namen
articleReadComplete, article-read-complete, article_read_complete = drei Events in GA4. Einheitlich snake_case.

Fehler 2: gemischte Parametertypen
reading_time: 5 vs. "5 minutes" vs. true – GA4 behandelt das als verschiedene Parameter.

Fehler 3: Consent Mode v2
EU + Consent: bei Ablehnung fehlen Events – Berichte „schrumpfen“, kein Config-Bug.

Fehler 4: reservierte Namen
page_view, session_start, first_visit nicht als Custom-Events missbrauchen. Parameter-Reserved-Liste in der Doku prüfen.

Blog-Events: Praxisliste

VerhaltenEventParameter
Artikel gelesenarticle_read_completearticle_title, category, author
Kommentarcomment_submitarticle_title, comment_length
Abo-Klicknewsletter_clickbutton_location, article_title
Inhaltsverzeichnistoc_clicksection_title, article_title

Damit sehen Sie echtes Blog-Verhalten – als Nächstes: Funnels.

3. Conversion-Funnels

Events liegen vor – jetzt die Frage: Wie viele gehen vom ersten Besuch bis zum Ziel – und wo brechen sie ab?

Funnel Exploration in GA4 ist flexibler als UA: eigene Schritte, Segmente, Zeit bis Conversion.

Ersten Funnel anlegen

GA4 → Explore > Funnel Exploration. Bis 10 Schritte – Blogs reichen oft 4–5.

Beispiel Abo-Funnel:

  1. Artikel (page_view, page_location enthält /posts/)
  2. Abo-Seite (page_view, page_location enthält /subscribe)
  3. Formular (newsletter_signup)
  4. E-Mail geöffnet (email_opened) – mit Mail-Tool

Pro Schritt: einfache, klare Bedingungen – sonst wird der Funnel unlesbar.

Abbruchstellen lesen

SchrittNutzerRate (von vorherigem)
Artikel10000-
Abo-Seite8008 %
Formular24030 %
E-Mail18075 %

Größter Drop: Artikel → Abo-Seite (8 %). Einstieg zur Abo-Seite zu schwach. Zweiter Drop: Abo-Seite → Formular (30 %) – Formular oder Value Proposition.

Dann Segmente: wer bricht wie ab?

Segmente: wer verliert sich?

  • Neu vs. wiederkehrend – Neu oft niedriger (noch kein Vertrauen)
  • Mobile vs. Desktop – Formulare auf Mobile schwächer
  • Kanal – Suche vs. Social

Beispiel Abo-Funnel:

SchrittNeuWiederkehrend
Artikel → Abo5 %15 %
Abo → Formular25 %40 %

Neue Nutzer: 5 % zur Abo-Seite – Einstieg unsichtbar. Lösung bei mir: Abo-Karte am Artikelende → 5 % → 12 %.

140 %
Steigerung Conversion Neunutzer
Source: Eigene Messung nach Abo-Karte

Open Funnel

Standard: linear – nur strikte Reihenfolge zählt. Realität: Abo direkt im Artikel, ohne /subscribe.

Open Funnel: Schritte ohne Zwang-Reihenfolge – zeigt atypische Pfade. Bei mir: 15 % Abos ohne Abo-Landing – Footer im Artikel schlägt eigene Abo-Seite. Fokus auf Footer-UX statt nur Abo-Seite.

Funnel-Fallstricke

Nur End-Conversion – Zwischenschritte sind der Hebel, nicht nur „1,8 % gesamt“.

Zeit ignorieren – „Lesen → Kauf“ in 7 Tagen = langer Entscheidungszyklus; Vertrauen/Nurturing anpassen.

Zu wenig Daten – Dutzend Nutzer pro Schritt = instabile Raten; hunderte pro Schritt für belastbare Analyse.

4. BigQuery-Export

Alles bisher in der GA4-UI. Limit: bei großem Traffic Stichproben in Berichten – für exakte Conversion-Mixe mit vielen Dimensionen unzuverlässig.

BigQuery = Vollbestand per SQL.

Einrichtung in drei Schritten

1. BigQuery-Projekt
Google Cloud Console, BigQuery API, Free Tier: 10 GB Speicher, 1 TB Queries/Monat – für Blogs meist genug.

2. Verknüpfung in GA4
Verwaltung → BigQuery Linking → Projekt, Frequenz:

  • Daily – Vortag, stabil für Trends
  • Streaming – nahezu live

Beides aktivieren ist sinnvoll.

3. Warten
Export startet innerhalb ~24 h. Keine Historie: nur ab Verknüpfung – früh einrichten.

Datenmodell

Tägliche Tabelle events_YYYYMMDD, z. B. events_20260429.

FeldBedeutung
event_namez. B. page_view, article_read_complete
event_timestampMikrosekunden Unix
user_pseudo_idanonyme User-ID
event_paramsverschachtelt – per SQL UNNEST
geoLand, Stadt
deviceBrowser, OS, Gerätetyp

SQL-Beispiele

Unique User für ein Event:

SELECT
  COUNT(DISTINCT user_pseudo_id) as unique_users
FROM `your-project.analytics_123456789.events_*`
WHERE event_name = 'article_read_complete'
  AND _TABLE_SUFFIX BETWEEN '20260401' AND '20260429'

Parameter-Verteilung:

SELECT
  param.value.string_value as article_category,
  COUNT(DISTINCT user_pseudo_id) as users
FROM `your-project.analytics_123456789.events_*`,
UNNEST(event_params) as param
WHERE event_name = 'article_read_complete'
  AND param.key = 'article_category'
  AND _TABLE_SUFFIX BETWEEN '20260401' AND '20260429'
GROUP BY article_category
ORDER BY users DESC

GA4-UI vs. BigQuery

SzenarioGA4BigQuery
Tages-Traffic-
Funnel-
>4 Dimensionen-
Exakte Raten ohne Stichprobe-
Export nach Looker/Python-
Live (heute)StreamingStreaming

Alltag: GA4-Oberfläche; Tiefe: BigQuery.

Kosten

Abrechnung nach verarbeiteten Daten. Sparen:

  1. _TABLE_SUFFIX für Datumsrange
  2. frühes WHERE-Filtern
  3. Materialized Views für wiederkehrende Queries

Mein Blog: ~1 GB/Monat, <100 GB Queries – im Free Tier.

5. GA4 vs. UA für Umsteiger

Nicht nur neues UI – andere Logik. Gewohnte UA-Konzepte fehlen oder heißen anders.

Event-Modell vs. Session-Modell

UA: Session als Kern – mehrere Pageviews/Events pro Besuch.
GA4: Event als Atom – Session ist Event-Menge.

UA: Sessions, Pages/Session. GA4: Events, Users, User Journey – Vormittag + Nachmittag = ein User, zwei Besuche, nicht zwei „getrennte Welten“.

Engagement Rate vs. Bounce Rate

UA-Bounce: eine Seite = Absprung – auch 10 Minuten Lesen auf einer Seite.

GA4 Engagement Rate: >10 s, Conversion-Event oder ≥2 Seiten = engagiert. Engagement Rate = engagierte Sessions / alle Sessions.

Nicht 1:1 mit UA-Bounce vergleichen.

Data Streams vs. Views

UA-Views mit Filtern (nur DE, ohne interne IPs). GA4: Data Streams (Web, iOS, Android) – keine multiplen gefilterten Views wie UA.

Property Filters ersetzen Views teilweise – schwächer. Wer UA-Views für Daten-Trennung nutzte: BigQuery + Looker Studio oder neue Architektur planen.

Goals → Conversion Events

UA-Goals → GA4 Conversion Events. Nur „Event passiert“ – Seiten-Conversion = page_view als Event, dann als Conversion markieren.

Migration: UA-Goals listen, in GA4-Events mappen – sonst bricht die Conversion-Linie.

Fazit

Kurz die vier Bausteine:

  1. Events: automatisch → empfohlen → custom
  2. Funnel: Abbruch finden, segmentieren, Open Funnel
  3. BigQuery: früh verknüpfen, keine Historie
  4. Mindset: UA-Metriken nicht 1:1 auf GA4 pressen

Eine Sache sofort: Enhanced Measurement prüfen, 3–4-Schritt-Funnel für Ihren Abo-/Ziel-Flow bauen.

Daten sagen nicht die Lösung – aber wo das Problem liegt. Den Rest lösen Sie im Produkt und Content.


Quellen

GA4-Event-Tracking und Conversion-Funnels einrichten

GA4-Events von null konfigurieren und Funnels zur Verhaltensanalyse anlegen

⏱️ Estimated time: 60 min

  1. 1

    Step 1: Enhanced Measurement aktivieren

    GA4 → Verwaltung &gt; Datenstreams &gt; Stream wählen, Enhanced Measurement einschalten. Standard: 7 Interaktionen – Seitenaufruf, Scroll, Outbound-Klicks, interne Suche, Video, Dateidownload, Formulare.
  2. 2

    Step 2: Empfohlene oder benutzerdefinierte Events

    Je nach Bedarf:

    • Empfohlen: Blog mit sign_up, login, share usw.
    • Benutzerdefiniert: article_read_complete, newsletter_click usw.
    • Naming: einheitlich snake_case, kein CamelCase oder Bindestrich
  3. 3

    Step 3: Events per GTM auslösen

    In GTM:

    1. GA4-Event-Tag mit Measurement ID
    2. Trigger (z. B. Scroll Depth 90 %)
    3. Event Parameters (article_title, category …)
    4. Preview-Modus zum Testen
  4. 4

    Step 4: Conversion-Funnel anlegen

    GA4 → Erkunden &gt; Funnel Exploration:

    • 4–5 Schritte definieren
    • Bedingungen pro Schritt einfach halten
    • Segmente: Neunutzer vs. Wiederkehrende
    • Open Funnel für atypische Pfade
  5. 5

    Step 5: BigQuery-Export (optional)

    GA4 Verwaltung &gt; BigQuery-Verknüpfung:

    • Projekt verknüpfen
    • Daily und Streaming aktivieren
    • Datenfluss nach ca. 24 h
    • Hinweis: keine historische Rückfüllung

FAQ

Was unterscheidet die drei GA4-Event-Typen?
Enhanced Measurement (automatisch, begrenzt), empfohlene Events (Google-Spezifikation, fertige Berichte), benutzerdefinierte Events (flexibel, mehr Pflege). Reihenfolge: zuerst automatisch, dann empfohlen, zuletzt custom.
Engagement Rate in GA4 vs. Absprungrate in UA?
UA-Absprung zählt auch „eine Seite gelesen“ als Absprung. GA4-Engagement: &gt;10 s, Conversion-Event oder ≥2 Seiten = Engagement. Kein direkter Gegenpol – nicht 1:1 vergleichbar.
Wie viel Daten braucht ein Funnel?
Pro Schritt idealerweise einige hundert Nutzer. Bei wenigen Dutzend schwanken Raten stark – erst Daten sammeln, dann tief analysieren.
Kostet BigQuery-Export etwas?
Abrechnung nach Abfragevolumen; Free Tier: 10 GB Speicher + 1 TB Queries/Monat. Typischer Blog ~1 GB/Monat, Queries oft &lt;100 GB – meist kostenlos. Große Sites: Kosten im Blick behalten.
Wann erscheinen Daten nach der Konfiguration?
Enhanced Measurement sofort live; empfohlene/custom Events oft 24–48 h in Berichten. BigQuery startet innerhalb von 24 h, ohne Historie – früh verknüpfen.
Regeln für Event-Parameter-Namen?
Nur Buchstaben, Ziffern, Unterstrich; muss mit Buchstabe beginnen. snake_case (article_read_complete), kein CamelCase oder Bindestrich. Max. 25 benutzerdefinierte Parameter pro Event.
UA → GA4: Was neu einrichten?
UA Goals → GA4 Conversion Events; Custom Dimensions/Metrics neu; Views → Property Filters (schwächer); Berichte in Explore neu bauen. UA-Zugriff für Vergleiche behalten.

7 Min. Lesezeit · Veröffentlicht am: 29. Apr. 2026 · Aktualisiert am: 14. Juli 2026

Kommentare

Melde dich mit GitHub an, um einen Kommentar zu hinterlassen

Easton BlogEaston Blog