Event Taxonomy Design
Why naming conventions are a business problem
A poorly designed event taxonomy is the silent destroyer of analytics programs. The events exist. The data comes in. But six months after launch, nobody can answer basic questions because:
- button_click, btn_click, and cta_click all mean the same thing — split across 3 event names
- sign_up was renamed to registration_complete midway through the year
- Nobody documented what user_interaction means or when it fires
- GA4 shows 340 distinct event names and nobody knows which 20 actually matter
Fixing a broken taxonomy requires deploying new tracking, waiting for data to accumulate, and accepting a gap in historical data. It's expensive and disruptive. Design it right once.
The naming convention
GA4's recommended format: object_action (lowercase, underscores, no spaces).
Object: what was interacted with — form, button, video, menu, product, modal
Action: what happened — view, click, submit, play, open, close, complete
Good examples:
- form_submit (a form was submitted)
- video_play (a video started playing)
- modal_open (a modal opened)
- product_view (a product page was viewed)
- checkout_complete (checkout finished)
Bad examples:
- UserClickedButton (camelCase, not GA4 convention)
- click (too generic — which click?)
- event1 (meaningless)
- homepage_hero_cta_primary_button_click_desktop (too specific — creates hundreds of variants)
Parameters are the detail layer
Events should be generic enough to reuse. Parameters provide the specifics.
Instead of: contact_form_submit, newsletter_form_submit, demo_request_form_submit
Use: form_submit with parameter form_type: "contact" | "newsletter" | "demo_request"
This collapses 3 event names into 1 with a parameter. In BigQuery: WHERE event_name = 'form_submit' AND form_type = 'newsletter'.
Standard parameters to capture on almost every event:
- page_location — full URL
- page_title — page title
- component_name — which UI element triggered the event
- user_type — logged_in, anonymous, trial, paid
Lifecycle events (the ones that actually matter)
Most analytics implementations track too many low-value events and miss the high-value ones. Design your taxonomy around the user lifecycle stages:
Acquisition:
- page_view (auto-collected by GA4)
- session_start (auto-collected)
- first_visit (auto-collected)
Engagement:
- scroll (auto-collected at 90%)
- content_view (blog post, guide, case study)
- video_play / video_complete
- feature_explore (clicked into a product section)
Conversion:
- form_submit (with form_type parameter)
- sign_up_complete
- trial_start
- purchase (GA4 standard ecommerce)
Retention:
- login
- feature_use (with feature_name parameter)
- upgrade_click
Documentation is not optional
Your event taxonomy is only as good as its documentation. Every event needs:
1. Event name: form_submit
2. Description: "Fires when any form on the site is successfully submitted"
3. Trigger condition: "On GTM form submission trigger, filtered to exclude search bar"
4. Parameters: form_type (string), form_location (page section), lead_source (UTM source)
5. Owner: who is responsible for maintaining this
6. Date implemented: when it went live
7. Notes: any known issues or edge cases
Keep this in a shared Google Sheet or Notion database. Link it in your GTM container description. Update it every time an event changes.
The analytics team that writes documentation is the analytics team that can onboard new members in a day instead of a month.
Design for the questions you'll need to answer
I build these systems professionally.
Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.