Targeting

How to Create an Audience for an A/B Test

★☆☆ Technical level 1 of 3

Written by Neil Webley · Last updated 5 August 2026

Learn what an A/B test audience is and how to target visitors using URL, device, browser and behaviour rules.

What is an A/B test audience?

An A/B test audience is the group of visitors who are eligible to enter an experiment. Test locations decide where a test may run; an audience decides who can enter and, for behaviour rules, when they become eligible.

Audiences are necessary because a change is not always relevant to everyone. A mobile navigation experiment should not enrol desktop visitors, an exit-intent message needs an exit-intent signal, and a campaign-specific offer should be limited to the intended campaign. Accurate targeting protects the visitor experience and makes test results easier to interpret.

Default audiences

FreeCROTool creates useful starting audiences for each project:

All visitors , the broad starting point when everybody at a valid test location can enter.
Desktop Browsers - Exit Intent , desktop visitors who show the exit-intent behaviour.
Desktop Browsers , visitors identified as using a desktop browser.
Mobile browsers , visitors identified as using a mobile browser.

Default audiences cannot be edited, renamed or deleted. You can clone one and edit the copy. This preserves a dependable original while giving you a quick starting point.

Audiences can be shared by more than one test

An audience belongs to the project and can be used by several tests. This saves you from rebuilding the same targeting rules for every experiment and helps related tests use a consistent definition.

Editing a shared audience affects every test that uses it. Before changing one, check which tests are attached to it and confirm that the new rules are appropriate for all of them. If only one test needs different targeting, clone the audience and attach the copy to that test instead.

Saving in the Workspace does not change the live website

When you save an audience, the change remains in the Workspace as a draft. Your live tests continue to use the previously published audience rules.

FreeCROTool keeps a published copy of your project on a fast worldwide delivery system so visitor browsers can retrieve the test settings quickly. This system is often called a CDN, but you can think of it simply as the live copy used by your website visitors.

The live copy does not change until you publish the Workspace. When you publish, all pending Workspace changes, including tests, audiences, locations and other project settings, are published together and take effect on the live delivery system.

Review every pending change before publishing, not only the audience you just edited.
Test the audience and all affected tests in the Workspace first.
Coordinate publishing when several people are making changes to the same project.

Important: search engines are included by default

Default audiences do not exclude search engines. If a test transforms content early in the page load, a search-engine crawler may see the transformed version and it may be indexed.

For tests that materially change indexable content, consider cloning a default audience and adding a User Agent rule that excludes Googlebot and any other crawlers relevant to your site. User-agent filtering is useful but not a complete SEO guarantee because identifiers can change or be imitated. Use canonical tags, robots controls and server-side SEO controls where appropriate, and ask an SEO specialist when a test could substantially change search-visible content.

Video walkthrough

Video coming soon Audience creation walkthrough: naming, rules, AND/OR logic and brackets

How to create an audience

1. Choose a clear name

Describe the people and behaviour in plain language, for example “Desktop visitors from spring campaign” or “Product visitors inactive for 30 seconds”. A clear name makes the audience safer to reuse later.

2. Break the audience into conditions

Write each requirement as a short statement before building it. For example: the visitor is on mobile AND the URL contains utm_campaign=spring.

3. Join rules with AND and OR

AND means every connected condition must be true.
OR means either connected condition may be true.

Use brackets to keep related rules together and make the evaluation order explicit:

(Browser is Chrome OR Browser is Edge)
AND
(URL contains /pricing/)
AND
(User Agent does not contain Googlebot)

Without brackets, mixed AND/OR rules can produce a wider audience than intended. Read the finished rule aloud and test examples that should pass and fail.

Understanding comparison options

Text-based conditions can offer several comparisons:

Exact match , the complete value must match. Use it for a known, stable value.
Begins with , useful when the important part is always at the start.
Contains , useful for a distinctive part of a URL, cookie or user agent, but may match more than expected.
Regular expression , an advanced pattern for several possible formats. Test it carefully because a broad or invalid pattern can produce surprising results.
Case sensitive , uppercase and lowercase are treated as different.
Non-case-sensitive , letter case is ignored and is often safer for user agents, browsers and campaign values.

Negative versions such as “does not equal” and “does not contain” are useful for exclusions. Check empty and missing values: a missing cookie is different from a cookie whose value is an empty string.

Audience condition reference

URL Match

Matches the current page address. You can evaluate just the page URL, the full URL including query string and fragment, or only the query-string/fragment portion. Exact matching suits one page; begins-with and contains suit page groups; regular expressions suit advanced patterns. Decide deliberately whether tracking parameters and letter case matter.

Cookie Match

Checks whether a named browser cookie exists or whether its value matches. This can identify logged-in state, returning visitors or a site-defined segment. Cookie availability may depend on consent, domain, path and browser restrictions. Do not put sensitive personal information in audience rules.

User Agent

Checks the browser’s user-agent text. It can help identify Googlebot and other search-engine crawlers, devices or specialist browsers. Usually use a non-case-sensitive “contains” comparison. User agents can change or be spoofed, so do not use this as a security control.

