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

  1. Write the event dictionary before touching Google Tag Manager or the codebase.
  2. Fire lead events on confirmed success (a thank-you state or a server response), not on button click, or you will count failed submissions.
  3. Use GTM's preview mode and GA4 DebugView to confirm names and parameter values.
  4. Register only the parameters you will actually report on as custom dimensions.
  5. Mark the few events that represent real business outcomes as key events; do not mark every click.
  6. 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".

Further reading