A GA4 Event Naming Convention Your Whole Team Can Follow

#analytics #webdev #marketing #tutorial

Google Analytics 4 lets anyone who can edit a tag create a new event name. That flexibility is useful for about six months, until the property contains Form_Submit, form_submit, formSubmit and lead_form_sent - all meaning the same thing and none of them comparable over time.

A written naming convention, agreed before tracking is implemented, prevents that. This note is a starting point you can adapt.

Rules that come from GA4 itself

These are platform constraints documented by Google, not preferences:

Event names are case sensitive. sign_up and Sign_Up are two different events.
Event names must start with a letter and use only letters, numbers and underscores.
Event names are limited to 40 characters; parameter names to 40 characters; parameter values to 100 characters in a standard property.
Some names and prefixes are reserved (for example names starting with google_, ga_ or firebase_, and automatically collected event names). Do not reuse them for custom events.
An event can carry up to 25 parameters. Parameters only become available in standard reports once registered as custom dimensions or metrics, and a standard property has a limited number of each - so register deliberately.

Check the current limits in Google's documentation before a large implementation; they occasionally change.

Our conventions

Rule	Example	Why
`snake_case`, all lowercase	`generate_lead`	Matches Google's recommended events; avoids case duplicates
Use Google's recommended event when one exists	`sign_up`, `login`, `generate_lead`, `purchase`, `view_item`	Unlocks built-in reports and keeps you compatible with future features
Custom events: `object_action`	`quote_request`, `calculator_complete`, `video_progress`	Readable in reports, sorts related events together
Put detail in parameters, not in the event name	`generate_lead` with `form_id=contact_footer`	Avoids hundreds of near-identical event names
No personal data in names or parameters	Never send email addresses, phone numbers or names	Google's policies prohibit sending PII to Analytics
Parameter values are stable identifiers	`form_id=pricing_modal` not `form_id=Pricing Modal (new!)`	Values survive design changes and translations

A minimal event dictionary

Keep a single table - in a spreadsheet or in your repository - that is the source of truth for every event. For example:

Event name	Trigger	Parameters	Key event?	Owner
`generate_lead`	Successful form submission (after server confirms)	`form_id`, `form_location`, `lead_type`	Yes	Marketing ops
`book_call_click`	Click on any "book a call" button	`button_location`, `page_type`	No	Marketing ops
`calculator_complete`	User reaches the result step of a calculator	`calculator_id`, `result_band`	No	Product
`file_download`	Enhanced measurement (automatic)	`file_name`, `file_extension`	No	-

A dictionary like this also makes QA possible: the tester checks the property against the table instead of against somebody's memory.

Implementation checklist

Write the event dictionary before touching Google Tag Manager or the codebase.
Fire lead events on confirmed success (a thank-you state or a server response), not on button click, or you will count failed submissions.
Use GTM's preview mode and GA4 DebugView to confirm names and parameter values.
Register only the parameters you will actually report on as custom dimensions.
Mark the few events that represent real business outcomes as key events; do not mark every click.
Review the dictionary each quarter and remove events nobody uses.

Common problems in audits

Duplicate events caused by a tag firing both from GTM and from hard-coded gtag.js.
Enhanced measurement form interactions double counting a custom lead event.
Parameters sent but never registered, so the data exists only in BigQuery exports.
Cross-domain journeys (for example a booking tool on another domain) breaking sessions and attributing leads to "referral".

DEV Community