Event Tracking Naming Strategy for Google Analytics

HOW TO NAME EVENTS IN GOOGLE ANALYTICS

This post describes one proven naming strategy for Google Analytics event tracking. Event naming is critical for using Google Analytics event reporting hierarchy and drill-down structures. With a good naming system it will be easy for users to identify events they're interested in and break them down by where they happened or other relevant information. Without this system, analysis will often need to start with data cleanup and manual aggregation, and there won't be a logical method to find data in the reports.

Ideally naming will be intuitive enough that non-analytics specialists will be empowered to consider a question -- e.g. how do users reach the sign in screen? -- and be able to find the answer on their own, without requiring a tag debugger or guidance from an analyst.

EVENT CATEGORY NAMING

• Event categories should describe the page type or general module type that an event belongs to.
• Use existing event categories wherever possible. Only open up a new category when it makes sense and there are a reasonable number (at least 3) of events coming in for that category.
• Examples:
  Event Category = {{Page type}}: Homepage, Listing Page, Product Details Page, Checkout, Blog, Account
  OR
  Event Category = {{Global module type}}: Header, Footer, Sidebar

EVENT ACTION NAMING

• Event actions should display what action was taken, along with where the action occurred or some detail about it. Avoid simple event actions like 'click' or 'open' because they are too generic and essentially waste a slot.
• If you use the same event action for multiple events, ensure that they can be differentiated by the Event Category or Event Label.
• In general, start all event actions with a verb, like 'Clicked Navigation Bar', 'Submitted Signup Form'. One exception is if the action isn't triggered by a user, e.g. 'Modal Displayed'.
• Examples:
  Event Action =  {{Action}} {{Action Location}}: Submitted Email Address, Clicked Recommended Items, Completed Form Field, Clicked Hero Image, Clicked CTA Section

EVENT LABEL NAMING

• Event labels should describe specific, additional information related to an event. This is flexible; it should include whatever detail makes the most sense. Common examples would be the destination URL, a form field name, button text, scroll percent, etc.
• If there is no relevant additional detail for the event label, just leave the event label empty.
• If you have multiple pieces of information to include, separate them with a pipe or other separator. However, choose carefully to avoid unnecessary complexity.
• Examples:
  Event Label =  {{Detail}}: T12345, example.com/pricing_plans, Black | XS | Classic

FULL EXAMPLES

The following examples use the Event Category = {{Page Type}} format. This naming pattern allows all site interactions for a page type to roll up into their associated Event Category.

Homepage Clicks - Hero Image

Event Category = Homepage
Event Action = Clicked Hero Image
Event Label = example.com/pricing_plans

Homepage Clicks - Download Links

Event Category = Homepage
Event Action = Clicked Download Mobile App
Event Label = https://itunes.apple.com/us/app/apple-store/id123456789

PDP  Clicks - Product Info

Event Category = Product Details Page
Event Action = Clicked Product Info Box
Event Label = Learn More

PDP  Clicks - Add to Cart

Event Category = Product Details Page
Event Action = Added to Cart
Event Label = 123456

This screenshot shows what the output will look like in Google Analytics. It allows you to view important site interactions side by side for each page type, and, where relevant, further drill down into the Event Label for additional details.

These next examples use the {{Global module type}} pattern for the Event Category, because elements like a navigation bar and footer are visible site-wide, across all page types. Scroll tracking often gets tracked with this pattern as well, though it could reasonably fit into either type.

Top Navigation Bar - Menu

Event Category = Top Navigation
Event Action = Clicked Main Navigation
Event Label = Women's Shirts

Top Navigation Bar - Log In

Event Category = Top Navigation
Event Action = Clicked Log In
Event Label = null

This is an example of the report resulting from this type of naming pattern. Each main element of the top navigation is broken out into smaller logical subsections, which can then be further drilled into for additional detail.

Footer Clicks - About

Event Category = Footer
Event Action = Clicked About
Event Label = /example.com/about

Footer Clicks - Download Links

Event Category = Footer
Event Action = Clicked Download Mobile App
Event Label = https://itunes.apple.com/us/app/apple-store/id123456789

One benefit to this type of tracking is it allows you to easily see where important site actions happened. The tracking examples above showed links to an app store from both the footer and the homepage. By tracking those download locations in the category, you can search for Event Action = Clicked Download Mobile App, and then choose Secondary Dimension = Event Category to see where the click happened.

Scroll Tracking

Event Category = Scroll Tracking
Event Action = Scrolled Listing Pages
Event Label = Scrolled 20%

Event Category = Listing Page
Event Action = Scrolled /womens_shirts
Event Label = Scrolled 20%

As mentioned, sometimes an element doesn't neatly fall into either the page type or global module type model. In those cases, just use your best judgment to pick where it would be more convenient to view the data. I usually use the syntax in the first example, setting the category to Scroll Tracking and the Action to the page category, but the second example would be fine as well.

TIPS

• Be precise and avoid general terms like 'click' and 'button'.
• Plan out a naming matrix first, so that events have a logical location and can be summed and sliced easily.
• Don't track personally identifiable information (email, name, etc.) within events.

CONCLUSION

Whatever your preferred naming system, think it through as early as possible to allow for consistency as new events are tagged. When you want to tag a new site component, it should fit into the existing structure. This cuts down on the planning related to implementation, and makes the data more accessible to others in the company or organization.