Target audiences with conditions
Products
- Optimizely Web Experimentation
- Optimizely Edge Delivery
- Optimizely Personalization
The availability of features may depend on your plan type. Reach out to your Customer Success Manager if you have any questions.
When you configure audiences to target visitors in your experiment, you build those audiences using conditions. The following sections describe each audience condition, including common ways to use them to target certain visitors. See Target audiences using the Audience Builder.
Most default audience conditions are not "sticky," meaning the condition is re-evaluated for the visitor on each new page load. For example, a visitor may meet the targeting conditions and be included in the experiment early on. If the visitor returns later, maybe with a different browser or language setting that does not meet the experiment's audience conditions, the visitor is no longer included in the experiment. The exceptions to this rule are the Ad Campaign and New/Returning Session conditions.
Available audience conditions vary based on your Optimizely Experimentation plan type. If you do not have access to an audience condition you need, talk to your Customer Success Manager about changing plans.
Ad Campaign condition
The Ad Campaign condition lets you create audiences based on utm_campaign campaign source types. Visitors who arrive with the parameter utm_campaign capture the parameter value as a dimension, up to 20 characters (longer values are truncated). This lets you examine campaign keywords such as holiday_sale.
Visitor comes from an ad campaign
There are several options for how to target ad campaigns when selecting Visitor comes from any of these ad campaigns.
- equals – Target an exact utm_campaign value.
- contains – Target any utm_campaign value containing the string you enter (similar to substring match in URL targeting).
- matches – Target a value using a Regular expression match.
- has any value – Target any ad campaign, regardless of the value.
For example, if you want to include visitors from the "spring_15" utm_campaign value, select Visitor comes from any of these ad campaigns and the contains targeting option, and enter spring_15 in the text field.
Visitor does not come from an ad campaign
There are also several options for targeting certain ad campaigns when selecting Visitor does not come from any of these ad campaigns.
- equals – Target users that do not come from an exact utm_campaign value but still come from an ad campaign.
- contains – Target users that do not come from any utm_campaign value containing the string you enter (similar to substring match in URL targeting), but the users still come from an ad campaign.
- matches – Target users that do not come from a campaign that matches the Regular Expression but still come from a campaign.
- has any value – Will not target any visitors. A visitor cannot come from an ad campaign and have no value. This value should not be used.
When selecting Visitor does not come from*,* it is a common interpretation that anyone who comes to a page, except those from an ad campaign would be selected. But this is not true. Instead, the user must come from an ad campaign, just not the one you specify to be targeted.
To optimize based on ad campaigns, see optimizing search engine marking (SEM) campaigns.
Note
The Ad Campaign audience condition is sticky. In other words, if a visitor lands on a page with a query parameter from an ad campaign and gets targeted in the experiment, the targeting persists after the initial page view. This stickiness lasts for the duration of the campaign. The Ad Campaign condition is ideal for tracking visitors across multiple pages.
After a visitor is initially bucketed into an experiment using the Ad Campaign condition, Optimizely Experimentation places this information in the browser's localStorage so that the visitor continues to be targeted, even after they move to other pages on the site.
Browser condition
The Browser condition targets your experiment based on a visitor's browser. You can include or exclude visitors who are using specific browsers.
For example, suppose you want to target your experiment to visitors who are using Google Chrome. You can use the Browser audience condition to include visitors who are browsing in any version of Google Chrome in the experiment.
An alternative to targeting based on the browser is Custom JavaScript targeting.
Cookie condition
To target a visitor with a cookie from your site, enter the cookie's name, which determines if that cookie is set. You also can target cookie values with the following options:
- equals – Target an exact cookie value.
- contains – Target any cookie that contains the string that you enter (this is similar to substring match in URL targeting).
- matches – Target a value using a Regular Expression (currently, Optimizely Web Experimentation and Optimizely Performance Edge do not support flags).
- has any value – Target based on the presence of a cookie, regardless of what the value is.
Cookie targeting is case-sensitive for both names and values. If you need your cookie targeting to be case-insensitive, contact Optimizely support.
The most common use cases for the cookie condition:
- Set audiences by their logged-in state
- Create a test cookie to preview your experiment.
For example, you want to run an experiment on a pop-up banner highlighting a new-user promotion, but you also want to ensure that the experiment is only counting visitors for those who see the banner. You know that a cookie seen_promo=true is set on visitors when the pop-up appears.
First, identify how you will differentiate between visitors who have and have not seen the promotion. Select the Cookie condition, then Visitor does not have any of these cookies. Add the cookie name (seen_promo) in the left input field and the cookie value (true) in the right input field:
The experiment runs only for visitors who do not have the cookie seen_promo=true. This means your test will only be seen by visitors who are seeing the promotion for the first time.
As another example, let's say you want to run an experiment with layout changes for customers who are logged in to your site. You know that logged-in customers have a cookie logged_in=true.
First, identify how you will differentiate between logged-in and logged-out customers. Select the Cookie audience condition, then Visitor has any of these cookies. Add the cookie name (such as loggedin) in the left input field and the cookie value (true) in the right input field:
The experiment runs only for visitors with the specified cookie that distinguishes them as being logged in. In this case, a cookie is a differentiator, but in many cases, the logged-in state may be a variable on the page and you have to use a custom JavaScript condition.
Custom JavaScript
Custom JavaScript conditions let you target complex and customized sets of visitors based on conditions that you define. Ensure that the condition evaluates to true. To learn more about Custom JavaScript, including use cases, see Target audiences with custom JavaScript.
Device condition
Optimizely Experimentation targets your experiment based on device types. You can choose to include or exclude visitors who are using a specific device. Optimizely Experimentation detects devices based on the user agent provided by the visitor's browser, so this condition is not evaluated based on device width or screen width.
For example, if you have a responsive website, you might want to test adding a large image to your landing page. You know that adding an image to the page does not easily scale for smaller screens, so you can use the Device audience condition to exclude visitors who use a mobile phone from your experiment.
An open-source JavaScript library called ua-parser-js (USParser) defines the device type. Mobile and non-mobile segments on the results page are not defined using UAParser.
- Other tablet – If the device is a tablet but not one of the specified models (iPhone, iPad, and so on) on the UI, then the device is considered an "other tablet."
- Other mobile – If the device is a mobile device but not one of the specified models (iPhone, iPad, and so on) on the UI, it is considered an "other mobile."
Dynamic Customer Profiles (DCP)
A Dynamic Customer Profile (DCP) is a single, actionable view of your customer, built from a combination of Optimizely Experimentation behavioral data and your first-party and third-party customer data. DCP creates audience conditions based on information that you have about your customers and create 1-1 personalization. See Create audiences with Dynamic Customer Profiles.
IP Address condition
Set audiences based on the IP address of the visitor to your webpage. You have the following matching rules:
- Exact Match – The visitor's IP address must exactly match what is in the box for the targeting condition to be true (so you must enter a full IP address).
- Prefix Match – Define the starting part of the visitor's IP address that must match. Any IP addresses that start with the same numbers as what is in the box should match.
- Regular Expression – Get specific in terms of the matching conditions for your visitors. See About regular expressions page.
- CIDR Notation – Express an entire subnet more capably than the other match types. If you are not familiar with CIDR Notation and have more advanced technical skills, see Classless Inter-Domain Routing.
Language condition
Browsers store preferred language choices, such as "en-us" (for US English), so you can set audience conditions by language preference. However, this assumes that a visitor's language preference corresponds with their location. For example, a US citizen might have his browser set to prefer "en-us" even though he's actually living in Brazil. If your plan does not include geotargeting, this feature effectively lets you target by country:
List attributes
List attributes are a type of external attribute that enable you to target visitors that are part of an audience you have already defined somewhere outside of Optimizely Web Experimentation. They let you import custom lists of users and then create audience conditions based on those lists. See Set up list attributes.
Location (geotargeting) condition
Location (also known as geotargeting) runs experiments for visitors coming from specific geographic locations. You can also target specific DMA Regions. DMA regions are specific geolocations in the US created by Neilson for better marketing purposes.
To use this Location as an audience condition, start typing the name of a major city, country, state, region, or continent, and a drop-down displays. DMA regions display [DMA Region]. Select your location from the drop-down:
Standard locations
DMA region
You can add more than one location.
With these targeting settings, the experiment runs only for visitors who come from these specific locations.
The geographic information comes from Cloudflare. This geographic information is derived from the source of the internet connection. This means that under certain conditions, the information may have an accuracy variability, such as a visitor identified with a city may actually be from a suburb close to the city.
Visitors also using a VPN for another city are bucketed into an experiment targeting that city. For example, if a visitor's location is in Boston after VPN, they are bucketed into an experiment targeting Boston visitors, regardless of their real location.
Mobile visitors are often identified as coming from a location that is different from where they actually are because their internet traffic is routed according to their service provider. For example, a visitor accessing a site on her phone from Livermore, California may appear to come from Sacramento, California, depending on how her service provider routes traffic. (You can use the Device audience condition to exclude mobile visitors.)
Visitors whose geographic information cannot be determined will not match any locations. This means that if you are targeting specific locations, these visitors will not see the experiment if you are targeting specific locations. However, if you are targeting to exclude locations, these visitors will see the experiment.
Warning
Using the Location audience condition may cause page flashing because the script that obtains the visitor's IP and location information runs asynchronously.
Because this information is returned asynchronously, sometimes an experiment can finish evaluating audience conditions before the geotargeting script returns the information. Once this information is available from the geo2.js resource, it is cached in the visitor's browser for later reference.
New/Returning Session condition
The New/Returning Session condition targets experiments towards new or returning visitors to a page where your Optimizely Web Experimentation snippet is implemented.
Note
The New/Returning Session audience condition is sticky. This condition is session-based, meaning that the first time someone goes to a domain where your Optimizely Web Experimentation snippet is implemented, they are considered new for the remainder of the session.
A session is a period of activity for a user. An existing session ends and a new session begins after 30 minutes of inactivity on the site. The maximum session length is 24 hours, at which point a new session automatically begins (even if the user wasn’t inactive for 30 minutes).
For a new visitor, this audience condition is also sticky for the duration of that session. In future sessions, those visitors become returning visitors and are not targeted as new visitors.
When you interpret and segment results, note that even if a visitor is counted as new and later returns as a returning visitor, that visitor will count in the new segment.
This condition changed as of the release of Audiences. Previously, it was not session-based. Experiments using our old new/returning functionality, before audiences were released, will not migrate automatically to audiences.
Platform condition
The Platform audience condition creates audiences based on the platform or operating system a visitor is using such as Windows or macOS. For example, if you run a promotion for a new mobile app that you are launching for iOS and you only want to show that promotion to visitors who are using iOS, you can include visitors who are viewing the specified URL from a device running any version of iOS.
This dimension uses the same library as the Device condition above and introduces a set of values to target other than the device.
Like the Device condition above, this condition targets your experiment based on device type, which is inferred from the user agent provided by the visitor's browser. It provides a slightly different set of values that you may target:
- Mobile Platforms – iOS, Android, Windows Phone, Blackberry
- Desktop Platforms – Windows, macOS, Linux
Predicted intent condition
The Predicted Intent audience condition determines whether your visitors are most interested in a topic. This eliminates the need to enter all possible combinations of criteria when defining your audience.
Query parameters
URLs can contain a lot of information, and one of the most common components is the query string. Query strings contain many pieces of information, and you can personalize your experiments. A common use case for setting audiences based on query parameters is targeting your experiment for paid ads and search engine marketing (SEM) campaigns. You have the following options to target query parameters:
- equals – Target an exact query parameter value.
- contains – Target any query parameter value that contains the string that you enter/ (This is similar to substring match in URL targeting.)
- matches – Target a value using a Regular Expression.
Note
Optimizely Web Experimentation and Optimizely Performance Edge do not support flags.
- has any value – Target based on the presence of a query parameter, regardless of what the value is.
Query parameter targeting is case-sensitive for names and values. If you need your query parameter targeting to be case-insensitive, contact support.
Query Parameter conditions will not continue to include a visitor in an audience if the visitor returns to the page without the query parameter. In a multi-page experiment, the visitor fails targeting conditions if they navigate to another page in the experiment without the query parameter that is used in the audience condition.
For example, if you want to test changing a search widget for visitors who are arriving at the page from SEM campaigns, the desired audience has a query parameter utm_medium=cpc.
First, identify the name and value of the query string parameter you care about. Is the value always guaranteed to be the same, or will it change? Are you looking for a specific value, or will any value work?
If the experiment should run for all visitors with utm_campaign present in the URL, but the value does not matter, select Visitor matches any of these query parameters, add utm_campaign in the left input field as the parameter name, and select has any value from the drop-down list.
If you do care what the value of the query string parameter is, such as utm_medium=cpc, follow the same steps, but choose equals from the dropdown and enter the value of the query parameter.
Add as many query parameters as you want.
For a more in-depth example of how you can use Query Parameter audience conditions to deliver more value from your search engine marketing (SEM) and ad campaigns, see optimizing based on SEM campaigns.
Referrer URL
The Referrer URL audience condition option triggers an experiment based on the URL that your visitors came from, known as the referrer.
Typical use cases include the following:
- Set audiences by the search engine they use.
- Exclude certain promotional referrers.
For example, if you run several offers on popular discount sites and want to run an experiment that tests adding promotional banners to your page, but you do not want the visitors coming from a discount site to see these alternate offer, first identify which URL sources should be excluded from the experiment. Then, select Visitor does not come from these URLs and add the specific page URL with the appropriate match type.
Referrer URL match types can be one of the following:
- Simple match – This is the default match type. It is useful for testing a single page.
- Exact match – Use only if the URL significantly changes how the page displays due to added query parameters or hash parameters. To target visitors who are using a certain query parameter, use an audience condition instead of an exact match.
- Substring match – Use to match specific strings of text within a URL. It is useful for experiments that change the same element site-wide or on multiple pages.
- Regular expression – Use to target complicated URL structures that are not easily captured by the other URL match types.
In this case, the referral is from a substring match to www.groupon.com and www.livingsocial.com:
This ensures that the experiment runs for every visitor except those who were on a groupon.com or livingsocial.com page immediately prior to arriving at this site.
In another example, if you run an experiment to provide targeted content to visitors arriving from common search engines, first identify which search engines should be included in the experiment. Select Visitor comes from these URLs and add the specific page URL with the appropriate match type. In this case, the referral is from a substring match to google.com, yahoo.com, and bing.com.
This ensures that the experiment run for visitors who were Google, Yahoo, or Bing immediately prior to arriving at his site.
To include visitors who came to your site by specific search terms, see Target audiences by Referrer URL.
Time/Day of Visit condition
The Time/Day of Visit audience condition targets experiments to visitors during certain days and at certain times. Times can be specified to the minute or for the entire day, and they correspond to the visitor's local time zone.
Time/Day of Visit targeting will not include a visitor in an audience if the visitor loads your page outside of the day or time frame. However, the visitor's conversions count toward whichever variation they were exposed to, even if they convert outside of the day or time frame.
Traffic Source condition
The Traffic Source condition creates audiences based on the source type in the browser:
- Campaign – Contains visitors that arrive on a URL containing a utm_campaign, utm_source, gclid, or otm_source query parameter. If the URL contains one of these parameters, the visitor counts as Campaign traffic even if they arrived through Search.
- Search – Contains visitors that visit through a referral URL containing Bing, Google, Yahoo, or Baidu but NOT a specific campaign parameter (otherwise, they would be bucketed as Campaign).
- Referral – Includes visitors that come from another URL that does not count as Campaign or Search.
- Direct – Includes visitors who do not have any external referrer in their URL.
These are the same as the source types found in Optimizely Experimentation's default segments.
The Traffic Source source types (except Campaign) are based on the document.referrer value in the browser. Your visitors' source type values may change as they navigate your site.
For example, suppose your site's flow includes a step where visitors leave the page, go to a third-party site or different subdomain, and come back to your site. After they come back to your site, they count as a referral and are included in your experiment if it is targeted toward referral visitors. Be mindful of using this audience condition if your site includes such a step.