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.
What this means
Create event lets you define a new event that GA4 generates whenever an existing event matches conditions you set — for example, create a 'purchase_high_value' event when purchase has value above a threshold, or rename a legacy event to a new convention. Modify event changes events as they are processed: rewriting a parameter value, renaming an event, or correcting a taxonomy mistake, all from the admin UI.
Order, scope, and limits
Modify-event rules are applied in order and before create-event rules in processing, so the sequence matters when rules interact. These features operate on incoming data going forward — they do not retroactively rewrite historical events. There are limits on the number of rules and the conditions available. Crucially, they cannot un-collect personal data: if PII reached the parameter, the only real fix is to stop sending it at the source.
- Create event derives a new event from a match
- Modify event rewrites names/params in processing
- Forward-only, ordered, and rule-count limited
How it appears in analytics and logs
An event you never instrumented appearing in reports may be a create-event rule; an event whose parameters differ from what you send may be reshaped by a modify-event rule.
Diagnostic use case
Fix or extend your event taxonomy in the GA4 UI — renaming, merging, or deriving events — without waiting on a code deploy.
What WebmasterID can help detect
WebmasterID favours getting event names right at collection; the same outcome these UI rules chase is achieved with a clean, stable event vocabulary from the start.
Common mistakes
- Expecting these rules to fix historical data retroactively.
- Using modify event to 'clean' PII instead of fixing collection.
- Ignoring rule order when modify and create rules interact.
Privacy and accuracy notes
These rules reshape events but do not sanitise personal data already in them — the fix for PII is at collection, not via modify event. This is educational, not legal advice.
Related pages
- 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.
- 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.
- Key events vs conversions in GA4
In 2024 GA4 renamed its measurement concept of 'conversions' to 'key events', while 'conversions' became the term used in Google Ads bidding. A key event is an event you mark as important in GA4; a conversion is how Ads counts it for optimisation. They can differ. This page explains the terminology shift, why it reduces confusion across products, and how to mark and read key events.
- Event Explorer
See events as collected and reshaped.
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.