LaunchDarkly vocabulary

Overview

This topic defines common words used in the LaunchDarkly application and documentation. While many of these words may be familiar to you, in some cases they have nuances specific to LaunchDarkly.

The following definitions may be useful as you work in LaunchDarkly:

A

Application

An application is a LaunchDarkly resource that describes what you are delivering to a customer. LaunchDarkly automatically creates applications when it establishes a connection with a LaunchDarkly SDK that contains application information. After an application is created, you can build flag targeting rules based on application name, version, or other properties, such as whether or not a particular application version is supported.

To learn more, read Applications and application versions.

Attribute

An attribute is a field in a context that you can use in targeting rules for flags and segments. Each context that encounters a feature flag in your product can have a different value for a given attribute.

To learn more, read Context attributes.

Audience

An experiment's audience is the combination of the targeting rule you're experimenting on and the number of contexts you allocate to each flag variation.

To learn more, read Allocating experiment audiences.

C

Cohort

A cohort can refer to a group of contexts in Amplitude synced with a LaunchDarkly segment, or to the targeting rules on a migration flag.

To learn more about Amplitude cohorts, read Syncing segments from Amplitude cohorts.

Migration flag cohorts are analogous to the targeting rules for other types of feature flags. The default cohort is analogous to the default rule.

To learn more, read Targeting with migration flags.

Context

A context is a generalized way of referring to the people, services, machines, or other resources that encounter feature flags in your product.

To learn more, read Contexts.

Context instance

A context instance is a unique combination of one or more contexts that have encountered a feature flag in your product.

To learn more, read Context instances.

Context kind

A context kind organizes your contexts into different types based on the kinds of resources encountering flags. Each context has one kind with a unique set of corresponding attributes that you can use for targeting and Experimentation.

Some customers are billed by contexts. This billing method uses the primary context kind.

To learn more, read Contexts and context kinds.

D

Default rule

A default rule describes the feature flag variation to serve to the contexts that don't match any of the individual targets or rules you have previously specified for the flag. It is sometimes called the "fallthrough" rule because all of the rules preceding it have been evaluated, and the context encountering the flag has "fallen through" to this last rule. To learn more, read Setting the default rule.

The default rule only applies when the flag is toggled on. If the flag is toggled off, then LaunchDarkly will serve the "default off variation" for the flag. In the LaunchDarkly user interface (UI), the default off variation is specified in the field labeled "If targeting is off, serve." To learn more, read Setting the default off variation.

E

Environment

An environment is an organizational unit contained within a project. You can create multiple environments within each project. Environments in LaunchDarkly typically correspond to the environments in which your code is deployed, such as development, staging, and production. All environments in a single project contain the same flags. However, the flags can have different states, targets, and rules in each environment.

To learn more, read Environments.

Evaluation

An evaluation is what happens when your application's code sends the LaunchDarkly SDK information about a particular flag and a particular context that has encountered that flag, and the SDK sends back the value of the flag variation that the context should receive. We say that the SDK evaluates the flag, or that the flag has been evaluated for a particular context or customer.

Experiment

An experiment is a LaunchDarkly feature that connects a flag with one or more metrics to measure end-user behavior. Experiments track how different variations of a flag affect end-user interactions with your app, and determine the winning variation. You can run an experiment for one or more iterations.

To learn more, read Experimentation.

Experiment flag

An experiment flag is a temporary flag that has an experiment running on one of its targeting rules.

To learn more, read Flag templates.

F

Fallback value

The fallback value is the flag variation that LaunchDarkly serves in the following two situations:

• If your application cannot connect to LaunchDarkly.
• If your application can connect to LaunchDarkly, but the flag is toggled off and you have not specified a default off variation. To learn more, read Setting the default off variation.

Regardless of how you configure targeting for your feature flag, each time you evaluate a flag from the SDK, you must include a fallback value as one of the parameters.

Fallthrough rule

A fallthrough rule is a synonym for default rule.

Feature change experiment

A feature change experiment lets you measure the effect different flag variations have on a metric.

To learn more, read Experiment types.

Flag

A flag is the basic unit of feature management. It describes the different variations of a feature and the rules that allow different entities to access them. Different entities that access your features could be a percentage of your application's traffic, individuals, or people or software entities who share common characteristics like location, email domain, or type of mobile device. The entities that encounter feature flags in your product are called contexts.

To learn more, read Using feature management.

Funnel metric group

A funnel metric group is reusable, ordered list of metrics you can use with funnel optimization experiments to measure end user progression through a number of steps, typically from the awareness stage to the purchasing stage of your marketing funnel.

