Enter a search term such as “mobile analytics” or browse our content using the filters above.
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.
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.