Server-side Target and the Marketing Team

12 Jul 2020 » Server Side

Server-side Target seems to be a recurring topic. I have written a few times about it. However, I have been guilty of keeping the posts very technical. Lately, I have received more questions about it and I want to clarify some important, non-technical aspects from this type of implementation.

Tech vs biz

Unfortunately, there is a big divide between the IT and the marketing departments. If you want my point of view, check my posts on this topic: Business vs technology and Technology vs Business - Revisited. The case of implementing Target server-side shows this problem again.

If you ask the IT team about their KPIs for the website, they will say that site speed is paramount. Maybe not the top KPI, but it will be among the top and the IT team will do whatever they can to reduce the load time. I do not disagree with this KPI, but I have to admit I have reservations. Moving Target to the server is very tempting, as it helps this KPI.

Now, let’s go to the marketing department. Their KPIs related to the website will very likely be around conversation rate, average order value, customer value and, maybe, site speed. There will be no KPI about a user-friendly editor interface, but it is taken for granted. Marketeers do not have a degree in computer science and do not want to deal with difficult UIs.

In case you have not noticed it, there is already a conflict arising.

Target UI

One of the great features of Adobe Target is its Visual Experience Composer (VEC). You load any page of your website in the VEC and, with a WYSIWYG interface, you can create a very wide array of changes to the look and feel: replace images, modify text, move a menu, add a new element… without any knowledge of HTML, JavaScript or CSS.

I do not like how the word “democratise” has been abused, but this is one of such “democratisations”: everybody can use Target. The VEC effectively hides all the technicalities needed to optimise and personalise a website.

Regional mboxes

As I have written in my posts about Target server-side, the first you lose is the VEC. Instead, you need to go back to the old regional mbox implementations from Target Classic. For the tech team, this will look like a compromise. In the end, it is not that difficult to write JSON or HTML, so the marketing department should make the effort and learn these languages. Site speed is all important and people should not get in the way.

Well, if you think like this, let me tell you a secret: yes, people will get in the way. If you tell your friendly marketeer to stop using the VEC and start using the forms composer together with JSON or HTML, she will stop using Target altogether. She does not want to learn a programming language, let alone understanding mboxes, when she could do everything without knowing any of it.

Besides, in my view, any server-side implementation will be very limited in features. It is fairly easy to replace content. However, the VEC also allows to, among other features, move, rearrange, add, remove, restyle and resize objects around. Adding all these features to a server-side implementation may become very challenging, if not impossible.

Value

We must not forget that, in the end, it is all about value. Both the IT and marketing teams are trying to maximise value.

On the one hand, there are some studies that show that faster websites draw more traffic to them. On the other hand, Adobe Target is one of those Adobe tools that shows its value very quickly. I have seen some companies increasing revenue by 7-digit amounts just by using Target client-side.

So, between abandoning Target while increasing site speed and using it client-side, adding a few hundred milliseconds to the load time, in my personal opinion, the latter weighs much more. If you do not want to take my word, compare both options. Since this may not be possible, you can evaluate the value that client-side Target can bring after one year of optimisations and compare it with the theoretical value a load of a few hundred milliseconds less.

The future of server-side Target

I would not dare to use the word “dead” in this scenario. I have heard of a very limited number of cases where this implementation has succeeded. However, most of the time, the development of Target server-side is abandoned for the reasons I have mentioned above. You cannot ignore the people who will use the tool.

If you want to embark in a server-side Target implementation, you now know what your challenges will be.

 

Image by rawpixel.com



Related Posts