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.
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:
But if using object arrays, it’s ok to use a normalized name:
product: { s name, price ] }
plan: { { name, price ] }
Is this correct in what you’re recommending?
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.
