Wie eine Event-Naming-Konvention ihre erste Umbenennung übersteht

Warum zählt eine Event-Naming-Konvention?

Sich am ersten Tag für eine Event-Naming-Konvention zu entscheiden ist billig und am zweihundertsten Tag teuer, denn Google Analytics 4 wendet eine Umbenennung nie auf bereits erfasste Daten an. Jeder inkonsistente Name, den Sie ausliefern, wird zu einer dauerhaften zweiten Zeile in jedem Bericht, der nach Ereignis gruppiert, und der einzige Weg, diese Zeilen im Nachhinein zusammenzuführen, ist, die Daten selbst in einem Warehouse neu zu berechnen.

Der Fehler ist weder theoretisch noch ordentlich. Drei Entwickler instrumentieren denselben Button über drei Sprints, und Sie bekommen signup_click, SignupClick und click_signup. GA4 behandelt alle drei als getrennte Ereignisse, denn "event names are case sensitive. For example, my_event and My_Event are distinct events." Ihr Funnel teilt sich dreifach, Ihre Zahl der Schlüsselereignisse ist ein Drittel der Wahrheit, und niemand merkt es, bis jemand das Dashboard mit Stripe vergleicht. Die breitere Disziplin behandelt Event-Tracking; diese Seite handelt von den Namen selbst.

Welche Namen lehnt GA4 rundweg ab?

GA4 lehnt reservierte Namen und reservierte Präfixe ab, und Googles Regeln zur Ereignisbenennung nennen die Folge klar: "If you try to use a reserved prefix or name, Analytics will display an error message." Die Regeln, die für jeden Namen gelten, sind kurz:

• "Event names must start with a letter. Use only letters, numbers, and underscores. Don't use spaces."
• "Event names are case sensitive."
• "Event names can include English and non-English words and letters."

Für Web-Datenstreams reserviert Google query_id als Präfix und reserviert neunzehn Ereignisnamen rundweg. Die, die ein Implementierungsteam treffen, sind die plausibel klingenden, nach denen Sie ganz natürlich greifen würden:

Im Web reserviert	Warum Sie danach gegriffen hätten
click	Der naheliegende Name für jeden Klick-Handler
error	Der naheliegende Name für einen clientseitigen Fehler
scroll	Der naheliegende Name für ein Scrolltiefen-Ereignis
file_download	Der naheliegende Name für einen PDF-Download
page_view	Der naheliegende Name für einen virtuellen Seitenaufruf in einer Single-Page-App
session_start	Der naheliegende Name für ein Gegenstück zum App-Start
user_engagement	Der naheliegende Name für ein Verweildauer-Ereignis
video_start	Der naheliegende Name für ein Player-Ereignis
ad_impression	Der naheliegende Name für einen eigenen Anzeigenplatz

Die meisten davon werden Ihnen bereits durch Enhanced Measurement gesendet, und deshalb sind sie reserviert. Prüfen Sie, was Ihre Property ohne Konfiguration erfasst, bevor Sie irgendetwas benennen, und sehen Sie Autocapture dazu, was automatische Erfassung erwischt und was nicht.

Die Referenz zum Measurement Protocol ergänzt eine zweite, längere Liste, die gilt, wenn Sie Ereignisse serverseitig senden, darunter first_open, first_visit, app_exception, os_update und die gesamte firebase_-Familie, und hält fest, dass "ad_impression, in_app_purchase and screen_view events are only allowed for App streams."

Parameter tragen ihre eigenen Reservierungen. Der Name firebase_conversion ist reserviert, und Parameternamen "cannot begin with" _, firebase_, ga_, google_ oder gtag.. Namen von Nutzereigenschaften dürfen nicht mit _, firebase_, ga_ oder google_ beginnen, und die Namen first_open_time, first_visit_time, last_deep_link_referrer, user_id und first_open_after_install sind vergeben.

Welche Längenbegrenzungen gelten?

Vierzig Zeichen für den Ereignisnamen, und die Strafe fürs Überschreiten ist seltsamer als eine schlichte Ablehnung. Googles Limits zur Ereigniserfassung nennen für einen Ereignisnamen "40 characters" und ergänzen dann: "If you mark an event as a key event and the event exceeds 40 characters, then the event will not be reported as a key event because the appended _c will be missing." Das Ereignis wird weiterhin erfasst. Es hört nur still auf, als Schlüsselereignis zählbar zu sein, weil GA4 intern _c anhängt und der angehängte Name überläuft.