To learn more, read Metric groups.

Funnel optimization experiment

A funnel optimization experiment uses multiple metrics within a funnel metric group to track the performance of each of the steps in a marketing funnel over time.

To learn more, read Experiment types.

I

Iteration

An iteration is a defined time period that you run an experiment for. An iteration can be any length that you choose, and you can run multiple iterations of the same experiment.

To learn more, read Managing experiments.

K

Kill switch

A kill switch is a permanent flag used to shut off tools or functionality in the case of an emergency.

To learn more, read Flag templates.

M

Member

A member or account member is a person who uses LaunchDarkly at your organization. These people work at your organization or have access rights to your organization's LaunchDarkly environment for another reason, such as contractors or part-time employees.

To learn more, read LaunchDarkly account members.

Metric

LaunchDarkly uses different kinds of metrics to do things like measure flag change impact, gauge application performance, track account usage, and more.

The five kinds of metrics within LaunchDarkly include:

• Flag impact metrics: these metrics allow you to measure specific end-user behaviors as part of an experiment or flag change. Metrics can measure things like links clicked, money spent, or response time. When combined with a flag in an experiment, metrics determine which flag variation is the winning variation. To learn more, read Metrics.
• Engineering insights project metrics: these metrics track engineering team efficiency and performance. To learn more, read Project metrics.
• Migration flag metrics: these metrics track the progress of a migration flag. To learn more, read Migration flag metrics.
• Application adoption metrics: these metrics track the adoption percentage for an application version. To learn more, read Understanding adoption metrics.
• Account metrics: these metrics help you understand your client-side primary context usage, Experimentation key usage, Data Export usage, and server usage for billing purposes. To learn more, read Account usage metrics.

Migration flag

A migration flag is a temporary flag used to migrate data or systems while keeping your application available and disruption free. Migration flags break up the switch from an old to a new implementation into a series of recommended stages where movement from one stage to the next is done in incremental steps.

To learn more, read Flag templates.

Monthly active users (MAU)

MAU is a billing metric that measures the number of user contexts your flags encounter from client-side SDKs over a particular month. MAU includes user contexts that are both single contexts and those that are part of a multi-context. If you are being billed by MAU then your MAU appear on the Contexts list, and expire from the list after 30 days of inactivity.

To learn more, read Account usage metrics.

P

Percentage rollout

A percentage rollout is a targeting rule that serves a given flag variation to a specified percentage of contexts that encounter the flag. A common use case for percentage rollouts is to increment the percentage of customers targeted by a flag over time until 100% of the customers receive one variation of a flag.

To learn more, read Percentage rollouts.

Prerequisite

You can make flags depend on other flags being enabled to take effect. A prerequisite flag is one on which a second flag depends. When the second flag is evaluated, the prerequisite flag must be on, and the target must be receiving the variation of the prerequisite flag that you specify. If the prerequisite flag is toggled off, the target will receive the default off variation of the dependent flag.

To learn more, read Flag prerequisites.

Primary context kind

The primary context kind is the context kind with the highest volume of monthly activity.

Some customers are billed by contexts. For these customers, LaunchDarkly only charges for contexts from the primary context kind. LaunchDarkly calculates this as the context kind with the largest number of unique contexts that evaluate, initialize, or identify any flag from a client-side SDK over a given calendar month.

To learn more about context kinds, read Contexts and context kinds. To learn more about billing by contexts, read Calculating client-side billing.

Project

A project is an organizational unit for flags in your LaunchDarkly account. You can define projects in any way you like. A common pattern is to create one project in your LaunchDarkly account for each product your company makes. Each project can have multiple environments.

To learn more, read Projects.

R

Randomization unit

An experiment's randomization unit is the context kind that the experiment uses to randomly sort contexts into each variation by, according to the experiment's traffic allocation.

To learn more, read Randomization units.

Release flag

A release flag is a temporary flag that initially serves "Unavailable" (false) to most or all of its targets, then gradually rolls out the "Available" (true) variation until it reaches 100%.

To learn more, read Flag templates.

Release pipeline

A release pipeline tracks the progression of a feature flag across a series of phases, where each phase consists of one or more environments. You can use release pipelines to view the status of ongoing releases across all flags within a project, enforcing a standardized process and ensuring they are following best practices.

To learn more, read Release pipelines.

Role, custom role

A role is a description of the access that a member has to information within LaunchDarkly. Every LaunchDarkly account has four built-in roles: Reader, Writer, Admin, and Owner.

