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


Notice: Trying to access array offset on value of type null in /bitnami/wordpress/wp-content/themes/echologyx/single-post.php on line 25

Notice: Trying to access array offset on value of type null in /bitnami/wordpress/wp-content/themes/echologyx/single-post.php on line 25

“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.

Don’t just take our word for it…

Don’t just take our word for it…

Customers’ Talking

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

Initially, when working with EchoLogyx, we ran a few test experiments to see how they perform. They did really well, QA was really positive. And then we sort of stepped it up very quickly from there. We are producing 12-15 tests a month. Communication is absolutely great. I can contact the team at any point in the day even after hours they are still responding to me. Since working with EchoLogyx, we have never had an issue with a test that has gone live.

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