WT.helpers – Utility Methods

WT.helpers is the object in which you’ll find a handful of utility methods. These are things you are likely to require in various places throughout your work in the UI.

These methods are only available for Web, and only if served through our CAPI (there are other options for rendering tests, such as directly accessing our REST or JSONP APIs).



This helper allows you to Set and Remove CSS stylesheets, written the page with an easy-to-follow patten in JavaScript.

CSS – Add

This is the method to write stylesheets to the page.

The first argument is required, and is either a String or Array of strings. These hold the CSS rules you wish to write to the page.

The second argument is an optional String, which attaches an id attribute to the <style> tag which gets written to the page. This is particularly useful if at some point you intend to remove the stylesheet.

// One CSS rule:
WT.helpers.css.add("#myElm { attribute: value; }");

// One CSS rule, with ID 
WT.helpers.css.add("#myElm { attribute: value; }", "myStyleSheet");

// Multiple CSS rules
    "#myElm1 { attribute: value; }",
    "#myElm2 { attribute: value; }",
    "#myElm3 { attribute: value; }"

// Multiple CSS rules, with ID
    "#myElm1 { attribute: value; }",
    "#myElm2 { attribute: value; }",
    "#myElm3 { attribute: value; }"
], "myStyleSheet");


CSS – Del

A simple method to delete your stylesheet. In reality, this method actually removes any element by the provided id.




This helper method allows you to check, write and delete cookies to the page. These are written using JS, and so are first-party.


This returns the value of a cookie, or null if not found.

// returns value of cookie, or null.



This sets a first-party cookie to the page. It has various arguments:

  • Name, required, String – the cookie name

  • Value, required, String – the value you want to assign to the cookie

  • Expiry, optional, Integer – the time in days you want the cookie to expire in. If no value provided, it becomes a session cookie.

  • Path, optional, String – the path value you want to be written into the cookie. Defaults to /.

  • Domain, optional, String – the domain you want to be written into the cookie. Defaults to the top-level domain the page is on. Useful if you want to restrict the cookie to a subdomain.

WT.helpers.cookie.set(name, value, expiry, path, domain);

// e.g. Session cookie
WT.helpers.cookie.set("cookieName", "cookieValue");

// e.g. Cookie with 30 day expiry
WT.helpers.cookie.set("cookieName", "cookieValue", 30);



As the method suggests, this loads a file asynchronously. A script file. It accepts two arguments:

  • URL, required, string – the URL of the script file you want to write to the page

  • Callback, optional, function – a function that will execute onload of the script.

// e.g. Load a file:

// e.g. Load a file with a callback
WT.helpers.loadFileAsync("https://c.webtrends-optimize.com/myscript.js", function(){
    console.log("it loaded!");



This is a self-executing function, which holds the value of Device Type – ”desktop”, ”tablet” or ”mobile”.

It can be accessed as WT.helpers.device. This is a basic check using some rudimentary conditions – nothing to the power behind our segmentation engine, but often helps to accomplish a straightforward goal.



Leaving stray console logs in your work is not advised for any of the work that we do. Clients will often pick up on it, perhaps leaking into monitoring tools, and can confuse the logging and reporting they have.

To help with this problem, we suggest all logging take place through a proxy-function. The principle is that the logs or alerts will only trigger if you have the cookie _wt.bdebug=true. For normal users, who won’t, the logs won’t be relayed to window.console or window.alert.

Available methods include:

  • WT.helpers.bdebug.log – a proxy for console.log

  • WT.helpers.bdebug.info – a proxy for console.info

  • WT.helpers.bdebug.warn – a proxy for console.warm

  • WT.helpers.bdebug.error – a proxy for console.error

  • WT.helpers.bdebug.dir – a proxy for console.dir

  • WT.helpers.bdebug.alert – a proxy for window.alert


Find Variation Name

By default, Optimize does not relay “friendly names” to the front-end. The [Optimize Build Framework] is the only exception to this rule, where names are transmitted to the front-end based on however you choose to code them. We have generic names as standard, but you’re able to modify the code as you see fit.

WT.helpers.findVariationName is an easy and uniform way to get your test name and variation name, without having to worry about the intricacies of the type of project you’re running.

To call the method, you provide a testAlias to performa lookup on.


It returns an Object containing your test name and variation name:

    "testName": "Test 1 - Homepage USP ABn",
    "variationName": "1 - Free Delivery"

This call is often used in conjunction with [Pageview](addEventHandler) event subscriptions, as that page will explain.