How an event name works
Every event carries a name saying what happened — page_view, form_submit, purchase. GA4 treats that name as the grouping key: it counts identical names together and keeps different names apart. Nothing clever happens behind the scenes. Two names that a human would read as the same action are, to the platform, two unrelated things.
Names are case sensitive, so an event sent as Purchase and one sent as purchase sit in separate rows forever. They should use lower case with underscores, start with a letter, and avoid spaces and punctuation. A small group of names is reserved by Google for its own automatic events, and a property also has a ceiling on how many distinct names it will accept — not a number most sites approach, but one a badly designed naming scheme can reach surprisingly fast.
Why event names matter
The name is the only handle you have later. Audiences, key events, funnel steps, custom reports and the import into Google Ads all begin by selecting an event name from a list. A name that is vague, inconsistent or duplicated makes every one of those jobs harder, and the fix always involves retagging rather than a setting.
Names also outlive the people who chose them. Whoever inherits the property in a year will read the list without any of the context you had. If it takes explanation to know what click_alt or submit_new means, the naming has failed even if the tracking is technically perfect.
Common mistakes with event names
The biggest is putting the variable detail into the name instead of into a parameter — form_submit_contact, form_submit_quote, form_submit_footer. That produces one row per variant, no way to see the total, and a list that grows every time a page is added. One name, with the variant carried as an event parameter, gives you both the total and the breakdown.
Close behind are near-duplicates created by different people at different times — lead_form, lead-form, leadForm — and inventing a name for something Google already defines. If a recommended name exists for the action, using it unlocks reporting and integrations that a custom name never will.
How to act on it
Agree a convention before tagging: lower case, underscores, verb plus object, the same words used across the whole site. Write the agreed list somewhere the next person will find it, alongside which parameters each name carries. That document is worth more than any dashboard when a site is rebuilt or handed to a new developer.
Check the actual names arriving, not the ones you intended to send, in DebugView or the realtime report. If you are building the tagging plan alongside the site itself, the naming decisions belong with the rest of the Tag Manager configuration, not bolted on afterwards.