Configuration Settings

The Configuration tab controls how A vs B makes statistical decisions about your experiments and how it tracks visitor behavior. The settings here apply to every experiment in the project, so changes should be made thoughtfully.

Accessing the Configuration tab

Open your project, click the gear icon in the left sidebar to open Project Settings, then click the Configuration tab.

Confidence Threshold

The confidence threshold is the minimum level of statistical confidence required before A vs B declares a variation the winner of an experiment. It is expressed as a percentage and can be set anywhere between 50% and 99%. The default is 95%.

In plain terms: a 95% confidence level means that if A vs B reports a winner, there is only a 5% chance the result is due to random variation rather than a real difference between the variations. A higher threshold means you need more data before a winner is declared, but you can trust the result more.

Lower it (e.g. 80–85%) if you are running quick internal experiments where the cost of a wrong call is low, or if you have limited traffic and need faster results. Be aware that lower thresholds produce more false positives.

Raise it (e.g. 99%) if you are testing changes with significant business or revenue impact — for example, a checkout flow redesign or a major pricing change. Higher confidence means you need more visitors before a result is declared, but you can act on it with greater certainty.

For most teams, the default of 95% is the right balance between speed and reliability.

Attribution Window

The attribution window defines how long after a visitor is exposed to an experiment variation A vs B will still credit a conversion event to that experiment. It is split into two parts that combine to form a single window:

Days — a number between 0 and 90. Set to 0 to disable the day component.
Hours — a number between 0 and 23. Combined with the days value to form the full window.

For example, setting 7 days and 0 hours means: if a visitor sees variation B on Monday, any conversion they complete up to the following Monday will be counted as a conversion for that experiment. A conversion they complete 8 days later will not be counted.

The right attribution window depends on your product's typical decision-making cycle:

E-commerce — 1–3 days is common. Shoppers usually convert within hours or revisit within a day or two.
SaaS sign-up flows — 7–14 days. Visitors often think it over before signing up.
Content or media — a shorter window like 24 hours is usually sufficient since the action (a click, a read) happens during the session.

A very long attribution window can pollute your results with conversions that had nothing to do with your experiment. Start with 7 days and shorten it if your product has a fast conversion cycle.

SPA Support

The SPA Support toggle enables compatibility with single-page applications — websites built with React, Vue, Angular, Svelte, or any other framework where navigation happens without a full page reload.

In a traditional multi-page website, the browser loads a fresh HTML document for each page the visitor visits. The A vs B snippet runs on every page load, so it naturally re-evaluates which variation to show whenever a user navigates.

In a single-page application, navigation changes the URL and updates the page content but does not reload the HTML document. The snippet only runs once when the SPA first loads. With SPA Support enabled, the snippet listens for URL changes and re-evaluates experiment eligibility on each navigation — so your experiments run correctly on every page the visitor visits, not just the first one.

If your website uses Next.js, Nuxt, Gatsby, or any SPA framework, enable SPA Support. Leaving it off means experiments may not apply to visitors who navigate deeper into your site without refreshing.

Responsive Website

The Responsive Website toggle enables breakpoint-aware tracking. When turned on, A vs B records the viewport size of each visitor alongside their experiment assignment. This lets you analyze results segmented by device type — for example, comparing how your variation performs on mobile versus desktop.

This toggle is most valuable when:

Your experiment makes changes that look or behave differently on different screen sizes
You suspect that the winning variation might differ between mobile and desktop visitors
You want to understand whether conversion rates vary significantly by device type

Enabling this adds a small amount of additional data to each tracked event but has no meaningful performance impact.

Anti-Flicker Protection

The Anti-flicker protection toggle controls whether the snippet hides the page while experiments are being evaluated. When enabled, the snippet sets the page to invisible immediately on load and reveals it once all variations have been applied — preventing the “flash of original content” (FOOC) that visitors would otherwise see.

Anti-flicker is enabled by default. You should disable it only if your experiments do not make visual changes (for example, behavioural experiments, server-side tests, or below-the-fold changes only). Disabling it does not affect experiment evaluation or tracking — it only controls the page-hide behaviour.

See Anti-Flicker for a deeper explanation of how this mechanism works.

Reset and Save

Click Save to apply your configuration changes. All new experiment sessions will use the updated settings immediately. In-progress experiments will continue using the window and threshold that were set when they started unless you explicitly update them. Click Reset to discard unsaved changes.