GA4-Ereignisse verstehen: Was automatisch entsteht und was deine Website melden muss

Diese vier Namen gehören zum Grundbestand von Google Analytics. Sie erscheinen aber nicht alle als eigene Messanfrage: page_view und user_engagement werden vom Google-Tag gemeldet, session_start und first_visit entstehen erst in Analytics. Voraussetzung bleiben eine funktionierende Einrichtung und passende Einwilligungseinstellungen.

• page_view – eine Seite wurde aufgerufen. Bei Seitenwechseln ohne vollständiges Neuladen kann die Einstellung für Seitenänderungen im Datenstream weitere Aufrufe melden.
• session_start – Analytics beginnt eine neue Sitzung. Nach einer Phase ohne Aktivität kann der nächste Besuch eine neue Sitzung auslösen; standardmäßig beträgt diese Pause 30 Minuten.
• first_visit – Analytics erkennt einen ersten Besuch in diesem Browser. Verfügbare Kennungen, gelöschte Cookies und die Einwilligung beeinflussen, ob ein Besuch wiedererkannt werden kann.
• user_engagement – das Google-Tag übermittelt aktive Nutzungszeit, etwa beim Verlassen einer Seite oder einem Wechsel in den Hintergrund. Analytics nutzt diese Angaben für die Interaktionsdauer.

Ein einzelner page_view bestätigt zunächst nur diesen Seitenaufruf. Fehlen weitere Ereignisse, prüfe deren Auslösebedingungen und die Einstellungen der optimierten Analysen. Aus dem fehlenden Namen allein lässt sich die Ursache nicht bestimmen.

Die optimierten Analysen können weitere Aktionen automatisch im Browser erkennen. Du aktivierst sie am Web-Datenstream in Google Analytics; zusätzliche einzelne Ereignis-Tags im Tag Manager sind dafür nicht nötig.

Jeder Ereignistyp hat eigene Voraussetzungen. Diese Liste hilft dir, mit einer passenden Aktion zu testen.

• scroll – 90 % der Seitenhöhe wurden erreicht. Die automatische Messung erfasst diese Schwelle einmal pro Seite, nicht jede Scrollbewegung.
• click – ein ausgehender Klick auf eine andere Website. Der technische Name lautet click; ein zusätzlicher Parameter kennzeichnet den ausgehenden Link. Interne Links gehören nicht zu dieser Messung.
• view_search_results – eine Seite mit einem Suchbegriff in ihrer URL wurde geöffnet. Übliche Suchparameter sind q, s, search, query oder keyword.
• file_download – ein Link zu einer unterstützten Dateiart wurde angeklickt, etwa einem Dokument, Archiv oder einer Tabelle. Das bestätigt den Klick, nicht den abgeschlossenen Download.
• form_start und form_submit – der Beginn einer Formularinteraktion und das Absenden eines erkannten Formulars. Das Absenden bestätigt noch keine erfolgreich angenommene Anfrage.
• video_start, video_progress und video_complete – Wiedergabeereignisse unterstützter eingebetteter YouTube-Player. Die Einbettung muss die JavaScript-API zulassen.

Prüfe zuerst den Hauptschalter „Optimierte Analysen“ im Datenstream. Bei über die Analytics Admin API angelegten Streams kann er deaktiviert sein, obwohl einzelne Messoptionen bereits aktiv aussehen. Entscheidend sind Hauptschalter und jeweilige Unteroption zusammen.

SignalHost versucht den Hauptschalter beim Erstellen einer Property zu aktivieren. Gelingt das nicht, erscheint ein Hinweis. Öffne den Datenstream in Google Analytics und prüfe die Einstellung, wenn automatische Ereignisse trotz passender Website-Aktion fehlen.

Eine Registrierung, eine Anfrage oder ein Kauf muss von deiner Website nach erfolgreicher Aktion gemeldet werden. Der technische Ereignisname muss exakt stimmen. Der dataLayer ist dafür die Ereignisliste im Browser; ein passendes Tag verarbeitet den Eintrag.

