Server-side Tag Management


Julià Pujol

April 20, 2021
Server side tagging is a clear improvement over client side tagging. Server side improves data security and reduces page load times, two very important topics that directly affects your business.

Understanding user behaviour is key to running effective digital marketing campaigns. Whether it is Ads or on-site conversion optimization, we, the marketers, like to understand why certain groups of users end up buying products, while others don't. What makes some fill out a form or why they abandon the site seconds after clicking.

How do we get to know all that? Yep, with Tags. You already know what tags are, small pieces of code that websites dispatch every time a page loads or a user clicks somewhere. Usually, web developers were the ones in charge of the tag integration as Developers are tidy and organized folk. They work by gathering business needs and apply the changes in batches - "usually" every two or three weeks. 

However, nowadays we can't wait that much time for a tag to be set up if the business urgently needs it. We can't wait if a change to an existing tag is needed. We needed a different modus operandi. Tag Management tools came to bridge that gap by giving the marketers the means to manage tags, regardless of the developers release lifecycle. But, what does this mean for "Server-side" Tag Management? Do you or your company need it? Bear with me.

Tracking, the olden days

To understand where we are today with tracking, it's important to understand where we came from. When digital marketing started being a "thing", everyone quickly realized that there wasn't much improvement without measurement, so the industry came up with a very simple approach: load invisible images (<img />) inside websites to send and store user's behaviour data.

If you know a bit of HTML, you can quickly realize that this approach is basically tricking the browser by misusing the HTML <img/> tag. Have a look:

//a real image
<img src="" alt="Uptimal logo" width="500" height="600"./>
//a tracking pixel or tag 
<.img src=";type=abcde123;cat=fghij456;u1=product1,product2,product3;u2=340;u3=euros;ord=20735208354394?" width="1" height="1" alt=""./>

Loading above two URLs in your browser should be enough for you to realize that the second image is in fact, not an image, but yet still the browser thinks it's and so it makes a call to i.e server (Google Display Advertising server):

You may have noticed that the URL contains some information such as u1=product1,product2,product3 or u2=340 - this is a sample of purchase information that the server will store once the browser renders the "image". This is the data that we use, for example, to understand the user's average spent on our site or maybe to stop him from seeing ads as the purchase has already been made.

Why "management"?

As an example, I've picked the Google Campaign Manager tag but I could have picked any of the hundred tags currently existing in the marketing technology landscape - analytics, media, A/B testing, chats, pop-ups...

Each tool requires its own tag and it is estimated that, on average, there are around 11 tools used per site. On top of that, each tag has different code structures based on the type of page where they're triggered. An e-commerce could have around 7-page types (product page, category page, cart...) - the maths is simple, 7x11=77. Seventy-seven different tags spread across one site.

Managing that amount of tags is not something to take lightly. As the site changes or new tools emerge, changes need to be made, tested and deployed. To overcome this, most of the folks in the industry shifted towards Javascript (and Iframes or also, Javascript inside Iframes) to manage tags at scale. Without getting into technicalities, think of Javascript as a way to dispatch multiple pixels on multiple pages with one unique piece of code injected in all pages:

This is a clear improvement both for maintenance and agility but it left tagging to a handful of marketers that knew how to code. Those folks weren't common so many startups and tech companies saw the opportunity and they built tools that, in a visual manner and minimal technical skills, allowed marketers to create those Javascripts; these tools are the Tag Managers.

Client Side Tag Management

Tag Managers allow marketers to manage tags without web developers involvement with (almost) no technical knowledge, thus bringing agility to the tagging process.

Although indeed one has the ability to manage tags independently, truth be told, help from the developers may still be needed (not mandatory but desirable), especially to organise the page's data by building what's known as the Data Layer. Despite this, Client-Side Tag Managers give high degrees of agility and freedom - but nothing comes for free, does it?

Let's take a look at how a Client-Side Tag Management tool works:

The first step is to 1), place a piece of Javascript inside the website. This piece of Javascript, once a page loads and before the user is able to interact with the page, calls the Tag Manager and 2) invokes all the tags and places them into the page.

Once the tags are loaded, 3) these are constantly listening for user's events (page load, click, scroll, drag...), when an event happens, they check if this event has been attached to them, if so, the tag is dispatched (being the tag either in a Javascript or image form) and the data (action type, user id, browser user-agent, IP...) is sent over a platform such as Google Analytics or Facebook Ads.

