Your Guide to Successfully Implementing A/B Testing in a Single Page Application

Single-page applications, often referred to as SPAs, are rapidly replacing traditional multi-page websites for several reasons. Performance and user experience are some of the key advantages of using SPAs. But when it comes to implementing A/B testing in your SPA, you may run into challenges without proper guidance. This article will demystify key concepts and guide you through the essentials of a successful Adobe Target implementation in any SPA framework, whether it is React, Vue, Angular, Ember, or any other.

The views and framework lifecycle events

In the past few years, I have implemented Adobe Target in many SPA frameworks. The first essential to do it successfully is to understand the framework life cycle events. In a single-page application, the visitor is always on one page, while views (i.e., virtual pages) and URLs change as the visitor navigates to different pages in the flow. The concept of the view should be the main core when thinking about the implementation of Adobe Target or any other third-party service in your SPA. Once we connect the concept of view to the framework life cycle events related to the views, we can achieve successful results by knowing exactly when to trigger a Target call to retrieve a visitor’s personalized content.

Since we are delivering alternate content with an A/B test, the call to Target must occur as soon as possible in your view. This is needed to minimize the chances of seeing a flicker as default content gets replaced with other content from the test. Every SPA view should trigger a new call to Target to retrieve relevant content for the view. We do not want to load content on the initial page load for any views (or virtual pages) where the visitor eventually never goes in your SPA. The only exception will be when we pre-fetch the views. More on content pre-fetching is mentioned below.

In a nutshell, your Target call must occur on every view of the SPA as soon as possible. Every framework provides convenient life cycle events to know when we have the view start. In React, for example, the page component “componentDidMount” is a good indicator of the view start. In Angular, the method “ngOnInit” indicates the start of view. At the same time, we can rely on router life cycle events as well. Angular’s Router “NavigationEnd” event is a perfect place for firing a call since we know the URL is now updated and the new view is about to be displayed. For older AngularJS versions 1.x, the equivalent is “$routeChangeSuccess.”

SPA Lifecycle Events.

Data layer

Data Layer is important for your website. It is a web standard today, and most likely you already have it implemented. If not, I recommend adding it to your website as early as possible on the page, following the structure as defined by the W3C (World Wide Web Consortium) standards. Data Layer is a JavaScript object that holds information about the page, the visitor, and more. This information is shared between any third-party services. Therefore, it is important to initialize the data before sending the request to pass the necessary information in the call. For best personalization results with Adobe Target, we must initialize and set Data Layer values before the call. Conveniently, there are “targetPageParams” and “targetPageParamsAll” functions that help consume Data Layer values you want to pass in the Target call.

Defining the Data Layer.

Content pre-fetching

There are many awesome innovations in Adobe Experience Cloud services. In SPA, Adobe Target has introduced content pre-fetching. Now you can pre-fetch all content from Target on the initial page load and display it, on demand, with the “adobe.target.triggerView” method. This will pull personalized content from the cache rather than making an additional call to Target.

Virtual DOM and dynamic states in SPA

When using React or other frameworks with Virtual DOM (Document Object Model) or dynamic states, one of the challenges you may face while integrating any content delivery service is around the ability to persist your personalized content. Imagine your React app applies personalized content from Target to the browser’s DOM. A few moments later, however, you start seeing your default content again, as if the personalized content were wiped out. This is your Virtual DOM speaking. React may use state management libraries that rely on Virtual DOM rather than the browser’s DOM. While this was designed to improve the performance of the app, it also complicates any integrations related to DOM modifications. If your SPA cannot reliably persist personalized content changes in the app, there are several approaches to handle this. If your page component re-renders content, reapply Target content immediately with “applyOffer” or “triggerView{viewName, {page:false}}.” This way, the content will be applied every time the DOM reverts the changes, and visitor increment will not occur. Alternatively, you can use Feature Flag Testing to display and hide pre-built experiences based on delivered flag value. In some cases, the Target server-side approach may be the solution to consider based on your SPA architecture. Your Adobe technology consultant can help you determine the best approach for your architecture.

In a nutshell

Here’s a summary of the best practices discussed above:

• Detect the view start in your SPA for firing a call. Use framework life cycle events to determine the view start.
• Update the Data Layer for every view before sending the request to Adobe Target.
• Make a call to Adobe Target in every view after the Data Layer values (and URL) are updated. Send the call as soon as possible to minimize the chances of seeing a flicker.
• Process or apply personalized content to the page. For dynamic views, consider reapplying the content, if necessary.

Following the tips and insights outlined above, your SPA implementation of Adobe Target should be a smooth process.