Skip to main content

According to amplitude academy, fundamentals of data taxonomy design course, they recommend using past tense verb. (see the bold & underlined text)

Here are some best practices for creating a taxonomy that makes your data easy to learn:

  • Maintain a consistent style (i.e. case and punctuation) for all of your events and properties. For example, you may use Title Case for all events and snake_case for all properties. Regardless of what you choose, the most important thing is to stay consistent. For easy differentiation, you should try using one style for your events and a different one for your properties.
  • For events, maintain a consistent syntax that includes a noun and a verb. For example, all of your events may follow noun + verb or verb + noun order. This will help you and other data users better map what event is triggered when an action is done in the product.
  • Name properties such that you can intuit their data type. While this may not always be possible, consider naming your properties so someone can figure out what the data type of that property value might be. For example, a property that takes boolean values could be named is_subscriber; a property that acts as a counter could be named num_purchases. While this is helpful, optimize for readability first.
  • Maintain the same verb tense across all events. We recommend using past tense to indicate that the event is triggered once the action is completed. For example, Category Browsed would be preferred over Category Browse. More importantly, do not mix tenses or people might be confused about when the event gets triggered.
  • Be concise in your naming. The more concise you can make your events and properties, the easier the query will be for others to read and comprehend. Since longer event and property names may be cut off at first glance, always consider how you can make an event name two words instead of five. Balance this with using the real-world language of the customer; this will make searching for events and creating new charts far more intuitive for new data users.

 

But, according to Data taxonomy playbook, they recommend using present tense verb.

Consistency in naming means that all events share the same syntax. If you do not have your own standard syntax in naming data, we recommend (1) all lowercase—this removes the possibility of casing instrumentation errors, and (2) present-tense verbs—this minimizes any confusion. Regardless of the syntax you choose, the most important factor is that all events consistently follow your chosen syntax.

 

I understand that tense is not that important(the most important thing is easy to understand and clear event name) but which is better?

Hi @Kay Lee 

I have personally used both in different implementations -  noun+verb  and verb+noun ( both in past tense ). This is due to the very reason Amplitude states in there - symbolizing that the ”event is triggered once the action is completed.”

The Data Taxonomy playbook article page has been around for 5+ years now , whereas the Amplitude Academy content is on the newer side. So the thought process of the folks writing those pieces would have been different at that time.

But ultimately it’s your team’s choice to decide on what works best semantically for them and stick to it consistently for better data governance.


Hi @Kay Lee, thank you for your question! I’m the author of the data governance Academy courses and I’ve double-checked with some of my professional services colleagues to make sure the information I’m getting to you is up-to-date. @Saish Redkar is spot on. I would recommend past tense because the event is fired once the user performs the action. Present-tense can sometimes introduce more confusion, in fact. For example, if the event that is triggered once a user joins a community is named “Join Community” it isn’t immediately clear that the user has already joined the community.

That said, the number one thing we’d recommend is consistency across case and tense. If there is a type of case or tense that makes sense for your implementation, it’s most important for those stylistic guidelines to be documented and enforced.

I definitely understand that it’s confusing to have conflicting best practices across different resources -- I’ll bring this up with my colleagues and we’ll make sure the content is revised! Please feel free to point out other issues like this if you encounter them.


Reply