> ## Documentation Index
> Fetch the complete documentation index at: https://launchdarkly-preview.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# LaunchDarkly vocabulary

> This topic defines common words used in the LaunchDarkly application and documentation.

> For the complete documentation index, see [llms.txt](/llms.txt). For the full documentation snapshot, see [llms-full.txt](/llms-full.txt).

## 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

### A/A test

An `A/A test` lets you split users into different, but identical, variations to compare two groups receiving the same product experience. This lets you validate that your [experiment](#experiment) setup is working as intended and your metrics are tracking events as expected.

You can run A/A tests on both [flags](#flag) and [AI Configs](#ai-config), using any [metric](#metric) type.

To learn more, read [Experiment metric types](/home/experimentation/types).

### A/B experiment

An `A/B experiment` or `A/B/n experiment` lets you measure the effect different flag [variations](#variation) have on a [metric](#metric) over time. You can run A/B experiments on both [flags](#flag) and [AI Configs](#ai-config), using LaunchDarkly hosted or warehouse native [metrics](#metric).

To learn more, read [Experiment metric types](/home/experimentation/types).

### AI Config

An `AI Config` is a LaunchDarkly resource that you create when your application uses artificial intelligence (AI) model generation. It manages the model configurations and messages you use in your application. When you use a LaunchDarkly [AI SDK](/sdk/ai) to [customize an AI Config](/sdk/features/ai-config), the SDK determines which message and model your application should serve to which [contexts](#context). The SDK also customizes the message based on context attributes that you provide.

To learn more, read [AI Configs](/home/ai-configs) and [AI SDKs](/sdk/ai).

### Alert

An `alert` is a notification LaunchDarkly sends when observability data meets a specific condition. Alerts are based on sessions, errors, logs, traces, or events within session replays.

An alert includes these components:

* [Thresholds](#threshold): The numeric values that trigger the alert condition.
* **Windows**: The time ranges LaunchDarkly searches and aggregates data for before deciding if the alert condition is met.
* **Cooldown periods**: The amount of time after a notification is sent before LaunchDarkly can send another notification for the same alert.
* **Recipients**: The members of your organization who receive notifications when the alert condition is met. Notifications are delivered by email and, if configured, through Slack.

Alerts are limited to observability and do not apply to feature flags, rollouts, or experiments.

To learn more, read [Alerts](/home/observability/alerts).

### Analysis method

A [metric's](#metric) `analysis method` is the mathematical technique by which you want to analyze its results. You can analyze results by mean, median, or percentile.

To learn more, read [Analysis method](/home/metrics/components#analysis-method).

### 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](/home/releases/apps-and-app-versions).

### Arm averages graph

In LaunchDarkly [experiment](#experiment) results, the arm averages graph displays the average value over time for each variation. This graph is useful for investigating trends that impact all experiment variations equally over time.

To learn more, read [Bayesian experiment results](/home/experimentation/bayesian-results) and [Frequentist experiment results](/home/experimentation/frequentist-results).

### Attribute

An `attribute` is a field in a [context](#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](/home/flags/context-attributes).

### Audience

An [experiment's](#experiment) `audience` is the combination of the targeting rule you're experimenting on and the number of [contexts](#context) you [allocate](#traffic-allocation) to each flag [variation](#variation).

To learn more, read [Allocating experiment audiences](/home/experimentation/allocation).

## B

### Base role

A `base role` is a set of permissions that describes the access a member has. LaunchDarkly provides Reader, Writer, Admin, and Owner base roles. Some customers also have a restricted No access role.

To learn more, read [Base roles](/home/account/roles/role-concepts#base-roles). For details on the permissions in each base role, read [Organization roles](/home/account/roles/organization-roles).

### Bayesian statistics

In LaunchDarkly [Experimentation](#experiment), `Bayesian statistics` is a results analysis option good for experiments with small sample sizes. The other analysis option is [frequentist statistics](#frequentist-statistics).

To learn more, read [Bayesian versus frequentist statistics](/guides/experimentation/bayesian-frequentist).

### Boolean flag

A `boolean flag` is a feature flag type with two variations that hold `true` and `false`.

Boolean flags can be used for on/off switches, new feature rollouts, or anything that requires a binary option.

To learn more, read [Flag types](/home/flags/types).

## C

### Cohort

A `cohort` can refer to a group of contexts in Amplitude synced with a LaunchDarkly [segment](#segment), or to the targeting rules on a [migration flag](#migration-flag).

To learn more about Amplitude cohorts, read [Syncing segments with Amplitude cohorts](/home/flags/amplitude).

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](/home/flags/target).

### Confidence interval

In [frequentist statistics](#frequentist-statistics), the `confidence interval` is the range of values within which the true [metric](#metric) value is likely to fall if you were to repeat the experiment many times. For example, a 95% confidence interval means that, in repeated experiments, 95% of the calculated intervals would contain the true value of the metric. To learn more, read [Frequentist experiment results](/home/experimentation/frequentist-results).

### 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](/home/flags/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](/home/flags/context-instances).

### Context kind

A `context kind` organizes your [contexts](#context) 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 [Monthly active users (MAU)](#monthly-active-users-mau).

To learn more, read [Context kinds](/home/flags/context-kinds).

### Control variation

The `control variation` is typically the existing flag [variation](#variation) that serves as the benchmark for a [progressive release](#progressive-release-or-progressive-rollout) or [experiment](#experiment). Metric values from the control variation determine whether the [treatment variation](#treatment-variation) has a negative or positive effect on the [metric](#metric) being measured. It is the departure point of the progressive release.

In [multivariate flags](#flag), the person configuring the release can designate any variation as the control when setting up the release.

To learn more, read [Experimentation](/home/experimentation).

### Conversion rate

In [Bayesian](#bayesian-statistics) results, the `conversion rate` column displays the following:

* For count conversion metrics: the total number of times a context triggered a conversion [event](#event)
* For binary conversion metrics: the percentage of contexts that triggered at least one conversion event

To learn more, read [Bayesian experiment results](/home/experimentation/bayesian-results) and [Frequentist experiment results](/home/experimentation/frequentist-results).

### Conversions

In [experiment](#experiment) results, the `conversions` column displays the total number of times a context triggered a conversion [event](#event) measured by a conversion [metric](#metric).

To learn more, read [Bayesian experiment results](/home/experimentation/bayesian-results) and [Frequentist experiment results](/home/experimentation/frequentist-results).

### Credible interval

In [Bayesian statistics](#bayesian-statistics), the `credible interval` is the range of values within which the true [metric](#metric) value is likely to fall, given the observed data and prior beliefs. For example, a 90% credible interval means that there is a 90% probability that the true value lies within this range, based on the posterior distribution. To learn more, read [Bayesian experiment results](/home/experimentation/bayesian-results).

### CUPED

Controlled-experiment using pre-experiment data, or `CUPED`, is a statistical method that uses data collected before an experiment begins to reduce variance in experiment results. Applying CUPED to experiment results makes it easier to detect differences between variations.

To learn more, read [Covariate adjustment and CUPED methodology](/guides/statistical-methodology/cuped).

### Custom role

A `custom role` is a set of permissions that you define that describes the access a member has. When you create a custom role, you define the access using a set of statements. Each statement comprises resources and actions. Together, these are called a [policy](#policy-custom-role).

To learn more, read [Roles](/home/account/roles).

## D

### Dashboard

An observability `dashboard` is a configurable view of observability data in LaunchDarkly. Dashboards include graphs that visualize data about sessions, errors, logs, or traces. Dashboards track error rates, latency, or user engagement over time. Observability dashboards are limited to observability and do not apply to feature flags, rollouts, or experiments.

To learn more, read [Dashboards](/home/observability/dashboards).

### Data Export experiment

A `Data Export experiment` lets you export experiment data to a third-party tool for analysis using [Data Export](/integrations/data-export). Data Export experiments do not require a LaunchDarkly metric, and do not generate analysis results in the LaunchDarkly user interface (UI). This is useful when you want to use LaunchDarkly to manage your experiment, but have a preferred external analysis tool that allows you to import experiment data from other systems.

### Default rule

A `default rule` describes the feature flag [variation](#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 [Set the default rule](/home/flags/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 [The off variation](/home/flags/off-variation).

## E

### Environment

An `environment` is an organizational unit contained within a [project](#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](#flag). However, the flags can have different states, targets, and rules in each environment.

To learn more, read [Environments](/home/account/environment).

### Error

An `error` is an issue in your application that LaunchDarkly records through observability SDKs. LaunchDarkly groups errors based on their messages and stack traces, so you can see how often they occur and what contexts they affect. Error details include the number of affected contexts, when the error was first and most recently observed, and whether it has been resolved. Errors are limited to observability and do not apply to feature flags, rollouts, or experiments.

To learn more, read [Error monitoring](/home/observability/errors).

### Evaluation

An `evaluation` is what happens when:

* your application's code sends the [LaunchDarkly SDK](#sdk) information about a particular [flag](#flag) or [AI Config](#ai-config) and a particular [context](#context) that has encountered it, and
* the SDK sends back the value of the [variation](#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. We say that the SDK *customizes* the AI Config, because for AI Configs the SDK both sends back the value of the variation and also customizes that value based on context attributes.

<Card
  icon={<img src="https://fern-image-hosting.s3.us-east-1.amazonaws.com/launchdarkly/terminal.svg" class="terminal" />

}
  iconPosition="left"
>
  Try it in your SDK: [Evaluating flags](/sdk/features/evaluating), [Customizing AI Configs](/sdk/features/ai-config)
</Card>

### Event

An `event` refers to data that LaunchDarkly [SDKs](#sdk) send to LaunchDarkly when a user or other [context](#context) takes an action in your app. Server-side, client-side, and edge SDKs send analytics events to LaunchDarkly as a result of feature flag evaluations and certain SDK calls.

To learn more, read [Analytics events](/sdk/concepts/events) and [Events](/home/metrics/metric-events).

### Event key

An `event key` is a unique identifier you set for a particular kind of event within your app. [Metrics](#metric) use event keys to identify events for performance tracking. Events are [environment-specific](#environment).

To learn more, read [Events](/home/metrics/metric-events).

### Expected loss

The `expected loss` for a [variation](#variation) within an [experiment](#experiment) is the risk, expressed as a percentage, that the variation will not actually be an improvement over the [control variation](#control-variation) due to the margin of error in metric results. Expected loss displays only for metrics that use an "Average" [analysis method](#analysis-method).

To learn more, read [Bayesian experiment results](/home/experimentation/bayesian-results) and [Frequentist experiment results](/home/experimentation/frequentist-results).

### Experiment

An `experiment` is a LaunchDarkly feature that connects a [flag](#flag) or [AI Config](#ai-config) with one or more [metrics](#metric) to measure end-user behavior. Experiments track how different [variations](#variation) affect end-user interactions with your app, and determine the [winning variation](#winning-variation). You can run an experiment for one or more [iterations](#iteration).

To learn more, read [Experimentation](/home/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](/home/flags/templates).

### Experimentation key

An `experimentation key` is a unique [context](#context) key from a server-side, client-side, AI, or edge SDK, that is included in each experiment:

* If the same context key is in one experiment multiple times, LaunchDarkly counts it as one Experimentation key.
* If the same context key is in two different experiments, LaunchDarkly counts it as two Experimentation keys.

Some customers are billed by Experimentation keys. To learn more, read [Experimentation keys](/home/account/calculating-billing#experimentation-keys).

### Exposures

In LaunchDarkly [experiments](#experiment), `exposures` are the total number of contexts included in the experiment over time.

To learn more, read [Bayesian experiment results](/home/experimentation/bayesian-results) and [Frequentist experiment results](/home/experimentation/frequentist-results).

## F

### Fallback value

The `fallback value` is the value your application should use for a feature flag or AI Config in error situations.

Specifically, for the client-side, server-side, and edge SDKs, the `fallback value` is the flag [variation](#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 [The off variation](/home/flags/off-variation).

For the AI SDKs, the `fallback value` is the value of the variation of your [AI Config](#ai-config) to use if the AI Config is not found or if any errors occur during processing.

Regardless of how you configure variations or targeting rules, each time you evaluate a flag or customize an AI Config from the LaunchDarkly SDK, you must include a fallback value as one of the parameters.

<Card
  icon={<img src="https://fern-image-hosting.s3.us-east-1.amazonaws.com/launchdarkly/terminal.svg" class="terminal" />

}
  iconPosition="left"
>
  Try it in your SDK: [Evaluating flags](/sdk/features/evaluating), [Customizing AI Configs](/sdk/features/ai-config)
</Card>

### Fallthrough rule

A `fallthrough rule` is a synonym for [default rule](#default-rule).

### 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](#context).

To learn more, read [Using feature management](/home/getting-started/feature-management).

### Flag exposure

A `flag exposure` occurs when a unique [context](#context) encounters a [flag](#flag) for the first time and becomes part of the experiment population. Exposures determine which contexts receive the [control variation](#control-variation) or the [treatment variation](#treatment-variation).

In a [guarded rollout](#guarded-release-or-guarded-rollout):

* If the first stage is set to 1%, then 2% of the flag's population participates in the experiment, with 1% receiving the control variation and 1% receiving the treatment variation.
* Guarded rollouts maintain an equal ratio of contexts between variations to ensure fair comparison. When this ratio becomes imbalanced, it creates a [sample ratio mismatch (SRM)](#sample-ratio-mismatch-srm).
* For conversion metrics, all flag exposures count toward that metric's exposure total.
* For other metric types, exposures count only when the contexts generate a [metric event](#event).

To learn more, read [Guarded rollouts](/home/releases/guarded-rollouts).

### Forest plot

In LaunchDarkly frequentist [experiment](#experiment) results, the forest plot shows the confidence interval for each treatment variation with respect to the control variation. The forest plot should be your main decision-making tool when deciding on a winning variation for frequentist experiments.

To learn more, read [Frequentist experiment results](/home/experimentation/frequentist-results).

### Frequentist statistics

In LaunchDarkly [Experimentation](#experiment), `frequentist statistics` is a results analysis option good for experiments with larger sample sizes. The other analysis option is [Bayesian statistics](#bayesian-statistics).

### Funnel metric group

A `funnel metric group` is an ordered list of metrics you can use to create experiments using funnel metric groups, which measure end user progression through a number of steps. Steps in the experiment typically progress from the awareness stage to the purchasing stage of your marketing funnel.

To learn more, read [Metric groups](/home/metrics/metric-groups).

## G

### Guarded release or guarded rollout

A `guarded release` or `guarded rollout` is a [progressive release](#progressive-release-or-progressive-rollout) that includes attached [metrics](#metric). These metrics run a structured A/B experiment to detect whether the [treatment variation](#treatment-variation) has caused a [regression](#regression).

In a guarded rollout, LaunchDarkly gradually increases the percentage of [contexts](#context) that receive a particular flag [variation](#variation) while monitoring those metrics for regressions. To perform this monitoring, you must attach one or more metrics to your flag. You can configure LaunchDarkly to notify you or automatically roll back a release when it detects a regression.

To learn more, read [Guarded rollouts](/home/releases/guarded-rollouts) and [Releasing features with LaunchDarkly](/home/releases/releasing).

## H

### Holdout

A `holdout` is a group of [contexts](#context) that you have temporarily excluded from all or a selected set of your [experiments](#experiment). Holdouts allow you to measure the effectiveness of your Experimentation program.

To learn more, read [Holdouts](/home/holdouts).

### Hypothesis

In LaunchDarkly, a `hypothesis` is a theory or assumption that can be tested with an [experiment](#experiment). A hypothesis should be specific and answer a single question. You can phrase a hypothesis for a LaunchDarkly experiment as:

> If \[I make a specific change to our codebase], then \[one or more measurable metrics will improve] because \[the change had this effect].

To learn more, read [Formulate a hypothesis](/guides/experimentation/designing-experiments#formulate-a-hypothesis).

## I

### Iteration

An `iteration` is a defined time period that you run an [experiment](#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](/home/experimentation/manage).

## J

### JSON flag

A `JSON flag` is a feature flag type with variations that hold structured data as a JSON object or array. They are multivariate flags, meaning they can have more than two variations. JSON flags have a size limit of 32KB.

JSON flags are useful when you need to bundle multiple related values within a single variation, such as settings for a UI layout or an API response.

To learn more, read [Flag types](/home/flags/types).

## 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](/home/flags/templates).

## L

### Layer

A `layer` is a set of [experiments](#experiment) that cannot share traffic with each other. All of the experiments within a layer are [mutually exclusive](#mutually-exclusive-experiment), which means that if a context is included in one experiment, LaunchDarkly will exclude it from any other experiments in the same layer.

To learn more, read [Mutually exclusive experiments](/home/experimentation/mutually-exclusive).

### Log

A `log` is an event in your application that LaunchDarkly records through observability SDKs. Logs include attributes such as level, message, service name, environment, file path, line number, and session ID. Logs help you troubleshoot issues and trace events back to related sessions. Logs are limited to observability and do not apply to feature flags, rollouts, or experiments.

To learn more, read [Logs](/home/observability/logs).

## M

### Mean

In [frequentist](#frequentist-statistics) experiment results, the `mean` is a flag [variation's](#variation) average numeric value that you should expect in an [experiment](#experiment), based on the data collected so far. Only numeric [metrics](#metric) measure the mean value.

To learn more, read [Frequentist experiment results](/home/experimentation/frequentist-results).

### 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 [Members](/home/account/members).

### Metric

A `metric` is a curated event query that defines a specific time series of data based on an underlying [event](#event). A metric defines what you want to measure and the [context kind](#context-kind) used as the analysis unit. Metrics have three types: count, binary, and numeric.

LaunchDarkly uses different kinds of metrics to measure the impact of variation changes, gauge application performance, track account usage, and more.

The different kinds of metrics within LaunchDarkly include:

* **Experimentation and guarded rollout metrics**: these metrics allow you to measure specific end-user behaviors as part of an [experiment](#experiment) or [guarded rollout](#guarded-release-or-guarded-rollout). Metrics can measure things like links clicked, money spent, or response time. When combined with a [flag](#flag) or an [AI Config](#ai-config) in an experiment, metrics determine which [variation](#variation) is the [winning variation](#winning-variation). Metrics send metric [events](#event) to LaunchDarkly. To learn more, read [Metrics](/home/metrics).
* **AI Config metrics**: these metrics are automatically created by LaunchDarkly AI SDKs and monitor the performance of an AI Config. AI Config metrics are available in the LaunchDarkly UI if you [track AI metrics in your SDK](/sdk/features/ai-metrics).
* **Migration flag metrics**: these metrics track the progress of a migration flag. To learn more, read [Migration flag metrics](/home/flags/migration-metrics).
* **Application adoption metrics**: these metrics track the adoption percentage for an application version. To learn more, read [Adoption metrics](/home/releases/apps-and-app-versions#adoption-metrics).
* **Account metrics**: these metrics help you understand your monthly active users (MAU) usage, Experimentation key usage, Data Export usage, and server usage for billing purposes. To learn more, read [Account usage metrics](/home/account/metrics).
* **Launch Insights metrics**: these metrics summarize how your organization is adopting the best practices associated with risk-free releases. To learn more, read [Launch Insights](/home/getting-started/launch-insights).

### Metric estimate

A `metric estimate` is the current expected value for a [metric](#metric). For mean metrics, this value is the [posterior mean](#posterior-mean), which represents the average value of the posterior data for the metric.

To learn more, read [Analyzing experiments](/home/experimentation/analyze).

### 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](/home/flags/templates).

### Monthly active users (MAU)

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

To learn more, read [Account usage metrics](/home/account/metrics).

### Multiple comparisons correction (MCC)

`Multiple comparisons correction` is a statistical method that helps reduce false positives in frequentist experiment results. MCC changes the threshold for declaring significance in experiments to avoid declaring significance too easily.

To learn more, read [Multiple comparisons correction](/guides/statistical-methodology/mcc).

### Mutually exclusive experiment

A `mutually exclusive experiment` is an [experiment](#experiment) configured to prevent its [contexts](#context) from being included in other experiments. Experiments are mutually exclusive from each other when they are contained within the same [layer](#layer).

To learn more, read [Mutually exclusive experiments](/home/experimentation/mutually-exclusive).

## N

### Number flag

A `number flag` is a feature flag type with variations that hold numerical integer or floating point values. They are multivariate flags, meaning they can have more than two variations.

Number flags are useful for numerical configuration parameters, such as thresholds or timeouts.

To learn more, read [Flag types](/home/flags/types).

## O

### Observability settings

`Observability settings` are project-level settings that control how LaunchDarkly ingests and manages observability data.

Observability settings include these components:

* **Filters**: Rules that exclude sessions, errors, logs, or traces before ingestion. Filtered data does not count against observability quotas.
* **Sampling**: A percentage value that controls how many records LaunchDarkly ingests. Sampling helps reduce data volume.
* **Rage click detection**: Configurable options for detecting repeated end-user clicks that indicate frustration. Settings include elapsed time, click radius, and minimum number of clicks.
* **Source maps**: Uploaded files that let LaunchDarkly display error stack traces in human-readable form.
* **Auto-resolution rules**: Options to automatically resolve errors that have not occurred for a defined period of time.

Observability settings are limited to observability and do not apply to feature flags, rollouts, or experiments.

To learn more, read [Observability settings](/home/observability/settings).

### Organization role

An `organization role` is a type of [role](#role). It is a set of permissions that you can assign to an account member. LaunchDarkly provides several of these as [preset roles](#preset-roles), including Billing Admin, Admin, Architect, and Member.

To learn more, read [Roles](/home/account/roles), [Organization roles](/home/account/roles/organization-roles), and [Member role concepts](/home/account/roles/role-concepts).

## P

### P-value

In [frequentist](#frequentist-statistics) experiment results, a [treatment variation's](#treatment-variation) probability value, or `p-value`, is the likelihood that the observed difference from the [control variation](#control-variation) is due to random chance. A p-value of less than or equal to 0.05 is statistically significant. The lower the p-value, the less likely the [relative difference](#relative-difference-from-control) is due to chance alone.

### Percentage rollout

A `percentage rollout` is a rollout option for a targeting [rule](#rule) that serves a given flag [variation](#variation) to a specified percentage of contexts that encounter the flag. A common use case for percentage rollouts is to manually 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](/home/releases/percentage-rollouts) and [Releasing features with LaunchDarkly](/home/releases/releasing).

### Policy (custom role)

A `policy` is part of a [custom role](#custom-role). A policy combines resources and actions into a set of statements that define what members can or cannot do in LaunchDarkly. You can create policies using the [policy builder](/home/account/roles/role-create#create-policies-for-roles) or the [advanced editor](/home/account/roles/advanced-editor).

To learn more, read [Roles](/home/account/roles) and [Using policies](/home/account/roles/role-policies).

### Posterior distribution

In [Bayesian statistics](#bayesian-statistics), the `posterior distribution` is the expected range of outcomes for a [treatment variation](#treatment-variation) based on prior beliefs about your data gathered from the control variation.

To learn more, read [Bayesian versus frequentist statistics](/guides/experimentation/bayesian-frequentist).

### Posterior mean

In [Bayesian](#bayesian-statistics) experiment results, the `posterior mean` is a flag [variation's](#variation) average numeric value that you should expect in an [experiment](#experiment), based on the data collected so far. Only numeric [metrics](#metric) measure the posterior mean.

To learn more, read [Bayesian experiment results](/home/experimentation/bayesian-results).

### Preset roles

A `preset role` refers to a [project role](#project-role) or [organization role](#organization-role) that LaunchDarkly provides for customers on select plans. You can assign a preset role to members or teams in your account. You can also add [policy statements](#policy-custom-role) to a preset role. However, you cannot remove existing policy statements from a preset role.

To learn more, read [Preset roles](/home/account/roles/role-concepts#preset-roles). For details on the permissions in each preset role, read [Project roles](/home/account/roles/project-roles) and [Organization roles](/home/account/roles/organization-roles).

### 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](#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](/home/flags/prereqs).

### Primary context kind

The `primary context kind` is the [context kind](#context-kind) with the highest volume of monthly activity. For most customers, the primary context kind is `user`.

For billing purposes, LaunchDarkly only charges for contexts from the primary context kind, called [MAU](#monthly-active-users-mau). 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 [Context kinds](/home/flags/context-kinds). To learn more about billing by contexts, read [Calculating billing](/home/account/calculating-billing).

### Probability density graph

In LaunchDarkly Bayesian [experiment](#experiment) results, the probability density graph displays fine differences in probability for each experiment variation over time.

To learn more, read [Bayesian experiment results](/home/experimentation/bayesian-results).

### Probability to be best

In [Bayesian](#bayesian-statistics) experiment results, the [variation](#variation) with the highest `probability to be best` is the variation that has the largest positive impact on the metric you're measuring. Probability to be best displays only for metrics that use an "Average" [analysis method](#analysis-method).

To learn more, read [Bayesian experiment results](/home/experimentation/bayesian-results).

### Probability to be worse

In LaunchDarkly's [Bayesian model](/guides/experimentation/bayesian-frequentist), `probability to be worse` indicates how likely it is that the [treatment variation](#treatment-variation) performs worse than the [control variation](#control-variation). LaunchDarkly calculates this value by drawing numerous samples from the posterior distributions of both variations and calculating how often the treatment's sampled value is worse than the control's by more than the defined [regression threshold](#threshold).

To learn more, read [Bayesian experiment results](/home/experimentation/bayesian-results).

### Probability to beat control

In [experiment](#experiment) results, a [treatment variation's](#treatment-variation) `probability to beat control` is the likelihood that the variation is better than the control variation.

To learn more, read [Bayesian experiment results](/home/experimentation/bayesian-results).

### Progressive release or progressive rollout

A `progressive release` or `progressive rollout` is the delivery of a feature flag rule that gradually increases traffic from a low percentage up to 100%. In a progressive rollout, LaunchDarkly gradually increases the percentage of [contexts](#context) that are receiving a particular flag [variation](#variation). You can specify the duration and how the percentage increases. A common use case for progressive rollouts is to automatically 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 [Progressive rollouts](/home/releases/progressive-rollouts) and [Releasing features with LaunchDarkly](/home/releases/releasing).

### Project

A `project` is an organizational unit in your LaunchDarkly account. Many LaunchDarkly resources, such as [flags](#flag) and [AI Configs](#ai-config), are unique at the project level. Customers on plans that allow creating your own [roles](#custom-role) can choose to limit access for members or teams based on project.

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 has multiple [environments](#environment), and may include multiple [views](#view).

To learn more, read [Projects](/home/account/project).

### Project role

A `project role` is a type of [role](#role). It is a set of permissions that you can assign to an account member. LaunchDarkly provides several of these as [preset roles](#preset-roles), including Project Admin, Contributor, Developer, Maintainer, and Viewer. Customers on select plans can also create their own project roles.

To learn more, read [Roles](/home/account/roles), [Project roles](/home/account/roles/project-roles), and [Member role concepts](/home/account/roles/role-concepts).

## R

### Randomization unit

An [experiment's](#experiment) `randomization unit` is the [context kind](#context-kind) that the experiment uses to randomly sort [contexts](#context) into each [variation](#variation), according to the experiment's [traffic allocation](#traffic-allocation).

A [guarded rollout's](#guarded-release-or-guarded-rollout) `randomization unit` is the [context kind](#context-kind) that the rollout's [flag](#flag) and [metrics](#metric) use when tracking a flag variation's performance over time.

Any percentage-based release requires a defined randomization unit. This unit is the chosen context kind used both to randomize the exposure traffic for the release and to measure the associated [metrics](#metric).

To learn more, read [Randomization units](/home/experimentation/randomization).

### Regression

A `regression` is when LaunchDarkly detects a negative effect on your application performance as a result of a flag change or rollout. You can use guarded rollouts to notify you or automatically roll back a release when it detects a regression.

To learn more, read [Guarded rollouts](/home/releases/guarded-rollouts).

### Relative difference

The `relative difference` is the percentage difference between the [metric estimates](#metric-estimate) for the [control variation](#control-variation) and the [treatment variation](#treatment-variation). Relative difference measures how much the treatment's performance differs from the control's benchmark.

To learn more, read [Bayesian experiment results](/home/experimentation/bayesian-results) and [Frequentist experiment results](/home/experimentation/frequentist-results).

### Relative difference graph

In LaunchDarkly [experiment](#experiment) results, the relative difference graph displays a time series of the relative difference between the treatment variation and the control. This graph is helpful for investigating trends in relative differences over time.

To learn more, read [Bayesian experiment results](/home/experimentation/bayesian-results) and [Frequentist experiment results](/home/experimentation/frequentist-results).

### Relative difference from control

In [experiment](#experiment) results, the `relative difference from control` column displays how much a metric in the treatment variation differs from the control variation, expressed as a proportion of the control's estimated value.

To learn more, read [Bayesian experiment results](/home/experimentation/bayesian-results) and [Frequentist experiment results](/home/experimentation/frequentist-results).

### Release flag

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

To learn more, read [Flag templates](/home/flags/templates).

### Release pipeline

A `release pipeline` lets you move flags through a series of phases, rolling out flags to selected [environments](#environment) and audiences following automated steps. You can use release pipelines to view the status of ongoing releases across all flags within a [project](#project), enforcing a standardized process and ensuring they are following best practices.

Release pipelines are in beta, and are available only to certain customers with an Enterprise plan.

To learn more, read [Release pipelines](/home/releases/release-pipelines).

### Release policy

A `release policy` is a prescribed set of default configurations or preferences that define how releases are created within a given scope. Release policies standardize release behavior so that engineers do not need to configure all release settings individually. For example, a release policy can specify that all [guarded releases](#guarded-release-or-guarded-rollout) in a production environment use automatic rollbacks and require a minimum sample size of 100.

To learn more, read [Release policies](/home/releases/release-policies).

### Role

A `role` is a description of the access that a [member](#member) or [team](#team) has within LaunchDarkly. Every LaunchDarkly account comes with several built-in [base roles](#base-role), including Reader, Writer, Admin, and Owner.

Customers on select plans additionally have:

* access to a No access base role.
* access to several [organization roles](#organization-role) and [project roles](#project-role) provided by LaunchDarkly. These provide different sets of permissions that are commonly grouped together, designed around typical personas. For example, LaunchDarkly provides a Developer project role that can perform all flag actions within projects they are assigned, and a Contributor project role that can make changes to flag status but cannot perform destructive actions on it.
* the ability to create their own roles, sometimes called custom roles. When you create your own role, you define the access using a set of statements called a policy.

Every member must have at least one 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 [Roles](/home/account/roles) and [Member role concepts](/home/account/roles/role-concepts).

### Role attribute

A `role attribute` is a key that you may use to parameterize a [role](#role). When you define a role, you can optionally specify a [role scope](#role-scope) and corresponding role attributes. Some [preset roles](#preset-roles) also include role scope.

For example, suppose Member A should have access to all actions on flags in Project A, and Member B should have access to all actions on flags in Project B. You can create one role with access to all actions on flags, and set a role scope of project, using a role attribute of `developerProjectKey`.

When you assign this role to Member A, you can specify "Project A" as the value of the `developerProjectKey` role attribute. This gives Member A access to all actions on flags in Project A. When you assign the same role to Member B, you can specify "Project B" as the value of the `developerProjectKey` role attribute to give Member B access to all actions on flags in Project B.

`roleAttributes` cannot be passed through SAML assertions for single sign-on. For SAML-based SSO, LaunchDarkly supports mapping only the `role`, `customRole`, and `teamKey` attributes.

To learn more, read [Member role concepts](/home/account/roles/role-concepts).

### Role scope

A `role scope` is a [resource type](/home/account/roles/role-resources) by which a [role](#role) may be parameterized. When you define a role, you can optionally specify a role scope and the parameter, which is called a [role attribute](#role-attribute). Some [preset roles](#preset-roles) also include role scope.

For example, suppose Member A should have access to all actions on flags in Project A, and Member B should have access to all actions on flags in Project B. You can create one role with access to all actions on flags, and set a role scope of project. Then, you can specify Project A when you assign this role to Member A, and specify Project B when you assign this role to Member B.

To learn more, read [Member role concepts](/home/account/roles/role-concepts).

### Rule

A `rule` or `targeting rule` is a description of which [contexts](#context) should be included for a given outcome. In [flags](#flag), targeting rules determine which flag variations your application should serve to which contexts. In [segments](#segment), targeting rules determine which contexts are part of the segment. In [AI Configs](#ai-config), targeting rules determine which 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 [Target with flags](/home/flags/target), [Targeting contexts in rule-based and smaller list-based segments](/home/flags/rule-based-segments), [Targeting contexts in larger list-based segments](/home/flags/list-based-segments), and [Target with AI Configs](/home/ai-configs/target).

## S

### Sample ratio mismatch (SRM)

A `sample ratio mismatch` (SRM) occurs when the distribution of traffic across different [variations](#variation) deviates from the expected allocation. An SRM can bias or invalidate results. SRMs are most commonly caused by outdated [SDKs](#sdk) or issues with SDK or [metric](#metric) implementation.

To learn more, read [Analyzing experiments](/home/experimentation/analyze).

### Saved search

A `saved search` is a set of search filters stored in the LaunchDarkly UI. Saved searches return specific sessions or errors and can be shared with others through URLs. Saved searches are limited to observability and do not apply to feature flags, rollouts, or experiments.

To learn more, read [Search specification](/home/observability/search).

### 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](/home/getting-started/setting-up) and [Choosing an SDK type](/sdk/concepts/client-side-server-side). For more information about the differences between the LaunchDarkly SDK and the LaunchDarkly REST API, read [Comparing LaunchDarkly's SDKs and REST API](/guides/api/comparing-sdk-rest-api).

### Search specification

A `search specification` defines the syntax and operators available to query and filter observability data. It supports comparisons, logical operators, regex, wildcards, and saved searches across sessions, errors, logs, and traces. The search specification is limited to observability and does not apply to feature flags, rollouts, or experiments.

To learn more, read [Search specification](/home/observability/search).

### Segment

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

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](/home/flags/segments).

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

* You can use Twilio Segment as a destination for LaunchDarkly's Data Export feature. To learn more, read [Twilio Segment for Data Export](/integrations/data-export/segment).
* You can use Twilio Segment as a source for metric events. To learn more, read [Twilio Segment for metrics](/integrations/metric-segment).
* Twilio Segment Audiences is one of several tools you can use to create synced segments. To learn more, read [Segments synced from external tools](/home/flags/synced-segments).

### Session

A `session` is a recorded period of interaction between an end user and your application. Sessions are captured by the session replay SDK plugin and may include events, errors, logs, and traces. Sessions are the foundation for replays and can be filtered by attributes such as browser, device, or location. Sessions are limited to observability and do not apply to feature flags, rollouts, or experiments.

To learn more, read [Session replay](/home/observability/session-replay).

### Session replay

A `session replay` is a recorded exploration of an end user's session in your application. LaunchDarkly records user interactions so you can play them back to understand behavior, diagnose issues, and improve user experience. Session replays are limited to observability and do not apply to feature flags, rollouts, or experiments.

To learn more, read [Session replay](/home/observability/session-replay).

### Significance level

The `significance level` of a frequentist [experiment](#experiment) is the configured allowable rate of false positives for an experiment. This is sometimes called the "false positive rate." The significance level is usually represented by the Greek letter "alpha."

### Span

A `span` is the fundamental unit of a [trace](#trace). A span represents a single operation or step in a trace and includes attributes such as span name, duration, parent span ID, and related context. Spans are limited to observability and do not apply to feature flags, rollouts, or experiments.

To learn more, read [Traces](/home/observability/traces).

### Standard metric group

A `standard metric group` is a reusable set of metrics you can use to standardize metrics across multiple experiments.

To learn more, read [Metric groups](/home/metrics/metric-groups).

### Statistical significance

In frequentist [experiments](#experiment), `statistical significance` indicates the likelihood that the observed relationship or effect in the data is not due to random chance. When an experiment result is statistically significant, it means the observed effect is unlikely to have occurred purely by random variation.

### String flag

A `string flag` is a feature flag type with variations that hold simple configuration values. They are multivariate flags, meaning they can have more than two variations.

String flags can be used for things like switching between different versions of header text, URLs, or other configurations.

To learn more, read [Flag types](/home/flags/types).

## T

### Target

To `target` (verb) is to specify that specific [contexts](#context) that encounter [feature flags](#flag) or [AI Configs](#ai-config) in your application should receive a specific variation of that resource. A `target` (noun) is an individual context or a set of contexts described by a targeting [rule](#rule).

To learn more, read [Target with flags](/home/flags/target), [Targeting contexts in rule-based and smaller list-based segments](/home/flags/rule-based-segments), [Targeting contexts in larger list-based segments](/home/flags/list-based-segments), and [Target with AI Configs](/home/ai-configs/target).

### Team

A `team` is a group of members in your LaunchDarkly account. To learn more, read [Teams](/home/account/teams).

### Threshold

In Bayesian [experiments](#experiment), the `threshold` indicates how confident you'd like to be in the experiment's results before making a decision. A standard threshold is 90%, which means that you want an experiment [treatment variation](#treatment-variation) to have a [probability to beat the control](#probability-to-beat-control) variation of at least 90% before declaring it a [winning variation](#winning-variation).

If you require higher confidence, such as 95% or 99%, it will typically take more time to gather enough data to reach that level of certainty. To learn more, read [Bayesian experiment results](/home/experimentation/bayesian-results).

### Total value

In [experiment](#experiment) results, the `total value` column displays the sum total of all the numbers returned by a numeric metric.

To learn more, read [Bayesian experiment results](/home/experimentation/bayesian-results) and [Frequentist experiment results](/home/experimentation/frequentist-results).

### Trace

A `trace` is a record of activity across spans in your application. Traces show how requests flow through services and components. Each trace consists of spans, which include attributes such as span name, duration, and related context. Traces are limited to observability and do not apply to feature flags, rollouts, or experiments.

To learn more, read [Traces](/home/observability/traces).

### Traffic allocation

An [experiment's](#experiment) `traffic allocation` is the amount of [contexts](#context) you assign to each flag [variation](#variation) you're experimenting on.

To learn more, read [Allocating experiment audiences](/home/experimentation/allocation).

### Treatment variation

The `treatment variation` is the new flag [variation](#variation) being released during a [progressive release](##progressive-release-or-progressive-rollout) or [experiment](#experiment). It is compared against the [control variation](#control-variation) to determine if the treatment has a negative or positive effect on the [metric](#metric) being measured. If the treatment variation's metrics perform worse than the control, LaunchDarkly identifies a [regression](#regression). The treatment variation represents the change being introduced in the progressive release.

To learn more, read [Experimentation](/home/experimentation).

## U

### Unit aggregation method

The `unit aggregation method` for a [metric](#metric) is the mathematical method you want to aggregate [event](#event) values by for the metric's results. You can aggregate either by sum or by average.

To learn more, read [Unit aggregation method](/home/metrics/components#aggregation-method).

### 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](#context). 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](#context-kind) of context.

People who are logged in to the LaunchDarkly user interface are called [members](#member).

## V

### Variation

A `variation` is a description of a possible value that a [flag](#flag) or [AI Config](#ai-config) can have.

For flags, each variation must contain the possible flag value. It may also contain a name and description. For AI Configs, each variation must contain a model and one or more messages. It must also have a name.

Both flags and AI Configs share variations across environments within a project. However, they can have different states, [targets](#target), and [rules](#rule) 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.

AI Config variations all have the same structure: a name, model configuration, and one or more messages.

To learn more, read [Creating flag variations](/home/flags/variations) and [Create and manage AI Config variations](/home/ai-configs/create-variation).

In [migration flags](#migration-flag), 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](/home/flags/target).

### View

A `view` is a resource that logically groups flags within a [project](#project). You can create multiple views within each project. For example, you can use views to group flags according to the teams in your organization and the features they work on. A given flag can be linked to more than one view.

Views let you restrict access to sets of flags. For example, you can create a role that only allows access to flags in certain views.

To learn more, read [Views](/home/account/views). For an example of using a view in a role policy, read [Example: View-specific permissions](/home/account/roles/example-roles#example-view-specific-permissions).

## W

### Winning variation

An [experiment's](#experiment) `winning variation` is the [variation](#variation) that performed the best out of all the variations tested.

For [Bayesian](#bayesian-statistics) experiments, the winning variation is the variation with the highest [probability to be best](#probability-to-be-best) that exceeds the Bayesian [threshold](#threshold) you set when you created the experiment. If a Bayesian experiment has collected enough data to determine a winning variation, and that winning variation is not the control, then the winning variation is highlighted in green in its results table.

For [frequentist](#frequentist-statistics) experiments, every experiment iteration displays each variation's [p-value](#p-value). The variation with the highlighted p-value is the winning variation.

To learn more, read [Analyzing experiments](/home/experimentation/analyze).