Configuration

The Configuration tab controls how A vs B tracks visitor behavior on your site: how long a conversion still counts, which route changes count as a new page, and what happens before a visitor answers your cookie banner. These settings apply to every experiment in the project, so change them thoughtfully.

1. Attribution window: how many days and hours a conversion still counts after a visitor sees your experiment.
2. Advanced settings: four toggles, including Hash-based routing and Consent mode.

Accessing the Configuration tab

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

Attribution Window

The attribution window sets how long a conversion still counts after a visitor sees an experiment variation. It has two parts that add together:

• 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, 7 days and 0 hours means this: a visitor sees variation B on Monday. Any conversion up to the following Monday counts for that experiment. A conversion 8 days later does not count.

The right window depends on how your visitors usually decide:

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

Hash-Based Routing

Route detection itself is not a setting. A vs B always watches the browser's history API and re-checks every experiment whenever the URL path changes, on every project, with nothing to turn on. This covers ordinary single-page apps built with React, Vue, Angular, Svelte, Next.js, Nuxt, or any framework that changes the page without a full reload.

The Hash-based routing toggle covers one narrower case: a site where navigation changes only the part of the URL after a #, like example.com/#/pricing. Switch it on and a changed # section counts as a new page, so your experiment re-checks visitors who move between hash routes. Leave it off, which is the default, and a link to a #section on the same page (a normal jump-to-anchor link) is correctly ignored rather than miscounted as a new page.

Responsive Website

The Responsive website toggle turns on breakpoint-aware tracking. When on, A vs B records each visitor's screen size alongside their experiment assignment, so you can compare results by device.

Turn this on when any of these is true:

• Your experiment looks or behaves differently across screen sizes.
• You suspect the winning variation differs between mobile and desktop.
• You want to know whether conversion rates vary by device type.

Turning it on adds a small amount of extra data to each tracked event. It has no meaningful effect on page speed.

Anti-Flicker Protection

The Anti-flicker protection toggle controls whether the snippet hides the page while it decides which variation to show. On, the page starts invisible and reappears once every variation has been applied. This is what stops visitors seeing a flash of the original content before your change appears.

Anti-flicker is on by default. Turn it off only when your experiments make no visual change, for example a behavioural experiment, a server-side test, or a change below the fold. Turning it off does not affect evaluation or tracking. It only controls whether the page hides while it waits.

See Anti-Flicker for how this works in more detail.

Consent

The Consent section sits at the bottom of the Configuration tab, under the Advanced settings toggles. It decides what A vs B does before a visitor answers your cookie banner, and what happens to a visitor who says no to analytics.

A visitor who refuses analytics is never measured. A vs B collects no experiment views, conversions, purchases, or recommendation events for them, and forwards nothing about them to your analytics tools. These settings only decide whether that visitor still sees your experiment at all, and how A vs B learns their answer.

Consent mode

Consent mode is the last toggle in the Advanced settings group above. Turn it on and the snippet holds everything back until your site says the visitor has agreed. No cookies are set. No experiments run. No tracking data is sent, until your site calls avsb.init(). Leave it off, which is the default, and experiments start as soon as the page loads.

This is the strictest, all-or-nothing option. The two settings below answer a different question: what happens to a visitor who is browsing a site where experiments run, but who has refused analytics.

1. Cookie classification: choose Functional or Analytics for the visitor cookie.
2. Read Google consent signal: on by default.

Cookie classification

A vs B keeps one visitor cookie so the same person keeps seeing the same variation from page to page. How your cookie banner classifies that cookie is your decision, and A vs B supports both choices.

• Functional (the default): A vs B writes the visitor cookie even when a visitor denies analytics, and you declare it as functional in your banner. That visitor keeps seeing the same variation on every page, and still contributes no data. Your experiment stays consistent for everyone who lands on it, and your results are counted only from visitors who agreed.
• Analytics: the visitor cookie counts as analytics. When a visitor denies analytics, A vs B writes no cookie, so that visitor sees the original page, with no experiment and no data. Nobody who refused ever enters a test, at the cost of showing your variation to fewer people.

Read Google consent signal

Leave Read Google consent signal on, which is the default, and A vs B follows the visitor's banner choice automatically whenever your site uses Google's consent tools, with no extra code for you to write. Turn it off if you would rather A vs B ignore that signal and use only what your banner tells it directly.

Reset and Save

Click Save changes to apply your configuration changes. Every new experiment session uses the updated settings as soon as the change reaches your site, about a minute later. An in-progress experiment keeps using the window and threshold it started with unless you update it directly. Click Reset to discard unsaved changes.

AvsB Copilot

AvsB Copilot is the AI feature built into the visual editor, separate from the Assistant, the chat helper in your dashboard. Describe a change in plain English, for example "make the hero heading bolder" or "add a countdown banner above the fold," and it builds it for you to review and save. This card is a read-only summary. It shows whether the copilot is available to your organization, and how many AI actions your organization has used this month, counted together with the Assistant. There's nothing to switch on or save here.

For a full tour of what the copilot can do, see AvsB Copilot in the Visual Editor guide.

Availability

Once your organization has billing details on file, the copilot is available in the editor for every project. There's no per-project switch to flip. Access is set at the organization level, so a teammate opening any project with access finds the sparkle button ready in the editor's top bar.

AI actions this month

One AI action is one request to the copilot or the Assistant. AI actions are billed per action, at the rate on the Billing page, with no monthly allowance to run out and no packs to buy. This card shows how many your organization has used this month. The count is shared across your whole organization, and across both the copilot and the Assistant, rather than split per project or per feature, and it reads the same everywhere you look.

If your usage is covered by an agreement with us, the agreement sets a monthly number of AI actions instead, and the card shows how many of them are left. A Manage in Billing link takes you to your usage and the rate card. See Billing → AI actions.