Operating System

Targets visitors identified as using systems such as Windows, macOS, Android or iOS. It is useful when an experience or hypothesis is platform-specific, but detection depends on browser-provided information.

Browser

Targets a browser family such as Chrome, Safari, Edge or Firefox. Use it for genuine compatibility or browser-specific hypotheses, not simply because one browser performed differently in a small sample.

Is Desktop

A true/false device classification for desktop browsing. Combine it with Is Tablet and Is Mobile when you need an explicit device definition.

Is Tablet

A true/false tablet classification. Tablets can overlap desktop-like and mobile-like behaviour, so test representative devices before launch.

Is Mobile

A true/false mobile classification. Use it for layouts or behaviours designed specifically for smaller touch devices.

Exit Intent

Becomes true when a desktop pointer moves towards the browser controls, suggesting that the visitor may leave. It is desktop-only because touchscreens do not provide the equivalent cursor signal. See the exit-intent guide.

Inactivity Period

Becomes true after the visitor has been inactive for the configured number of seconds. It can trigger contextual help after hesitation. Choose the delay from real behaviour and confirm which mouse, keyboard, scroll and touch actions reset it. See the inactivity guide.

JavaScript condition

Runs a JavaScript expression whose result must be true. This is the most flexible and most technical option. Use it only when built-in rules cannot express the audience, keep it fast and defensive, avoid personal data, and handle missing variables without throwing an error.

Useful A/B testing audience examples

Start with the broadest audience that can answer your hypothesis. Add rules only when the experience or question genuinely applies to a particular group. The examples below can be adapted to your website.

Everyone visiting the tested pages

All visitors

Useful for: site-wide wording, proposition, pricing presentation or checkout changes that are relevant to everybody. This is often the best starting point because it gives you the largest eligible sample.

Mobile visitors on product pages

(Is Mobile is true)
AND
(URL Match begins with https://example.com/products/)

Useful for: testing mobile navigation, sticky purchase buttons, image galleries or layouts designed specifically for smaller screens.

Desktop visitors showing exit intent

(Is Desktop is true)
AND
(Is Tablet is false)
AND
(Is Mobile is false)
AND
(Exit Intent)

Useful for: testing relevant last-minute help, delivery information or reassurance when someone appears ready to leave. Exit intent is desktop-only and should not be treated as proof that every visitor intends to abandon the page.

Visitors from a particular campaign

(URL Match contains utm_campaign=spring_sale)

Useful for: keeping landing-page wording consistent with an advertisement, email or social campaign. Check how your site preserves or removes campaign parameters as visitors move between pages.

New or returning visitors identified by your cookie

(Cookie Match: returning_visitor exact match true)

Useful for: testing onboarding for new visitors or shortcuts for returning visitors. Only use a cookie your website deliberately sets, account for consent and cookie expiry, and test what happens when the cookie is absent.

Visitors who may need help after becoming inactive

(URL Match contains /checkout/)
AND
(Inactivity Period is 30 seconds)

Useful for: testing contextual assistance on a complex form or checkout. Base the delay on observed behaviour; a visitor pausing to read is not necessarily stuck.

One experience for desktop, another for mobile or tablet

(Is Desktop is true)
OR
(Is Mobile is true OR Is Tablet is true)

Useful for: understanding how brackets group device rules. In practice, create separate audiences when the desktop and touch-device experiences need different variants or separate reporting.

Exclude a crawler from an otherwise broad audience

(User Agent does not contain Googlebot)
AND
(User Agent does not contain Bingbot)

Useful for: reducing the chance that known crawlers enter a test which changes indexable content. Use non-case-sensitive comparisons. This is not a security boundary or a complete SEO safeguard because crawlers and user-agent identifiers can change.

A site-defined JavaScript segment

window.customerTier === "standard"

Useful for: targeting a reliable state already exposed by your website when no built-in condition represents it. Guard against missing variables, avoid personal data and do not place sensitive business logic in browser-side rules.

Avoid creating an audience just because a subgroup appears to perform differently after looking at the results. Define important audience segments before launch where possible. Small, retrospective segments are more likely to produce misleading patterns.

Worked examples coming soon

This section has been reserved for complete examples showing how individual conditions are configured in FreeCROTool.

Simple URL match with an optional query-string value

Example to add: a simple URL audience where a query-string value may be present but is not required for the visitor to qualify.

URL match requiring a particular query-string value

Example to add: a more complex URL audience where the visitor qualifies only when a named query-string parameter has the required value.

Cookie matching one of two values

Example to add: a cookie audience using OR logic so the named cookie can contain either of two accepted values.

Before using an audience in a live test

Preview visitors and URLs that should qualify.
Test near-matches that must be excluded.
Check missing cookies and unavailable JavaScript values.
Test desktop, tablet and mobile classifications on real devices where possible.
Check search-engine exposure for early or indexable content changes.
Estimate whether the audience will still provide enough traffic for a useful result.
Record why every rule is necessary so future users can safely reuse it.