{{ searchResult.published_at | date:'d MMMM yyyy' }}

Loading ...
Loading ...

Enter a search term such as “mobile analytics” or browse our content using the filters above.

No_results

That’s not only a poor Scrabble score but we also couldn’t find any results matching “”.
Check your spelling or try broadening your search.

Logo_distressed

Sorry about this, there is a problem with our search at the moment.
Please try again later.

Tag management is rapidly becoming one of the must-haves for site owners. The ability to manage the ever-growing number of measurement and marketing tags on a website offers huge benefits to webmasters and web marketers alike.

However, there are two fundamentally different approaches to tag management and anyone looking to adopt the technology should be aware of the benefits and limitations of each.

The key difference lies in where the tag management activity itself resides, in the browser or on the server-side. Browser-side tag management sees all of the tags on a site being placed into a so-called ‘container tag’ and then loaded in the browser as part of the site.

Server-side tag management systems, meanwhile, act as an intermediary between the site owner and their third party systems – hosting all of the tags on their own servers and thus deploying very limited technology on the site. 

The server-side tag management advocates would claim that their approach has a number of benefits. Because no tags are loaded on the site itself then there is no impact on site speed. Moreover, because the technology is hosted on the provider’s servers, there is less technology interference with the site. 

However, browser-side tag management fans , and QuBit resides firmly in this camp, would strongly disagree.  

At a basic philosophical level the idea of a tag management provider acting as an intermediary seems wrong. The trend in web development has been more and more towards the browser and the new generation of lighter, faster browsers such as Chrome only validate this belief.  

Furthermore, the idea that the tag management provider will sit between the company and its third party systems also implies a loss of control that would be unacceptable to many. The idea that the server-side tag management system can act as a ‘black box’, farming out your data to third party systems is a rejection of the increasing openness we have come to expect from the web and is anti-innovation, implying a real, long term cost to the client who must rely on their single provider to offer the next level of functionality. 

Claims about speed can also be roundly rejected. By using a browser side container tag approach, tags can be loaded asynchronously, ensuring that the important aspects of a site can be loaded first, resulting in the best consumer experience of the site itself. 

At a more prosaic level the server side argument also has its downsides. Foremost, amongst these is the issue of technology tie-in. Whilst a browser-side tag management system can, theoretically, be replaced with a single line of code on the site, a server side tag management deployment would require a significant technology migration to enable switching to another provider.

In a fast moving market such as tag management – where new solutions and technologies arise all of the time – technology tie-in should be avoided by clients at all cost and should be catered for by providers as a matter of best practice. 

The fact that the vast majority of tag management systems have chosen to take the browser side route would seem to indicate that it’s winning as a model. Indeed, Google’s recently launched Google Tag Manager takes a browser-side approach, adding the weight of the technology giant behind this argument. 

Despite this, some players still remain wedded to a server side approach, offering clients a sub-optimal technical structure and threatening the fluidity of the tag management marketplace with inappropriate technical inflexibility.  

Ian McCaig

Published 3 October, 2012 by Ian McCaig

Ian McCaig is Founder at Qubit and a contributor to Econsultancy.

29 more posts from this author

Comments (6)

Comment
No-profile-pic
Save or Cancel
Avatar-blank-50x50

Matt Lovell, Head of Group Analytics & Digital Insight at Thomas Cook Group AirlinesEnterprise

While I'm in agreement with you that a browser side approach seems to make the most sense, one of the biggest concerns a lot of companies have is that a tag management solution won't actually solve all of their problems in that as soon as the required tagging becomes complicated (needing to capture variables, behaviour on click or submit etc.) and when concerns are raised about understanding how regularly tags do manage to fire when placed asynchronously, none of the current browser solutions really seem to be able to do everything required...

about 4 years ago

Ian McCaig

Ian McCaig, CMO & Founder at Qubit

Hi Matt, I am pleased you agree with the Browser side approach and agree capturing values from users, pages and products etc can be very complicated for large Enterprise businesses. At QuBit we have created an Enterprise OpenData model which businesses are now adopting as a standard approach. We have made this OpenSource and are working with other ad tech partners as we believe the sooner the industry adopts a single approach the better for all parties involved. We will have an exciting announcement on this very soon.

