Naming Conventions for GA4 Events

Naming feels like the least important decision you'll make when setting up GA4. It isn't. The names you pick on day one are the names you'll be staring at in the Events report two years later, after a dozen new pages, three developers, and a marketing team that fired tracking through whatever felt natural at the time. Good names are quiet: you never think about them. Bad names cost you an afternoon every reporting cycle.

This guide is one opinionated house style. Adopt it whole, write it down, and apply it to every event and parameter you send. The specific rules matter less than the fact that everyone follows the same ones.

The Cost of Inconsistent Names

Here is what a property looks like when nobody owns the naming. Three people wanted to track sign-ups, and over eighteen months you ended up with all of these in the Events report:

• signup
• sign-up
• SignUp
• sign_up_complete
• newsletter_signup

To GA4 these are five completely different events. There is no "sign-up total" anywhere in the interface, because GA4 has no idea these are the same thing. To report on sign-ups you now have to remember all five names, build a comparison or a custom dimension that lumps them together, and re-do it every time someone adds a sixth variant. The same rot shows up in parameters: lead_form on one event, leadform on another, form on a third. Each spelling is a separate column you have to reconcile by hand.

None of this is recoverable cheaply. GA4 does not backfill renamed events, so the day you finally standardise, your history splits into "before" and "after." The fix is to never let it happen.

The Core Rules

Six rules cover almost every case. Apply them to event names and parameter names alike.

1. Lowercase snake_case, always

Words separated by underscores, everything lowercase: view_item, add_to_cart, form_submit. This matches Google's own recommended events, so your custom events sit naturally alongside the automatic ones. No spaces, no hyphens, no camelCase, no PascalCase. GA4 treats names as case sensitive, so Purchase and purchase are two different events: lowercase removes the ambiguity entirely.

2. The verb_object pattern

Lead with a verb describing the action, then the thing it acted on: view_item, submit_form, start_checkout, select_promotion. This reads cleanly in a list and keeps related events sorted together. A noun-only name like form or video tells you nothing about what happened.

3. Present tense, no past tense

Use complete_purchase, not purchase_completed or purchased. Events describe something that just happened; present-tense verbs keep every name in the same grammatical shape so they line up predictably.

4. No PII, ever

Never put personal data in a name or a value: no email addresses, names, phone numbers, or user IDs. Sending PII into GA4 is a Terms of Service violation and a privacy risk, and it makes names explode in cardinality. If you need to tie behaviour to a person, that belongs in your own systems keyed on a non-identifying ID, not in the event name.

5. No volatile values baked into names

The event name is a constant. Anything that changes per occurrence goes in a parameter, not the name. Do not create view_product_4821, view_product_4822, and so on: fire view_item and pass item_id as a parameter. Names that embed IDs, dates, or prices generate thousands of distinct events and make every report useless.

6. Be specific, but not redundant

Name the thing precisely enough that you never have to guess: submit_contact_form beats submit_form if you have several forms, but you can also keep submit_form and pass form_name as a parameter. Pick one approach and use it consistently. What you must avoid is two events that mean the same thing with slightly different words.

Naming Parameters Consistently

Parameters need the same discipline as events, and they fail more quietly because the inconsistency hides inside the event rather than in a top-level list. Use snake_case here too, and reuse the same parameter name for the same concept everywhere. If "which form" is form_name on submit_form, it is form_name on view_form as well, never form or formName or form_id standing in for the same idea.

Match Google's parameter vocabulary where one exists. The eCommerce schema already defines item_category, item_brand, coupon, value, and currency: use those exact names rather than inventing product_category or discount_code. For more on getting parameters to actually appear in reports, see GA4 event parameters.

Reuse Google's Recommended Events First

Before you invent a custom event, check whether Google already has a recommended one for it. GA4 ships a list of recommended event names (login, sign_up, search, view_item, add_to_cart, purchase, generate_lead, and many more) that unlock pre-built reporting and behave predictably with Google's own features. Using sign_up instead of your own user_registration means GA4 understands the event and you spend zero of your custom-definition budget on it. Only invent a name when nothing recommended fits.

The Cheat Sheet

Print this and stick it next to whoever writes tags. The pattern is always the same: snake_case, verb first, value in a parameter.

Governance: One Owner and a Tracking Plan

Conventions only hold if someone is responsible for them. Name a single owner of the measurement schema, the person who decides what a new event is called before it ships. Back them with a tracking plan: a simple shared document (a spreadsheet is fine) listing every event, its parameters, where it fires, and what question it answers. Every new event gets added there first and named there second, before a single tag is built. The plan is the source of truth; GA4 is just where the data lands.

Common Mistakes

• Letting developers and marketers name events independently, so the same action gets two names.
• Mixing cases (Purchase and purchase) and assuming GA4 merges them. It does not.
• Encoding IDs, prices, or dates in the event name instead of a parameter, exploding cardinality.
• Inventing a custom name when a recommended event already exists, losing free reporting.
• Renaming events later to tidy up, which splits your history with no backfill.
• Naming parameters loosely so the same concept arrives under three spellings.

In adop.tools

Clean, consistent event names pay off the moment you open a report. Because adop.tools breaks events down by name and rolls them into conversion groups, well-named events read cleanly with no per-name relabelling: submit_form is one row, not four near-duplicates. Messy names force manual cleanup, mapping signup, sign-up, and SignUp back together by hand every time you build a view. The naming discipline you apply at implementation is the difference between a report that reads itself and one you have to babysit.

Start Now, Not Later

Naming conventions are cheapest the day before you ship your first event and most expensive every day after. Write the house style down, name an owner, build the tracking plan, and hold the line. None of it is hard. It only requires deciding once and then refusing to drift.