What’s new
A/B test targeting decides which visitors see a test and when it starts for them. Since 14 October 2026, Cuttl’s Web Experiments has finer targeting rules and triggers, reports you can filter and compare by segment, and a review workflow for live tests. It is live now in Web Experiments.
The release covers five areas:
- Audience rules: device model, OS version, data layer values, ad blockers, pages visited and events, custom attributes and value lists, IP and weather, grouped with AND/OR brackets.
- Triggers: pages viewed, a click, a form submit, engagement, a new session, JavaScript, a goal, or having seen a version of another test, with all/any logic and saved triggers.
- Reports: saved filters, segment comparison, an all-metrics table with a column chooser, CSV export, share links you can revoke, and recordings and heatmaps of visitors who did and didn’t convert.
- Workflow: unpublished changes on live tests, launch approvals, version history with restore, and comments with mentions.
- Visual editor: an element tree, paste HTML, a QA checklist, device preview QR codes, personalised text, translations, live social proof and AI text suggestions.
Why it matters
A test shown to the wrong visitors measures the wrong thing. A free-delivery banner aimed at UK shoppers is diluted if visitors from other countries, who can’t get the offer, are counted too. Targeting keeps the test population to the people the change is for, so the result describes them.
Reading results by segment helps you spot when one group reacts differently, such as a variant that helps on desktop and hurts on mobile. It also carries a risk: compare enough segments and one will look like a winner by chance. Decide the two or three segments that matter before launch, treat surprises in other segments as ideas for the next test, and confirm them with a test of their own.
Review before launch matters most when several people run tests on one site. A change to a live test now waits as unpublished changes until someone publishes it, and sites that turn on approvals need an owner or admin to sign off launches and publishes. A broken variant is more likely to be caught before visitors see it, and every decision has a record.
How it works
Open a test in Web Experiments. The side menu holds Versions, Goal, Audience, Traffic and Review & launch, with Statistics, Schedule & limits, Priority & exclusion, Activation & code and notes under More settings.
- Audience: add conditions and group them with AND/OR brackets, for example “iPhone or iPad, and has visited /pricing, and is not using an ad blocker”. Weather and IP conditions use the visitor’s approximate location.
- Activation: pick what starts the test for a visitor, such as a click on the size guide or a submitted newsletter form, and choose whether all or any triggers must match. Save a trigger to reuse it in later tests.
- Review & launch: on a site with approvals turned on (A/B settings), the launch request goes to an owner or admin.
- Live edits: changes to a running test are saved as unpublished changes, with Publish and Discard buttons. Each published state is kept in version history, and any version can be restored.
- Reports: on the test page, filter the results, compare segments side by side, choose the columns, export a CSV or create a share link. Program results, under Experiments, collect results across tests.
Our guide to statistical significance explains why a segment needs enough visitors of its own before its result means much.
Who it’s for
These features are built for teams that run tests often or with several people involved. Some examples by role:
- CRO and experimentation leads: turn on approvals so no test goes live without review, and use comments to agree the hypothesis before launch.
- Ecommerce managers: target a shipping offer to visitors in the countries it applies to, then compare new and returning customers in the report.
- Growth and performance marketers: target a landing page test to one campaign’s visitors with a UTM or data layer condition, and share the results with a link instead of a spreadsheet.
- Developers: start a test from JavaScript or a custom event, and check variants on real phones by scanning the preview QR code.
- Agencies: send a client a revocable share link to the report, and keep every change to a live test in version history.
Examples by industry
The same tools fit different questions depending on the site:
- Online stores: show a rain-jacket banner only to visitors where it is raining, and watch recordings of visitors who saw it but didn’t buy.
- SaaS: test a new pricing table only for visitors who already visited /pricing earlier in the visit, and require approval because pricing changes are sensitive.
- Lead generation and service businesses: trigger a test when someone clicks into the quote form, then compare mobile and desktop results in the report.
For background on the method itself, read what A/B testing is and how to plan a test before launch.
How to start in Cuttl
In app.cuttl.io, go to Web Experiments, then Experiments, and open a test. A good first step is to add one audience condition that matches the change you are testing, for example limiting a mobile menu test to phones. If several people work on your tests, turn on launch approvals in A/B settings next. The targeting section of the Web Experiments page lists the conditions and triggers.
A few limits: SAML single sign-on isn’t included (OpenID Connect is), AI text suggestions in the editor need the site’s own Claude API key, and live social proof shows rounded counts only, never fewer than 5. AI assistants connected through the Cuttl MCP server can publish or discard unpublished changes, read and restore versions, and comment on tests, with launches still waiting for a person.
