What to keep in mind when coding A/B tests

Bind the element's path tightly

Tie the element so you are sure you do not affect other elements.

  • Use more unique Classes/IDs than general ones (Example of general classes are Bootstrap classes)



To make sure we overwrite their CSS, it's important to use !important as much as possible. Always write !important after the CSS code and remember to tie tightly, e.g.

.product-info-main-wrapper .page-title-wrapper .page-title {
color: red !important;
font-weight: bold !important;

NOTE! Do not use !important on styling you later need to change with javascript


Check that your CSS changes are responsive (must look good on desktop, tablet, mobile and all website breakpoints) e.g.

@media screen and (max-width: 1199px) {


@media screen and (max-width: 991px) {
@media screen and (max-width: 767px) {




Bind elements tightly

Bind elements tightly to CSS and Javascript, e.g. if you want to access the H1 below, you can for example bind this element like this:


.product-info-main-wrapper .page-title-wrapper h1.page-title

Not safe:



<div class="columns">
  <div class="column main">
    <div class="product-info-main-wrapper">
      <div class="product-info-main">
        <div class="product-title-wrapper product">
          <h1 class="page-title"></h1>

Make changes as soon as possible by using /* no_doc_ready */

By default, the javascript code you write is executed at Document ready. This means that the whole page is loaded before your changes are applied. This can sometimes cause “flickering”.

To avoid flickering, we want our changes to happen as quickly as possible (we want our code to run before the Document is ready/finished loading). You can avoid flickering by changing the way Symplify executes javascript.

To do this you first have to add /* no_doc_ready */ in the top of the code.

/* Write custom javascript / jQuery here! */ 
/* no_doc_ready */

When you use / * no_doc_ready */, it is important to make sure that the elements we want to change have been loaded before the code executes. Therefore it is important that you set the AUDIENCE to the elements you want to change (audience: Page content).

Should it happen that you change multiple elements (for example in a Product Detail Page redesign test), you do not need to have all elements in the AUDIENCE, but take a couple of elements so that you are sure that all changes take place. This need to be thoroughly tested in Preview to make sure that all you changes happen on every page load/way to load the page.

If “flickering” occurs because AUDIENCE has to wait for too many elements, you can use a mutation observers or intervals in your project code. Then you can remove minor control elements in the AUDIENCE and instead set an observer that handles elements that load late.

Was this article helpful?
0 out of 0 found this helpful