Hunor.digital
← All writing
GA4 · Tracking

A sane GA4 event naming convention you can steal

snake_case, verb first, parameters documented, convention enforced in review. The naming rules I use on client properties, with the reasoning, so you can adopt them in an afternoon.

Lázár HunorDigital Fixer
↑ Part of Tracking implementation and the dataLayer, done properlyLast reviewed 05 Jul 2026
The short answer

Use snake_case, English, present tense verbs, and verb_object order for GA4 events: select_plan, submit_lead_form, view_pricing. Keep parameters snake_case too, reuse GA4's recommended events where they exist, and write the convention down in one shared document that code review actually enforces. Consistency beats cleverness; a mediocre convention applied everywhere outperforms a perfect one applied sometimes.

Every messy GA4 property I have ever audited had the same root disease: three naming conventions living in one property. Not zero conventions. Three. Each one was somebody's good idea, each was half-applied, and together they turned the event list into a junk drawer where generate_lead, Lead, and form_submit_new all mean the same thing and no report can be trusted without a forensic session first.

So here is the convention I apply on client properties. It is not clever. That is the point.

The rules

  1. snake_case, always. GA4 event names are case sensitive: sign_up and Sign_Up are two different events that will split your data. Lowercase with underscores removes the entire class of error.
  2. English, always. Even if your team speaks Hungarian or German internally. Mixed-language properties age terribly and confuse every future contractor.
  3. Verb first, present tense: view_pricing, select_plan, submit_lead_form, start_trial. The verb answers "what did the user do", which is the question every report starts with.
  4. Reuse Google's recommended events before inventing your own. purchase, add_to_cart, generate_lead, login and the rest come with built-in reporting and, in some cases, machine learning benefits. Invent a synonym and you lose that for nothing.
  5. No redundant prefixes. Not click_button_cta_click. The event's parameters carry the context; the name carries the action.
  6. Parameters are snake_case too, and every custom one is documented: name, type, example value, which events send it. Parameters are where naming chaos hides after you clean up the event names.
  7. One shared document, one owner. The convention that lives in someone's head is not a convention. It is a preference, and it leaves when they do.

Why these exact choices

Case sensitivity is the quiet killer, so rule one does the most work. The verb-first order is for sorting: when your event list is alphabetical, all the view_ events cluster together, all the submit_ events cluster together, and gaps become visible. You notice you track submit_lead_form but never view_lead_form, and that asymmetry is usually a measurement plan bug.

Reusing recommended events matters more than people think. GA4 treats certain names as meaningful: purchase populates e-commerce reporting, generate_lead feeds lead reporting. A custom synonym is invisible to all of it. Check Google's current list of recommended events before you name anything; it grows over time, and the current version is always in their documentation.

And know the hard limits: event names have a length cap, there are quotas on distinct custom events and on custom dimensions you can register, and both are documented by Google. I am deliberately not quoting the exact numbers here because Google adjusts them; look them up the week you implement. The convention above keeps you comfortably inside every quota I have met in practice, because it produces fewer, better events.

The part everyone skips: enforcement

A convention document that nothing enforces converges on chaos at the speed of your hiring. Three mechanisms actually work:

What to do with the existing mess

Do not rename historical events for cosmetics. GA4 does not retroactively merge them; you would just add a third name to the pile and break every comparison with last year. Instead:

  1. Write the convention first, as if the property were new.
  2. Apply it to all new events from today.
  3. Migrate old events only when you touch them anyway, and run old and new in parallel for a full reporting cycle before deleting the old push.
  4. Keep a mapping table (old name, new name, switch date) in the spec so future-you can read a year-over-year report without guessing.

Steal it and move on

Naming is a solved problem. The convention above is free, takes an afternoon to adopt, and pays back every week in reports you do not have to decode. The harder question is usually whether the events themselves are the right ones, and whether they actually fire with the right values on the pages your customers use. That is a verification problem, not a naming problem, and I wrote up the exact procedure in how to check if your GA4 tracking actually works. If the audit turns up more wrong than you have capacity to fix, that is the moment to bring in outside help for a week, not a quarter.