Sometimes, you want your test to only execute based on Javascript conditions. This document describes our thoughts on this, and how to approach it.
Webtrends Optimize is a very flexible platform. The following thought process will point you to the right solution based on the situation:
1. Is the information you need available before the wt.js tag fires?
IF YES - Consider the data layer approach - Jump to this
IF NO - Continue below.
2. Would the decision be best made in a Location object?
IF YES - Delay the execution of Optimize until the data is available - Jump to this
IF NO - Continue below.
3. Are you using the OBF?
IF YES - Check out Conditional Activation in the OBF Docs - Go there
IF NO - Use the non-OBF approach below - Jump to this
Data Layer Approach
There is a detailed document here describing how the data layer works, how you can feed information into the platform, and how you can use it for Location and Segmentation targeting.
Delaying the execution of Optimize
By default, your post-load script will look similar to:
WT.optimize.setup(WT.optimizeModule.prototype.wtConfigObj);
This is the "go" function call, that tells the platform we're ready to evaluate tests. You can delay this call, waiting for some condition to be ready such as the datalayer on the page.
var intvl = setInterval(function(){
// Poll
if(!window.dataLayer) return;
clearInterval(intvl);
// Add the data we want into the datalayer
var myvalue = window.dataLayer.filter(x => x.event === "something important").importantValue;
WT.optimizeModule.prototype.wtConfigObj.data.mykey = myvalue;
// Tell Optimize to initialize.
WT.optimize.setup(WT.optimizeModule.prototype.wtConfigObj);
}, 100);
Conditional rendering and pageviews with Javascript
This is handled in the pre-render script of your test, which is available both in the Visual Editor and Advanced Editor.
There are two controllable aspects to this - rendering and pageviews.
Controlling rendering
Rendering is controlling whether or not your variations and post-render execute. Considering the default is that they do execute, your logic would be to find reasons for them to not execute.
The below code example uses our Velocity Templates engine to dynamically find your testAlias, making the code easy to copy/paste into any test.
/* @wt.parse="vm" */
WT.blockCodeRender.push("$testAlias");
You could wrap these in any conditions, such as:
/* @wt.parse="vm" */
if( !something_good ){
WT.blockCodeRender.push("$testAlias");
}
Note, however, that your conditions will need to execute immediately as the default will be to render your variations and post-render immediately without delay after pre-render fires.
Controlling pageviews
Pageviews are the platform counting users. Without this, we may choose to run code on their machine, but they would not be registered as belonging to your test.
There are two aspects to this - blocking and then manually tracking pageviews.
Blocking pageviews
The below code example uses our Velocity Templates engine to dynamically find your testAlias, making the code easy to copy/paste into any test.
/* @wt.parse="vm" */
WT.blockPV.push("$testAlias");
As with the above, you could wrap these in IF conditions, but they again do not need to be set immediately, without delay.
Manually tracking pageviews
After blocking (or more accurately: pausing) pageviews, you can track them quite easily.
The below code again uses Velocity Templates to avoid manually writing the testAlias value into your code.
/* @wt.parse="vm" */
WT.optimize.lookup("$testAlias").track("pageview");
Note that the first line only needs to be written once, and so complete code with both parts in place may look like:
/* @wt.parse="vm" */
// Pause pageviews by default
WT.blockPV.push("$testAlias");
// Wait for something e.g. datalayer
var intvl = setInterval(function(){
if(!window.dataLayer) return;
clearInterval(intvl);
// Check condition
if( window.dataLayer.filter(x => x.event === "something important").length ){
// We're happy, count the user
WT.optimize.lookup("$testAlias").track("pageview");
}
], 100);