When creating a split (or segment or metric for that matter) it's a good idea to create a convention that your team can follow. Your approach will be specific to your organization, of course. Below are some suggestions based on conventions we use internally:
You could enforce names that are lower case only, camel case, or snake case (no periods, no spaces, etc.). Use a common taxonomy, for example:
Metrics: Descriptive, also useful to note per v. across
- Tasks completed per user
Split's web-console can get crowded, and we are constantly trying to improve this experience. Below are some tips to help stay organized as a team.
Tags: Add tags to splits to associate them with projects, teams, features. For example, multiple splits for the same feature should all utilize the same tag for better filtering. You may want to indicate where the feature is built. Tags are case sensitive, and lowercase is recommended. For example:
- frontend splits, use
- backend splits, use
Owners: At a minimum, the split creator will be an owner (along with Admins). Typically, an engineer and PM will both 'own' a split. Segments and metrics may only have a single owner, and are less likely to change. Groups, such as an engineering team, are also useful to make as owners.
Starring: Star any splits that you would like to surface easily. Starring is isolated to you, so it's a good way for an individual to drill into currently used splits.
Traffic Type: While not the primary use for Traffic Type, you can use it as a way to filter in on a specific set of splits.
You may want to tag objects that need to be deleted as a reminder, depending on your process, or as a check before taking action. For example:
- Splits should only be deleted if they have the tag
- Please confirm with a member of the appropriate team before removing any splits.