27 October 2026·4 min read
Event naming rules — snake_case, reserved names, non-English names
Your event list has Purchase and purchase in it, a name with a space, and one written in Korean. What GA4 actually forbids, what it merely does not recommend, and what you give up when you rename an event that already has history.
Symptom
You open Reports → Engagement → Events and the list reads like this.
purchase
Purchase
상품구매완료
add to cart
btnClick_main
addToCart
Different names, added at different times, by different people, under different rules. Ask how many purchases there were and the answer arrives split across two rows, and the person who joined last month has no way to tell which one is real.
What GA4 actually forbids
Start by separating the rules from the preferences. This is what Google's documentation states.
- A name must start with a letter, use only letters, numbers and underscores, and contain no spaces. So
add to cartand2step_signupare outside the rules. - Names are case-sensitive. The documentation says
my_eventandMy_Eventare distinct events.purchaseandPurchaseabove are not one action split in half; as far as GA4 is concerned they are strangers. - Names are limited to 40 characters. The documentation adds a consequence here: mark an event longer than 40 characters as a key event and the
_cthat gets appended goes missing, so the event is not reported as a key event. A long name is not a cosmetic problem, it is a conversion that disappears. - Some names are reserved. On web streams you cannot use the names that automatic collection and enhanced measurement already use —
page_view,click,scroll,session_start,first_visit,user_engagement,form_start,form_submit,file_download,video_start,view_search_resultsand others. The reserved prefix on web streams isquery_id.
What GA4 does not forbid — non-English names
Here is a myth worth ending. An event name in Korean does not break any GA4 rule. Google's documentation says plainly that event names can include English and non-English words and letters. 상품구매완료 is not dropped or rejected.
We still treat it as a deduction, and not because GA4 blocks it. Because people and tools trip over it.
- One non-English name almost never stays alone. The property ends up with two conventions running side by side —
purchaseand상품구매완료— and the next person does not know which to follow. - GA4's own standard events (
purchase,add_to_cart,sign_up) are all lowercase snake_case, and ecommerce reporting and recommended-event behaviour hang off those exact names. Using a different name where a standard one would fit means giving up what GA4 already built for you. - Names are handled as strings everywhere downstream: search, filters, exports. When the spelling wobbles, all of those wobble slightly too.
So our check compares custom event names against ^[a-z][a-z0-9_]*$. GA4's automatically collected and recommended events are excluded from the denominator — only the events you named yourself are counted. Above 10% violations the deduction starts, and above 30% the item scores zero. One or two names are survivable; half the list wobbling means the property was accumulated rather than designed.
How to check in GA4
Put the event list from Reports → Engagement → Events on one screen and look for four things.
- Pairs that differ only in case —
Purchase/purchasesit next to each other in the list. - Spaces, capitals and hyphens — these are outside the rules, so they go first.
- Two names for one action —
add_to_cartandaddToCart,purchaseand상품구매완료. This is a naming problem that grows into a duplicate collection problem. - Long names — count the characters on anything approaching 40, especially if it is meant to be a key event.
How to fix it
Apply the rule to new events first. The rule itself does not need to be elaborate. Lowercase snake_case, verb_noun (view_item, submit_form), and always the GA4 standard name where one exists — three lines is enough. A single page everyone reads before building a tag outlasts a perfect taxonomy nobody maintains.
Be careful with names that already have history. GA4 can rename incoming events through its modify-event feature (Admin → Data display → Events). But Google's documentation states that modified events do not apply to previously collected data. The moment you rename, the record of one action is split between the old name and the new one, and nothing in reporting will merge them back.
So check three things before renaming.
- Is the name registered as a key event? The registration has to be redone under the new name.
- Is it wired into audiences, custom dimensions, or ad platform conversions? Those have to move on the same day.
- Did you write down when you changed it? That note is the only thing that will explain the step in the chart a few months from now.
If a name is used in one place and wired into nothing, renaming today is as cheap as it will ever be. If three years of data hang off it, writing "historical exception" next to it in the convention doc is a perfectly defensible choice.
In one line
GA4 only blocks spaces, a bad first character, 40-plus characters and reserved names; the rest is a promise you make to yourselves. Remembering that different case means a different event will clean up half the list on its own. And since renaming is not retroactive, if you are going to do it, today is the cheapest day.