Introduction to Global Metric Capture
Note: This process will require Javascript developers
Global Metric Capture is a code-driven process, where we hook into the functionality of the site as required using Javascript. An experienced developer should manage this without much difficulty, but this is only suitable for teams with access to Javascript developers.
Are you more of a visual learner? Check out this video instead:
VIDEO COMING SOON.
What is Global Metric Capture?
Account-wide metrics. Require only initial setup, and zero no per-test effort.
Why is this a good way to approach goal tracking?
You can track ad-hoc, per-test metrics, but it leaves it down to chance as to whether or not the developer / specialist remembers to add the metric, if they coded it the same way a previous developer did.
For QA, there is also an additional effort - if it could be different every time, you need to put more attention into testing this.
Instead, standardising your important, common metrics and having them captured in the same way for every single test you build takes all of this away.
Available Approaches to Global Metric Capture
These approaches can be used together
The approaches described below are not confined to being used in isolation. Many users of Webtrends Optimize will use two or all three methods, adapting based on what's right for the situation / specific goal.
There are a few different approaches we can take. Expand on the below - pros and cons.
Scrape: Conversion Package - jump to this section
Intercept: GTM Mirroring - jump to this section
Notify: opt_data.push - jump to this section
We will discuss each of these below.
Conversion Package
Pros - Cons - What to expect - Our thoughts - Full guide
This is a scrape approach. We observe the page, hook into user actions as required, and lift out the information that we need.
Pro:
Fast, easy - To track a few page-load goals, you could be set up in minutes.
In control, no reliance on the outside world. JS dev can make things work in any way they wish to.
Con:
Need to work out how to play with the site. SPAs etc. We've made this as easy as possible, but it's still a consideration.
Example of what to expect:
In a block of code, the useful and immediately configurable part looks like:
{
name: "page_cart",
path: /^\/cart/i
},
{
name: "page_shipping",
path: /\/checkout/i,
ifCondition: function(){
return document.title.match(/shipping/i)
}
},
{
name: "purchase",
onEvent: "datalayer-ready",
collectData: function(){
let purchaseEvent = dataLayer.filter(x => x.ecommerce);
return {
revenue: purchaseEvent.purchase.actionField.revenue,
units: purchaseEvent.purchase.products.length
}
}
}
// ...
The ways to identify your metric include:
regex - a full URL check
path - a check for just the pathname of the URL
ifCondition - an open-ended javascript condition check
onEvent - ability for you to trigger "events" that this hooks into.
To collect data, you then have options of:
name - the event / metric name. E.g. purchase, page_shipping, click_addtobag.
collectData - attaching any Custom Data to the metric. E.g. adding Revenue and Units to a Purchase event.
Our thoughts on this approach:
For customers with straightforward websites, who want to get moving as quickly as possible, this is by far our recommended approach. We've found it to be the most straightforward, and the approach to come back with amendments needed the least often.
It is also most useful for customers where tracking more data than GA4 (having a fuller view of website activity) is acceptable. Strangely, this is not the case for all customers - some would rather have parity than accuracy.
Full Guide
GTM Mirroring
Pros - Cons - What to expect - Our thoughts - Full guide
This is an intercept approach. We hook into GTM's datalayer.push method, and intercept all data flowing through it. When an event matches our criteria, we collect it in Optimize.
Pro:
Less reliant on coding around the quirks of the site - presumably the effort has already been done.
More suitable for like-for-like comparisons with GA, where definitions are at least similar.
With well-defined event names, it's easy to do a big bunch of these - setting up 20 events to be captured can take just minutes
Con:
Assumption that your GTM tagging is good. From our experience, this is not always the case.
Tagging in GTM doesn't always use event names as the descriptor. In this case, you might need to look up other attributes, which adds a layer of complexity. Not too difficult for an experienced developer
Example of what to expect:
var eventsWeAreInterestedIn = [
"plp click sort and filters",
"pdp click colour swatch",
"add_to_cart",
"view_cart",
"remove_from_cart",
"form_submission"
];
var evt = o.event;
if(eventsWeAreInterestedIn.includes(evt)){
captureMetric(evt);
}
This is the most straightforward use of this, assuming events are the identifying parameter. We loop into datalayer.push, and check the "event" parameter against our list. If something is found, we track it in Optimize too.
If we find the "event" parameter is not sufficient, we can check other attributes too. For example:
var eventsWeAreInterestedIn = [
"plp click sort and filters",
"pdp click colour swatch",
"add_to_cart",
"view_cart",
"remove_from_cart",
"form_submission"
];
var evt = o.event;
var pagecat = o.pageCategory;
var evDesc = o.eventDescription;
if(
eventsWeAreInterestedIn.includes(evt) ||
eventsWeAreInterestedIn.includes(pagecat) ||
eventsWeAreInterestedIn.includes(evDesc)
){
captureMetric(evt);
}
As you can see, a tiny change expands the scope of what we have access to quite drastically.
Our thoughts on this approach:
The challenge with this approach is less setting it up, which is very easy, but it's the mindframe that you're likely tieing yourself into - that you want to have like-for-like data with GA4, which as this article describes, is incredibly challenging in the current state of GA4.
Users can also block GA, and GTM, but have Optimize running - this leaves our data unnecessarily incomplete.
We also find that GTM tagging is often flawed, and returning to the basics for capturing events such as basing decisions on simple URL structure instead of intercepted events from GTM can be the most straightforward solution to the problem at hand.
It's still a good solution though. For customers who are confident in their GTM tagging and the detail of how it works (e.g. event name vs. a parameter sent along), it's by far the fastest way to set up a dozen or more metrics including obscure metrics like clicks.
And, where updates to the website break tracking, it'll break GA tracking which typically is fixed quickly and Optimize will be fixed as part of this process - that makes this far more scalable as a solution than having multiple platforms each with their own responsibility for event hooks working.
Full Guide
opt_data.push
Pros - Cons - What to expect - Our thoughts - Full guide
This is a notify approach. You embed small snippets of code onto the website or into a tag manager, which trigger when your important event/s take place, and these notify Webtrends Optimize. When we are notified, we collect the event for all experiments a user belongs to.
Pro:
If you have the right level of access, it's quick to set up.
Incredibly resilient approach - if embedded onto the website itself, developers can be responsible for its function and so future website changes are unlikely to break the functionality of our tracking.
Con:
Requires collaboration with website developers, or Tag Manager admin.
Example of what to expect:
opt_data.push({
event: "click_addtobasket"
});
You would embed code like this into your website or Tag Manager, and send along event names and data attributes as appropriate. Webtrends Optimize will collect the data as it gets pushed to us.
If you want to attach custom data to an event, such as revenue and units to a purchase event, you can attach a data object to your event:
opt_data.push({
event: "purchase",
data: {
revenue: 123.45,
units: 3
}
});
Our thoughts on this approach:
This is the best approach for customers who wish to have a long-term commitment to using Optimize as their testing solution. It is also best suited to those who have website updates often, and to those who want to ensure tracking is never broken.
While it does require support from your website development team, or Tag Manager admin, the benefits of resiliency far outweigh any initial effort invested in our opinion.