Implement Adobe Target Server Side - Part 1

A quick introduction to me and a review of the advantages and disadvantages of client side vs server side Adobe Target implementation.


Hey everyone my name's Dan, and in this video is a hands-on demonstration of how you would implement Adobe Target server side. And what some of the advantages and disadvantage of that are. Before I start, I'll quickly introduce myself and so we will quickly run through my LinkedIn. So, like I said my name is Dan and I am a Digital Optimisation Director at Optisights which an agency based in London which specialises predominantly in Adobe Target.

So, work with Adobe Target for quite a few years in a few of my previous roles for the last seven or eight years, I am a bit of a mix of a kind of the business head as well as a bit of a technical side. So, I am a Certified Adobe Expert (ACE) as well as being a full-stack JavaScript developer and a Certified CXL Optimiser. So, before I kind of jump into the code level detail one of the things I'm going to start on in this video was when to use server-side testing and what are the advantages.

Because I think there's quite a few myths floating around about server-side. I used to go to quite a few events with both Optimizely and Adobe. And I'd always come across some form of non-technical Marketing Director or Marketing Manager that would always say, the future of testing is to go server-side and to basically not do anything client-side now. I don't agree with that, I think the best article I can find that summarises the kind of advantages and disadvantages is this Optimizely article and it's just this little kind of table here.

So, I'll zoom in and talk through it from my perspective I don't fully agree with this I think that a lot of it is right but some of it is somewhat outdated. So, I'll just jump through all the points and like I said some of this is personal preference and some of this has changed over time. But the first one is deployment, so on a client-side implementation or a client-side experiment there is no code release required, which can be an advantage or disadvantage. The fact that you know you can make changes on the fly to the website and release them is a fantastic thing it doesn't slow you down with the releases, but it can also be dangerous on the flip side.

I think anyone that's worked with testing platforms long enough will have made the odd error here and there and basically brought a few websites down I think it's par for the course. The server-side approach to deployment is that a release will be required and with that there is some engineering time and some engineering expertise needed. It's slower but it can be more powerful and it can still be unit tested as per any code release and it can be revision controlling in github, it has advantages. Caching is the next one not a big consideration for me.

So, client-side experimentation compatible with any CDN provider. So, basically when you go client side and you can basically use any CDN provider because it's bringing it in after essentially the server's return the content. Whereas on the server treatment must be cached at a CDN layer, again like I said for me not really a big consideration. Next one accessibility, now this one is a big consideration for me. So, I think most people are getting into testing tend to get into it more from a non-technical side.

So, all of the top tools these days have a WYSIWYG editor and what you see is what you get, you can go in load your page up you can mess around with things and that kind of gives you the bug. So, the advantage of this is that, if you're a marketing team and you're non-technical and you have any of the major tools and in all honesty they're all from a visual editor point of view as good as each other in my opinion. And you can go in there you can move things around you can change colors you can do fair bit.

So, non-technically you can go in you can set up some tests and get some wins you get the ball rolling. Also, client side especially with Target you have the form-based editor that lets you essentially run any CSS, JavaScript or any HTML manipulation you want. So, with a bit of basic you know some web foundations of HTML, CSS, JavaScript. You can start to do some pretty complex things in terms of the UI and building kind of quite different variations and really get some big wins, that's fantastic.

Obviously on the server side you can't just randomly dip your finger in the water the expertise you need for this is is very unique. It isn't just knowing a back-end language like Node or Express, it's having the actual knowledge of Target itself. So, it isn't just the case of having a couple of developers that are part-time testing developers and 80% they will be doing other things. You really need fenced-off resource with this and the time to upskill developers to really make this process fluent, otherwise it's kind of stagnant and a bit stop start.

Implementation so, the actual implementation of Adobe Target or Optimizely or whatever it may be on the most simple level client side is it's a piece of cake. It's basically dropping the JavaScript snippet into any tag management system, whether that be DTM, Launch or GTM whatever you want or just put it manually into the page. To add to that there is more complex versions of a client-side implementation. So, a lot of my implementations pass in bespoke things so as the user goes around the site and the data layer of the website will get populated with certain variables, and they can be passed into the mbox via the mbox parameters. And those can allow you to target and audiences on a more niche level.

