Adobe Target at.js 2.0 - Part 1 - Overview

A quick look into Adobe Target at.js 2.0, the key differences from at.js 1.0 and how triggerView() can be used to create tests in the Visual Experience Composer (VEC) for use in Single Page Applications (SPA's)


Hey everyone, Dan here, and in this video series, I’m going to cover off at.js 2.0 which is the new version of the at.js released by Adobe.

This is part 1 of a 2 part series and in the second part of this, I am going to go into a technical demonstration of how you would implement this through Adobe Launch and actually in your own single page application. But this part 1 is going to be an overview of the key differences between version 1 and version 2 of the at.js. I think the best place to start is looking at the life cycle of a traditional multi page application and a single page application.

A traditional multi page application goes through the process you can see in this top diagram. A client (which is normally a web browser) makes an initial request to the server. That server then returns html and the page is rendered, for example the home page of a website. When a user navigates to another section of that site, for example a contact page, this whole process happens again. The client (i.e. the web browser) makes it’s request to the server and the server will return content in the form of html which will render on the client. And this will happen on as many pages as the user goes to, this same process will happen time and time again.

Whereas a single page application, you still have the client (the web browser) and it still makes a request to the server and that server still returns html but as the name suggests, a single page application is a single page so there is no more reloads after the initial load. Any changes to the UI, any page changes, any component updates, happen via an AJAX call to the server, which will return JSON, which will then be rendered by the client.

Now this poses a few complications when it comes to testing. Testing in a traditional multi page app with version 1 of the at.js has historically been pretty simple but with a single page application, especially with the visual experience composer, it’s a bit tricky and we run into a few issues. So what I want to do is demonstrate exactly what those issues are and how a traditional multi page app differs to a single page app when it comes to testing.

So what I’ve got over here in this tab is my agency website which is a staging version which we have here, and this website has two parts to it. This home page and this contact page are a multi page app and once we jump into the blog, the blog is actually a single page application which is built in React. So what I’m going to do is, I’ve set up a few tests in Target that I’m going to launch in a second after I’ve shown them to you, and this should demonstrate the differences between testing with version 1 of at.js in a single page versus a multi page application.

So I’ll just show you what these are first of all if I jump into multi page app demo home. They are pretty crude tests that just change the background colour of certain pages. So the home page background colour has turned green, the contact page background colour has turned blue, the home page of the blog has turned yellow and finally an article page in the blog has turned a nice fuchsia colour. So if I put these live (which I’ll do just now), we can jump on into the staging site and we can view them. If we go to the home page, we’ll see that we get the green page. Now if we open up the developer tools and go to the network tab and we refresh this, we will see that we get one mbox request. This mbox contains information which comes in the form of parameters, so you’ll see here query string parameters and specifically this one which says mbox URL which is So this is how Target knows that it should fire the green background on this page. If we then move to the contact page, we get a nice blue background and what you will notice is that in the network tab, the initial request we made on the home page has now gone and we’ve got a new one. So when the page reloads, the network tab gets completely cleared so the historic request is no longer there. This mbox request works exactly the same as the one I just explained but this time in the parameters, the mbox URL is Again, this is how that Target knows to fire the blue background.

Now if we move into the single page application which is the blog, on initial load everything looks the same as it did previously. We have the one mbox call, the mbox call has an mbox URL and this URL matches the URL we have in the URL bar at the top which is why we get the yellow background. Now if we go into read, what we’d expect to see here is the nice fuchsia background but we don’t get the fuchsia background because this being a single page application, we have not reloaded the page and because of that, as far as Target is aware, at this moment in time we are still on But if we were to manually force this and we refresh it ourselves, we would then get our nice fuchsia page because we’ve manually forced the refresh.

What at.js 2.0 gives us is a new function and this function is called trigger view. Now what trigger view does is it allows us to imitate a page reload without the page actually reloading. So within our application, we can fire these trigger views and pass in the name of the view, and then we can fire tests based on the view which means we can run tests on different views in single page applications. The function itself can take a parameter of page and page can be either true or false. If page is true, in the analytics it will count as an impression so you’d want it to be true if the view is rendering a completely new page and you’d want it to be false if it is rendering just a section of a page i.e. a module like something in the bottom here (you would not want it to count as an impression).

As well as bringing in this handy function, what it also brings in is a few changes in how Target actually operates. So if I jump back to my first tab, down here you will see that the at.js version 2 gives us the ability to cache all offers on page load. So when the client makes the request to the server and the server responds with our application and then our application renders Adobe Target, Target will download and cache every possible offer for our single page application. Now what this means is that when we click and we move around our single page application, there is no need for a server call to Adobe Target to return content because we already have it. So when a view is triggered, the content is already there and this tremendously increases the speed in which our offers are displayed. And then finally, the one we’ve just spoken about, which is with a single line of code that your developer would implement, we can deploy views and these views can be used to allow the visual editor to work in a single page application.

So this is it for the overview of at.js version 2. In the second part of this, I’m going to go into how you would implement it with Launch and exactly how everything works so please go into that episode and watch that. But for now, thank you very much!