You are able to set up and track things you want to measure the success of your experience by. This can include things such as clicks and page views.

Be aware, if you are looking to track conversions in 'Shopify' this is handled differently and more info can be found here.

Also be aware tracking conversions using the OBF is done slightly differently to without, this is covered below. For more info on using the OBF see here.

These conversions are what will populate in the reporting when you are analysing the success of your experience. They will always come through in the same format whereby the name given is the name that will be shown in the report.

It is worth considering if this conversion point should be tracked in the advanced editor or if it would be better to be added as a global conversion (tracked for all experiences run). For more info on creating global conversions see here.

Tracking options

If you have decided that the project is the place to track the conversion then you have several ways to achieve it, including using the 'Create' form:

Tracking page load conversions (page visits) - you can do this via the create form and more info can be found here.
Tracking remote script based conversions - this might be to track something that is not on the page your experience is on (maybe a click), and you can add these in the create form. More info can be found here.
Tracking custom events - these will be things to track on the same page the experience is running on, such as a click.

This document outlines the options available to you with custom events.

Tracking custom events

For any metric you capture using Javascript, or with our REST APIs, you do not need to warn us in advance of the events you're capturing. These do not need to be declared anywhere, and you do not need to create any objects. We will index anything that is sent to us.

The only exception to this is Custom Data, which you need to warn us about due to field types. If your Custom Data is declared as Numeric, we will unlock Non-Binomial Reporting based on this data. This is covered below.

Be aware, we cover examples in this document however these are just for reference and you should be comfortable building these out whilst also considering a thorough QA process to test them.

Tracking single metrics

The simplest mark-up for tracking is as simple as:

WT.click({
testAlias: "ta_something",
conversionPoint: "event_name_here"
});

To break this down:

WT.click(...): A function tracks a click or a conversion event.
testAlias: "ta_something": Identifies the experience this event belongs to (in this case, test alias "ta_something").
conversionPoint: "event_name_here": Identifies the specific conversion or event being triggered (like "signup_complete" or "button_click").

Be aware, you will need to add/define an event listener as part of building this conversion point for it to track at the correct time.

An example of tracking a 'form_submitted' event (which may fire upon someone completing one of your forms) and when the user is part of test alias 'signup_form_test' may look like this where the output in reporting would be a conversion event of 'form_submitted':

WT.click({
    testAlias: "signup_form_test",
    conversionPoint: "form_submitted"
});

To find your test alias you will need to access the experiences screen, click on the overview icon and view the 'metadata' tab:

Tracking multiple metrics

If you are looking to track lots of these metrics it may help to create a small 'track' helped function such as:

!function(){
var track = function(name){
WT.click({
testAlias: "ta_something",
conversionPoint: name
});
};

track("metric_1");
track("metric_2"); 
// etc.
}();

To break this down:

!function(){ ... }(); This is an IIFE (Immediately Invoked Function Expression). It runs immediately after being defined — a common way to isolate scope and avoid polluting the global namespace.
Inside the function, a local track function is defined. This function takes a metric name (e.g., "metric_1") and sends it to the WT.click method, tagging it with a test alias ("ta_something") and a conversion point name.
It then calls the track function twice resulting in two tracking events being fired.

An example of why you would use this may be you are running an experience (ta_something) and want to track multiple things such as:

Viewing a modal
Clicking a CTA
Reaching a scroll depth

Each of those can be represented by a different "metric_x" string, and tracked independently in the Webtrends Optimise platform.

Tracking element visibility

We are able to track whether an element was visible or not which can help understand how many users saw something. This example is a basic implementation, for more performant ones, consider throttled events or intersection observers.

An example of this where we want to track users who scrolled within 200px of the 'About us' section could be:

var scrolled = false;
document.addEventListener(
    'scroll', e = > {
      if (scrolled) return;
      if (window.scrollY + (window.innerHeight - 200) >
          document.querySelector('#about-us-section').offsetTop) {
        track("scroll_myelm");
        scrolled = true;
      }
    });

To break this down

var scrolled = false;

Sets a flag so the tracking only fires once, no matter how many times the user scrolls.

document.addEventListener('scroll', e => {
Listens for the scroll event on the entire page.
if(scrolled) return;
If the event has already been tracked, it exits early to avoid duplicate tracking.
if (window.scrollY + (window.innerHeight - 200) > document.querySelector('#about-us-section').offsetTop) {
Checks if the user has scrolled to within 200px of the top of the #about-us-section.
- window.scrollY: How far the page is scrolled from the top.
- window.innerHeight - 200: Approximates when the section is coming into view.
- offsetTop: Distance from the top of the document to the target element.
track("scroll_myelm");
Fires a tracking function named track, sending the label "scroll_myelm" indicating that the user reached the "About Us" section.
scrolled = true;
Sets the flag to true so the event is tracked only once.

Tracking a metric with custom data

You are able to pass through extra data as part of your conversion point and this could be things such as an order value as part of a purchase conversion.

An example of how this would look is as follows:

WT.click({
testAlias: "ta_something",
conversionPoint: "event_name_here",
data: { key1: "value1", key2: "value2" }
});

To break this down

WT.click(...):
Calls a method (likely from a global WT object) to log a click or conversion.
testAlias: "ta_something":
Identifies the A/B test — this lets the testing system know which experiment this event is tied to.
conversionPoint: "event_name_here":
Names the event being tracked — e.g., "button_click", "form_submit",
"scroll_depth_reached", etc.
data: { key1: "value1", key2: "value2" }:
Optional metadata attached to the event. This can include things like:

Revenue
User state (e.g., logged in or not)
Specific values for segmentation or analytics

When adding these values and sending them through you will need to specify the format in which they are coming through. This is done on the 'Create' form under 'Variables'. You will need to define the name given in the above script and the type of data which Webtrends Optimize should expect to see coming in. The 3 options are decimal, integer and text.

You will need to 'Create new Variable' and define these here.

By using 'Custom data' we also have the ability to track the impact on page load performance as part of your experiences. This is slightly more advanced and more info on how to do this can be found here.

Using the OBF to track conversions

When using the OBF, tracking conversions is much simpler and does not require adding the test alias. It is very similar to above and there are 2 examples below to show how they differ.

With the OBF you are specifying the metrics slightly differently and more information on how to use the OBF can be found here.

Tracking a metric in the Optimize Build Framework

This method replaces the Wt.click and with Test.conversion and does not have the test alias attached.

Test.conversion("event_name_here");

Tracking a metric with Custom Data in the Optimize Build Framework

As above this method replaces Wt.click with Test.conversion and also excludes the test alias.

Test.conversion("event_name_here", { 
data: { key1: "value1", key2: "value2" }
});

Available methods in the Web Client API (CAPI)

How to QA metric capture

How to measure page load performance as part of your experiences

Creating conversions in the visual editor

Creating an experience in the Advanced editor (CSS and JS)

Creating conversions in the advanced editor