Force Variation

avsb.forceVariation() lets you manually override which variation of an experiment you see. A variation is one specific version being tested: the control, or one of the challengers. Use it for QA testing, debugging, and internal previews. It lets you see exactly what a visitor in any variation sees, instead of being randomly bucketed (sorted into a variation using a consistent hash of your visitor id) into one.

Method signature

// avsb.forceVariation, a member of AvsbApi in @avsbhq/snippet-typesforceVariation(  experimentId: string | number,  variationId: string | number,  options?: { track?: boolean; persist?: boolean },): boolean

Parameters

Return value

avsb.forceVariation() returns a boolean:

• true: the variation was found and applied. The page updates immediately.
• false: one of the two ids is not in the live datafile (the small file listing every running experiment). The console says which id it could not place and where to find the right one, so nothing fails silently. Check that the experiment is running, and that you used the numeric ids rather than the UUID.

The single quiet false is after avsb.disable(). Once a visitor has opted out, nothing writes a new assignment for them and there is nothing to warn about.

What happens when you call it

Forcing a variation triggers a sequence of actions in the snippet:

1. Deactivates the previous variation: the visitor might currently be in a different variation of the same experiment. If so, that variation's CSS and JS are reversed or removed from the page.
2. Saves the assignment: the forced variation is written to the _avsb_visitor cookie (and the copy the snippet keeps in the browser's local storage), so it persists across page loads and browser sessions on the same device. With { persist: false } nothing is saved, and your next page load shows your usual variation again.
3. Injects the new variation: the target variation's CSS is injected into a <style> tag and its JavaScript is executed.
4. Sends an exposure event: an exposure, the event that counts this visitor as having seen the test, is recorded for the forced variation. This affects your experiment's analytics. { track: false } skips it.

On every later page load, a persisted force is simply your assignment. The experiment's targeting still applies: the forced variation shows on the pages the experiment runs on, and nowhere else.

When to use it

• QA testing before launch: verify that each variation looks and works correctly on the real website, before the experiment goes live to real visitors.
• Debugging: when something looks wrong in one variation, force yourself into it from the DevTools console to reproduce the issue.
• Internal previews: share a URL with a team member and have them run a DevTools command. They see a specific variation without needing a special preview link.
• Stakeholder sign-off: let a product manager or designer force themselves into the variant variation so they can approve the experience before launch.

Code examples

Force yourself into a specific variation for testing:

// Force yourself into a variation. 42 is the Experiment ID, 1487 the Variation ID.const success = avsb.forceVariation(42, 1487);console.log('Force variation:', success ? 'applied' : 'failed');

Force from the browser DevTools console, then click through your site:

// Open DevTools, go to the Console tab, and paste this:avsb.forceVariation(42, 1487);// The page updates immediately, and every page you open next keeps the variation

Force back to the control, or force for this page only:

// To go back to the control, force the control's Variation IDavsb.forceVariation(42, 1486);// This page only: the next page load shows your usual variation againavsb.forceVariation(42, 1487, { persist: false });// Apply a variation without recording an exposure for this callavsb.forceVariation(42, 1487, { track: false });

Seeing it in debug mode

With debug mode on, the console names every forced variation, on the page where you forced it and on every later page where it applies:

[avsb] experiment 42 forced: 1487

Finding experiment and variation IDs

You need two ids: the Experiment ID and the Variation ID. Both are in the Experiment details panel: open the experiment in the builder and click the info button in the sidebar. Every value there has a copy button.

• Experiment ID: the number in the row labelled Experiment ID. It is the same number as in the dashboard URL and in the CLI.
• Variation ID: the Variations section of the same panel lists each variation by name with its Variation ID underneath.

Each row also shows a UUID. That is the internal id A vs B uses in its own storage, and this method does not accept it: pass the numbers.

Resetting forced variations

To clear every forced variation and go back to normal bucketing, run this in the DevTools console:

avsb.exitPreview();

It removes the forced assignments and reloads the page. You keep the same visitor id, so you land back in the variation the normal bucketing gives you.

A forced variation also clears itself when its experiment ends or is archived.

To forget your visitor completely instead, delete both copies the snippet keeps: the _avsb_visitor cookie (DevTools, Application tab, Cookies) and the _avsb_visitor entry under Local storage in the same tab. Deleting only the cookie is not enough, because the snippet restores it from local storage on the next page load. Your next visit is then bucketed as a brand new visitor.