Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs-staging.auth0-mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

Auth0 Experiment Center is a native Auth0 experimentation engine. It lets you A/B test changes to your authentication experience and see the impact in your auth event 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.

​
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.
During Beta, Experiment Center runs on development tenants only. Production tenants are not supported.

​
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:
StatusMeaning
draftCreated but not running. Safe to test using query parameter overrides.
activeRunning. Variant assignment and context injection are live for all auth transactions.
pausedTemporarily suspended. No new assignments. In-flight sessions keep their assigned variation.
completedConcluded. No new assignments. Configuration retained for reference during manual promotion.
archivedSoft-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.

​
Experiment context

When an experiment is active and a variation is assigned, the Experiment Center injects an ExperimentContext object into your runtime surfaces. ACUL screens receive it only when you opt the screen in via context_configuration. To learn more, read ACUL integration guide. Actions and page templates receive it automatically whenever an experiment is active. The object shape: 
{
  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.

​
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:
StatusMeaning
draftCreated but not yet active. Cannot be referenced by an active experiment.
activeReady for use. Required before any experiment that references this flag can activate.
archivedTerminal. No new experiments can reference this flag. Create a new flag if needed.
To learn more about the feature flag entity, read Entities Details.

​
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.

​
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.

​
Limitations

The following limitations apply during Beta:
  • One active experiment per tenant. You can have many experiments in draft, paused, or completed states, but only one can be active at a time.
  • Structured parameters only. Feature flag parameters use the key/type/value structure.
  • Three Actions triggers. Experiment context is available in post_login, pre_user_registration, and post_user_registration.
  • Test traffic only. Beta runs on development tenants with traffic you generate. Production end-user data does not flow through Beta.
  • Manual promotion. When an experiment completes, you apply the winning variation’s configuration to your tenant manually. Automated promotion is post-GA.

​
Learn more

Read Entities Details to learn about Experiment Center entities and properties. Read Experiment Center Quickstart to learn how to create a flag, activate an experiment, and observe enriched log events end to end.