> ## Documentation Index
> Fetch the complete documentation index at: https://docs-staging-automated-sdk-version-update.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Experiment Center

> Learn about Auth0 Experiment Center and how to create authentication flows for A/B testing.

export const ReleaseStageNotice = ({feature, stage, plans, contact, terms}) => {
  const stageTextMap = {
    "beta": "Beta",
    "ea": "Early Access"
  };
  const stageText = stageTextMap[stage] || "a product release stage";
  const prsLink = "/docs/troubleshoot/product-lifecycle/product-release-stages";
  const linkify = (text, url) => {
    return <a href={url} target="_blank" rel="noreferrer" class="link">{text}</a>;
  };
  const includeDetails = (plans, contact, terms) => {
    const hasDetails = terms || plans || contact;
    if (!hasDetails) return null;
    return <span data-as="p">
            {plans && <>This feature is available for {linkify(`${plans} plans`, "https://auth0.com/pricing")}. </>}
            {contact && "To participate, contact " + contact + ". "}
            {terms && <>By using this feature, you agree to the applicable Free Trial terms in Okta's {linkify("Master Subscription Agreement", "https://www.okta.com/legal")}.</>}
        </span>;
  };
  return <Warning>
            <span data-as="p">
                <strong>The {feature} feature is in {linkify(stageText, prsLink)}.</strong>
            </span>

            {includeDetails(plans, contact, terms)}
        </Warning>;
};

<ReleaseStageNotice feature="Auth0 Experiment Center" stage="ea" plans="Enterprise" contact="your Account Executive" />

Auth0 Experiment Center is a native Auth0 experimentation engine. It lets you A/B test changes to your [authentication](/docs/authenticate/login/auth0-universal-login) experience and see the impact in your auth event [logs](/docs/deploy-monitor/logs).

With Experiment Center, you define your A/B test in Auth0, traffic splits deterministically, and your existing auth events come back enriched with experiment metadata so you can analyze results in your own tools.

Experiment Center is part of the [Auth0 Identity Conversion Suite](/docs/customize/identity-conversion-suite).

## How it works

Experiment Center lets you run controlled A/B tests on your Auth0 authentication pipeline. Instead of deploying a change to every user at once, you expose new behavior to a controlled percentage of traffic, measure the result through enriched auth events, and promote the winner when you are ready.

Experiment Center is built around three entities:

* **Experiment**: defines how traffic is split and when the test runs.
* **Feature flag**: defines what you are testing and the possible variations.
* **Segment**: defines a set of rules to route experiments to specific variations.

<Warning>
  Customer is responsible for using functionality related to cookies and similar technologies only for purposes that are strictly necessary for the Customer to provide its services to its end-users.

  To learn more, read [Auth0 General Data Protection Regulation Compliance](/docs/secure/data-privacy-and-compliance/gdpr).
</Warning>

## Experiment

An experiment is a measurement wrapper around a feature flag. It defines:

* Which feature flag is being tested
* How traffic is allocated across variations
* When the test is running

Each experiment references exactly one feature flag.

### Experiment lifecycle

Experiments have five states:

| Status      | Meaning                                                                                      |
| ----------- | -------------------------------------------------------------------------------------------- |
| `draft`     | Created but not running. Safe to test using query parameter overrides.                       |
| `active`    | Running. Variant assignment and context injection are live for all auth transactions.        |
| `paused`    | Temporarily suspended. No new assignments. In-flight sessions keep their assigned variation. |
| `completed` | Concluded. No new assignments. Configuration retained for reference during manual promotion. |
| `archived`  | Soft-deleted. Hidden from default list views. Analytics data retained.                       |

### Allocation strategies

An experiment uses one of two allocation strategies:

**Percentage-based:** Traffic is split across variations by weight. All weights must sum to 100. A weight of 0 is valid (the variation is in the experiment definition but receives no traffic).

**Segment-based (targeted):** Traffic is routed to variations based on segment membership. Segments are evaluated in priority order. The first matching segment wins. If no segment matches, the `is_fallback` allocation receives the request.

To learn more about the experiment entity, read [Entities Details](/docs/customize/experiment-center/entities#experiment).

### Experiment context

When an experiment is active and a variation is assigned, Experiment Center injects an `ExperimentContext` object into your runtime surfaces.

[ACUL](/docs/customize/login-pages/advanced-customizations#advanced-customizations-for-universal-login-acul) screens receive it only when you opt the screen in via `context_configuration`.
To learn more, read [ACUL integration guide](/docs/customize/experiment-center/integrations/acul-integration-guide).

[Actions](/docs/customize/actions/actions-overview) and [page templates](/docs/customize/login-pages/universal-login/customize-templates#customize-universal-login-page-templates) receive it automatically whenever an experiment is active. The object shape:

```typescript theme={null}
{
  experiment_id: string;   // The active experiment ID
  variation_id: string;    // The assigned variation ID
  config: {                // Merged configuration (baseline + overrides)
    [paramName]: { value: unknown }
  };
  is_control: boolean;     // True if this is the control variation
}
```

The `config` field contains the complete merged configuration for the assigned variation. Every parameter defined on the feature flag always has a value. You do not need to write fallback logic.

### Assignment

An assignment is how a user gets routed to a specific variation during an auth transaction. Assignments are deterministic and sticky: the same user consistently sees the same variation for the same experiment on the same device, so their experience stays stable across logins.

* **Percentage allocation** splits traffic across variations by weight. A given subject is consistently assigned to the same variation.
* **Segment allocation** evaluates the request's properties against your segment rules in priority order. The first matching segment determines the variation, and a request that matches the same segment always resolves to the same variation.

Assignment results are recorded in your tenant logs under `details.experiment`; they are not exposed through a separate API.

To learn more about the assignment entity, read [Entities Details](/docs/customize/experiment-center/entities#assignment).

## Feature flag

A feature flag is the control unit for what is being tested. It contains:

* A **baseline configuration**: typed parameters and their default values
* One or more **variations**: alternative configurations that differ from the baseline

Feature flags are tenant-scoped and reusable. The same flag can be referenced by multiple experiments over time (for example, a Q1 test and a Q2 refinement on the same feature).

### Feature flag lifecycle

Feature flags have a stored lifecycle with three states:

| Status     | Meaning                                                                               |
| ---------- | ------------------------------------------------------------------------------------- |
| `draft`    | Created but not yet active. Cannot be referenced by an active experiment.             |
| `active`   | Ready for use. Required before any experiment that references this flag can activate. |
| `archived` | Terminal. No new experiments can reference this flag. Create a new flag if needed.    |

To learn more about the feature flag entity, read [Entities Details](/docs/customize/experiment-center/entities#feature-flag).

### Variation

A variation is one version of the experience defined within a feature flag. It specifies which configuration parameters differ from the baseline, and by how much.

* The **control variation** is the baseline; it has empty overrides (no parameters changed from the flag's defaults).
* **Treatment variations** each specify one or more parameter overrides.

Variations do not carry an `is_control` marker. Whether a variation is the statistical control for a given experiment is set on the allocation, not the variation. The same variation can be the control in one experiment and a treatment in another.

To learn more about the variation entity, read [Entities Details](/docs/customize/experiment-center/entities#variation).

## Segment

A segment is a named group of authentication requests that match a set of rules. You use segments in targeted allocation experiments to route specific traffic cohorts to specific variations.

Segments are tenant-scoped and reusable across experiments.

To learn more about the segment entity, read [Entities Details](/docs/customize/experiment-center/entities#segment).