Using Adobe Target’s A/B Testing to Improve User Experience

In a previous blog post, we touched on how Adobe Target can boost your personalization strategy. One activity type we focused on was A/B testing – which compares two or more versions of your website content to see which version will best improve your conversions. In this blog post, we’re going to go over how one of our enterprise clients implemented Adobe Target for A/B Testing and the benefits achieved from the results.

Our client simply wanted to A/B test a form on their homepage banner. However, they didn’t want it to be a standard 50/50 split between the current experience vs the new experience. They wanted to keep the majority of the users seeing the current experience and test out how four different types of content would perform on a subset of users. They determined that 60% of users would get the current experience and the other four new experiences were each weighted at 10% of users each.

Many users of Target skew toward a typical 50/50 split. But we have seen this type of asymmetrical breakout can be even more valuable. Clients are able to test a variety of situations without compromising a proven experience.

The Evolution of the Business Ask

Before we get into how we created the A/B Test Scenarios let’s take a step back at how the business ask evolved to using A/B testing. Initially, there was a request to make a couple of UI tweaks to the existing layout. Working with the client for multiple years we knew that the home page banner was a highly visible and important piece of their site. Instead of simply making the layout changes, we asked what making those tweaks would solve. Were there any tests or success metrics that would deem these modifications successful over what was previously there?

What we realized was that there were no tests done or success metrics created. We worked with the client to come up with a strategy using Target that could test the modifications to a subset of users and analyze the conversion rate to see if what was suggested would actually be successful.

The Strategy Behind our Technical Approach

Before we cover the technical solution in-depth let’s review why we decided to go down the implementation path we did. Often times when using Adobe Target you’ll statically include your content as HTML directly into the experience within Target. You’ll see in detail later in our post we include a path to a page within Adobe Experience Manager (AEM), storing the content in AEM. The primary reason for doing this is the client had a very thorough process for any content that was published on the site. They wanted to be able to utilize existing workflows and components in AEM so it wouldn’t break their process. This would also allow all their content to be in a central location.

Download Blue Acorn iCi’s Complete Customer Experience Report to learn how to create an unforgettable, personalized customer experience.

Creating the A/B Test Scenarios

AEM comes out of the box with an xRef component which is a reference to another piece of content. We created a similar component (for purpose of this post let’s call it the xRef Target component) which consists of two dialog options. One which contained an MboxID field and one which contained a Default content URL field.

The first step is placing the xRef Target component on a page where you want your referenced content to appear. For the sake of our example, we placed the component within the homepage banner.

The MBoxID would be matched to Location ID in Target. Pay careful attention to how both the values in the dialog and in Target are the same.

The second dialog option was the default content URL. This was a reference to the piece of content that you would want to be displayed if the call to Adobe Target failed (i.e. Adobe Target was unreachable due to network issues etc. This URL would be the same as the default experience configured in Adobe Target for any given experience).

In our example, the client wanted five different experiences. Therefore, we would create five different versions of the xRef Target component that contained five different versions of what we wanted to present to the user. For example, if in experience #3, instead of showing a form we just wanted to show a call to action we would create a new page that just contained the call to action button. Ensure that you place the full path to the new page you created in the HTML Content section of Target (see example 1 below). Don’t forget to place those different instances of the component in the homepage banner since each experience would have a different piece of content within it.

Another crucial step was putting the keyword <exp>{name of experience} next to the page name inside of Target. This is used to identify what experience number you want that piece of content mapped too.

Now that we have our five different xRef Target components and content within those created let’s apply an update that will tell Target what Mboxes are on the page. This is key since we need to let Target know what MBoxes are on the page in order to know what experience and content to use. We did this by creating a new page property called MboxIDs. Here we would put the value of the MBoxID’s for our 5 different experiences separated by commas.

In the business layer within AEM we’re making a single REST call to Adobe Target on the page we applied our MBoxID page properties to. This call includes the five different MBoxes, browser information, and user profile related data. Adobe Target based on certain criteria that you set (such as percentage weighted for each experience) makes a determination on which one of the five experiences we are going to show to the user. Here is what the five different experiences contained:

Experience 1 = Form with 3 fields
Experience 2 = Form with 2 fields
Experience 3 = Form with 1 field
Experience 4 = Call to action
Experience 5 = Call to action with different text from experience 4

After this was successfully implemented the client was able to determine exactly what experience performed the best and to their surprise, it wasn’t what they expected. Which oftentimes is the case when running A/B tests. With the knowledge that Target was able to provide they were able to drive in more leads and better improve the user experience.

This example is just one of the many ways you can implement Target with AEM. There are many other ways such as A/B testing with analytics data or Experience targeting.

If you need help implementing Target with AEM or you have questions about A/B testing, contact us today.

Subscribe to Our Newsletter

Get the latest insights from Blue Acorn iCi