Version History
Every meaningful draft edit creates a snapshot with an auto-generated summary. Restore any prior version into the current draft.
Version History
Every meaningful edit to a draft creates a versioned snapshot with an auto-generated change summary. Roll back to any prior version when you need to — the restore is itself captured in history.
Version history is your safety net while authoring an experiment. Add a variant, rewrite a goal, change targeting — each save creates a checkpoint you can come back to. The system stores both the full snapshot and a diff against the previous version, so the timeline reads like a commit log for the experiment.
Restore is intentionally draft-only. Once an experiment has launched and is collecting data, changing its configuration would invalidate the results, so the restore button is hidden on running, paused, completed, and archived tests. The same rule covers regular edits via the wizard — see Test Lifecycle.
How it works
- 1
You save a meaningful change
Any save that changes a test-level field, a variant, a goal, or a team assignment triggers a version snapshot. Cosmetic saves (no actual diff) are deduplicated and don't create new versions. - 2
A snapshot is taken
Otter A/B serializes the full experiment state — test fields, variants and their DOM changes, goals with their config, assigned teammates — and stores it alongside a diff against the previous version and an auto-generated summary describing what changed. - 3
The version appears in the timeline
Open the test's Version History panel to see each version with its number, who made the change, when, and the auto-summary. Newer versions are shown first. - 4
Restore a prior version when you need it
Click Restore on any version. Otter A/B rebuilds the draft from that snapshot inside a transaction. The restore itself is appended as a new version with a link back to the source.
What's in a version
- Test fields — name, URL, URL match type, traffic allocation, trigger, confidence level, analysis method, hypothesis, scheduled start/end, stop conditions, targeting rules, custom CSS/JS.
- Variants — every variant with its name, weight, is_control flag, and its full list of DOM changes (selector + action + value).
- Goals — every goal with its name, goal type, primary flag, and config.
- Team assignments — the list of teammates collaborating on the test.
Restore semantics
- Draft-only. Restore is blocked on running, paused, completed, and archived tests. Duplicate them first to get a fresh draft you can restore into.
- Test key stays the same. The SDK-facing slug used for assignment doesn't change on restore, so existing SDK references to the test keep working.
- Past schedules are nil'd. If the snapshot's scheduled_start_at or scheduled_end_at is in the past, restore sets them to nil instead of replaying an expired schedule.
- Departed teammates are skipped. Team assignments are filtered to include only people who are currently valid members of the account.
- The restore is itself a version. A new version is appended to the timeline with a link back to the source — so the timeline shows a complete record of edits AND rollbacks.
- Recorded in the activity log. Restoring writes a ‘restored’ entry with the source version number so the action is traceable beyond the version timeline.
When restore is the right tool
You overwrote good work with a bad change. Restore to the last known good version, keep editing from there.
You want to spin off a new test from an earlier iteration. Duplicate the test first, then restore the duplicate to the version you want as the starting point.
You're A/B-testing the A/B test setup itself. Save, see how a change feels, restore if it didn't work. Use the timeline as a worktable, not a permanent archive.
When NOT to use restore: if the test has launched. Even if it's paused, restoring would mix data collected under two different configurations. Complete first, duplicate, then restore the duplicate.
Frequently asked questions
Quick answers to the questions teams ask most about this part of Otter A/B.