Code on screen

Running A/B tests using Adobe Target 1.X on sites built with SPA frameworks

“Our whole website has been redeveloped and now it is using a new SPA framework. My development team is saying that we can’t build tests using Adobe Target on the new site because the way the pages are changing, it is not loading the test scripts.” – Sounds familiar? Well, you are not alone. I am going to talk through a way to tackle this issue that will make sure that you don’t need to worry about running tests using Adobe Target on SPA sites.

Why is this a challenge:

In short, the main purpose of using an SPA is to speedup page loads. The common elements within the page (such as header, footer, layouts etc) usually stays the same but inner content changes when a user navigates from one page to another. In most cases, using an SPA helps speed up the page load by only fetching the core content that needs to be updated on the page rather than the elements that are already delivered to the user.

This poses an issue with widely used A/B testing tools such as Adobe Target, Optimizely, Monetate, VWO, Convert, Optimize etc. Why – because the “single line of JavaScript tag” that has been implemented across the site no longer gets reloaded when the page content is changing. As a result, if let’s say you are targeting your funnel step 2 to run an experiment, your testing tool will not be able to detect when the user has landed on that step and display the variation. Bummer…

What can you do within Adobe Target (1.x) to detect the changes and run a test

You need to run two experiments:
1. A background experiment running globally to 100% traffic without any changes apart from some JavaScript code,
2. Your core experiment that will have the variation code for your experiment
Within the background experiment, by using MutationObserver you can detect the changes to the page content. When you detect any changes, find the element that signifies the specific page – e.g. Step 1: Delivery Address / Step 2: Billing Address etc. You will then need to make a call to getOffer() and applyOffer().

adobe.target.getOffer({
"mbox": "newPage",
"params": {
"loadedPage": "FunnelStep1"
},
"success": function (offer) {
adobe.target.applyOffer({
"mbox": "newPage",
"offer": offer
});
},
"error": function (status, error) {
//console.log('Error', status, error);
}
});

Now let’s get to your original experiment – for this use a Form based experiment and target the mbox called newPage. Although this is not necessary, it is a good idea to specify the additional targeting conditions here – such as custom parameter loadedPage is PageX.

Add your JS code here to make your variations, including your goals and additional targeting conditions. And that’s it! The background experiment will continuously listen to the page changes and whenever it finds the right page to run your experiment, it will call for that form based experiment, put the visitor in control or one of the variations, and the experiment will work as normal.

Let's have a chat

If you want to find out a bit more, just get in touch. We love a chinwag, and we'd love to help you out.

Contact us

Don’t just take our word for it…

Our customers are our biggest advocates. That’s why we let them do the talking.

  • They come to me saying, this can be done better. This proactiveness is what I most like about the EchoLogyx team. They have got a strong QA team as well so that nothing goes out live without going through a thorough QA

    Nabil AlJannati

    Brand Manager, Ninety Percent
    4 3 2 1 0
  • Our experience of Echologyx is resoundingly positive. They’re very thorough and detailed. We’ve got a great working relationship with our optimisation managers.

    James Amborse

    Head of Operations, RedEye Optimisation
    4 3 2 1 0