Review & Publish
Step 5 is the final step before your experiment goes live. A vs B runs a series of pre-flight checks to catch common configuration problems, then gives you one last opportunity to review everything before you click publish.
Pre-flight checks
A vs B automatically validates four things before allowing you to publish:
1. Snippet is installed
A vs B checks whether the snippet is detected on the website URL associated with your project. If the snippet is not detected, the experiment cannot run because there is nothing to evaluate targeting rules or inject variation code.
If this check fails: Go to Project Settings → Snippet and follow the installation guide. See Verifying Installation for troubleshooting help.
2. URL targeting is configured
The experiment must have at least one URL targeting rule. Without a targeting rule, A vs B would not know which pages to run the experiment on.
If this check fails:Click the Edit button next to "Targeting" to go back to Step 1 and add at least one URL rule.
3. Variations are valid
The experiment must have at least two variations (Control + at least one Variant), and all variation traffic splits must add up to exactly 100%.
If this check fails:Click the Edit button next to "Variations" to go back to Step 2 and adjust the configuration.
4. At least one metric is selected
The experiment must have at least one metric to track. Without a metric, there is nothing to compare between variations and no way to determine a winner.
If this check fails:Click the Edit button next to "Metrics" to go back to Step 3 and select or create a metric.
Reviewing the experiment summary
Below the pre-flight checklist, you will see a summary of your experiment configuration:
- Targeting rules and audiences
- Variations, traffic splits, and whether each has CSS or JS
- Primary metric and any secondary metrics
Review this carefully before publishing. Once an experiment is live, some settings (like variation code) can be edited, but changing an experiment mid-run can affect the statistical validity of your results.
Where analysis configuration lives
The stats engine, confidence level, variance-reduction mode, ROPE bounds, and the analysis plan all live on the previous step — Analysis— not on Review. Click the Analysis tab in the builder sidebar to change any of these. If the pre-flight checklist below shows an Analysis Plan Complete row that is failing, the failure links back to the Analysis step.
Once the experiment is published, the analysis fields become read-only. Switching stats engine or variance-reduction mode mid-flight would invalidate the result, so the API rejects changes to these fields once the experiment leaves DRAFT or SCHEDULED. See Variance Reduction (CUPED) and Choosing a stats engine for background on each option.
Publishing the experiment
The pre-flight checklist is more than informational — it now gates launch. Until every check shows a green checkmark, both the Publish and Schedule controls stay disabled. This includes the JS Snippet Detected on Site check: if the snippet has not been detected on your site yet, you cannot publish or schedule until it is.
When all checks pass, the Publish experiment button becomes active. Click it. A confirmation modal appears with a final warning that publishing will make the experiment live for real visitors on your website. Click Publish to confirm.
The experiment immediately switches to Runningstatus. You are redirected to the experiment's results page.
Publishing from the builder header
You don't have to scroll to Step 5 to launch. While you build, the builder header carries the same Publish and Schedulebuttons, gated by the exact same pre-flight checklist — so a button disabled in the header is disabled on the Review step too, and vice versa. Hovering a disabled button explains what is still outstanding. The header buttons change with the experiment's status: a running experiment shows Pause, a paused one shows Resume and Stop. See Managing Running Experiments for those controls.
Seeing when an experiment launched
Once an experiment is live, the Scheduling card on the Review step records when it went live and how. Recent launches read as relative time (for example, "Launched 5 minutes ago"); older launches show the full date and time. Every time is shown in your own local timezone.
The card also notes who launched it: the teammate's name when someone published it by hand, or "automatically, on schedule" when the scheduler fired it at a pre-set time. For a finished experiment, the same card summarises the actual moments it launched and ended. See Scheduling for how to set up an automatic launch.