A custom role is also a description of the access that a member has to information within LaunchDarkly. With custom roles, you create the description of the access using a set of statements called a policy.

Every member must have at least one role or custom role assigned to them, either directly or through a team. This is true even if the role explicitly prohibits them from accessing any information within LaunchDarkly.

To learn more, read LaunchDarkly's built-in roles, Custom roles, and Custom role concepts.

Rule

A rule or targeting rule is a description of which flag variations your application should serve to which contexts.

Targeting rules can have one or more conditions. Each condition has three parts:

• A context kind and attribute, which defines the scope of the condition's impact, such as only targeting an email address for the selected context kind.
• An operator, which sets differentiating characteristics of the attribute, such as limiting the condition to emails that end with certain extensions.
• A value, which identifies the attribute by a value you specify, such as .edu.

To learn more, read Targeting rules.

S

SDK

The LaunchDarkly SDK is the software development kit that you use to integrate LaunchDarkly with your application's code.

We provide more than two dozen LaunchDarkly SDKs, in different languages and frameworks. Our client-side SDKs are designed for single-user desktop, mobile, and embedded applications. They are intended to be used in a potentially less secure environment, such as a personal computer or mobile device. Our server-side SDKs are designed for multi-user systems. They are intended to be used in a trusted environment, such as inside a corporate network or on a web server.

When your application starts, your code should initialize the LaunchDarkly SDK you're working with. When a customer encounters a feature flag in your application, your code should use the SDK to evaluate the feature flag and retrieve the appropriate flag variation for that customer.

To learn more, read Setting up an SDK and Client-side, server-side, and edge SDKs. For more information about the differences between the LaunchDarkly SDK and the LaunchDarkly REST API, read Comparing LaunchDarkly's SDKs and REST API.

Segment

A segment is a list of contexts that you can use to manage flag targeting behavior in bulk. Segments are useful for keeping groups of contexts, like beta-users or enterprise-customers, up to date. They are environment-specific.

LaunchDarkly supports:

• rule-based segments, which let you target groups of contexts individually or by attributes,
• list-based segments, which let you target individual contexts or uploaded lists of contexts, and
• synced segments, which let you target groups of contexts backed by an external data store.

To learn more, read Segments.

Segment is also the name of a third-party software application that collects and integrates customer data across tools. LaunchDarkly integrates with Segment in the following ways:

• You can use Segment as a destination for LaunchDarkly's Data Export feature. To learn more, read Segment.
• You can use Segment as a source for metric events. To learn more, read Segment for metrics.
• Segment Audiences is one of several tools you can use to create synced segments. To learn more, read Segments synced from external tools.

Standard metric group

A standard metric group is reusable set of metrics you can use with feature change experiments to standardize metrics across multiple experiments.

To learn more, read Metric groups.

T

Target

To target (verb), is to specify that LaunchDarkly should serve certain flag variations to specific contexts that encounter feature flags in your application. A target (noun) is an individual context or a set of contexts described by a targeting rule.

To learn more, read Target with flags.

Team

A team is a group of members in your LaunchDarkly account. To learn more, read Teams.

Traffic allocation

An experiment's traffic allocation is the amount of contexts you assign to each flag variation you're experimenting on.

To learn more, read Allocating experiment audiences.

U

User

Previously, a user was the only way to refer to an entity that encountered feature flags in your product.

Newer versions of the LaunchDarkly SDKs replace users with contexts. Contexts are a more powerful and flexible way of referring to the people, services, machines, or other resources that encounter feature flags in your product. A user is just one kind of context.

People who are logged in to the LaunchDarkly user interface are called members.

V

Variation

A variation is a description of a possible value that a flag can have. Each variation must contain the possible flag value. It may also contain a name and description.

Flags share variations across environments within a project. However, the flags can have different states, targets, and rules in each environment.

When you create a flag, you must decide whether it is a boolean flag or a multivariate flag. Boolean flags have exactly two variations, with values of "true" and "false." Multivariate flags can have more than two variations. Each of the variations must have a value of the same type, for example, a string.

To learn more, read Creating flag variations.

In migration flags, variations are built-in and cannot be edited because they are linked to the migration's stages.

To learn more, read Targeting with migration flags.

W

Winning variation

An experiment's winning variation is the variation that performed the best out of all the variations tested. Every experiment iteration displays each variation's "probability to be best." The variation with the highest probability to be best is the winning variation.

To learn more, read Analyzing experiments.