Managing Running Experiments

Once an experiment is live, you may need to pause it, make changes to it, or stop it when you have enough data to make a decision. This page covers all the management actions available for running experiments.

Pausing an experiment

Pausing stops an experiment from running without discarding it or its data. When paused:

The experiment stops evaluating for new visitors. No new visitors are bucketed into variations.
Existing visitors who were already assigned to a variation will no longer see the variation — they will see the original page (because the snippet skips the paused experiment).
All data collected so far is preserved. The results page still shows historical data.

To pause: open the experiment and click Pause. The control is in the top-right of the builder header (and on the results page), and it changes with the experiment's status — a running experiment shows a single Pause button.

To resume: a paused experiment shows Resume and Stop buttons in the same place. Click Resume and the experiment returns to Running status and begins bucketing visitors again. All launch controls require the Publish to productionpermission; members without it don't see them.

When you pause an experiment, visitors who were seeing a variation will immediately revert to the original experience. If your variation made a significant visual change, this could be jarring for a small number of visitors who are actively on the page. For most experiments this is acceptable, but keep it in mind.

Stopping an experiment

Stopping completes the experiment. Once stopped, it cannot be restarted. When stopped:

All variation code is removed immediately — all visitors see the original page.
The experiment moves to Completed status.
All historical data is preserved and viewable on the results page.

To stop: a paused experiment shows a Stop button in the builder header (and on the results page). Stopping is irreversible. If you stop a Frequentist experiment before it reaches its planned sample size, A vs B asks you to confirm and log a reason, because stopping early inflates the false-positive rate.

Stop an experiment when you have reached a clear conclusion: either a variation has won with statistical significance, or you have decided the experiment is not worth continuing.

Editing a live experiment

Some aspects of a running experiment can be edited without stopping it. However, editing a live experiment is risky because changes take effect immediately for all visitors and can affect the statistical validity of your results.

Safe edits

These changes have minimal impact on statistical validity:

Renaming the experiment or a variation.
Adding secondary metrics (not the primary metric).
Narrowing the targeting (reducing the scope to fewer pages).

Risky edits — use with caution

These changes can invalidate your results if done mid-run:

Changing variation CSS or JS — visitors already bucketed into a variation will start seeing the new code. Your data would now be a mix of results from two different versions of the variant.
Changing traffic splits — changing how much traffic goes to each variation can cause Sample Ratio Mismatch, which invalidates the statistical analysis.
Changing the primary metric — if you switch the primary metric mid-experiment, the historical data was collected for a different goal.

When you edit a running experiment, a yellow banner appears at the top of the experiment page labelled “Pending changes — not yet published”. Your edits are saved as a draft but are not applied to the live experiment until you explicitly click Publish changes. This gives you time to review edits before they go live. You can also click Discard changes to revert to the current live version.

Publish history & restore

Every successful publish on a web experiment writes an entry to its history — both the initial launch and every subsequent “Publish changes” from the builder. Status-only transitions (pause, resume, stop) do notcreate entries because they don't change the experiment's configuration. The full audit trail is retained — entries are not trimmed.

To open it, click the Historytab in the experiment builder's left navigation. The list shows every publish, newest first, with the author, a relative timestamp, and a one-line summary of what changed (variation code, traffic split, targeting, metrics, or audiences).

Use the search box to filter by summary text or author name. The list refreshes as you type.
Click Load more at the bottom of the list to paginate older entries.
Click any entry to open its details on the right — author, timestamp, and a field-by-field diff against the experiment's current published state (only the parts that differ are highlighted).

Restoring a previous version

Inside the detail panel, click Restore this versionto copy that snapshot into the experiment's current draft. Restore never auto-publishes — it sets the “pending changes” flag and takes you to the Variations step so you can review and re-publish from the bottom bar. For a running experiment the live experience continues unchanged until you publish the restored draft.

If the current draft already has unsaved changes, restore asks for confirmation before overwriting them.

Restore is unavailable in two cases:

The experiment is Completed— a stopped experiment can't be re-published, so restore would be a dead end. The button is disabled with an explanatory tooltip.
The snapshot references a metric or audience that has since been removed from the project. The detail panel lists exactly which metrics or audiences are missing so you know what to recreate (or pick a different entry to restore from).

Variations are an exception — if the snapshot references a variation that you've since deleted, restore re-creates it from the snapshot and reuses its original ID, so any results data still keyed to that variation stays linked.

What restore changes: variation names and code, traffic split, targeting rules, metric selection, audience configuration, scheduling, and triggers. What it doesn't change:the experiment's name, description, integrations, or accumulated results data.

Permissions

Anyone in the organisation can browse the history list and inspect any entry. The Restore this version button is hidden for members without the Edit code variations permission — viewers and collaborators see history as read-only. Publishing the restored draft still requires the publish permission, so an editor without publish rights can stage a restore for a teammate to ship.

Archiving experiments

Once an experiment is completed, you can archive it to keep your experiments list tidy. Archived experiments are hidden from the main list but remain accessible via the “Archived” filter.

Archiving is non-destructive — all data is preserved. You can unarchive an experiment at any time.