Many marketing teams end up struggling to build effective dashboards and reports because their underlying event tracking is a mess.
Take, for example, the simple action of a user signing up for a newsletter. You could implement the event as Sign up, Signup, User Signed Up, sign_up, signed_up or signedUp, which can quickly become problematic.
Most analytics tools are case sensitive, so even “Sign_up”, and “sign_up” will create two separate events.
Don’t reinvent the wheel
There are a number of proven and well documented event tracking frameworks used by some of the worlds largest companies that are designed to fix exactly this problem, so there’s no need to reinvent the wheel.
Table of contents
Open Table of contents
The Object-Action Framework
The object-action framework has emerged as the general best practise and single most widely used approach to event tracking and naming. Below are some of the leading analytics companies that recommend it.
-
Segment: “At Segment, we implement analytics using the object-action framework.” Source
-
Amplitude: “Use a framework like Object Action as a best practice for governing the structure of your events” Source
-
MixPanel: “MixPanel Defines events with properties that can map to objects and actions” Source
-
PostHog: “For event names, use the category:object_action framework to make it easier to find a specific event within a long list:” Source
-
mParticle: “An object-action naming convention is clear and concise.” Source
The object-action framework states that every action performed by a user should be based on an ‘action’ operating on an ‘object’. For example: Form Submitted, Button Clicked, Page Viewed. In addition all actions should be documented in the past tense (i.e. Form Submitted and not Form Submit).
To clarify the Object-Action naming convention comprises of:
-
The Object - the thing on your website or app that customers interact with e.g. Button, Form, Page
-
The Action - actions customers have performed on those objects e.g. Clicked, Viewed, Submitted
Object-Action Event Examples
Below are examples of some common events based on the object-action framework.
-
Form: Started – Form Started
-
Form: Submitted – Form Submitted
-
Link: Clicked – Link Clicked
-
Button: Clicked – Button Clicked
-
Video: Started – Video Started
-
Video: Watched – Video Completed
-
Page: Visited – Page Visited
The Category:Object_Action Framework
For larger event tracking implementations many companies add category to the object_action framework in order to group related events and make them easier to find.
category:object_action
For example, categories could help make it easy to understand exactly where the event originated:
-
site:newsletter_subscribed -
app:account_created -
portal: user_passwordChanged -
api:check_complete
So app:account_created happened in the main app, affected the account, and tells me exactly what happened (new account created). You could also group related events by type e.g. Onboarding events, Navigation events, User interaction events etc.
What to track?
The general best practise here is to Keep it simple, Stupid as trying to track every possible action often results in data overload, which can hinder your ability to extract meaningful insights
Often, we see new customers try to track most—or even all—of the actions a user could possibly take in their product. Resist this urge. Though it feels logical to say that more data will lead to more insights, it usually doesn’t work out that way. Too much data actually obscures insights, burying them under an avalanche of events and properties you don’t really need to know about.
We suggest starting out by tracking two event types:
-
Signups, or conversions (those that enable you to understand growth)
-
“Value moments” or “Significant actions” a user takes, like clicking a button, completing a form, or watching a video
Typically growth marketers are most interested in events such as:
-
Demo booked
-
Button clicked
-
Call booked
-
Video played
-
Form submitted
-
File downloaded
One good way to approach a new event tracking implementation is to ask the 5 to 10 burning questions your team would like answers to, and to use these to define the most necessarily events and event properties to start with.
A note on autocapture (aka autotrack)
All modern analytics tools include autotrack or autocapture functionality which provides an out-of-the-box way to start capturing user interactions without requiring any custom configuration or code. For example GA4 has Automatically Collected Events and PostHog has Autocaptured events.
Amplitude famously didn’t build auto-tracking functionality initially but finally introduced it into their platform in late 2024.
Autocapture is quick, accessible, and easy to use for non-engineers. Autocapture involves a one-time setup that captures user interactions and doesn’t require constant access to your app’s code or upfront coordination with an engineer. There’s a much lower learning curve and much less setup time required.
However, Autocapture does not completely eliminate the work needed to maintain your data. Instead, it shifts the work from the engineering team to the data team, which is responsible for sorting data, labeling events, and dealing with potential break-fixes caused by less stable tracking on your website or app.
For smaller teams, autotracking provides the ability to quickly get started with tracking without the need to manually create custom events for every button, link, form and conversion flow on their website. But, you absolutely still require an event tracking plan (see below for more information).
For most teams we recommend getting started with default events, particularly as platforms will often have pre-defined reports associated with default events. Then when it comes to custom events, use the object-action framework.
To get the most out of event tracking most marketing teams will always need to combine default events (like page views) with custom events.
Ensure Consistent Casing
A major culprit of data quality issues is inconsistent naming conventions. Inconsistencies build up gradually yet even the minor of inconsistencies can result in data quality and reports becoming confusing, unreliable and untrusted.
There are a number of casing options for event names, here are the most common:
-
All lowercase: All letters are lowercase. Example: button clicked
-
Snake Case: Words are lowercase and all words are separated by underscores. Example: button_clicked (or user_signed_up)
-
Title Case: Capitalise the first letter of each major word. Minor words (e.g., prepositions, articles) are usually lowercase unless they are the first or last word. Example: Button Clicked
-
Proper Case: Similar to Title Case but capitalises the first letter of every word, regardless of its part of speech. Example: Button Clicked
-
Camel Case: Capitalise the first letter of each word except the first, with no spaces. Example: buttonClicked
-
Sentence Case: Capitalise only the first letter of the first word, with proper nouns also capitalised. Example: Button clicked
Whilst there are no hard and fast rules for event and property name conventions, here are a few tips to keep in mind:
-
Avoid spaces in names as most platforms prefer delimiters (e.g. like underscores) instead of spaces.
-
Casing conventions often depend on the platform or analytics tool being used, so check for your individual use case.
-
Whilst preferences for event names tend to differ, almost all analytics platforms suggest snake_case or camelCase for property names.
-
Proper Case event names (e.g. Button Clicked) look nicer in dashboards and reports than snake_case (e.g. button_clicked)
Create a tracking plan
The most important step before you begin sending data to any analytics platform is to build a data tracking plan. This documents all the user behaviours you want to track, why they are important, and how they are defined.
A data tracking plan (usually referred to as just a tracking plan) is a document that acts as a source of truth for your event data—it’s a living document that contains all the information related to the data you gather about your customers.
Below is an example event tracking plan from Segment which shows what data is being tracked, where you’re tracking that data, and why.
Key Takeaways
It’s far better to invest time upfront in designing and document a system that works for your entire organisation than to rush an implementation and try to fix it later.
Small inconsistencies in event names can quickly add-up to cause major problems when it comes to building reports and many analytics platforms don’t let you rename events without losing historical data, making your initial choices effectively permanent.