Below, you’ll find details for tagging your website with Webtrends Optimize Tag.
What is the Webtrends Optimize Tag?
How to get your Tag
You can find a full tagging guide in the Optimize UI, found in the top nav. This includes guidance on Content Security Policies, Tag Management containers, etc.
Broadly, as mentioned above, this will involve placing one SCRIPT tag into the HEAD of your website (or at least the pages you wish to test and track on).
How it works – serving experiences, behavioural tracking
- Your users request the web page, in the same way they do today.
- Your server returns a web page, in the same way it does today.
- That web page contains our Tag, before any visual elements. This triggers as the page loads in the browser. At this point, we mask the page (optionally, to avoid flickering).
- A request is made to Optimize to see if there is anything on the page that needs to executed (a test/target) or tracked (clicks, page loads, revenue, etc.
- The optional masking is removed, and the final page is ready for a user
Impact on page load performance
When considering page load performance, we typically consider the metrics that Google Lighthouse allows us to report on. These will be discussed below.
DOM Content Loaded, First Contentful Paint – “load speed”
This considers how quickly the page loads in and gets content onto the page. For these metrics, the weight of our tag, and in-memory footprint is important.
To minimise our footprint here and keep our tag as small as possible, we:
- Write concise code in ES5, and not transpiling – something that our competitors do. Using transpiled code adds unnecessary bloat – something others don’t consider when their tag is already considerably large.
- Avoid using libraries, which often contain a plethora of features that you’ll never need.
- A loader – dependancy mechanism. We have a minimal loader, and subsequent requests are pulled in as dependancies. This allows the rest of the page to continue to load, whilst we make decisions about the user and execute everything we need to – something which is better for initial footprint than having a very large file that’s blocking the critical path to content loading.
This metric considers content shifting the page, which is often the case when experimenting.
To improve this, we implement masking on the page to hide areas of the website which are likely to change or jump. By only showing users the final content, they don’t recieve a jittery experience, which Google is currently penalising.
We experiment and personalise our own website. As part of our process, we discovered that our website itself, without any additional software, had poor performance. By buidling a website with great performance scores – 95+ – we noticed that our tag had minimal-to-no impact. Even when running tests, our scores remain at 90+, often 100.
We have, and continue to, find any opportunity to reduce our footprint though, and come up with solutions which ensure solid onsite experience which reflects in good performance scores.
To understand how to do this, see the details found here.