Reserved and restricted event names
GA4 reserves a set of event names, parameter names, and user-property names for its own use, plus reserved prefixes you cannot start your own names with. Reusing a reserved name (like a built-in event) or a reserved prefix (like ga_, google_, firebase_) causes the event to be dropped or mishandled. Knowing the restricted list keeps your custom events from silently failing.
What this means
GA4 maintains lists of reserved event names (such as the automatically collected and certain built-in events), reserved parameter names, and reserved user-property names that you cannot create yourself. It also reserves prefixes: names beginning with ga_, google_, or firebase_ are off-limits for custom events, parameters, and user properties. Using a reserved name or prefix means GA4 will not record your custom version as intended.
Why it matters
If you name a custom event the same as a reserved one, or start a parameter with a reserved prefix, the platform either ignores it, drops it, or applies its own meaning — and your data quietly never arrives. Because there is no loud error, this is easy to miss for weeks. Check a candidate name against GA4's reserved lists before rolling it out, and prefer clearly custom, descriptive names that cannot collide.
- Reserved event, parameter, and user-property names exist
- Reserved prefixes: ga_, google_, firebase_
- Collisions are dropped or overridden, often silently
How it appears in analytics and logs
A custom event that never appears in reports may be using a reserved name or prefix — GA4 ignores or overrides those rather than recording your version.
Diagnostic use case
Name custom events, parameters, and user properties safely by avoiding GA4's reserved names and prefixes, so nothing is silently dropped.
What WebmasterID can help detect
WebmasterID's event vocabulary uses clear, non-reserved semantic names, avoiding collisions with platform-reserved identifiers by convention.
Common mistakes
- Reusing a built-in event name for a custom event.
- Starting a parameter name with ga_, google_, or firebase_.
- Assuming a dropped event would raise a visible error.
Privacy and accuracy notes
Reserved-name rules are about data integrity, not privacy, but the usual rule still applies: never put personal data in any name regardless of whether it is reserved. This is educational, not legal advice.
Related pages
- Event naming conventions
An event naming convention is the agreed rule for what events are called: the case, the separators, and the vocabulary. It sounds trivial but it is the difference between clean analytics and a fragmented mess where signup, sign_up, and SignUp count as three things. This page covers the conventions that work, reserved names to avoid, and why a documented taxonomy matters more than any single rule.
- Recommended vs custom events
GA4 events come in three tiers: automatically collected, recommended, and custom. Automatic events fire without setup; recommended events have Google-defined names and parameters that unlock standard reports; custom events are ones you invent. The practical rule is to prefer a recommended name whenever one fits, because custom names miss out on prebuilt dimensions, reports, and predictive features.
- Create event and modify event in GA4
Create event and modify event are GA4 admin features that let you derive new events from existing ones, or alter incoming events, entirely in the interface — no code changes or redeploys. Create event builds a new event when conditions match; modify event changes parameters or names of events as they are processed. They are powerful for fixing taxonomy after the fact, within documented limits.
- Events reference (docs)
Naming conventions for WebmasterID events.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.