Skip to main content

Tag Configuration overview

What options are available to you when configuring your tag

James Harber avatar
Written by James Harber
Updated over 2 weeks ago

What are Tag Configurations in Webtrends Optimize?

Webtrends Optimize is fairly unique in offering users a mechanism to build draft and live versions of their tag / js snippet. You can test all of these separately, and set them live as you wish.

So, when you have a Global JS change that you wish to make, you can create a Draft tag config, write and test your changes, and then set it live when ready.

Most of the values controlled here can also be set / manipulated with Javascript in preinit. You'll find them in WT.optimizeModule.prototype.wtConfigObj. and they typically start with s_.

We will discuss each of the options below.

Name

Name of the tag. Must be alphanumeric only.

Description

Optional description to make clear to others what the piece of work is for.

Tag version

This is a dropdown, allowing you to select which lib version you want to use.

Users also have the ability to define this with Javascript, using the following code in their preinit:

WT.optimizeModule.prototype.wtConfigObj.libUrl = "url here";

This custom route allows us to make custom libs that you can host in your Asset Manager, with tailored features for you.

State

Draft - available to preview, QA and eventually set live when you're happy. You can have as many tag configs in the Draft state as you wish.

Live - being served to users. You can only have 1 tag config live at any given time.

Display mode

Webtrends Optimize masks the page while fetching your experiments. The display mode dictates if and how we do it.

None - No page masking. Also used if you want Custom CSS page masking or to write your own rules by hooking into the hide_show event.

Display - Uses display:none as a CSS rule to mask the page.

Visibility - Uses visibility:hidden as a CSS rule to mask the page.

Shift - Shifts the page off the screen, using position: absolute; left: -1000% to mask the page.

Overlay - Creates an iframe which is placed on top of the page to mask it.

Overlay colour

If you're using the Overlay hide method, what colour should we make it?

Page mode

You can control when Optimize executes, both with pre-defined methods in the tag config, and by altering post-load scripts.

Head - Fire immediately, without delay. Best if you use JS/CSS for your experiments, and will poll in your experiments for the things you need.

Dom - Wait for domready. With a traditional page, all elements will be available by domready.

Onload - Wait for the window.load event. This wait for most Javascript on the page to execute, such as that which builds Single Page apps.

Timeouts

The timeout mechanism dictates how long we should wait before events or actions are abandoned.

Page timeout

What most people think of when referring to "timeouts". While we're fetching experiments, what is the max time we should wait before abandoning page load and letting the default website take over.

This accounts both for latency and disaster scenarios in Webtrends Optimize, but also for websites which are taking "too long" to load.

Conversion timeout

We have conversion capturing mechanisms in the platform. How long should they wait before we redirect users onwards.

Cookie timeout

Where we write cookies to the page, you can control when they expire.

Flags and other options

Cookie inspection

Should we read and consume onsite cookies when evaluating experiments or measuring behaviour? This powers cookie-based segmentation. Turning the value off would provide marginal performance gains.

Lightweight mode

For data fields, enabling lightweightmode allows you to only send data fields in the request that you whitelist. Again, the idea is to reduce the footprint of our requests and therefore have them transmit and process faster.

Scripts

Pre-init

Pre-init executes before the platform starts any core processes, including masking, fetching experiments, loading libraries, etc.

This is the core place where users will provide their customisations, such as cookie consent handling, custom CSS masking, conversion packages, custom 3rd party integrations, etc.

Pre-load

This is where masking takes place. We expose the logic, if you wish to change how it works.

Post-load

This is where Optimize "executes". You can delay this if needed, such as polling for GTM or Bloomreach Datalayer to load before we go off to fetch your experiments.

Calling .setup ships all values in WT.optimizeModule.prototype.wtConfigObj.data, and so updating it's values on a delay won't have any effect on evaluation of experiments.

Did this answer your question?