Adobe Target Hybrid Deployment

Transcript

Target is an application that both marketers and developers live in every day. I’m excited to show how we’re pushing the envelope with our hybrid deployment model. Hybrid deployment brings the best of both worlds of client side and server side implementations. It combines the performance that developers are looking for with the flexibility and WYSIWYG tools that marketers need. As brands evolve their personalization programs, we’re seeing some new trends in our customer base. IT teams are adopting technologies like single page applications, that radically change how webpages are developed and modified. We’re also seeing a shift toward more server-side deployments to cut down on the number of calls or to avoid vendor JavaScript tags. Adobe Target is constantly releasing capabilities that appeal to both the marketer and the developer. Developers are often launching more complicated tests like feature flagging a new product capability, or a change to a workflow or a customer journey. Marketers on the other hand, are often nontechnical and set up their changes visually using the visual experience composer without needing to touch code. The IT team wants faster page load times, integrations with their tech stack of choice, and server side for delivery to ensure experiences are delivered with rapid speed. Marketers want to be able to set up their tests or Targeted experiences, without developer intervention. Enter Adobe’s unique differentiation, a hybrid deployment model. This allows non-technical users to author an experiment or personalization activity using the WYSIWYG visual experience composer, and then having that experience be executed, delivered, and rendered, by the server side implementation thus improving performance. In other words, we’re talking server side and client side at the same time, and speaking to each other. This is how it works. The user will go to the customer’s website and from the customer’s website, the browser is going to go to the web server to figure out what kind of HTML it needs to retreat.

On our customer’s web server, they’ll have no JS or the Java server side SDK installed. From their servers, we make an API request to the Target servers. And then the response we’re going to return includes both the VEC created activities that were created by the marketer, and the server side form based composer activities created by developers. Once that response comes back from our Target servers, that response is added to a variable called server state, which gets packaged into the overall HTML, and returned back to the end user’s device and or browser. When the browser loads the HTML, At.js 2.0, which has single page application VEC support, will load and immediately look at the variable server state. And in this case, it’ll see that the service date is populated with the request and response from Target edge servers, with both the VEC created activities and the server site experiences. At.js then immediately renders and executes the decisions. And the end user will see the content for the webpage. All of this happens with just one single server side call which optimizes for performance. Let’s take a look at this in action. First, I’m going to build an experience using our purpose built visual experience composer for single page applications. And then I’m going to show how it’s deployed server side in a hybrid deployment model. Our visual experience composer for single page applications was purpose built from the ground up. And it’s intelligent, where it can automatically understand custom events and triggers from a customer single page app. We support all of the common frameworks like react, angular, Amber, or even a customer’s home grown single page application implementation. Just like a traditional webpage, you’ll see a blue outline appearing over the elements I can edit, and a contextual tool tip for making my changes within this visual experience composer. Since you’ve already seen this before, I’ll just go ahead and swap this image for the hero banner to our big sale. As I enter navigate mode and browse to different links, notice the view changes on the right. This is different than the regular visual experience composer because with this single page application, it’s not loading a new page. It’s just a new view or a state within the application. Let’s add this item to the cart.

And here, you can see when I click the radio button my view state changes. Even though it’s not a new page, it’s just a new element I’ve clicked. So I can set up a test experience when a user clicks Express Delivery, for example, and change the text to this offer to, let’s say, This Offer Rocks. Great. I can add as many experiences as I’d like, and on this next step, I can apply AI for my allocation method. And last, I’ll set my goal, and then set it live.

Okay, let’s pull up the single page application and see our new experience. Here, we see our new hero banner, and as I navigate to the cart, we see our express delivery offer.

So you can see we’ve created and edited the single page application and set up this test just as a marketer would within the visual experience composer. And that’s really compelling in and of itself. Now, let’s look at the delivery because, what’s really unique here is that this is being delivered server side. First, I’ll view source. And you can see that we have the server state variable set where it has all the information on the experiences we’ve configured for this activity. When the browser loads the single page application, Adobe Target’s At.js 2.0 will immediately look at this variable server state, and see that it’s being rendered server side. Meaning, there’s no call to render this experience to the client side because it’s happening in server side on the edge. Let’s take a look at the network calls to check this out. With the typical client side delivery, you’d see two calls here. One, where the experience is being rendered and another that’s more of an analytics call to notify Adobe Target that they experience is being delivered. Here, in this hybrid deployment, we’re only seeing one call. That’s because the experience is being rendered by the server. So what you’re seeing here is the call for the analytics on the impression letting Adobe Target know that the user arrived at the page. In summary, what I’ve just shown is Adobe’s unique differentiation in deploying a hybrid delivery model. So experiences can be created visually, and yet rendered server side. We’re giving the best of both worlds to marketers and developers with Adobe Target. -