What are the best practices for Event Nomenclature in Product Analytics?

This is Part 7 of a long-form series of setting up Product Event Analytics correctly.

You could read Part 6 to learn how to come up with events for instrumentation and the best practices for their documentation.

If you already have an understanding of the best practices around naming your events, feel free to skip over to the next section where I discuss which Product Metrics to track

So, we’ve already learned the documentation of events to instrument. Let’s now discuss a common nomenclature method for your entire team to continue to come up with the names of events and parameters in a consistent manner.

Events

The best practice for naming your custom events is the ‘Object Action’ framework.

The object action framework states that every action performed by a user should be documented in the form of past tense and should be based on a clear logic of an ‘action’ operating on an ‘object’.

Another way to think about naming your events is the ‘Noun Verb’ framework which states that your event must be a noun (For Example — A Button, a photograph, a card, a widget, etc.) being acted upon with some action type (For Example — Click, Swipe, Pull, Drag, etc.).

I’d slightly modify this ‘Object Action’ framework to this more nuanced title of the ‘Object Widget Action’ framework. Mostly, the object’s name is not sufficient to differentiate the same from other objects. Hence, at times you may be required to also include the widget name in the name of the event.

It’s also important to name your events in the title case. All the words in your event names should start with a capital letter.

Taking the same example as discussed in the last part, we had already documented the list of events that we wanted to instrument. Let’s dissect the name of any one of those events and understand the reasoning behind the same.

Destination Entry Clicked — ‘Destination’ is the Object ‘Entry’ is the text field widget, and ‘Clicked’ is the action being performed on the object.

The naming of ‘Objects’ is pretty much custom to your use case. The objects could be as varied as a ‘Post’ for a social media platform to a ‘ride’ for an online cab booking platform.

The naming of ‘Widgets’ mostly prescribes the syllabi of all the widgets that your design team uses. The most commonly used widgets are as follows —

• Button
• Card
• Carousel
• Hamburger Menu
• Search Field
• Date Field
• Drop Down

The naming of ‘Actions’ is mostly a standard process unless your designs have customized action sets. The most commonly used actions are as follows —

• Click
• Scroll
• Swipe
• Pull
• Drag

Parameters

There’s no hard rule for naming your parameters. However, your parameters should be documented in the snake case, which is that every word of your parameter’s name should be separated with an underscore (‘_’).

It’s generally better to instrument as many parameters as possible so that they can be used to generate newer types of insights while examining the details of a single event.

Let’s take the same example event’s parameters mentioned below —

• destination_name — This is the destination’s locally referenced name selected by the user while booking a ride and is usually fetched from a Maps’ API list of destinations.
• destination_location — This is the location of the destination selected by the user in the form of a pair of ‘latitude’ and ‘longitude’.

Summary

The best practices for documenting your Event Names, Parameter Names, as well as your Instrumentation Document structure have been covered in this part as well as the previous ones.

Armed with all this information, we’d finally discuss the Product Metrics to track and how to come up with Product Metrics to track for your use case in the next part.

Do share your feedback with me at kshitj.saxena@gmail.com or connect with me on LinkedIn