The advanced code editor allows you to make more fundamental changes and you have the ability to use JS and CSS here to create your transformations.

In this document we will walk through all the options available as well as tips and tricks on how to maximise what you can do.

Once you have completed the 'Create' form you will select the option for 'Launch Advanced Editor'.

Once selected, you are presented with the option of using the OBF (Optimize Build Framework).

When continuing you will be presented with the code editor itself.

The code editor is broken into several sections (depending on how many variations you want to run as part of the experience). We will cover all of these below.

A small feature, but one that’s incredibly useful. Developers iterate on their code quickly and often – the 'save' button saves your changes within a couple of seconds to the Optimize platform, and this is distributed to our servers with sub-second latency making it instantly available – no “waiting on CDN” anymore.

E.g. If you are building your experience you will likely have the page open in one browser window, on one screen, and the WTO editor open in another. Saving will allow you to refresh the page you are working on and see the changes reflected almost instantly.

The global section houses 2 key scripts and is relevant to what happens before and also after the experience runs. You may use these sections to enable a test to run, based on a JS condition or alternatively add a conversion you wish to track.

Webtrends Optimize is very flexible and although these docs cover the basics, there is a huge amount you can do within the advanced editor.

In the pre-render script we can define certain things prior to the experience running. It may be we want to add some JS logic, such as a user clicking on something, which must be met before the experience is delivered.

The post render script allows you to do things after the transformations have taken place. This can be things such as click tracking, on an element changed/added in the experience, or sending data into third party tools based on a condition or event.

This section allows you to apply JS to the control variant. In this case this is only applied to the control and enables you to do thing such as tracking an element specific to the control variant only.

E.g. we may be changing/removing a button as part of our experience. In this case we would need to track this within the control variant. This is used rarely however as tracking it as part of a conversion point overrules this.

As above this section allows us to apply CSS to the control only. Similarly it may be to apply something to the control variant only.

E.g. we may want to prevent inheriting/overriding styling from a global sheet or we may want to apply a visual label for debugging/QA. This is also rarely used but is available should it be required.

In this section we will be using JS to build our variation scripts and make the changes to the page, or pages, as part of your experience. You are able to make changes to elements on the page from here and they are reflected only for users in the variant and not the control.

As above, this section allows for you to add CSS to the variant only and allows you to make changes to the page, or pages we are running our experience on. As with the JS, these changes only apply to the variant and not to the control experience.