SignalHost richtet die Tags für 16 Geschäfts- und Shop-Ereignisse automatisch ein. Zusätzlich stehen fünf feste Namen für eigene Aktionen zur Verfügung. Prüfe den Einrichtungsstatus deines Containers, bevor du die Ereignisse testest:

• Neun Shop-Ereignisse: view_item_list, view_item, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info und purchase. Die passenden Produkt- und Bestelldaten stehen im ecommerce-Objekt.
• Fünf Ereignisse für Anfragen und weitere Geschäftsaktionen: generate_lead, contact, schedule, submit_application und subscribe.
• Zwei Ereignisse für Registrierung und Testphase: sign_up und start_trial.

Shopify und WooCommerce benötigen eine passende App, ein Plugin oder eigenen Code, der diese Aktionen meldet. Auf Shopify kommen Checkout-Ereignisse zusätzlich aus einem Custom Pixel. Für andere Aktionen kannst du die vorbereiteten Namen custom_event_1 bis custom_event_5 verwenden. Ein eingerichtetes Tag erkennt die Aktion nicht selbst; die Website muss sie melden.

Unter „Unterstützte Ereignisse“ auf der Karte „Ereignisse“ findest du Namen, Erklärungen und Beispiele. SignalHost berücksichtigt geeignete vorhandene Tags, statt sie unnötig zu ergänzen. Ist die Zuordnung nicht eindeutig, erscheint ein Prüfhinweis. Vorhandene Konfigurationen werden nicht ungeprüft ersetzt.

Die aggregierte Ereigniszählung speichert Namen und Anzahlen pro Tag bis zu 400 Tage. Dieser Zähler enthält keine Besucher-URL, Client-ID oder vollständigen Ereignisparameter. Welche historischen Zeiträume du aufrufen kannst, hängt von deinem Tarif ab. Detaillierte Statistiken und die kurzzeitig verfügbare Live-Ereignisansicht sind davon getrennte Auswertungen.

Unterschiedliche Ereignisse müssen nicht gleich häufig sein. Zehn Seitenaufrufe und zwei Scrollereignisse können beispielsweise bedeuten, dass nur bei zwei Aufrufen die Scrollschwelle erreicht wurde. Die Ereignisse messen verschiedene Aktionen und Bedingungen.

Im Advanced-Modus können Google-Tags auch ohne erteilte Einwilligung Messsignale ohne Cookies senden. Bei einer bewussten Blockierung im Basic-Modus lädt das Snippet vorher nicht. SignalHost trennt die aufgezeichneten Einwilligungszustände; ältere Daten ohne diese Aufzeichnung bleiben unbekannt. session_start und first_visit werden dagegen erst in Analytics berechnet und erscheinen hier nicht als eigene Ereignisnamen.

Die Checkliste zeigt, welche vorbereiteten Ereignisse SignalHost im ausgewählten Zeitraum bereits empfangen hat. Ein fehlendes Häkchen ist ein Ausgangspunkt für die Prüfung, aber kein Beweis für einen Fehler: Die betreffende Aktion muss in diesem Zeitraum auch stattgefunden haben.

Prüfe zuerst den Eingang bei SignalHost und danach die Verarbeitung im Zielsystem. Das sind zwei getrennte Schritte.

Fehlt der Name in SignalHost, kontrolliere zunächst den Zeitraum. Führe anschließend die Aktion auf deiner Website aus und prüfe Snippet und Cookie-Banner. Bei automatischen Ereignissen kontrollierst du die optimierten Analysen; bei selbst gemeldeten Aktionen den exakten dataLayer-Namen und das zugehörige Tag.

Ist das Ereignis in SignalHost sichtbar, ist sein Eingang bestätigt. Damit sind Weiterleitung, Verarbeitung und Darstellung in Analytics noch nicht nachgewiesen. Prüfe Mess-ID, Datenstream, Einwilligung, Filter und Berichtsauswahl. Verwende bei passender Debug-Einrichtung die DebugView und berücksichtige Verarbeitungszeiten.

Du richtest gerade deinen ersten Container ein? So richtest du serverseitigen Google Tag Manager Schritt für Schritt ein.