Important, please note that some of the tags are also Javascripts. We have said that Javascripts can dispatch multiple image tags at a time so, if you place a Javascript tag in your tag manager, do you really know what this tag is doing or dispatching? No, you don't, you can guess it by debugging but if the logic is complex and the code well minified, I can guarantee you that it can be extremely difficult to figure out what is going on. This Javascript tag may send the data from your own website to several servers you know very little about.

Additionally, through Javascript, any code snippet has access to the browser configuration, a source of many abusive practices such as Browser Fingerprinting, used to uniquely identify users. With data bound to a unique id, any party could take advantage of your own site users and bid for them in an Ad auction.

Notice how tagging freedom comes with a price in a form of (possible) data leaks. Another "price" to pay is time, the time it takes your page to load. It's estimated that a 0.1s improvement in site speed could increase conversion rate up to 8% . It's also known that on average tracking tags increase the average load time of sites by 6.77 seconds. You can do the maths yourself.

Either it's a data leak that increases your bid costs or page load time that affects your conversions, eventually, it all affects your business. Taking this into account, let's see how Server Side Tag Management can help.

Server Side Tag Management

First let me say that this isn't a new thing, many tools like Segment have been doing server-side tagging for many years but certainly when a big player like Google (or Adobe) makes a move in that direction, we can all expect that in time, it will be mainstream.

But you, as a decision-maker, need to know "why" make an investment (or not) to adapt to this new way of doing tracking. Luckily, regarding the reasons to move away from client-side tagging, there is no much to add other than what I've mentioned in the last section: data leaks and page speed.

Let's see how Server Side Tag Management works to comprehend how it overcomes the challenges of client-side tagging:

First, like in client-side tagging, 1) you have to have a Javascript snippet to interact with the Tag Manager. This snippet is in charge of listening for any user's interaction we want to track and gather all its associated data. Once the data reach the tag manager's server, 2) it's there when it is decided where and how to send the data.

Maybe at a first glance, you can't see what's different here. The first important thing to notice is that the tags don't get loaded into the website, nor are they being dispatched by the website. Why is this important? It is important because the platforms where you send the data, know nothing about the web other than the data we choose to send. Nor can they dispatch any additional code on the web. Browser fingerprinting or cookie dropping are also avoided as no one, other than the tag manager, gets access to the user's browser. This is a huge improvement. It keeps your users and your user's data secure.

Additionally, realize that at the time to load, the page just needs to render one Javascript code, as opposed to client-side tagging where several Tags (many as Javascript codes as well) need to be rendered. That could easily mean, on average, a reduction of 90% in tracking load time.

As you can see, server-side is a clear improvement over client-side tagging, no doubt. Why then, isn't everyone investing in moving to server-side?

Troubled times

The times they are a changing in the digital world. Privacy has become a real concern for users and that is shaping the industry for good. One of these changes is the fact that third party cookies will soon be replaced (in Chrome; Safari and Firefox they're already blocked) by something else and the AdTech community together with Browser providers still haven't found a cross-browser solution to satisfy all parties. The most serious proposal for a replacement comes from Google with its Privacy Sandbox - still in development.

Third-party cookies (and browser fingerprinting) and tagging, particularly media tagging, are highly coupled as a means to identify a user and target him with Ads on other sites. That's not the case for other types of tools such as analytics where the tracking scope is just the own site.

If you are an advertiser and have investments in advertising, especially in display, you must know that most of the media platforms, due to the aforementioned reasons, still haven't found a way around third party cookies or browser fingerprinting. Therefore most of them are currently using both practices (that's not how it should be but it is the reality). That being said, if you move from client to server-side tagging you will wipe out the AdTech platform's ability to re-target your users outside of your site.

Some platforms, for example, Facebook Ads, have released server-side tagging APIs using first-party cookies in the browser and sending its Ids to the Server Side Tag Manager. This won't be a long term approach, plus currently, you still need to place the Facebook Javascript code in the browser.


Server-side tagging is a clear improvement over client-side tagging. Server-side improves data security and reduces page load times, two very important topics that directly affect your business. On the other side, it brings some problems, especially with everything related to identifying users for media platforms. Additionally, the skillsets required to properly set up server-side infrastructure are a bit different from the ones needed to set up client-side; you need a partner that knows how to do it properly. At Uptimal we can assess your current situation and help out if you are thinking of making the switch.

Also, if you and your business aren't ready to make the change due to your media investments and the platforms used for it, we can work together to reduce the impact of third party tracking on your page speed and audit your tagging setup to avoid leaks.

Tagging is essential, security as well - let's make it work together.

Posts that might be of your interest