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.

User's behaviour is key to run 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 some don't, or what makes some fill out a form or even why they’ve abandoned the site right after they’ve visited it.

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. Traditionally web developers were the ones in charge of its implementation. Developers are tidy and organized folks - they usually work by gathering business needs and apply the changes in batches - "usually" every two or three weeks. 

We can't wait that much time for implementing a tag if the business really needs it. We can't wait that much time if a change to an existing tag is needed. We do have 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. So, what "Server side" Tag Management stands for? 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're coming from. When digital marketing started being a "thing", everyone quickly realized that there wasn't much of 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 will use, for example, to understand the user's average spent in our site or maybe to stop him seeing ads as the purchase has already being 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 requieres its own tag and it is estimated that, in average, there are around 11 tools used per site. On top of this, tags got different code structures based on the type of page where they fire. An e-commerce could have around 7 page types (product page, category page, cart...) - maths are simple, 7x11=77. Seventy seven different tags spread across one site.

Managing that amount of tags it is not something to take lightly. As the site changes or new tools emerge, changes needs to be made, test 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; those 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 have the ability to manage tags independently, truth being told, help from the developers may still be needed (not mandatory but desirable), specially to organise 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, isn't it?

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

As a first thing to do 1), a piece of Javascript needs to be placed inside the website. This piece of Javascript, once a page loads and before the user is able to interact with the page, it 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 a image form) and the data (action type, user id, browser user-agent, IP...) is sent over a platform such as, for example, Google Analytics or Facebook Ads.

Important, notice 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 do not, 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 wat 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 have access to the browser configuration, source of many abusive practice 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, in 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 effects to your business' pocket. Knowing this, let's see how Server Side Tag Management could help with it.

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, this will be the mainstream.

But you, as a decision maker, you 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 to where and how send the data.

Maybe at a first glance you can't see what's different in here. The first important thing to notice is that the tags don't get loaded into the website, nor those are being dispatched by the website. Why is this important? It is important because the platforms to where you send the data, they know nothing about the web other than the data we choose to send, nor can they dispatch any additional code in the web. Browser fingerprinting or cookie drooping 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 opposite of what is happening in client side tagging where several Tags (many as Javascript codes as well) need to be rendered. That could easily mean, in average, a reduction of the 90% of tracking time load.

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

Troubled times

We are facing times of changes in digital. Privacy has become a real concern for users and that is shaping the industry accordingly - for good. One of this changes is the fact that third party cookies will son be replaced (in Chrome; Safari and Firefox are just blocked) by something else and the AdTech community together with Browser providers did not still find 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 in other sites. That's not the case for other types of tools such analytics where the tracking scope is just the own site.

If you are an advertiser and have investments in advertising, specially in display, you must know that most of the media platforms, due above reasons, didn't still find its 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 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, specially with everything related with 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 - we can assess your situation and help if you are thinking on making the switch.

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

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

Posts that might be of your interest