Managing experiments

In the admin: Experiments — the screen this page documents (opens in the running app).

What/why: Experimentation — what this screen manages and why it exists.

Purpose: create and run A/B experiments — split visitors between variants, watch the goal metric, and promote the winner — without a rebuild or deploy.

When to use

• Testing which persona path (track) converts better for a segment of visitors.
• Testing a presentation (theme + layout) variant against the current look — see the presentation-experiment walkthrough.
• Stopping an experiment early, or promoting a winning variant.

Prerequisites

• Admin access with the edit_data capability (any data_editor or admin role).

Steps

1. Open Admin → Experiments (/admin/experiments). The list shows every experiment with its status, goal metric, arm count, and control.
2. Create — click New experiment, choose what to test (track or presentation; fixed once created), add at least two variants with one marked as control, set the goal metric and guardrails (minimum sample size per variant, minimum runtime), and save the draft.
3. Start — from the list, start a draft experiment. Traffic is split evenly between arms from that moment.
4. Stop / Resume — pause an experiment (visitors fall back to the default experience) and resume it later; assignment is sticky, so returning visitors keep their arm.
5. Promote — open the experiment's detail screen (where the per-arm results live) and promote the winning variant once the guardrails are met. Promotion applies the winner as the new default and concludes the experiment.

Behavior guarantees

• Every lifecycle action (start / stop / resume / promote) is guarded server-side and audited.
• Guardrails (sample size, runtime) protect against promoting on noise — the results view shows progress against them.

For the metrics an experiment can target and how they're computed, see the behavioral metrics reference.