Implement Adobe Target Server Side - Part 1
Published on 01/07/2019
8 min read
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.
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.
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.
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, 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.