Server-side digital marketing
13 May 2018 » MSA , Server Side
A few weeks ago I read a great blog post entitled The Era of Server-side Everything from my colleague Jan Exner. I wanted to write a comment, but as I started to think about what to write, I realised it was going to be too long. Instead, I decided I would write my own post on this topic. Then, as I started to think what I would include, additional blog posts came to my mind. So, this is the first of a series of posts on server-side digital marketing.
First of all, what is this concept really about? As Jan explains, we tend to think in JavaScript terms. When a customer asks us to do something, we immediately think on how it would be done on the website. We have JavaScript libraries for Adobe SaaS tools: ECID (fka MCID), Analytics, Target and Audience Manager. All the data collection and actioning is done through these libraries in the browser.
Now, imagine you want to do exactly the same things, but without JavaScript. Is this even possible? The answer is yes. How? Having the web server run your digital marketing code instead of the browser; I will show you how in future posts. Why would you want to do that? Read on…
Advantages of server-side digital marketing
Reduced load time
Although this is arguable, it should decrease your page load time. Do not expect massive changes, but if you are an advocate of minimal websites, then this is for you. Since you will not be loading and executing any Adobe library on your website, it should load a few hundred milliseconds faster.
This comes at the cost of more expensive server-side hardware. The functionalities still require code, which has to be executed in your servers. Remember that one of the reasons of running code client-side is that you have thousands or millions of browsers executing this code for you. When moving the functionality server-side, it will execute in a handful of servers. Either you need more servers or more powerful hardware.
Accuracy
I remember, many years ago, a customer saw a drop in page views after an upgrade in the Adobe Analytics code. After some research, they found that a combination of a specific Google Chrome version and a specific browser extension blocked some code. In another example, an online newspaper had just deployed Adobe Analytics and the numbers did not match the previous web analytics software. The problem was that the code was running at the bottom of the page and the homepage was huge. It took many seconds to reach the bottom of the page and many visitors had already clicked on a link before the Analytics code had the opportunity to execute. As a final example, you will have probably seen that you always get some spurious server calls with unusable data.
In summary, when you execute your JavaScript, you cannot control what actually happens. There are too many combinations to cater for all of them. However, if you move this code to the server (and adapt it to your server’s environment), you are in control of it. You decide when it is executed and, unless you have a fault in your servers, it will always be executed with the correct data. No more timeouts or blocked code and less errors in the data.
Easier SPA development
When I ended my days as an Adobe Analytics consultant, Single Page Applications (SPA) were a rarity. I never had to work with one. However, from what I hear from my colleagues, more and more companies are moving to SPAs. With traditional websites, you rely on the browser loading the full page every time. The digital marketing code fires in different places, according to the page load process.
However, with in an SPA, the typical process changes completely. There is only one page load for the whole visit. The frameworks do most of the heavy lifting, but the digital marketing code is not included in these frameworks. As a consequence, you need to manually add ad-hoc code for Analytics and Target, to fire where you need it and with the data you want. Obviously, if you move this code server-side, the SPA becomes easier to develop.
Disadvantages
You would not expect all to be advantages, right?
Less flexibility
Adding and removing JavaScript code from your website is relatively easy, especially if you are using a tag manager. This is thanks to the way the W3C standards work. You can decouple quite well your digital marketing new features from the website release process, which gives you a lot of flexibility. With server-side code, this flexibility is lost and any change will have to follow the website release cycle.
Increased time to market
When you run your digital marketing code in your servers, every time you need a new A/B test or a new metric, you will have to open a ticket with IT. This ticket will go into a long queue, until a resource is available and starts coding your request. Once the feature is ready, it will only be pushed to production in the next release. Therefore, any change you need will take weeks or months before it is live. You can no longer apply quick changes to your code, you now have to plan months in advance.
Increased complexity
JavaScript is a simple language and the W3C standards allow you do to a lot with it. You can even deface a website with just a few lines of code. However, when it comes to server-side development, things are not that easy. Programming languages are more complex (usually Java, but expect C#, PHP, Ruby and others) and then, on top of them, you have the framework of the CMS.
For example, with Adobe Target, the mbox.js or at.js code takes care of everything for you on the website. You only need to configure the tests or personalisations using an intuitive UI. If you want to use Target server side, you will need to code every single test or personalisation.
Dependence on IT
One of the hidden goals of any digital marketer is to be totally independent of IT. They speak different languages and have different goals. Unfortunately, I have seen too many times the lack of synchrony between marketing and IT. As I said above, using a tag manager allows for an easy decoupling of these two teams. In the particular case of Adobe Target, once you deploy it, you probably do not need any additional code.
However, as you can see from the previous disadvantages, with server-side code, you need IT for every change. I still have to see a web administrator giving access to any other teams to the code of the website. And if it is an external agency managing your website, you are doomed.
Which way to go?
As with most things in life, there is no black or white here. You have to evaluate your particular case and decide if it makes sense. I still believe that the benefits of the client-side code outweigh the benefits of server-side code, but I also know that the differences are narrowing.
I had an Adobe Analytics customer, who did a full server-side implementation of Adobe Analytics. The were very serious, as they wanted to reduce the load time of the website. After months of implementation and issues that needed some changes in their configuration, the code was ready. However, this code never went live.
Which way do you see digital marketing will take in the future?