Targeting

Step 1 of the experiment builder is Targeting. This is where you tell A vs B which pages the experiment should run on and which visitors should be eligible. Getting targeting right is crucial: too broad and you may run the experiment on irrelevant pages; too narrow and you may not collect enough data.

The Targeting step: URL rules on top, audience selection below, here limited to the 'Mobile Traffic' audience.

URL targeting rules

URL targeting rules define which pages trigger the experiment. You can add as many rules as you need. If a visitor's current page URL matches any of the rules, the experiment is eligible to run (rules use OR logic).

Each rule has two parts: a match type and a condition.

Match types

The match type dropdown offers five options, in this order. A new rule starts on Substring, the default.

Exact match

The visitor's whole address must be the same as the value you type. That includes the https:// prefix, the domain, and any query string. Differences that don't change the page are ignored: the case of the domain, a trailing slash, a #fragment, a default port, and the order of query parameters.

  • Value https://example.com/pricing: matches that address and https://example.com/pricing/. It will not match http://example.com/pricing (a different protocol), or the same address with a query string on the end.
  • Because it needs the whole address, use Exact match for one specific page you can copy the full URL of. For "starts with this path," use Path match below instead.

Path match

The visitor's URL path must exactly equal the value. The domain, any query string, and a trailing slash on either side are all ignored.

  • Value /pricing: matches /pricing and https://example.com/pricing?ref=ad, but not /pricing/enterprise or /pricing-old.
  • Useful for a single landing page, when you don't want to type the whole address.

Substring match

The value must appear anywhere in the visitor's whole address: the path, the domain, or the query string.

  • Value checkout: matches /checkout, /checkout/confirm, and /store/checkout/payment.
  • Type only the piece you're looking for, such as checkout or pricing.html. It doesn't need https://. A page address never contains a space, so the builder flags a value that has one.
  • Useful for matching a URL that could appear in different positions in the address.

Pattern match

A simpler alternative to Regex match, using two wildcard characters: * stands for any run of characters, and ? stands for exactly one character. Like Exact match, the pattern is compared against the visitor's whole address. Start it with * to match a path that could be anywhere in that address.

  • Value */checkout*: matches any address containing /checkout, such as https://example.com/checkout or https://example.com/store/checkout/payment.
  • Value *: matches every address, because the asterisk stands for "anything." This is the clearest way to run an experiment site-wide.

Regex match

The value is a JavaScript regular expression, matched against the visitor's whole address. This is the most powerful and most complex option.

  • Value /product/\d+$: matches any address ending in /product/ followed by digits, such as https://example.com/product/123, but not one ending in /products or /product/abc.
  • Value /(pricing|plans)$: matches an address ending in /pricing or /plans.
Info

Exact, Substring, Pattern, and Regex all compare against the visitor's whole address, including https:// and the domain, not the path alone. Path match is the one option that looks at the path by itself. Reusing a regular expression written for a path-only match? Drop the leading ^. A real address never starts with a slash, so an anchored pattern like ^/pricing$ will never match.

Simple match still exists, but only on older rules

An older match type called Simple matched a path prefix. It's no longer offered when you add a new rule. An experiment created before this change might still have a Simple rule, and it keeps working exactly as before: it matches any address whose path starts with the value.

Conditions

Each rule has a condition that is either Matches or Does Not Match.

  • Matches: the URL must match the rule for the experiment to be eligible.
  • Does Not Match: the URL must NOT match the rule. Use this to exclude specific pages from an otherwise broad experiment. For example: a Pattern match on * (all pages) combined with a does-not-match Path match on /admin would exclude the admin page.

Multiple rules and OR logic

When you add multiple URL rules, the experiment is eligible to run if the current URL matches any rule (OR logic). For example:

  • Rule 1: Path match on /pricing
  • Rule 2: Path match on /plans

With these two rules, the experiment would run on both the pricing page and the plans page.

Tip

If you want to run an experiment site-wide, add a single Pattern match rule with value *. The asterisk stands for "anything," so it matches every address.

Testing your rules

Before you save, check your rules against a real address using the Test a URL box shown in the screenshot above.

Paste a full address, including https://. A vs B checks it two ways:

  • It should belong to your project's domain. Paste a URL from another site and you still get the rules' answer, with a note under it: that address is not on your project's domain, so the snippet never runs there.
  • It runs through your rules, the same way a visitor's browser would. You'll see This URL matches your targeting rules or This URL does not match your targeting rules.

This is the fastest way to catch a typo in a rule before you launch.

Running on every page

Clearing every URL rule means the experiment runs on every page of the site. This is the same outcome as the site-wide Pattern match tip above, reached a different way: instead of adding a rule that matches everything, you remove all the rules and there is nothing left to narrow eligibility.

New experiments don't start empty, though. A new experiment is seeded with one rule matching your project's URL, using Substring match, so it's eligible on your site from the moment you create it. You can edit that rule to narrow it, or remove it (along with any others) to run everywhere instead.

Audience selection

Below the URL rules, you can optionally add one or more audiences. Audiences further narrow who is eligible for the experiment beyond URL matching. For example: only show the experiment to visitors on mobile devices, or only to visitors from specific countries.

If you don't pick an audience, the audience picker shows Targeting everyone and the experiment runs for every visitor who matches the URL rules. If you add audiences, a visitor must match at least one audience to be eligible.

Audiences are created separately in the Audience Builder and then referenced here. You cannot create audiences directly from the experiment builder: create them first, then come back and select them.

Saving and continuing

Changes to targeting are not saved as you type. An Unsaved changes bar stays at the bottom of the page until you click Save Draft, or Next, which saves and moves on to Step 2 (Variations). Discard on the same bar drops your edits. You can always click Back from any subsequent step to return and edit targeting.

Was this helpful?