And the implementation, and we will be talking about this later on in these videos on the server side can be easy it can be hard. It ultimately depends on a couple of things the technology that you’re using and the skill level of the members of staff in your team. I’m a firm believer of if you have a technical expert on the development side regardless of what tech stack you have, you'll be fine. Some tech stacks are more difficult than others single page applications Angular and React can be a bit more painful, because you've got to find out where to plug them in with the life cycle events. It's not quite as simple but again depending on skill level it can be easy can be hard.

Performance, performance is one I don't fully agree with anymore as well as flicker. So, historically flicker and performance were an issue with client side so you would often get that you might be changing a headline for example and you'd often get you see the old headline and then the new headline, with newer versions with a prefetch in there and pre hiding snippets. Flicker has kind of been eradicated as kind of an issue anymore. And I think performance is kind of with that, I mean I was just looking before starting this video and I've got quite a complex test quite a few lines of code.

And then it's only used 56 kilobytes and it's essentially deployed client-side in a millisecond. And I think you know like I said with faster computers, the prefetching and Internet speed getting higher. I actually don't think performance is much of a consideration, granted server-side you'll almost have no performance impact whatsoever. Because it's obviously all done on the server and the client doesn't have to do anything. Privacy again one I don't see as a problem I think it depends what industry you work in. So, what this table is saying is that it's pretty easy if you go to a website that runs any other major optimisation tools client-side.

If you know what you're doing you can find out if you're in a test you can find out why you're in the test, you can find out what the code is that runs the test. And you can essentially find out what your competitors are testing. For me, it's not big issue if you maybe work for you know an industry that is highly regulated or there's a lot of money in it, then maybe that becomes an issue. Server side that's not an issue at all because all of the fetching and all the mbox calls are done server-side. So, by the time the content renders, there is nothing to see. So, it's untraceable as it were, and then you've got channels.

So, I think challenges is a fair one, ultimately client-side implementations only allow for experimentation where there's a browser that can run JavaScript. So, that's most of the time websites, it can be mobile apps pretty simple, the newer versions of at.js in Target now you can use the visual editor. So, the WYSIWYG editor in mobile apps and update stuff on the fly without any kind of release to App Store. But if it was something like an ATM or maybe you've got some kind of bespoke software that runs on an iPad that your company uses. It may not have JavaScript and a client you can manipulate, but it most definitely will have a server.

So, that's when server-side can really come into its own. So, a bit of a summary that ultimately client-side and server-side are both massively important. It does depend on what the use case is, some of them fall definitively in one side, some of them fall in a grey area. I would always if it is a grey area try and do it on the client side, just because I've always found it easier that way. And you can sometimes go down a blind alley with server side, but sometimes like we've talked about if you're trying to do things on non-JavaScript based kind of applications or something like that, it's got to be server-side, or if you're trying to do something really quite complex.

So, this 1, 2, 3, 4, 5th one down depth is quite an interesting one and just because with client-side you've ultimately only got the client to play with. So, once it's rendered you can change any UI you want, whereas on the server side if it's an algorithm say it's a pricing algorithm for example. And there's no way of changing that on-the-fly client-side because the servers already retuned a price. But by running Target or any of these top tool’s server-side you can obviously return different variables or different content in the server as its rendering. Which can have a different impact on an algorithm i.e. a price algorithm.

So, I think the takeaway is that it's worth having a think about what exactly you're trying to achieve but for me the hybrid approach is the way to go, why not have both tools at your disposal when you need them, and make a kind of a test by test decision. And once you get a few tests in, you tend to kind of just know what fits where. That's kind of it for a wrap up of this, and next I'm going to move on to a bit more technical with more hands-on and how the server-side implementation works and how you call the api's. But definitely worth keeping in mind that server side is not the answer to everything.