Appendix: Glossary – Split Help Center

The following terms are used by Split. In most cases, the definition is one commonly found in computing, experimentation or in the use of feature flags.

Terms	Definition
Split	Combines the feature (any front end or back end change) being released with the rollout plan associated with it. (i.e. a feature flag). Could also include how that given code change is impacting the metrics you care about.
Tags	An additional way to filter your Splits. Use tags for things like identifying several Splits on a theme or Splits that are long-lived for product packaging vs. short-term experiments.
Editors	Users of the Split app with the permission to edit a Split (i.e. feature)
Permissions	Framework for managing Split user access
Environment	Systems that participate in your development lifecycle, from local to test, staging, production, etc.
SDK	The Split team builds and maintains SDKs (Software Development Kit) for the most popular language libraries, which are available under Open Source licenses.
Evaluator	A generic SDK with a REST API wrapper that enables Split to be used with any language where Split has not built an official SDK.
Traffic Type	Base unique identifier of the traffic on which you will split and measure features: user, account, store, etc.
Treatments	The versions/variations of your feature that you might show to your users.
Default Treatment	The safest version of your feature. Split will push this version of your feature to all your customers if you ever hit the “Kill” switch in the UI.
Control Treatment	A reserved treatment in Split named control that will be served to customers if a) the rollout plan for any Split has not been defined, b) the SDK does not have the feature cached, or c) the SDK encounters an exception.
Unique Users	Users are, generically, the external users or customers of the software where Split is being used for experimentation. Also known as “visitors.” Unique users are individual users with any duplicates of that user removed.
Segment	Lists of customer IDs that can be used for targeting and putting groups of customers into specific treatments of a feature.
Targeting	The rules for which users should see which variation of a feature.
Whitelists	The part of a roll-out plan individual customers or segments of customers can be assigned to a specific treatment.
Traffic Allocation	The percentage of your customers that you want to be used in your targeting rules and default rule.
Targeting Rules	If/else statements with user-defined matching criteria to put subsets of traffic into different treatments.
Custom Attribute	Any dimension of your customer base available to your code at run-time, typically used as criteria in a targeting rule. This data is not sent to Split.
Dependency Matcher	Ability to use the treatment that a customer would get from one split to define what treatment a customer sees in another split.
Default Rule	Final catch-all piece of a Split roll-out plan that determines what treatment a customer is served if they don’t fall into a whitelist or targeting rule.
Impressions	Unique event record generated for every time an app calls the Split SDK to get what treatment (i.e. variation) of a feature to show a user.
Events	The log of events occurring in your application that have been pushed into Split (e.g. clicks, conversions, search, 500 errors).
Metrics	The object(s) that represent how you want to measure a given event stream (e.g. count of clicks per user vs. total count of clicks across all users).
MDE	Minimum Detectable Effect - The effect size is calculated as the difference between the means of two treatments as of the last update time.
Controlled Rollout	Rooted in the concepts of feature flagging, dynamic configuration, and experimentation gives teams the ability to roll out any feature gradually and immediately mitigate any problems that occur.
Rollout Plan	The staged release of any feature by percentage, segment, attribute, or explicit include (i.e. turn 5% of my beta users “on”, keep all other users “off”).
Reallocate Traffic	“Reshuffles the deck” to reset and randomly re-assign customers to the same rollout plan. For example, if a feature is set to “on” for 1% of customers and the feature has a bug, once the bug is fixed traffic can be reallocated to be “on” for a new 1% of customers in order to gain unbiased feedback.
Split API	Used to configure Split or make other changes programmatically.
Kill Switch	When triggered, the Kill switch will immediately revert 100% of customers to the selected default treatment for that Split. Once killed, a feature can also be “Reactivated” to revert customers back to the exact state of the rollout plan set prior to the Kill.

Related articles