We know that multiple people should easily understand all material if it follows some standardization of a style guide. This also happens when we want to map the pages and events of our product in our analytics tool.
That’s why it’s important to dedicate some time to establishing a naming convention for your product analytics effort. This will allow you to make the most of the data you collect. A predefined approach will allow you or others involved in this process stage to follow these practices.
Otherwise, asking someone to track a click on a “cancel” button without a naming guideline can turn into a real mess throughout your product, making it difficult to analyze and even understand what it is about. Let’s do a quick exercise. Let’s think about the possible variations in the account creation process: sign up, signed up, created, registration, registered, account, user, username. Imagine you are working in Brazil, and common English terms are mixed with Portuguese. Again, chaos!
But don’t worry! If you’ve never thought about this, you’re not alone. This confusion is super common. But with the right approach, you’ll see that everything will be resolved before the first event is inserted into your product analytics platform.
To avoid future problems, you must define how your events and properties should be named and replicate this pattern, if possible, throughout your organization. This will allow not only the product you are implementing to have consistency, convenience, and clarity in your data but also that a “form submitted” event is equally interpreted in any other product or that features in reports for management are easily compared. Clearer and easier-to-find data allows anyone to access, analyze, and extract basic insights without the need for the “analytics owner”.
Another clear benefit of a naming structure is that what you capture today in your MVP may grow to many more pages and features in the future. And I can guarantee you that you will want all “email address” fields to have the same naming convention and that new tracking is done more quickly by developers.
Think more strategically when establishing the convention you want to use, and you can even consider the product vision in it before anything is developed. And once defined, stick with it because changing what has been ingested by your analytics tool can be quite painful.
At this very moment, I just created all the elements that I wanted to track from my new product, and I realized that there were so many that I ended up making a big mess in understanding them. As I am still in the mapping stage in a non-production environment, I will dedicate myself to standardizing the terms to help me interpret the analyses that will come when the data analysis tool is officially available. And that was my motivation for writing this post.
