Running Experiments with Adobe Target 1.x on Single Page applications
Single page applications (SPAs) are more and more common, replacing traditional websites that are made up of multiple pages. The main driver behind this transition is a better user experience as SPAs behave more like native apps than websites. All the HTML, Javascript and CSS is loaded in one go (or loaded based on specific interactions), no new pages are loaded/retrieved, allowing for a smoother and faster user experience.
A/B testing and front-end experimentation relies on pages being called to intercept them and serve the variations, consequently running experiments on SPAs is not as straightforward as on traditional websites, but it is still possible with a little customisation.
Before we discuss how it is possible to conduct experiments using Adobe, it is worth noting that testing on SPAs is an industry challenge, irrespective of which tool you use: Adobe Target, Optimizely, Monetate, VWO, AB Tasty, Optimize…
The reason every testing tool is affected is simply because they all rely on a “JavaScript single tag” being reloaded as and when new pages are loaded, the tag calls the testing tool server and fetches the relevant experiment. As mentioned above this “page reload” does not happen on SPAs so the tag does not reload either, meaning no calls to your testing tool can be made.
How to run experiments with Adobe 1.x on SPAs
You need to run two experiments, the first experiment is setup to “listen” for changes on the SPA, while the second one will serve the variation(s). let’s look at each one in more detail:
1. A background experiment running globally to 100% traffic without any changes apart from some JavaScript code:
Using “MutationObserver” in the background experiment, you can detect changes to the single page content, essentially indexing the SPA into a series of “virtual pages”. The background experiment can therefore be configured to detect when a specific event happens on the SPA and associate it to a “virtual page”. Whenever the relevant “virtual page” appears the background experiment will then call the server to getOffer() and applyOffer() retrieving the core experiment which is running on the custom mbox called “newPage” in this example.
2. Your core experiment which will contain the required variation code must be a form-based experiment.
The important part is that this is a form-based experiment which is not running on the target-global-mbox rather, it is running on the custom mbox “newPage”. Add your JS code to create your variations, including goals and additional targeting conditions and you are done!
To conclude
The background experiment will continuously listen to the page changes and whenever it finds the right “virtual page” to run your experiment, it will call for that form based experiment, add the visitor to either the control or one of the variations, and the experiment will work as normal.