Was ist Event-Tracking

Die Maßeinheit ist das Ereignis: ein benannter Eintrag, der beschreibt, dass etwas passiert ist, begleitet von Parametern, die ihn genauer fassen. Wenn jemand den Download-Knopf eines Katalogs drückt, speichert das Werkzeug einen Ereignisnamen und daneben Daten wie den Titel des Dokuments oder den Bereich der Website, aus dem gedrückt wurde.

Drei Dinge, die täglich verwechselt werden, gehören auseinandergehalten. Das Analysewerkzeug ist der Ort, an dem sich die Daten sammeln und gelesen werden. Der Tag-Manager ist das Fahrzeug, das den Code ausliefert, ohne dass jemand das Template anfasst. Der Data Layer ist das Zwischenlager, aus dem dieses Fahrzeug Werte liest. Event-Tracking ist die Entscheidung vor allen dreien: welche Handlungen es wert sind, erfasst zu werden, und unter welchem Namen.

Ein Ereignis ist auch keine Conversion. Jede Conversion wird als Ereignis erfasst, doch die meisten Ereignisse beschreiben Verhalten ohne direkten kommerziellen Wert, etwa das Scrollen über die Seite oder das Abspielen eines Videos. Ein Ereignis als Schlüsselaktion zu markieren, ist ein späterer und bewusster Schritt, den jemand mit betriebswirtschaftlichem Urteil geht.

Google Analytics 4 ordnet Ereignisse vier Gruppen zu. Die automatisch erfassten entstehen allein dadurch, dass das Tag installiert ist. Die der erweiterten Messung erscheinen, sobald diese Option im Datenstream aktiv ist, und decken Scrollen, ausgehende Klicks, interne Suche, Video und Dateidownloads ab. Die empfohlenen setzt das Team selbst um, doch sie tragen von Google festgelegte Namen und Parameter. Die benutzerdefinierten definiert, wer sie umsetzt, mit voller Freiheit beim Namen.

Der Unterschied zwischen den letzten beiden Gruppen spart die meiste Arbeit. Ein empfohlenes Ereignis mit seinem exakten Namen und seinen vorgesehenen Parametern schaltet Berichte frei, die in der Oberfläche bereits existieren: E-Commerce oder Lead-Generierung lassen sich lesen, ohne etwas zu bauen. Wird derselbe Vorgang unter einem erfundenen Namen gesendet, landet das Datum ebenso in der Property, doch kein Standardbericht erkennt es, und jede Auswertung muss von Hand entstehen.

Die dokumentierten Grenzen sind der zweite übliche Stolperstein. Jedes Ereignis nimmt 25 Parameter auf. Der Ereignisname und jeder Parametername dürfen 40 Zeichen nicht überschreiten, und ein Parameterwert wird bei 100 abgeschnitten, mit Ausnahmen für Titel, Adresse und Verweisquelle der Seite. Web-Datenstreams haben keine Obergrenze für unterschiedliche Ereignisnamen; App-Datenstreams schon, mit 500 pro Nutzer. Um einen eigenen Parameter in den Berichten zu lesen, muss er als Dimension registriert werden, und dort verfügt eine Standard-Property über 50 auf Ereignisebene, 25 auf Nutzerebene und 10 auf Artikelebene, dazu 50 benutzerdefinierte Messwerte.

Vom Event-Tracking hängt eine sehr konkrete Entscheidung ab: wohin das Team im nächsten Quartal investiert. Ohne Ereignisse bleibt die Auswertung bei Seitenaufrufen und Sitzungen stehen, die sagen, wie viele Leute vorbeikamen, aber nicht, was sie taten. Mit gut benannten Ereignissen lässt sich beantworten, ob der Produktkonfigurator benutzt wird, ob das lange Formular im dritten Feld abgebrochen wird oder ob die interne Suche leere Ergebnisse liefert.

Es entscheidet auch, was sich in der Werbung optimieren lässt. Gebotsplattformen brauchen ein Qualitätssignal, um zu lernen, und dieses Signal stammt aus einem bestimmten Ereignis. Bekommt die Plattform „Klick auf den Knopf“ statt „Anfrage abgeschickt“, optimiert der Algorithmus auf die falsche Geste, und die Kosten pro echtem Kunden steigen, ohne dass das Dashboard es verrät.

Und es bestimmt, was sich später rekonstruieren lässt. Ein Ereignis, das im März nicht gemessen wurde, kommt im September nicht zurück, weil von dieser Handlung keine historische Spur bleibt. Deshalb wird die Ereignisliste vor dem Start einer Website entschieden und nicht an dem Tag, an dem jemand einen Bericht verlangt.

• Schreib ein Messkonzept, bevor du Code anfasst: eine Tabelle mit dem Ereignis, der Handlung, die es abbildet, seinen Parametern und der Person, die es später im Bericht sehen will.
• Sieh zuerst in der Liste der empfohlenen Ereignisse nach. Gibt es eines für deinen Fall, nimm es mit seinem exakten Namen und seinen vorgesehenen Parametern.
• Leg eine Namenskonvention in Kleinbuchstaben mit Unterstrich fest und wende sie ohne Ausnahme in der gesamten Property an.
• Registriere nur die Parameter als benutzerdefinierte Dimension, die jemand ansehen wird. Die 50 Plätze auf Ereignisebene sind schneller weg, als es aussieht.
• Prüfe jedes neue Ereignis im Debug-Modus vor der Veröffentlichung, und wiederhole die Prüfung mobil.
• Geh die vollständige Liste halbjährlich durch und archiviere, was niemand mehr abruft.

• Alles messen. Jedes Ereignis ohne Verantwortlichen und ohne Frage dahinter ist Rauschen, das sich hinterher niemand zu löschen traut.
• Namen neu erfinden, die es schon gibt, womit die Standardberichte leer bleiben, obwohl die Daten drin sind.
• Die 25 Parameter je Ereignis überschreiten oder bei einem Wert über 100 Zeichen gehen. Das Datum wird verworfen oder still gekürzt.
• Personenbezogene Daten in einen Parameter schreiben, etwa die E-Mail-Adresse oder die Telefonnummer, die jemand in ein Formular getippt hat.
• Ein Ereignis für gut befinden, weil es in Echtzeit auftaucht, ohne am Folgetag zu prüfen, ob es mit vollständigen Parametern ankommt.