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. |
Comments
0 comments
Please sign in to leave a comment.