Die umgebenden Limits formen eine Konvention genauso stark wie das Namenslimit:

Limit	Wert
Länge des Ereignisnamens	40 Zeichen
Verschiedene Ereignisnamen, Web-Stream	Kein Limit
Verschiedene Ereignisnamen, App-Stream	500 pro App-Nutzer
Ereignisparameter pro Ereignis	25
Länge des Parameternamens	40 Zeichen
Länge des Parameterwerts	100 Zeichen
Wert von page_title	300 Zeichen
Wert von page_referrer	420 Zeichen
Wert von page_location	1.000 Zeichen
Nutzereigenschaften pro Property	25
Länge des Namens einer Nutzereigenschaft	24 Zeichen
Länge des Werts einer Nutzereigenschaft	36 Zeichen

Der Parameterwert von 100 Zeichen ist der, der Teams erwischt. Ein Produktname, eine Suchanfrage oder ein Formularfehlertext überschreitet ihn, und der Wert wird gekürzt statt das Ereignis abgelehnt. Der Name einer Nutzereigenschaft mit 24 Zeichen ist noch enger und um sechzehn Zeichen kürzer als das Limit für Ereignisnamen, was ein guter Grund ist, Ereignisnamen nicht in Namen von Nutzereigenschaften zu spiegeln.

Die unbegrenzte Zahl verschiedener Ereignisse im Web ist eine Falle, keine Erlaubnis. Nichts hindert Sie daran, vierhundert Ereignisnamen auszuliefern; die Berichte werden dadurch schlicht unbrauchbar, und jeder muss als benutzerdefinierte Definition registriert werden, bevor er in den meisten Auswertungen erscheint. Diesen Registrierungsaufwand behandelt benutzerdefinierte Dimensionen einrichten.

Sollte das Objekt oder die Aktion zuerst kommen?

Der verbreitete Rat lautet Objekt zuerst, cart_added und video_played, mit der Begründung, dass Berichte alphabetisch sortieren und objektzuerst gebildete Namen alle Ereignisse zur selben Sache zusammenlegen. Das ist ein guter Rat, und er widerspricht Google.

Googles empfohlene Ereignisse stellen die Aktion voran. Allein das Retail-Set liest sich als add_payment_info, add_shipping_info, add_to_cart, add_to_wishlist, begin_checkout, purchase, refund, remove_from_cart, select_item, view_item, und das allgemeine Set ergänzt earn_virtual_currency, join_group, login, search, select_content, share, sign_up, spend_virtual_currency, tutorial_begin und tutorial_complete.

Das zählt, weil empfohlene Ereignisse nicht kosmetisch sind. Google beschreibt sie als "standardized events for different business verticals (e.g., retail, travel, games) that unlock prebuilt reporting panels," während benutzerdefinierte Ereignisse "events that you define yourself because no prepopulated automatic, enhanced, or recommended event fits your needs" sind und "accessible using custom reports". add_to_cart aus interner Konsistenz in cart_added umzubenennen kostet Sie die vorgebauten E-Commerce-Berichte.

Die praktikable Regel trennt daher nach Herkunft, nicht nach Geschmack. Nutzen Sie Googles Schreibweise überall dort, wo ein empfohlenes Ereignis existiert, genau wie veröffentlicht, und wenden Sie Ihr eigenes Objekt-zuerst-Muster nur auf Ereignisse an, die Google nicht definiert. Eine Konvention, die add_to_cart neben pricing_table_viewed erzeugt, sieht auf dem Papier inkonsistent aus und ist die einzige Fassung, die sowohl die Berichte als auch die Sortierreihenfolge erhält. Welche Reihenfolge Sie auch wählen, snake_case mit Kleinbuchstaben ist die einzige Schreibweise, die der Falle mit der Groß- und Kleinschreibung entgeht, denn eine Konvention, in der jedes Zeichen in der Schreibweise variieren kann, wird irgendwann verletzt.

Reihenfolge des Ereignisnamens wählen

1

Liste der empfohlenen Ereignisse prüfen. Prüfen, ob Google für das, was Sie messen, bereits ein Ereignis definiert, etwa add_to_cart oder begin_checkout.

