Skip to main content
Solved

What are best practices for property naming?

T
Peer Moderator
Forum|alt.badge.img+2

Wondering what is the best practice for property names and if there are advantages to normalizing them across events.

For example, imagine I have Event Foo and Event Bar.  Foo is an event involving a product and say Bar is an event involving a category.

 

Which is the best course of action in data modeling in Amplitude:

Option 1:

  • Event Foo
    • Property: product_name
  • ​​​​​​​Event Bar
    • ​​​​​​​Property: category_name

Option 2:

 

  • Event Foo
    • ​​​​​​​Property: name
  • ​​​​​​​Event Bar
    • ​​​​​​​Property: name

Basically what I’m asking is if there is any benefit to normalizing property names for charting or any other insights? Or is it a better practice to be as specific as possible?  The upside of this latter approach is that when we look at our property list in our data management, it’s really clear what a given property is for without needing to dig into the description.

The downside is that there are now N number of properties where as I could instead have a single “name” property for multiple events.

 

Best answer by dangrainger

This is very much an “it depends” answer….depends on the scale/ complexity of your product, on who your end users are, etc. If this is a POC and you’re looking to quickly get it off the ground then a concept of normalized naming will do an Ok job and is easy to understand. However, being specific is a better approach as the scale/ complexity grows, so you may be better off doing this from the offset.

To give a real example, in travel we have a concept of multi-destination search. So search results can have multiple destinations, but a “selection” from the results list will only have one. In the “select” event we want to know what’s being selected, but also what’s in the results at that point in time….so we can’t just use “destination name” as a parameter name as it’s not clear what it’s delivering in this context. There are also plentiful other examples we have like this.

View original
Did this topic help you find an answer to your question?

3 replies

dangrainger
Expert
Forum|alt.badge.img+9
  • dangrainger
  • Expert
  • 203 replies
  • Answer
  • March 13, 2023

This is very much an “it depends” answer….depends on the scale/ complexity of your product, on who your end users are, etc. If this is a POC and you’re looking to quickly get it off the ground then a concept of normalized naming will do an Ok job and is easy to understand. However, being specific is a better approach as the scale/ complexity grows, so you may be better off doing this from the offset.

To give a real example, in travel we have a concept of multi-destination search. So search results can have multiple destinations, but a “selection” from the results list will only have one. In the “select” event we want to know what’s being selected, but also what’s in the results at that point in time….so we can’t just use “destination name” as a parameter name as it’s not clear what it’s delivering in this context. There are also plentiful other examples we have like this.

T
Peer Moderator
Forum|alt.badge.img+2
  • trevin-bc
  • Author
  • Peer Moderator
  • 29 replies
  • March 13, 2023
dangrainger wrote:

This is very much an “it depends” answer….depends on the scale/ complexity of your product, on who your end users are, etc. If this is a POC and you’re looking to quickly get it off the ground then a concept of normalized naming will do an Ok job and is easy to understand. However, being specific is a better approach as the scale/ complexity grows, so you may be better off doing this from the offset.

To give a real example, in travel we have a concept of multi-destination search. So search results can have multiple destinations, but a “selection” from the results list will only have one. In the “select” event we want to know what’s being selected, but also what’s in the results at that point in time….so we can’t just use “destination name” as a parameter name as it’s not clear what it’s delivering in this context. There are also plentiful other examples we have like this.

 

Thanks Dan. Main reason I am asking is because in other analytics properties, the drop downs for properties on events can get really noisy because there isn’t filtering on relevant properties only for the events in question. So if you have multiple “name” properties:

  • product_name
  • plan_name
  • category_name
  • subcategory_name

they all appear when trying to find “name” and especially bad when you say filter down by keyword you have a crazy list of properties many of which aren’t relevant.

However, if you normalized on “name” it would all be a single property and the filtering would work but comes at the expense of less descriptive prop names.

So in your opinion, there is no advantage here of normalization unless I guess it is about object arrays, which then should allow us to normalize the name?

IOW, I think you are advising:

When not using object arrays, get specific in property names:

  • product_name
  • plan_name

But if using object arrays, it’s ok to use a normalized name:

product: { [ name, price ] }

​​​​​​​plan: { [ name, price ] }

 

 

Is this correct in what you’re recommending?

dangrainger
Expert
Forum|alt.badge.img+9
  • dangrainger
  • Expert
  • 203 replies
  • March 13, 2023

That’s what we’ve done in our implementation; it’s working well, end users feed back that it’s simple to find. Added bonus of Amplitude of course is that you can upload event/ property metadata to give specific detail of what the event/ property is providing, plus screengrabs where relevant.

Jeremie Gluckman
T
2 people like this
  • Jeremie Gluckman
    Jeremie Gluckman
  • T
    trevin-bc

Reply


Helpful Members this Week

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings