URL Targeting vs Audience Targeting in Optimizely: What's the Difference?

Here's a scenario I've seen play out more times than I can count: an experimenter runs what they think is a test on the checkout confirmation page, but the results show conversion rates that make no sense. When I dig in, I find the URL targeting was set to a simple "contains /checkout" match — which was also capturing the cart page, the checkout form, and the order confirmation page. Three different pages, three different user intents, all mushed into one "experiment."

URL targeting and audience targeting solve different problems. Confusing them is one of the most common technical mistakes in Optimizely setups.

The Exact Technical Difference

URL Targeting defines the pages where Optimizely loads and activates the experiment. It's evaluated against the browser URL at page load time. If the URL doesn't match, the experiment JavaScript never runs.

Audience Targeting defines which visitors qualify for the experiment after it has loaded on the matching URL. It's evaluated against visitor attributes — cookies, device type, geography, custom attributes, referral source, etc.

Think of it this way: URL targeting is your bouncer checking which venue you're at. Audience targeting is the bouncer checking your ID to see if you're allowed in. Both gates must be passed before a visitor enters your experiment.

The key implication: if URL targeting fails, Optimizely doesn't even evaluate audience conditions. If URL targeting passes but audience conditions fail, the visitor sees the control experience and is not counted in results.

**Pro Tip:** URL targeting is evaluated synchronously at page load. Audience conditions that depend on custom JavaScript attributes (like user data from an API call) can miss the evaluation window if the data hasn't loaded yet. For attribute-dependent targeting, consider using activation mode "manual" and triggering experiment activation after your data is available.

When to Use Each: Decision Table

The rule of thumb: if the targeting condition is about WHERE something happens, use URL targeting. If it's about WHO the person is, use audience conditions. When you need both, use both — they stack.

Examples: Testing only on /product/ pages → URL targeting. Testing only for mobile users → audience targeting. Testing only for returning visitors → audience targeting. Testing only on pages with ?sale=true → URL targeting (query param). Testing for logged-in users on checkout → both. Testing for users from email campaigns → audience targeting (UTM source). Testing on all pages except /admin → URL targeting (exclusion pattern). Testing for high-value customers → audience targeting (custom attribute).

Wildcard URL Patterns: What Actually Works

Optimizely's URL targeting supports several match types. Here's how each one behaves in practice:

Simple Match (default)

Matches the exact URL. https://example.com/checkout matches only that exact URL. Nothing else. Use this when you need absolute precision.

Substring Match

Checks if the pattern appears anywhere in the URL. Pattern: /checkout

Matches:

• https://example.com/checkout
• https://example.com/checkout/confirm
• https://example.com/checkout?step=2
• https://example.com/new-checkout-experience — UNINTENDED

This is where people get burned. /checkout will match any URL containing that string. If your site has /new-checkout-flow or /checkout-abandoned, those get included too.

Starts With

Pattern: https://example.com/checkout

Matches everything that begins with that string. More precise than substring. Doesn't catch /new-checkout because that's a different path.

Matches (Regex)

The most powerful option. Also the most error-prone.

Pattern: ^https://example\.com/checkout(/|$)

This matches:

• https://example.com/checkout
• https://example.com/checkout/
• https://example.com/checkout?step=2

But NOT:

• https://example.com/checkout-confirmation
• https://example.com/new-checkout

**Pro Tip:** Always anchor your regex patterns with `^` at the start to prevent partial domain matches. `checkout` matches any URL anywhere. `^https://example\.com/checkout` matches only on your domain at that specific path. Always test regex patterns in a tool like regex101.com before deploying.

Query Parameter Targeting

This is a frequently overlooked capability. You can target visitors based on URL query parameters either through URL targeting or through audience conditions.

Via URL targeting: Use "contains" match with the query parameter. Pattern: ?campaign=summer-sale

This catches any page with that query parameter. Works but is fragile — parameter order can cause misses.

Via audience conditions: Use the "Query Parameter" condition type. Name: campaign, Value: summer-sale.

The audience condition approach is more reliable because it parses the query string properly regardless of parameter order.

The hybrid pattern I use for campaign-specific tests: URL targeting scopes to the right pages (e.g., starts with https://example.com/landing), and a query parameter audience condition scopes to the specific campaign (utmcampaign = holiday2025). This keeps each targeting mechanism doing the job it's best at.

**Pro Tip:** Query parameter audience conditions are evaluated case-insensitively in some Optimizely implementations and case-sensitively in others. Test both `utm_campaign=Holiday` and `utm_campaign=holiday` in your QA environment to verify behavior. I've seen tests lose 40% of eligible traffic because of a capitalization mismatch in UTM parameters.

The Most Common Mistake: Wrong Mechanism for the Job

Here's the mistake in its most dangerous form: using URL targeting to target a visitor segment.

Bad: URL targeting set to contains /account to target "logged-in users."

Why this is wrong: /account might be accessible when logged out (e.g., a login page at /account/login). You're not actually targeting logged-in users — you're targeting people on account-related URLs, which is not the same thing.

Good: URL targeting set to starts with https://example.com/account (to scope the pages) PLUS an audience condition checking for a session or auth cookie.

The reverse mistake is also common: using audience conditions when URL targeting would do the job more reliably.

Bad: Using a custom attribute pagetype = checkout as an audience condition, set via JavaScript on the page, to scope your experiment to checkout.

Why this is wrong: if that JavaScript fires asynchronously or errors out, your audience condition never gets set and nobody enters the experiment. URL targeting fires first, before any page JavaScript, making it inherently more reliable for page-level scoping.

How URL Targeting and Audience Targeting Interact

When both are set on an experiment, both must match. The order of evaluation:

1. URL targeting is checked first (synchronous, fast)
2. If URL matches, Optimizely loads experiment code
3. Audience conditions are evaluated
4. If audience conditions match, visitor is bucketed and assigned a variation
5. Variation code runs

One important nuance: Optimizely re-evaluates audience conditions on each activation. If you're using manual activation mode and calling window.optimizely.push({type: 'activate', experimentId: 'X'}), the audience check happens at that call — not at page load.

Multi-Page Experiment URL Targeting

For experiments that span multiple pages (like a checkout funnel test), you have two options:

Option 1: Multiple URL conditions with OR logic

Add multiple URL targeting rules to the same experiment, with OR between them. This is the simpler approach.

Targets:

• URL starts with https://example.com/cart
• OR URL starts with https://example.com/checkout
• OR URL starts with https://example.com/order-confirmation

Option 2: Broad URL targeting plus page-specific variation code

Use a broad URL match (like contains example.com) and put the page-specific logic in your variation JavaScript, using if (window.location.pathname.includes('/checkout')) to scope what changes.

I prefer Option 1 for maintainability. Option 2 puts targeting logic inside your variation code where it's harder to audit and debug.

**Pro Tip:** For funnel tests where the same visitor needs to see consistent variation treatment across multiple pages, make sure all pages are included in your URL targeting AND test that the variation assignment persists correctly. Optimizely uses a cookie to remember variation assignments, but if a page outside your URL targeting triggers a re-evaluation, you can get unexpected behavior.

Regex Patterns That Actually Work

Here are tested patterns for the most common targeting scenarios:

Exact page: ^https://example\.com/checkout$

Page with or without trailing slash: ^https://example\.com/checkout/?$

Page with optional query string: ^https://example\.com/checkout(/|\?|$)

All pages in a section: ^https://example\.com/products/

Exclude a specific page from a broad match: Optimizely doesn't have native exclusion in URL targeting. Workaround: use a narrower "starts with" pattern and use audience conditions with a Current URL attribute to exclude specific paths.

Both www and non-www: ^https://(www\.)?example\.com/checkout

**Pro Tip:** When using regex URL targeting, always test on real URLs from your site — including URLs with query strings, hash fragments, and trailing slashes. A regex that looks correct in isolation often has edge cases in production. The Optimizely Chrome extension lets you test URL targeting rules against the current page URL before launching.

Common Mistakes

Using "contains" match for anything more complex than a simple path. It will match substrings you didn't intend. Always use "starts with" or regex for production experiments.

Not accounting for URL variations. Your checkout might be at /checkout, /checkout/, /checkout?ref=email. A simple exact match will miss most traffic. Use regex or "starts with" and test all URL variants.

Running the same experiment on URLs that serve very different user intents. If your /products URL targeting catches both category pages and individual product detail pages, you've mixed two very different conversion contexts. Split into separate experiments.

Changing URL targeting on a live experiment. Any change to URL targeting mid-experiment means some visitors saw the old targeting and some saw the new. Your data is now contaminated. Always stop and restart.

Forgetting that Optimizely evaluates URL targeting against the full URL including protocol. If you write /checkout as a "simple match," it won't match https://example.com/checkout because simple match requires exact match. Substring "contains" is different from simple/exact.

What to Do Next

1. Audit your top 3 live experiments — verify that each URL targeting rule is using the correct match type and test it against at least 5 real URLs from your site including edge cases (with query strings, trailing slashes, UTM parameters).
2. For any experiment using "contains" matching, convert to "starts with" or a properly anchored regex pattern. Document the change and restart the experiment if it was already running.
3. Build a URL targeting cheat sheet for your team — one page with the four match types, example patterns, and when to use each. It takes 20 minutes and eliminates a class of recurring mistakes.
4. Test your targeting with the Optimizely Chrome extension before every launch — verify that you land in the experiment on intended pages and do not land in it on unintended pages.