Tracking Plan Tips: Event and Property Recommendations

I also recommend the use of naming conventions for events and properties. There are four aspects to consider:

1. Object and action structure - usually the event name should consist of an object and an action e.g. Action Completed or Game Started. No matter what you pick, keep the same one throughout all your events.
2. Casing - Pick one casing and stick to it. Something like title case is good because it’s human readable, while camelcase isn’t. It doesn’t matter if you have spaces and capital letters or not. Most tools accept everything, but being readable is what is what matters most.
3. Tense - Such as past tense or present tense. As with everything else, whatever you pick, stick to it. I like the past tense as it flows better and works well when analyzing data from actions performed in the past.
4. Language - Don’t try to be fancy or use industry-standard words. Just use what your company uses, and everyone will understand, especially if you’re use consistent words for actions. Plus, try to be descriptive in your property names.

Beyond naming conventions, when getting more into the tracking plan, I have a number of recommendations about events:

• Add informative descriptions. I find it really useful to add informative descriptions for events. These are important for ensuring they are sent at the same time between all code paths, platforms, and products.
  
  The event name doesn’t usually tell the whole story, so it’s important to be really specific about when the event is supposed to be sent. For example, is it when the purchase is completed, or is it when the person hits the button? There is a difference in timing, and if you are inconsistent between iOS and Android, you’ll have different numbers between them.
• Start with the why. Consider what your goals are, what metrics you need to measure them, and what are the events you need to construct the metrics. Don’t track everything, as you will have many events you’ll never use that will inflate your volume and increase costs. Track only what matters.
• Describe user actions. Rather than button clicks or page views, user actions are much more descriptive. It’s also more intuitive to look for a user action when creating a chart. Plus, buttons and page names change, which can cause confusion in the future.
• Choose names that scale with your product. It can be tempting to have shallow events e.g. a distinct event for every user action so it doesn’t have as many properties. Whereas deep events are consolidated user actions within each event e.g. Profile Configured is a deep events. Instead of updating a username, profile picture, and birthday, you have this profile configured event that combines these multiple actions.
  
  You want to find the balance between shallow and deep events. Have shallow events for significant actions as you want to use them on their own. Less frequently used events like configuring your profile can be consolidated into a single event.
• Journeys have a beginning, middle, and end. If you have a sign-up completed event, you might want to have a sign-up started event. That makes it easy to figure out which events to use in your sign-up follow-up or conversion. There are also middle steps you can make an event for, such as sign-up step completed.

Like with events, good properties have:

• Informative descriptions. These go beyond the property name and are specific.
• Maintain consistency in definition between products, platforms, events, and code paths. A property definition has a few aspects, including a meaning, type, presence, and whether it’s required or optional. Keep that property definition as consistent as possible between iOS, Android, and the web for all of these aspects.
• Be specific about what the property represents. It helps the user understand what the data means. Use properties that scale with the product. For example, when you start a product, you may only have one authentication method, such as email. However, as you begin to add more properties, it becomes confusing. A better method is using string properties or numerical properties.
• Use property constraints wherever possible. Document your tracking plan and all the property values allowed or the range, if numerical, so you don’t end up with duplicates. You should also avoid duplicate names between event user and system properties.

Anuj Sharma, Sr. Customer Success Architect at Amplitude, then joined the session to answer some user questions.

Anuj highlights that Amplitude has a great feature for adding categories to events. When you try to find a specific event through the drop-down, it might have 500 event names to scroll through. If you add categories, the process is easier because they are broken down into small chunks.

Categories can also be used to filter data. You can add filters on that data screen and start filtering those events down by category. There is also a concept of tags, which can be used in a number of ways. While you might be restricted to one category per event, you can add multiple tags. Doing so makes it easier to filter events and find what you need.

Descriptions don’t necessarily make it easier to find an event, but they add a lot of meaning. If you hover over a category in the drop-down, you can see the descriptions, showing you what the event is for. If you want to simplify your event list, Amplitude allows consolidating events with multiple events in one.

Anuj mentions that it’s possible to merge properties into a single property. As your taxonomy expands, you might unintentionally change your property name and end up with the same property showing multiple names. Merging the property allows you to retain historical data and use a new name.

One note though, those mergers occur at query times so data forwarded from outside Amplitude doesn’t flow downstream.

If you have , those merges won’t show up where you’re sending data, so keeping track of them is important.

Maintaining consistency across all platforms, including web and mobile, is essential. Doing so means you won’t have to look at several events for the same query. Platforms, products, and code paths should all be a single event that remains consistent.

If you were using , they track platform properties by default, meaning you don’t even have to instrument them separately.

Changing the names of events and properties isn’t easy. However, analytics tools like Amplitude make it possible to merge them.

It’s important to have a good workflow and peer review, which can be a big task. If you want to change the naming convention or restructure events, it’s best to do it in parts. Start with a few events and properties that are important to you and gradually migrate to a better naming convention.

You need to do it for both the taxonomy and implementation side. It has to be a collaboration between different parts of the organization. Gather reviews to make sure everything makes sense to everyone involved.

Commit to and document what naming convention you migrate to. Consider the definitions, the implementation, and how to handle the historical data.

When you look at the data product in Amplitude, you have the option of adding the number of queries you have for certain events or properties and can sort data by that. Sort events with the highest volume or number of queries and prioritize your work for those. That’s where the majority of the impact will be.