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

Before you can publish, A vs B runs automated checks. Each one is a row on the Pre-Launch Verification card, and every row must turn green.

1. JS Snippet Detected on Site

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. Conversion Metrics Defined

The experiment must have at least one metric attached. Without a metric, there is nothing to compare between variations and no way to determine a winner.

If this check fails: Open the Metrics & Goals step from the builder sidebar and attach a metric.

3. Audience Eligibility Configured

If the experiment targets saved audiences, this row checks that every selected audience still exists and that none of them contains a rule the platform cannot evaluate (which would leave every visitor out). An experiment targeting everyone (no audience selected) passes.

If this check fails: Open the Targeting step. The row names the audience with the problem.

4. Traffic Split Validated

All variation traffic splits must add up to close to 100%. A vs B allows a small rounding margin (about 1%).

If this check fails: Click the Edit button next to "Variations & Split" to go back to Step 2 and adjust the weights.

5. Traffic Allocation Above 0%

The Overall Traffic Allocation slider on the Variations step controls how many eligible visitors enter the experiment at all. At 0%, the experiment would run without reaching anyone, so this row fails until the slider is raised.

If this check fails: Open the Variations step and raise the Overall Traffic Allocation slider above 0%.

6. URL Targeting Valid

Every URL targeting rule you have filled in must be readable. A rule with a syntax error (for example, a regular expression that does not compile) silently matches nothing on your live site, so the experiment would reach nobody or the wrong pages. Empty rules are ignored; they are dropped on save.

If this check fails: Open the Targeting step. Any rule with a problem shows a red message under the field explaining exactly what is wrong.

Two more rows can appear depending on your setup:

• Analysis Plan Complete, if your project requires a sealed analysis plan before launch. See "Where analysis configuration lives" below.
• One row per Ratio, Percentile, or Composite metric you attach, checking that the metric's underlying data sources are set up correctly.

Split URL experiments add four more rows specific to the redirect setup: control URL configured, match mode selected, at least one variant defined, and every variant has a destination URL. See Split URL Experiments for that flow.

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

A vs B does not require a URL targeting rule before you can publish. Leaving targeting empty means the experiment runs on every page where the snippet loads.

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.

Previewing your experiment before launch

Click Live Variation Preview to open your website with a floating preview panel, so you can confirm everything works exactly as configured before any real visitor sees it.

The page address starts filled in for you: the last address you previewed for this experiment, else the first page your include rules name (a path such as /pricing is joined to your project's site), else your project's URL. Change it to preview any other page.

The panel has four tabs:

• Preview: shows which variation is currently displayed and lets you switch between variations from a dropdown, so you can check each one without leaving the page.
• Targeting: shows whether the current page passes your URL targeting rules, audience conditions, and triggers, with a pass or fail badge for each.
• Conversions: lists every goal your experiment tracks, one row per goal. Each row shows whether that goal converted during your preview session, how many times, and which metrics are attached to it.
• Errors: surfaces any problems with your variation's code, such as a selector that did not match anything on the page.

Interacting with the page while the panel is open, for example clicking a button your variation changed, fires the same goals a real visitor's click would. This lets you confirm your metrics are wired up correctly before you publish.

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.

While Publish experiment is disabled, the line under it names the checks that have not passed yet, so you know which row to fix even when it sits further down the list.

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 Running status. You are redirected to the experiment's results page.

If delivery to your site is paused, the launch is refused instead: a dialog explains the pause and confirms that nothing was started. Owners and Admins also get a button to the Billing tab. Other members are asked to get one of them to act. See Delivery to your site is paused.

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 Schedule buttons, 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 names the checks that are 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.