How an Event Naming Convention Survives Its First Rename

Why does an event naming convention matter?

Picking an event naming convention is cheap on day one and expensive on day two hundred, because Google Analytics 4 never applies a rename to data it has already collected. Every inconsistent name you ship becomes a permanent second row in every report that groups by event, and the only way to merge those rows afterwards is to recompute the data yourself in a warehouse.

The failure is not theoretical or tidy. Three developers instrument the same button across three sprints and you get signup_click, SignupClick and click_signup. GA4 treats all three as separate events, because "event names are case sensitive. For example, my_event and My_Event are distinct events." Your funnel splits three ways, your key event count is a third of the truth, and nobody notices until someone compares the dashboard to Stripe. The broader discipline is covered in event tracking; this page is about the names themselves.

What names does GA4 refuse outright?

GA4 rejects reserved names and reserved prefixes, and Google's event naming rules state the consequence plainly: "If you try to use a reserved prefix or name, Analytics will display an error message." The rules that apply to every name are short:

• "Event names must start with a letter. Use only letters, numbers, and underscores. Don't use spaces."
• "Event names are case sensitive."
• "Event names can include English and non-English words and letters."

For web data streams, Google reserves query_id as a prefix and reserves nineteen event names outright. The ones that bite an implementation team are the plausible-sounding ones you would reach for naturally:

Reserved on web	Why you would have reached for it
click	The obvious name for any click handler
error	The obvious name for a client-side failure
scroll	The obvious name for a scroll-depth event
file_download	The obvious name for a PDF download
page_view	The obvious name for a virtual pageview in a single-page app
session_start	The obvious name for an app-open equivalent
user_engagement	The obvious name for a dwell-time event
video_start	The obvious name for a player event
ad_impression	The obvious name for a house-ad slot

Most of those are already being sent for you by enhanced measurement, which is why they are reserved. Check what your property collects without configuration before naming anything, and see autocapture for what automatic collection does and does not catch.

The Measurement Protocol reference adds a second, longer list that applies when you send events server side, including first_open, first_visit, app_exception, os_update and the whole firebase_ family, and notes that "ad_impression, in_app_purchase and screen_view events are only allowed for App streams."

Parameters carry their own reservations. The name firebase_conversion is reserved, and parameter names "cannot begin with" _, firebase_, ga_, google_ or gtag.. User property names cannot begin with _, firebase_, ga_ or google_, and the names first_open_time, first_visit_time, last_deep_link_referrer, user_id and first_open_after_install are taken.

What length limits apply?

Forty characters for the event name, and the penalty for exceeding it is stranger than a simple rejection. Google's event collection limits state that an event name runs to "40 characters," then add: "If you mark an event as a key event and the event exceeds 40 characters, then the event will not be reported as a key event because the appended _c will be missing." The event still collects. It simply stops being countable as a key event, silently, because GA4 appends _c internally and the appended name overflows.

The surrounding limits shape a convention as much as the name limit does:

Limit	Value
Event name length	40 characters
Distinct event names, web stream	No limit
Distinct event names, app stream	500 per app user
Event parameters per event	25
Parameter name length	40 characters
Parameter value length	100 characters
page_title value	300 characters
page_referrer value	420 characters
page_location value	1,000 characters
User properties per property	25
User property name length	24 characters
User property value length	36 characters

The 100 character parameter value is the one that catches teams. A product name, a search query or a form error string will exceed it, and the value is cut rather than the event refused. The 24 character user property name is tighter still, and shorter than the event name limit by sixteen characters, which is a good reason not to mirror event names into user property names.

The unlimited distinct event count on web is a trap rather than a licence. Nothing stops you from shipping four hundred event names; the reports simply become unusable, and each one has to be registered as a custom definition before it appears in most analyses. That registration cost is covered in setting up custom dimensions.

Should the object or the action come first?

The common advice is object first, cart_added and video_played, on the grounds that reports sort alphabetically and object-first names cluster every event about the same thing together. It is good advice and it disagrees with Google.

Google's recommended events are action first. The retail set alone reads add_payment_info, add_shipping_info, add_to_cart, add_to_wishlist, begin_checkout, purchase, refund, remove_from_cart, select_item, view_item, and the general set adds earn_virtual_currency, join_group, login, search, select_content, share, sign_up, spend_virtual_currency, tutorial_begin and tutorial_complete.

That matters because recommended events are not cosmetic. Google describes them as "standardized events for different business verticals (e.g., retail, travel, games) that unlock prebuilt reporting panels," where custom events are "events that you define yourself because no prepopulated automatic, enhanced, or recommended event fits your needs" and are "accessible using custom reports." Renaming add_to_cart to cart_added for internal consistency costs you the prebuilt ecommerce reports.

The workable rule is therefore split by origin, not by taste. Use Google's spelling wherever a recommended event exists, exactly as published, and apply your own object-first pattern only to events Google does not define. A convention that produces add_to_cart alongside pricing_table_viewed looks inconsistent on paper and is the only version that keeps both the reports and the sort order. Whichever order you pick, snake_case with lowercase letters is the only casing that avoids the case-sensitivity trap, since a convention where any character can vary in case is a convention that will eventually be violated.

