Naming Conventions for Segments and Metrics

[Thomas_Ashley]

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. 

[Jennifer_Dungan · Accepted solution]

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]

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]

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! 

[Thomas_Ashley]

Thanks for the tips! Yes our Segment and Calculated metrics will be in English. 

[Jennifer_Dungan]

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]

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]

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]

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!

[Jennifer_Dungan]

You can create adhoc segments at the top of the panel... when you hover over "Drop a segment here (or any other component)", a little + sign appears:

When you click, it will bring up the segment builder, but you will notice some extra options at the top:

IF you check the box, the segment will be created as a permanent segment in your components list, but if you don't, the segment will exist against the project only (adhoc)... if you save project as, copy panels or tables with the segment attached, the same segment will exist in all the projects... if you update / change it (just like permanent segments) the changes will occur everywhere (as the segment is still referencing the same segment id)

You can always make these segments permanent later if you need.

[Thomas_Ashley]

@Jennifer_Dungan thanks! Quick segments in general I knew about and have used a couple of times. However, it seems like making more use of them is something we need to encourage among our users to reduce our admin overheads. I didn't appreciate that deleting a component list segment effectively made it a quick/project only segment in the projects that still utilised it. This is useful as it mitigates risk if we become a bit over zealous when cleaning up existing segments. 

[Jennifer_Dungan]

Quick Segments and using the full Segment Builder "in-project" (ie. adhoc) are slightly different, but essentially result in the same thing... segments that apply only to the project.

The difference between Quick Segments and Creating a Full Segment in the panel is that the Full Segment still lets you leverage the full segment builder for complex logic... you cannot get the same sort of container / sequential / complexity in a quick segment... 

But for simple segments, quick segments work just as well. If people like the full segment builder, if they access directly from the panel, they will be able to create adhoc segments that they don't have to worry about adding to the components list....You can convert quick segments to the builder if you need to add complexity.

In the cases that I do turn an adhoc into a permanent segment, I will update the name, add description and tags (as per our standards) before checking that box to become permanent.

[Josh__Stephens]

That's great to know!  I've been afraid if I accidentally deleted a segment that was in use on a report it would break things!

[Jennifer_Dungan]

Lol, I was afraid too for the longest time... so one day I decided to test it out.. I created a test report with a test segment and then deleted it... when I reopened the report, it was still there

Also, if you incidentally delete a segment that you didn't mean to... if you can find the id of the segment in the admin logs, you can hack the URL, reopen it, then save it again