Server-side Target and the Marketing Team

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

7 thoughts on “Server-side Target and the Marketing Team”

  1. Interesting; a downside I can see with client side target is browsers versions; browser ad blockers and cookies. All these can affect if you are targeted or not eg incognito mode will effect numbers that target gathers In reports

    There is a balance here; server side target is more accurate I feel and better for api implementations eg mobile sdks

    The vec is more widely used and more business user friendly

    Thanks

    Ravinder

    Reply
    • Browser versions should not be an issue in 99.9% of the cases and, if cookies are blocked, then you can’t do personalisation or optimisation in any case. If an AdBlocker blocks at.js or mbox.js, then you are right.

      Reply
  2. Thanks Pedro – aligned here about to ensuring the technology should help marketing teams leverage MarTech and should not make them stop using it for better business results. However, one scenario where I find server side Target is useful is native apps where its still native code that finally delivers the content.

    Reply
    • You are right Rajneesh, i should have made clear that my post was for web only. Apps, IoT, voice assistants and similar scenarios will always need the forms-based interface.

      Reply
  3. Great post, Pedro! In the context of the coming wave of browser privacy changes, Intelligent Tracking Prevention, and the like – are there any mitigations or advantages from running server-side? In terms of more dependable user segmentation, etc?

    Reply
    • Thanks Grant!
      The point is that you still need to recognise the visitor to personalise/optimise the experience. If the browser prevents this from happening, then you are also in the dark server-side. It may be an advantage in this situation if server-side cookies are better treated than client-side cookies. However, remember that, in this scenario, it is always a 1st party cookie.
      In any case, we will have to see what happens over time with these constraints.

      Reply

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.