Webtrends Optimize developer for hire

Case studies on Webtrends Optimize

All four for Homeserve.

• A self-configuring cost-comparison section
• A cross-sell banner in the coverage gaps
• A site-wide stripe that keeps attribution across a domain hop
• Comparison PLP: bundle product removal , results pending

Selected Webtrends Optimize work

Real client side tests I built and shipped on Webtrends Optimize, each with the full engineering write up:

• A self-configuring cost-comparison section, HomeServe. Reads cover name, excess and job prices live from the DOM and injects a comparison table. +13.6% conversion, +53.5% revenue.
• A cross-sell banner in the coverage gaps, HomeServe. A repairs cross sell placed in the "what isn't covered" section on a Gatsby PDP. +42.9% progression, +12.3% conversion.
• A site-wide stripe that keeps attribution across a domain hop, HomeServe. Session state and cross domain attribution that stamps the experiment ids onto outbound links. +5.35% cross-sell page views.
• Comparison PLP: bundle product removal, HomeServe. A surgical PLP edit that re-initialises the host's Swiper carousel cleanly and gates a nav injection by session.

How builds work on Webtrends Optimize

I build in the Advanced Editor rather than the Visual Editor. Each factor has its own Control.js, Control.css, Variant.js and Variant.css, and my compiled bundle goes into the variant pair. The control sections stay empty unless the control needs its own tracking. Above the factors sit two global scripts. The pre-render script runs before the experience and is where I put the conditions a visitor has to meet. The post-render script runs after the changes are applied, so it is where click tracking on elements the variant added belongs.

Conversions go through WT.click, with the test alias from the experience metadata and a named conversion point. Custom data rides along in a data object, and each field has to be declared on the experience's Create form first, typed as Text, Integer or Decimal. I agree those names with the analyst before the build, not after launch.

// Post-render script: count clicks on a button the variant injected
document.addEventListener("click", (e) => {
  if (!e.target.closest(".wt-compare-cta")) return;
  WT.click({
    testAlias: "ta_something",
    conversionPoint: "compare_cta_click",
    data: { coverType: "boiler" }
  });
});

Masking on Webtrends Optimize

The tag can hide the whole body while tests evaluate, using display, visibility, shift or overlay modes, with a safety timeout set by s_pageTimeout that defaults to 5000ms. Five seconds of blank page is a long time on a slow connection. Where the account allows it I keep the page mask narrow, using the whitelist in the tag's pre-init script so only the URLs under test are covered, and inside the variant I mask just the element being changed with WT.helpers.css.add, removing it with WT.helpers.css.del once the new markup is in place. The options are listed in the vendor's masking documentation.

What to watch for on Webtrends Optimize

Out of the box the platform evaluates experiences once, as the page loads. On a single page app nothing runs again when the route changes unless the tag is told. The WT.SPA configuration takes a regex to limit which URLs it watches and a method whose return value is compared on each check, so a change re-executes your experiences. On React builds the alternative is to dispatch a wt-page-change event yourself, and the vendor is explicit that it should fire once per page, because a second dispatch renders and tracks twice. Either way the variant has to be written to run again safely: check for its own markup before injecting, and tidy up when the visitor leaves the page it targets.

The second trap is counting. Blocking the render with WT.blockCodeRender has to happen immediately in the pre-render script, and counting is controlled separately. If the condition is something like a data layer value, I hold the pageview with WT.blockPV and track it manually once the condition passes, so the report only includes visitors who could actually see the change.

The rest of the build

None of that replaces the engineering I put into every variant regardless of tool: activation that follows route changes, element scoped hiding, inputs that React and Vue actually register, waiting for elements that mount late, and accessible markup. It is written up on the A/B test developer page, with detail in my flicker guide and accessible variants.

How pricing works

Submit a brief and you get an hour estimate back within one UK business day, with a total you approve before any work starts. A single test usually takes between 2 and 20 build hours: a copy or layout change sits near the bottom of that range, a new component or a multi step flow near the top. Regular volume earns a discounted rate, and there is no lock-in: one-off builds are as welcome as a weekly commitment.