2

Übereinstimmung gefunden. Googles exakte Schreibweise verwenden, Aktion zuerst, um die vorgefertigten E-Commerce-Berichte zu behalten.

3

Keine Übereinstimmung. Eigenes objekt-first-Muster aus einer festen Liste von Verben und Objekten anwenden.

Was kostet das Umbenennen eines Ereignisses nach dem Start?

Es kostet Sie Historie, dauerhaft, und einen von fünfzig Plätzen. Googles Dokumentation zum Umbenennen von Ereignissen ist beim ersten Teil eindeutig: "Modified and new events do not apply to historical data." Die Änderung schreibt Ereignisse nur ab jetzt um. Jede Zeile, die bereits in der Property liegt, behält den alten Namen, und es gibt keine Neuverarbeitung, die das repariert.

Zwei weitere Einschränkungen stehen daneben. "An hour or more passes before modifications take effect," die Korrektur greift also selbst nach dem Vornehmen nicht sofort. Und "you can modify up to 50 existing events and create up to 50 events based on existing events," was bedeutet: Die Änderungsfunktion ist ein Reparaturset, keine Namensschicht, auf die Sie sich unbegrenzt stützen können.

Der praktische Preis einer Umbenennung ist damit:

• Eine dauerhafte Trennung in jedem Bericht, der nach Ereignisnamen gruppiert, am Tag der Änderung.
• Jede Definition eines Schlüsselereignisses, jede Zielgruppe und jeder Funnel, die den alten Namen nutzen, müssen auf den neuen dupliziert werden, sonst hören sie auf zu zählen. Den Unterschied zwischen den zwei Konzepten legt Schlüsselereignisse gegen Conversions dar.
• Jahresvergleiche über die Grenze hinweg müssen von Hand zusammengesetzt werden.
• Einer von fünfzig Änderungsplätzen, belegt so lange, wie der alte Name noch aus einer gecachten Seite oder einem nicht ausgelieferten App-Build eintrifft.

Nichts davon lässt sich mit mehr Geld oder mehr Geduld zurückholen, und das ist das ganze Argument dafür, einen Nachmittag in das Namensdokument zu stecken, bevor das erste Tag live geht.

Wie sieht eine funktionierende Konvention aus?

Eine Konvention besteht aus vier aufgeschriebenen Entscheidungen, nicht aus einer Namensliste. Treffen Sie jede einmal, und die Liste erzeugt sich selbst.

Schreibweise: nur kleingeschriebenes snake_case, für Namen wie für Parameter. Buchstaben, Zahlen und Unterstriche sind ohnehin alles, was GA4 akzeptiert, und Kleinschreibung entfernt den einzigen Weg, auf dem zwei identische Ereignisse auseinanderlaufen können.

Vokabular: eine geschlossene Liste von Verben und eine geschlossene Liste von Objekten. view, select, add, remove, submit, start, complete deckt die meisten Websites ab. Zwei Verben mit derselben Bedeutung sind der Weg, auf dem signup_submit und signup_complete beide in Produktion landen.

Reihenfolge: Googles Schreibweise, wo ein empfohlenes Ereignis existiert, Objekt zuerst überall sonst, und die Ausnahme ins Dokument geschrieben, damit der nächste Entwickler sie nicht still wegnormalisiert.

Platzierung der Details: variables Detail gehört in Parameter, nie in den Namen. form_submit mit einem Parameter form_name ist ein Ereignis, das Sie filtern können; newsletter_form_submit, contact_form_submit und demo_form_submit sind drei Ereignisse, die Sie ohne einen Bericht je Formular nicht vergleichen können, und sie verbrennen drei Ihrer Registrierungen für benutzerdefinierte Definitionen statt einer.

Länge: Halten Sie Namen mit Puffer unter 40 Zeichen, denn die Strafe beim Schlüsselereignis hängt _c an das an, was Sie gewählt haben, und der Fehler bleibt stumm.

Häufig gestellte Fragen

Welche Zeichen darf ein GA4-Ereignisname enthalten?

Buchstaben, Zahlen und Unterstriche, und der Name muss mit einem Buchstaben beginnen. Google formuliert die Regel als "Event names must start with a letter. Use only letters, numbers, and underscores. Don't use spaces." Nicht englische Buchstaben sind erlaubt: "Event names can include English and non-English words and letters."

