- Troubleshoot Audience conditions
- Access the visitor object
- How Audiences activate differently
- Understand how audience can change through a visitor's session or experience
Optimizely has a variety of different way an audience condition can be built. As such there are different approaches necessary for evaluating and troubleshooting each one.
Static audience conditions
Some audience conditions are evaluated at the beginning of the visitor's session and once evaluated Optimizely does not request the value again. These audience conditions are not expected to change, and therefore can be stored in local storage and referenced. Below are some examples of audience conditions that are evaluated at the beginning of the user's session and will be 'sticky' through the visitor's session regardless of how many experiments they activate. These audience conditions will be reevaluated on the users next session.
Device type uses last-touch attribution for a visitor session, meaning Optimizely will look at the visitor's user agent to determine what device type is being used and store that value in local storage to be referenced through the visitor's session. It is practical to assume that most visitor will not change the device they are on, however when working to QA your experiments, checking different device types is common.
In the QA scenario if a user is emulating mobile device in their browser, and gets bucketed into an experiment, then switches out of that emulated view back to desktop, Optimizely will still identify that users as being on a mobile device. The device can be checked by looking at the visitor object
optimizely.get(' , the value returned is the device that Optimizely is associating with the visitor. To change device, cookies and local storage must be cleared, or a new incognito window needs to be used.
The referring value is evaluate when the visitor first touches the snippet, and starts their session. An experiment does not need to activate to set this value, it is set automatically when Optimizely builds the visitor object. This value is sticky an will not be revaluated until the visitor starts a new session. This means that the visitor can have a different referring values for different sessions.
- This value is not the same as document.referrer. Optimizely's referrer is the last URL a visitor saw on a domain that did not have the current snippet on it.
Like referrer Traffic source is evaluated when the visitor first touches the snippet and starts their session. A computation based on referrer and window.location.href. Didn’t go as deep on this on the assumption that the same argument as made above for Referrer could be made for this, but can look into it more if needed. Confirmed at least that assigning to window.location.href generally causes a full page reload (assigning only a new hash or updating window.history will change the URL but don't change the traffic source, because they cannot change the hostname part of the URL).
This is a special query parameter that is stored in the visitor object
optimizely.get(' Unlike regular query parameters, the campaign query parameter value is stored in the visitor object. It only persist through one session.
These are values that are
Dynamic audience conditions
Audiences that are dynamic in nature can change each time an experiment activates.
The query parameter is evaluate on page load, and is evaluated right away. Unlike campaign parameters that are stored in the visitor object, query parameters only persist through page loads that include the query within in the URL.
If an experiment requires the query parameters be modified for an audience condition to match, this change must be done before Optimizely executes. Or the page must be refreshed.
- Update the modify a URL's query parameters for an audience condition, the change of the query parameters need to be adjusted,
- If the customer assigns to window.location.search, some browsers do a full page reload using the just-assigned query parameters. Since the client reactive on this reload, query parameters are guaranteed fresh.
- Another way of changing query parameters is using the browser’s window.history.pushState/replaceState API to change the URL, but this will not trigger a page reload. A manual reactivation of the client is required to apply to audience targeting conditions.
If a visitor changes an audience condition, that audience change only applies to events triggered for experiments that activate after the audience condition changed.
This section pertains to Dynamic Customer Profiles (DCP), List Attributes, IP Address, and Location, which all involve sending network requests.
Since these involve obtaining targeting data over the network, there is a tradeoff between immediately making a decision (of which variation, if any, to serve the visitor) with possibly-stale data, or deferring the decision in order and ensuring it’s made considering surely-fresh data, but risking prolonged flashing. Be assured though that in both cases, the snippet still kicks off a request to refresh the data, so subsequent snippet activations have a good chance of having valid cached data to work with.
If you are using any of these targeting conditions, Optimizely will send the requests to fetch the latest data from these services whenever the snippet activates. The responses to those requests may not have arrived by the time the snippet needs to decide what experience a visitor should have for a given experiment. That may not be as impactful as it first sounds, though, because there may be values for the needed visitor attributes cached in localStorage, from previous snippet activations. For list attributes, IP address, and location, the snippet will use these possibly-stale cached values, if available. The persisted values are eventually refreshed when the requests that were sent at the start of snippet activation receive their responses. This way, those attributes have a stale value at most once, and for experiments whose activation mode is anything other than immediate, the fresh value is likely used.
Optimizely's Geo-targeting is based off the information that Akamai EdgeScape has about a visitors' IP address in their database. Optimizely makes an API call to define the visitor's location when the snippet evaluates that an audience condition exists that evaluates geo-targeting. Optimizely will not make this call unless an audience has Geo-targeting and is being evaluated for an experiment that is activated on in the browser. From the network event the IP address is parsed and used in an API call that checks the visitors IP address against the EdgeScape database, then returns the information about the the visitors geographic information. Optimizely takes that returned data from Akamai and evaluates the audience condition based on the returned information. This information is then stored in the visitor object and referenced throughout the session.
To troubleshoot place the following URL in an adjacent tab of your website, the return object will contain the information Optimizely will use to build the audience condition at the beginning of the session. http://cdn3.optimizely.com/js/geo2.js
Since Optimizely evaluates this information at the start of the visitor's session, it is possible on a mobile device to move around during the session and the information being used by Optimizely is stale. To check of Optimizely is using stale data for location, use the visitor object
optimizely.get('to get the values Optimizely is actively using on the page.
DCP and List Attributes
DCP and list attributes work slightly differently to the other three. For DCP, if when the snippet activates it sees it has some cached data but that cached data is for a set of aliases which differ from the visitor’s current aliases, then it disregards that data on the grounds that it’s predicated on outdated aliases. Likewise for list attributes, if when the snippet activates it seems it has cached list attributes but that cached data is based on a set of list attribute values which differ from the visitor’s current values, then it disregards that data.
In either case, or in general when there is no cached data at all (e.g., for first-time visitors), the snippet will delay making a decision for a short amount of time (currently 2 seconds) in the hopes that the responses containing fresh data come back soon. If new data is received before that timeout, it will be incorporated into the visitor’s profile and used for evaluating audience membership. If new data is not received before the timeout, the decision proceeds without it. In the latter case, the visitor is assumed to not satisfy any conditions based on these kinds of data. Finally, note that even in those situations, the visitor may still qualify for an audience; consider an audience like DCP “or” Cookie, where knowing DCP information is not absolutely necessary to be included in the audience. For such an audience, determining experiment eligibility would be delayed only if the cookie condition failed and there was no cached and valid DCP data.
To refresh the data that comes from these sources long after the page has loaded (e.g., in a single-page app), reactivate the snippet via the “activate” API call.
Troubleshoot List Attributes
For List Attributes use the visitor object API call:
optimizely.get(' to determine if you get pass the conditions of an audience constructed with an uploaded list. Optimizely will return a true or false value of whether a visitor passes a DCP or Uploaded list audience. Below is an example of an uploaded list of California Zip Codes used as an audience conditions.
To identify what value Optimizely used to evaluate against uploaded audience conditions use the following URL in an adjacent tab to get the object from our audience evaluating software Tapi. This object will include more details than the geo-targeting URL above, including visitor postal code,
Optimizely will use the visitor's IP to find the zip code from via Akamai, our global content delivery network. Once the zip code is found the value is then passed to the list attributes targeting service to match the value against the lists you have uploaded through Optimizely. The value that service returns is true or false, and is what Optimizely will specifically use to determine if the visitor matches audience. This evaluation usually takes longer than a page load, so we generally will not see the zip code audience specifically defined until second page load.
The “waiting” policy for audience integrations (such as those for Demandbase, BlueKai, Lytics, etc.) is identical that described in the above section; i.e., the audience determination is deferred for up to 2000 ms, but if not received by then then it will proceed without it. The principal difference between this class of visitor attributes and those above is that rather than snippet initiating and waiting on HTTP requests, some other condition (e.g., a property on the global object being defined) is awaited.
Each audience integration has own implementation requirements. For a given integration, you can find its implementation instructions via Integrate Other Platforms “Optimizely X Web”.