Targeting & Audiences
Before an experiment can run for a visitor, it must pass a three-stage filter. Targeting rules decide which page they must be on. Audience conditions decide who they must be. Traffic allocation decides what slice of visitors gets let in at all. A visitor must pass all three stages to be assigned a variation: one specific version being tested, either the control or one of the challengers.
The filter chain
Think of it as a funnel. Every visitor who loads a page on your site enters the funnel. At each stage, some visitors are excluded. Only visitors who make it through all three stages get assigned to a variation and have the experiment applied to them.
Stage 1: URL targeting rules
The first check is: is this visitor on the right page?
Each experiment has one or more targeting rules. A rule is a web address you type in, plus a match type. The match type decides how strictly the address has to line up with the visitor's real address. The snippet checks the visitor's current address against every rule. If any one rule matches, the visitor passes this stage. Rules use OR logic, so matching any single rule is enough.
The rule picker offers five match types:
| Match type | What it checks | Example rule | Matches | Does not match |
|---|---|---|---|---|
| Path match | The path only: everything after the domain, before any ? or #. A trailing slash is ignored. | /pricing | https://acmecorp.com/pricing, .../pricing/, .../pricing?plan=pro | /pricing/enterprise |
| Exact match | The whole address, character for character, including the domain. | https://acmecorp.com/pricing | that exact address, and nothing else | the same page with a trailing slash or ?plan=pro added |
| Substring match | Whether your text appears anywhere in the whole address. | checkout | .../checkout, .../checkout/confirm, .../store/checkout/complete | any address with no "checkout" in it |
| Pattern match | Wildcards checked against the whole address: * matches any run of characters, ? matches exactly one. The address must fit the pattern start to end. | https://acmecorp.com/blog/* | any address under /blog/ | https://acmecorp.com/blog (nothing follows the slash) |
| Regex match | A regular expression tested against the whole address. | /product/[0-9]+$ | .../product/123 | .../products, .../product/123/reviews |
Most match types compare against the whole address, not just the path. A rule written as a bare path, like /pricing, only behaves the way you would expect with Path match. The other match types need the full address, starting with https:// and your domain, or they will never match anything.
An older match type, Path prefix, matches when the visitor's path starts with your value, so a rule of /blog also matches /blog/my-post. It no longer appears in the dropdown for a new rule, but an experiment built before this change may still have one. Path match, above, is its replacement: it requires the path to match exactly, not merely start with your value.
Each rule also has a condition: Matches (the address must match) or Does Not Match (the address must not match). Use "Does Not Match" to exclude specific pages from an experiment that otherwise runs broadly. An exclusion always wins: if a visitor's address matches one of your "Matches" rules but also matches a "Does Not Match" rule, they are excluded.
Stage 2: Audience conditions
The second check is: is this visitor the right kind of visitor?
An audience is a named, reusable group of visitors, built from conditions like device type, country, or a cookie value. Audiences let you target experiments to specific segments of your visitors. Examples: only mobile visitors, only visitors from the US, only logged-in users, only visitors who arrived from a Google Ads campaign.
An experiment can have zero or more audiences configured. The logic is:
- If no audiences are configured (the picker shows the Everyone tag), all visitors pass this stage.
- If one or more audiences are configured, the visitor must match at least one audience to pass (audiences use OR logic across audiences).
- Within a single audience, you choose the logic yourself with an AND/OR switch in the audience builder. AND (the default for a new audience) means every condition must be true. OR means any one condition is enough.
For example, say an experiment has two audiences: "Mobile visitors" and "US visitors". Any visitor who is either on mobile or in the US passes this stage. A visitor is excluded only if they are neither on mobile nor in the US.
Device, browser, platform, language, cookie, and query-parameter conditions all read something only a browser has, like navigator.userAgent or document.cookie. A web experiment always runs in a visitor's own browser, so these six work exactly as described here.
Audiences are shared, though. The same audience can also gate a feature flag: a setting in your code you can turn on or off without shipping new code. A flag can be checked from a server SDK (Node, Python, and others) with no browser involved. When a server SDK evaluates one of these six condition types, there is nothing for it to read. The condition never matches, and the audience quietly excludes every visitor, with no error to warn you. If you reuse one audience across a web experiment and a server-evaluated flag, keep the conditions simple. Use only things every environment can answer, like a custom attribute your own code passes in.
Stage 3: Traffic allocation
The third check is: is this visitor in the experiment at all?
Experiments have a traffic allocation percentage: the portion of eligible visitors who actually participate in the experiment. By default this is 100%, meaning all eligible visitors are included. You can lower it (for example, to 20%) to run the experiment on a smaller slice of your traffic.
The allocation is deterministic: it is based on a hash of the visitor's unique ID and the experiment ID. This means the same visitor always gets the same result: they are either always in or always out of a given experiment. There is no randomness per visit.
Variation assignment
Once a visitor has passed all three stages, they are assigned to a variation. This assignment is also deterministic, based on a hash of the visitor's ID and the experiment ID. The variation weights (traffic splits) you set in the experiment builder determine the probability of each outcome. Once assigned, though, a visitor stays in that variation permanently, until you change the experiment or they clear their cookie.
Because all allocation is deterministic, you can safely stop and restart an experiment without worrying about visitors switching variations. The same visitor will always land in the same bucket.
Where you set this up
URL targeting and audiences are both configured together, on Step 1 of the experiment builder ("Targeting & Audience"). There is no separate audience step. Traffic allocation lives on Step 2 ("Variations & Designs"), alongside your variations.