Experiment creation and lifecycle

Simple terms

An experiment is the actual test that can be shown to visitors. It owns the variants, targeting, traffic, metrics, QA, and launch status.

The core A/B testing workflow: create a draft, configure targeting and metrics, build variants, QA, launch, monitor, pause, complete, archive, or restore.

Routes

• /tests
• /tests/new
• /tests/[id]

Implementation behavior

• An Experiment owns status, traffic allocation, targeting JSON, schedule, planned-test settings, sequential settings, and optional backlog source.
• Each experiment has Variation records with weight, control flag, mutation payloads, code workspace metadata, and preview state.
• Primary and secondary metrics are connected through ExperimentGoal; a primary metric is required for meaningful launch/readback.
• Status transitions gate runtime eligibility: draft is not delivered, running can be assigned, paused stops new delivery, completed feeds readback, archived hides from default operations.
• Conflict checks compare targeting and schedule against other live or scheduled tests before launch.

How to use it

• Create the experiment from an idea or from /tests/new.
• Set the target URL/audience, traffic allocation, and schedule before building variants.
• Attach at least one primary metric and any secondary metrics.
• Build the variants, run QA, resolve blockers, then start the experiment.
• Pause for emergencies, complete after enough evidence, archive when it should leave the operating list.

When not to use it

• Do not launch an experiment for a change you already know you want to ship to everyone; use a feature flag or direct implementation.
• Do not create a test without a measurable primary metric.
• Do not run overlapping tests on the same page/audience unless the conflict is intentional and understood.

Implementation source

• Pages live under src/app/(dashboard)/tests.
• Dashboard handlers live under /api/experiments, /api/variations, and experiment subroutes for start, pause, complete, archive, restore, QA, goals, conflicts, and code workspaces.
• The Prisma models are Experiment, Variation, Goal, and ExperimentGoal; public automation uses /api/v1/experiments.

Data and API

• Prisma models: Experiment, Variation, Goal, ExperimentGoal, Page, Segment, AuditLog.
• Internal APIs: /api/experiments, /api/experiments/[id], /api/experiments/[id]/start, /api/experiments/[id]/pause, /api/experiments/[id]/complete, /api/experiments/[id]/archive, /api/experiments/[id]/restore, and /api/experiments/conflicts.
• Public APIs: /api/v1/experiments, /api/v1/experiments/{id}, /api/v1/experiments/{id}/start, /pause, /complete, /duplicate.

Failure modes

• Cannot launch: check missing primary metric, missing variant, no URL/audience, zero traffic allocation, or unresolved QA blockers.
• Visitors not assigned: experiment is not running, targeting does not match, or the SDK is not installed on that page.
• Overlapping tests: use conflict output to adjust URL, segment, schedule, or traffic.