Jedes GA4-Ereignis, das Ihr Server-Container sieht – und woher jedes einzelne kommt

Sobald das Google-Tag mit Ihrer Mess-ID lädt, fließen vier Ereignisse ohne jede Einstellung dahinter. Nichts in Analytics schaltet sie ab, und nichts in Ihrem Container muss sie anfordern.

• page_view – einmal pro Seitenaufruf, beziehungsweise pro Routenwechsel in einer Single-Page-App, wenn die Option „Seitenänderungen“ des Streams aktiv ist.
• session_start – der erste Treffer einer neuen Sitzung. Eine Sitzung endet nach dreißig Minuten Inaktivität; ein Besucher, der zwei Stunden später zurückkommt, startet eine neue.
• first_visit – einmal pro Browser, in der allerersten Sitzung, die GA4 von ihm gesehen hat. Gelöschte Cookies erzeugen ein weiteres.
• user_engagement – gesendet, wenn die Seite zehn Sekunden im Vordergrund war, oder wenn der Besucher nach einer Interaktion geht. Daher stammt die Interaktionsdauer in GA4.

Wenn Sie page_view und sonst nichts sehen, funktioniert das Tag. Das ist kein Fehler – es ist eine Website, auf der noch niemand bis ganz nach unten gescrollt hat.

Die optimierten Analysen von GA4 erfassen neun weitere Ereignisse im Browser, ohne ein Tag für eines davon. Sie werden am Datenstream konfiguriert, nicht im Tag Manager – deshalb leitet ein Server-Container sie weiter, ohne von ihrer Existenz zu wissen.

Jedes hat eine Bedingung, die strenger ist, als der Name vermuten lässt.

• scroll – einmal pro Seite, und nur wenn 90 % der Seitenhöhe sichtbar waren. Nicht bei irgendeinem Scrollen: beim Erreichen des Endes. Eine Seite, die kürzer als der Viewport ist, löst es nie aus.
• click – ein ausgehender Klick auf eine andere Domain als die aktuelle. Interne Links zählen nicht. Das Ereignis heißt click, mit einem outbound-Parameter; ein outbound_click gibt es nicht.
• view_search_results – ein Seitenaufruf, dessen URL einen Suchparameter trägt (standardmäßig q, s, search, query oder keyword).
• file_download – ein Klick auf einen Link, der auf eine Dokument-, Archiv-, Audio-, Video- oder Tabellenendung endet.
• form_start und form_submit – die erste Interaktion mit einem Formular auf der Seite und dessen Absenden.
• video_start, video_progress und video_complete – nur für eingebettete YouTube-Player, und nur wenn die Einbettung die JS-API aktiviert hat.

Und jetzt der Teil, der Leute Wochen kostet. Jedes dieser neun Ereignisse hängt am Hauptschalter der optimierten Analysen des Streams – und ein Stream, der über die Analytics Admin API angelegt wurde statt in der Analytics-Oberfläche, hat diesen Schalter AUS. Liest man die Einstellungen über die API, meldet jeder einzelne Unterschalter true; der Hauptschalter fehlt in der Antwort schlicht, weil er false ist und die API false-Booleans weglässt. Die Einrichtung sieht also vollständig aktiviert aus und liefert nur page_view.

Wir haben das auf unserer eigenen Property gefunden. SignalHost schaltet den Hauptschalter ein, wenn wir eine Property für Sie anlegen; wurde Ihre anderweitig erstellt und scroll kommt nie an, öffnen Sie den Datenstream in Analytics und prüfen Sie „Optimierte Analysen“ selbst – nicht die Schalter darunter.

Die Commerce-Ereignisse – view_item_list, view_item, add_to_cart, remove_from_cart, begin_checkout, add_payment_info und purchase – sind die, die einen Shop wirklich interessieren, und die einzigen auf dieser Seite, die nichts automatisch sendet. GA4 definiert Namen und Form; Ihre Website muss jedes davon in den dataLayer pushen, unter genau diesem Namen, mit einem ecommerce-Objekt dazu.

Ein Standard-Shopify-Theme tut das nicht. WooCommerce im Kern tut das nicht. Eine dataLayer-App oder ein Plugin tut es, und auf Shopify brauchen die Checkout-Ereignisse ein Custom Pixel, weil der Container des Themes auf den Checkout-Seiten nie lädt. Wenn Sie im SignalHost-Assistenten eine Shop-Plattform wählen, installieren wir für jedes der sieben Ereignisse einen Trigger und ein GA4-Ereignis-Tag – sobald Ihre Website purchase pusht, wird es weitergeleitet. Aber den Push müssen Sie einrichten. Der nächste Artikel beschreibt genau, was zu installieren ist.

Jede Messanfrage, die durch Ihren Container läuft, wird nach Ereignisnamen gezählt, pro Tag, 400 Tage lang. Nur der Name wird behalten – nicht die URL, nicht die Client-ID, kein einziger Parameter –, und genau das macht es unbedenklich, ihn so lange aufzubewahren. Die Liste zeigt, was an Ihrem Hostnamen angekommen ist, und beantwortet damit eine Frage, die Analytics selbst nicht beantworten kann: Hat der Browser es überhaupt gesendet?

Rechnen Sie mit ungleichen Zahlen. Jeder Seitenaufruf ist ein page_view; nur Seitenaufrufe, die das Ende erreichen, sind ein scroll; nur Sitzungen über zehn Sekunden ein user_engagement. Eine Website mit zehn Seitenaufrufen und zwei Scrolls ist eine normale Website.

Zwei Fälle, und die Container-Seite unterscheidet sie.

Steht das Ereignis nicht in der Liste des Containers, hat Ihre Website es nie gesendet. Der Container kann nicht weiterleiten, was nicht angekommen ist. Bei einem Standardereignis prüfen Sie den Schalter der optimierten Analysen am Stream; bei einem Commerce-Ereignis prüfen Sie, ob der dataLayer-Push stattfindet, mit dem richtigen Namen, auf der richtigen Seite.

Steht das Ereignis in der Liste des Containers, aber nicht in Analytics, ist es angekommen und wurde weitergeleitet – das Problem liegt auf Googles Seite der Linie: die falsche Mess-ID, ein Datenfilter, eine Property in einem anderen Konto als dem, in das Sie gerade schauen, oder schlicht die Berichtsverzögerung – Echtzeit zeigt es in Sekunden, Standardberichte brauchen bis zu einem Tag.