Unterscheiden GA4-Ereignisnamen Groß- und Kleinschreibung?

Ja. Googles Benennungsregeln halten fest, dass "event names are case sensitive. For example, my_event and My_Event are distinct events." Es gibt keinen Normalisierungsschritt, also erzeugen zwei Schreibweisen desselben Ereignisses zwei unabhängige Zeilen in jedem Bericht, der nach Ereignisnamen gruppiert.

Was passiert, wenn ich einen reservierten Ereignisnamen sende?

Analytics lehnt ihn ab und zeigt einen Fehler. Die Regeln zur Ereignisbenennung sagen, dass "if you try to use a reserved prefix or name, Analytics will display an error message." Reservierte Namen im Web sind unter anderem click, error, scroll, file_download, page_view, session_start, user_engagement und video_start.

Soll ich object_action oder action_object nutzen?

Nutzen Sie Googles exakte Schreibweise für dessen empfohlene Ereignisse, die die Aktion voranstellen, und Objekt zuerst für alles andere. Googles empfohlenes Set enthält add_to_cart, begin_checkout, select_item und view_item, und diese umzubenennen verwirkt die vorgebauten Berichtspanels, die Google daran hängt.

Kann ich ein GA4-Ereignis nach dem Start umbenennen?

Sie können es für die Zukunft umbenennen und nie rückwirkend. Google erklärt, dass "modified and new events do not apply to historical data," dass "an hour or more passes before modifications take effect," und dass Sie "can modify up to 50 existing events and create up to 50 events based on existing events."

Wie lang darf ein GA4-Ereignisname sein?

40 Zeichen. Ein Überschreiten hat eine bestimmte Folge über die Ablehnung hinaus: Google warnt, dass "if you mark an event as a key event and the event exceeds 40 characters, then the event will not be reported as a key event because the appended _c will be missing."

Was passiert, wenn ein Team uneinheitliche Ereignisnamen verwendet?

GA4 behandelt jede Schreibweise als eigenes Ereignis, weil Ereignisnamen zwischen Groß- und Kleinschreibung unterscheiden. Wenn drei Entwickler denselben Button als signup_click, SignupClick und click_signup benennen, entstehen drei getrennte Zeilen in jedem Bericht, der Funnel spaltet sich dreifach auf, und die Zahl der Key Events sinkt auf ein Drittel des tatsächlichen Werts. Meist fällt das erst auf, wenn jemand das Dashboard mit einer anderen Datenquelle wie Stripe vergleicht.

Gibt es eine Begrenzung, wie viele Ereignisnamen ich an GA4 senden kann?

Ein Web-Stream kennt keine Obergrenze für die Anzahl unterschiedlicher Ereignisnamen, aber genau das spricht gegen Sie statt für Sie. Ereignisnamen erscheinen von selbst, aber jeder Parameter, den Sie anhängen, braucht einen Platz für benutzerdefinierte Definitionen, sodass vierhundert Namen nur Berichte bringen, die niemand mehr lesen kann. Ein App-Stream begrenzt die Zahl dagegen auf 500 pro App-Nutzer.

Was unterscheidet ein benutzerdefiniertes Ereignis von einem empfohlenen Ereignis?

Ein empfohlenes Ereignis ist einer von Googles standardisierten Namen für eine Branche wie Einzelhandel oder Reisen, und laut Google schaltet es vorgefertigte Berichtspanels frei. Ein benutzerdefiniertes Ereignis definieren Sie selbst, weil keines der automatischen, erweiterten oder empfohlenen Ereignisse passt, und es erscheint nur in eigens erstellten Berichten. Wer add_to_cart aus Konsistenzgründen in cart_added umbenennt, verliert das dazugehörige vorgefertigte Panel.

Zählen Key Events weiter, nachdem ich das zugehörige Ereignis umbenannt habe?

Nicht automatisch. Jede Key-Event-Definition, Zielgruppe oder jeder Funnel, der auf den alten Namen verwies, muss auf den neuen Namen dupliziert werden, sonst zählt er ab dem Zeitpunkt der Umbenennung nicht mehr. Diese Duplizierung kostet keinen Änderungsplatz, nur die Umbenennung selbst verbraucht einen der fünfzig, die GA4 erlaubt.