Omniconvert code may be integrated synchronously or asynchronously, either directly in the website or through a tag management system (including Google Tag Manager). When integrated through a tag management system it is always async.
Keeping a seamless User Experience
We strongly recommend integrating the code synchronously. The reason for adding it directly in the header of your website is to allow a seamless User Experience when performing A/B Testing or doing any sort of personalization.
There are multiple undesirable consequences that appear when the code is integrated asynchronously:
The flicker effect
An async code will create a flicker that looks clunky / unprofessional to the user; it may even confuse the user if the changes are substantial.
Eg. imagine removing a wishlist button within a test, after the user clicked on it.
In this scenario, it can also contaminate the experiment results, even if the experiments run relatively timely every time, as the flicker effect will draw attention to the modified element(s). When this happens, then the level of interaction with the changed elements might be different from how it would be if it were displayed without the flicker and will influence the outcome of the test. In case it is considered a winning test and the winning changes are implemented directly on the website, user behavior might differ from the one during the experimentation stage when the flicker effect drew attention to the respective changes.
Undesired interaction with Control and Variation
It will allow the user to interact both with the Control and the Variation and produce irrelevant results in the desired user behavior. Imagine an experiment that pre-ticks all the checkboxes within a form, as opposed to having them un-ticket by default (on the Control version). The user may start ticking some, then all of them will be ticked by the experiment/Variation, and the user will be forced to un-tick some in the end.
Non-unitary display of design/elements
When you run a test that involves displaying the same changes on multiple pages, not having the code integrated synchronously will generate an inconsistent experience with one design shown on page A and another on page B although the intention was to test a unitary design.
Coordination of elements to be displayed
Even if not running A/B Tests, tracking of elements within the page will be affected, as well as other features, such as displaying an overlay with delay. Imagine a configured delay of 3 seconds could become 5, 7, 10 seconds, or even more, depending on the scripts which are loaded before the Omniconvert code (this is especially problematic in tag managers, when the priority of the Omniconvert script is low).
Tracking reasons
One other good reason would be tracking accuracy for elements not affected by an experiment. The sooner the code loads, the sooner elements can be tracked within the page. Let’s assume you have an experiment running on an e-commerce product detail page, which changes the image gallery; the tracking of the “Add to cart” button is a must-do in this case, and the sooner it starts running, the better the accuracy we will gain, thus allowing a better informed decision to be taken after the test is over.
Alternatives for integration
If including the code sync in the head is not an option, it is desirable to have the code loaded as soon as possible via these options:
– including the code async, topmost where possible would be the next best thing
– including the code deferred (including having it at the end of the body tag) is similar in approach, but may yield weaker tracking accuracy (see number 2 reason)
– using a tag manager would be the last choice; but if it must be used, please ensure the highest priority for the Omniconvert script.
Was this post helpful?