Below are some useful links on this:
OpenData Model - https://github.com/QubitProducts/UniversalVariable
Universal Variables - http://opentagsupport.qubitproducts.com/help/kb/installation/introduction-to-qubit-universal-variable

To your point about Asynchronous tag loading, it is important the TMS you work with can correctly load and then report against each tag loaded to ensure performance benchmarks are being met. With site speed being so important for website owners making all Tags Async is a must, especially when some sites have 20+ tags loading on any one page across analytics, marketing tags and web apps. One of the claims of server side Tag Management is the benefits from Javascript not loading on the site but in reality this is just a fallacy as an Iframe has to load 3rd party Javascript and execute all the tags being deployed due to the inherent security layer of the internet.

about 4 years ago

Avatar-blank-50x50

David Cook

Interesting article, I would add one additonal, yet fundamental, point about the server side approach, which is that there are a number of things that a server tag can't do in principle.
1. read or write cookie information. Any tracking related tags (e.g. retargeting or affiliate tags) will need to do this
2. read information from the page (either directly encoded on the page, like page coded parameter, or dynamically extracted from the document, like dynamic parameters)
3. realistically, execute JavaScript (this could be done server side, but in an environment where it is unlikely to do what is expected)
4. obviously, render anything in the page (MVT tags or display tags)

To an extent these things can be done on behalf of the tags by the container tag (and passed as parameters on the query string), but this will not be possible for 3rd party cookie information. In practice, server tags are only practical for very simple pixel tags, that don't require cookies.

about 4 years ago

Avatar-blank-50x50

Matt Lovell, Head of Group Analytics & Digital Insight at Thomas Cook Group AirlinesEnterprise

I understand these elements however my issue still remains that with the majority of browser side tag management solutions, these too in turn are unable to do everything that is really needed.

Having worked with a number of solutions to date, I've found that there are a number of problems generally such as:

- The need for a fairly manual implementation process in order to capture a lot of variables / actions on site which in its essence defeats the point of the solution

- Interfaces not being up to scratch to proide the necessary information that you would require to ensure that tags are managing to fire on a regular basis

- Problems with MVT tags and other tags that need to fire synchronously not being compatible with the solutions

Until enough of these are ironed out, I still think that in a lot of cases, the addition of a tag management solution doesn't actually improve complex development work timelines significantly (and in some cases can actually slow things down)

about 4 years ago

Ian McCaig

Ian McCaig, CMO & Founder at Qubit

Hi Matt,

Thanks again for your follow up comments. Below are responses to your 3 questions.

1. The need for a fairly manual implementation process in order to capture a lot of variables / actions on site which in its essence defeats the point of the solution

We have created a open universal variable model (link in previous post) and tagging standard that means once adopted all 3rd party data exchanges can be standardised and future proofed making management much easier and minimising data leakages.

With OpenTag, you can do this from the interface and even without universal variables you can build value extractors. This means you do not need to edit server side code

2. Interfaces not being up to scratch to proide the necessary information that you would require to ensure that tags are managing to fire on a regular basis

Reporting on tags firing is a good feature for showing which tags are currently experiencing issues. However, providing the TMS you use has been properly architected missing firing tags should not impact site performance

3. Problems with MVT tags and other tags that need to fire synchronously not being compatible with the solutions

Some Tag Management Systems have tackled this issue head on and in fact resolved the issues of MVT tags loading synchronously. With OpenTag we have developed our system to load tags Asynchronously even if they are Synchronous tags to ensure page speed is not impacted.

about 4 years ago

Avatar-blank-50x50

Jobe

My family all the time say that I am wasting my time here at web,
except I know I am getting know-how daily by reading such good
articles.

about 4 years ago

Comment
No-profile-pic
Save or Cancel
Daily_pulse_signup_wide

Enjoying this article?

Get more just like this, delivered to your inbox.

Keep up to date with the latest analysis, inspiration and learning from the Econsultancy blog with our free Daily Pulse newsletter. Each weekday, you ll receive a hand-picked digest of the latest and greatest articles, as well as snippets of new market data, best practice guides and trends research.