Choosing event order

1

Check the recommended list. See if Google already defines an event for what you are tracking, such as add_to_cart or begin_checkout.

2

Match found. Use Google's exact spelling, action first, to keep the prebuilt ecommerce reports.

3

No match. Apply your own object-first pattern from a closed list of verbs and objects.

What does renaming an event after launch cost?

It costs you history, permanently, and it costs you one of fifty slots. Google's documentation on renaming events is unambiguous about the first part: "Modified and new events do not apply to historical data." The modification rewrites events going forward only. Every row already in the property keeps the old name, and no reprocessing exists to fix it.

Two more constraints sit alongside. "An hour or more passes before modifications take effect," so the fix is not immediate even after you make it. And "you can modify up to 50 existing events and create up to 50 events based on existing events," which means the modification feature is a repair kit, not a naming layer you can lean on indefinitely.

The practical cost of one rename, then, is:

• A permanent split in every report that groups by event name, at the date of the change.
• Any key event definition, audience or funnel referencing the old name has to be duplicated onto the new one, or it stops counting. The difference between the two concepts is set out in key events versus conversions.
• Year-over-year comparisons across the boundary have to be stitched by hand.
• One of fifty modification slots, consumed for as long as the old name is still arriving from a cached page or an unreleased app build.

None of that is recoverable by paying more or waiting longer, which is the whole argument for spending an afternoon on the naming document before the first tag ships.

What does a working convention look like?

A convention is four decisions written down, not a list of names. Make each one once and the list generates itself.

Casing: lowercase snake_case only, for names and parameters alike. Letters, numbers and underscores are all GA4 accepts anyway, and lowercase removes the only way two identical events can diverge.

Vocabulary: a closed list of verbs and a closed list of objects. view, select, add, remove, submit, start, complete covers most sites. Two verbs meaning the same thing is how signup_submit and signup_complete both end up in production.

Order: Google's spelling where a recommended event exists, object first everywhere else, and the exception written into the document so the next engineer does not quietly normalise it away.

Detail placement: variable detail belongs in parameters, never in the name. form_submit with a form_name parameter is one event you can filter; newsletter_form_submit, contact_form_submit and demo_form_submit are three events you cannot compare without building a report per form, and they burn three of your custom definition registrations instead of one.

Length: keep names under 40 characters with room to spare, because the key event penalty appends _c to whatever you chose and the failure is silent.

Frequently asked questions

What characters can a GA4 event name contain?

Letters, numbers and underscores, and the name must begin with a letter. Google states the rule as "Event names must start with a letter. Use only letters, numbers, and underscores. Don't use spaces." Non-English letters are allowed: "Event names can include English and non-English words and letters."

Are GA4 event names case sensitive?

Yes. Google's naming rules state that "event names are case sensitive. For example, my_event and My_Event are distinct events." There is no normalisation step, so two spellings of the same event produce two independent rows in every report that groups by event name.

What happens if I send a reserved event name?

Analytics refuses it and surfaces an error. The event naming rules say that "if you try to use a reserved prefix or name, Analytics will display an error message." Reserved names on web include click, error, scroll, file_download, page_view, session_start, user_engagement and video_start.

Should I use object_action or action_object?

Use Google's exact spelling for its recommended events, which are action first, and object first for everything else. Google's recommended set includes add_to_cart, begin_checkout, select_item and view_item, and renaming those forfeits the prebuilt reporting panels Google attaches to them.

Can I rename a GA4 event after launch?

You can rename it going forward and never backwards. Google states that "modified and new events do not apply to historical data," that "an hour or more passes before modifications take effect," and that you "can modify up to 50 existing events and create up to 50 events based on existing events."

How long can a GA4 event name be?

40 characters. Exceeding it has a specific consequence beyond rejection: Google warns that "if you mark an event as a key event and the event exceeds 40 characters, then the event will not be reported as a key event because the appended _c will be missing."

What happens if a team ships inconsistent event names?

GA4 treats each spelling as a separate event, because event names are case sensitive. Three developers naming the same button signup_click, SignupClick and click_signup produces three separate rows in every report, splits the funnel three ways, and cuts the key event count to a third of the real total. Nobody notices until someone checks the dashboard against another data source like Stripe.

Is there a limit on how many event names I can send to GA4?

A web stream has no limit on distinct event names, but that absence of a limit works against you rather than for you. Event names appear on their own, but every parameter you attach needs a custom-definition slot, so four hundred names buy reports nobody can read. An app stream does cap the count, at 500 distinct events per app user.

What is the difference between a custom event and a recommended event?

A recommended event is one of Google's standardized names for a business vertical like retail or travel, and Google says it unlocks prebuilt reporting panels. A custom event is one you define yourself because none of Google's automatic, enhanced, or recommended events fit, and it only appears in custom reports you build. Renaming a recommended event like add_to_cart for internal consistency forfeits the prebuilt panel that comes with it.

Do key events still count after I rename the event they track?

Not automatically. Any key event definition, audience or funnel that pointed at the old name has to be duplicated onto the new name, or it stops counting the moment the rename takes effect. That duplication costs no modification slot; only the rename itself consumes one of the fifty GA4 allows.