Naming Conventions for Segments and Metrics | Community
Skip to main content
Thomas_Ashley
Level 2
June 12, 2023
Solved

Naming Conventions for Segments and Metrics

  • June 12, 2023
  • 3 replies
  • 4586 views

Hello,

 

We are considering implementing standardised naming conventions for segments and calculated metrics. Has anyone else done this within their organisation? Could you share any tips on how you came up with your naming scheme and how you incentivise/enforce adoption among users? I found an old post from 2017 but the only tip was on getting users to include their initials. 

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Jennifer_Dungan

I think this is very dependent on many factors...

 

I don't allow most people to create "permanent" segments / C into our components lists; most people in our org can only create adhoc segments and calculated metrics; so that we don't clog up our reusable components.

 

And I've also made sure that unless there is a valid reason to have segments or calculated metrics as permanent reusable items, that people with the access to save as permanent component items are still to create as adhoc.

 

This of course means that most items I don't have to worry to much about naming conventions....

 

But for items that are permanent, we have a more simplified approach....

 

(I should start with explaining we have a different profile types, most of our sites are News, and are on the global suite, but we have other items like Auto Selling/Reviews, Business Directory, etc)

 

Segments are always prefixed with the type, so that we can tell which profile it belongs to ("News: " or "Directory: ", etc)

 

Calculated Metrics... if these are using standard metrics that could apply to any site; have no prefix, and if they are specific to the custom metrics in a profile, then it should be prefixed as above.

 

 

After that, I just ask that the name represent in the most readable way that people can properly identify what is happening... if the calculated metric cannot be clearly understood in a short name what it's doing (i.e. PV/V or Meter Stop Rate, etc), then it's likely not a good candidate for a permanent component... 

 

Same with the segments, if the segment is too specific to a particular report, it should not be created as a permanent component.

 

If it's not permanent, then I don't care too much about the naming, just so long as it makes enough sense within the report, and if the segment requires additional information to give context, then add it into a text block or into the panel/visualization description.

 

 

I don't see any reason to add user initials into the name of either segments or components... the owner of the component is readily available; there's no need as far as I am concerned to show that in the reports that people are using... 

 

I do however also ensure that all permanent components have proper descriptions and tagging so that people using them can read a longer specific description about their purpose and potential uses, and the tags allow them to be found easier by additional criteria.

 

 

But what works for me may not work for you.... 🙂

My best advice it to work with your team to understand what they may want/need in naming conventions and work to make sure that you can come to a consolidated decision that works for everyone.

3 replies

Jennifer_Dungan
Community Advisor and Adobe Champion
Jennifer_DunganCommunity Advisor and Adobe ChampionAccepted solution
Community Advisor and Adobe Champion
June 12, 2023

I think this is very dependent on many factors...

 

I don't allow most people to create "permanent" segments / C into our components lists; most people in our org can only create adhoc segments and calculated metrics; so that we don't clog up our reusable components.

 

And I've also made sure that unless there is a valid reason to have segments or calculated metrics as permanent reusable items, that people with the access to save as permanent component items are still to create as adhoc.

 

This of course means that most items I don't have to worry to much about naming conventions....

 

But for items that are permanent, we have a more simplified approach....

 

(I should start with explaining we have a different profile types, most of our sites are News, and are on the global suite, but we have other items like Auto Selling/Reviews, Business Directory, etc)

 

Segments are always prefixed with the type, so that we can tell which profile it belongs to ("News: " or "Directory: ", etc)

 

Calculated Metrics... if these are using standard metrics that could apply to any site; have no prefix, and if they are specific to the custom metrics in a profile, then it should be prefixed as above.

 

 

After that, I just ask that the name represent in the most readable way that people can properly identify what is happening... if the calculated metric cannot be clearly understood in a short name what it's doing (i.e. PV/V or Meter Stop Rate, etc), then it's likely not a good candidate for a permanent component... 

 

Same with the segments, if the segment is too specific to a particular report, it should not be created as a permanent component.

 

If it's not permanent, then I don't care too much about the naming, just so long as it makes enough sense within the report, and if the segment requires additional information to give context, then add it into a text block or into the panel/visualization description.

 

 

I don't see any reason to add user initials into the name of either segments or components... the owner of the component is readily available; there's no need as far as I am concerned to show that in the reports that people are using... 

 

I do however also ensure that all permanent components have proper descriptions and tagging so that people using them can read a longer specific description about their purpose and potential uses, and the tags allow them to be found easier by additional criteria.

 

 

But what works for me may not work for you.... 🙂

My best advice it to work with your team to understand what they may want/need in naming conventions and work to make sure that you can come to a consolidated decision that works for everyone.

Thomas_Ashley
Level 2
June 12, 2023

Thanks Jennifer! I like the idea of only allowing users to create temporary segments as far as possible. I also like the idea of generating some ideas and then workshopping these with our users. Only a subset of our users have permission to create segments so it should be possible to create a working group to discuss and implement this. 

yuhuisg
Community Advisor
Community Advisor
June 12, 2023

I assume your names will be in English.

I normally prefix my Segments with "Hits from...", "Visits from...", "Visitors from...", depending on the outermost container's scope. For the rest of the name, I try to keep it as simple and short as possible, keeping in mind that the names could appear in visualisations.

Naming Calculated Metrics is "relatively" simpler: take a cue from how Adobe Analytics itself does it. That is:

  • Keep the name as short yet meaningful as possible, and
  • For counter/numeric metrics: use the plural form.

Whatever naming convention you use, make full use of the "Description" text box too! Fill in all of the detailed information that you need to describe your component to other users.

All the best!  😀

Jennifer_Dungan
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
June 12, 2023

Yes, good points on "Hits" / "Visits" / "Visitors".... I generally just make sure that Hit , Visit and Visitor segments are specifically indicated (sometimes through the name describing the behaviour, or adding "(Visit)" or "(Visitor)" at the end...

Josh__Stephens
Community Advisor
Community Advisor
June 13, 2023

These are great suggestions.

 

I've found and frequently use a method to try to avoid creating segments.  I like to create a Quick Segment, or open in the Segment Builder.  Once it's created, I can then drag the segment over a metric for example.  After that, I can remove it from the panel segment.  So I achieve my goal without adding to a long list of segments that others have to sort through.  It's not saved in the component list but it's allowed me avoid creating a lot of segments that aren't needed very often.

Jennifer_Dungan
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
June 13, 2023

That is generally my mode of operation too!

 

Here is another trick... IF you happen to create a permanent segment, that you don't actually want to be permanent; you can actually delete it from your components list (if it's still in the project it will stay in the project as an adhoc component)

 

Basically all components have a component id, but there is a flag that indicates whether the segment is part of the components list or not.... delete really isn't "delete", it's more of a delete from being shown in the list.

Thomas_Ashley
Level 2
June 14, 2023

Thanks @josh__stephens yes I think what's becoming increasingly clear as we talk about this internally is that we need to combine this with some kind of documentation on best practice and advice on only creating permanent segments where necessary. @jennifer_dungan I didn't know about that permanent vs adhoc component, thank you!