Deploying analytics through a TMS that is last to load? –It can be detrimental to your data

Many companies that purchase a basic tag management system (TMS) end up deploying it way down under on their website pages, right before the closing tag. This practice is purely a defensive move: having gone through much belated testing, these companies later realized that the lackluster availability and response times of the basic TMS tool they bought would wreak havoc on website performance should it load at the start. And so these companies resolved to avoid messing with the blocking menace and, instead, tuck the TMS tag far away from where it could do harm, in the corner of the web page, having it sheepishly rear its sluggish head only after all the HTML content streamed by and safely reached the client.

Enumerating the list of opportunity costs that spring from a TMS that is last to load is too arduous a task for a lowly blog post. Let us enjoy the suspense as we await a forthcoming white paper on the matter. But one assault cannot be concealed any longer; one victim must be spoken for!

And that, alas, is poor web analytics.

Before I state my case, let me submit the facts: Mark this website of a multinational enterprise servicing over 200 million customers. The website has relatively low traffic, and rightly so: it’s mightily slow. Slower than most, in fact. The not-so-proud owners of this said website had decided to speed things up by purchasing a basic TMS. But, lo and behold, they must have found the TMS further slowing down their slothful site, for – you guessed it – the TMS tag now crowns the tag.

All of this may have been forgiven if not for the owners’ second transgression, which was to deploy their website analytics through the TMS. What evil spirit possessed them to handle analytics with such reckless abandon pray we never encounter. The consequences, however, are horridly clear. Perpend:


Above is a test result snippet from All identifiable information has been masked. What you are able to discern, however, is a Google Analytics pixel request. Trust me that it is being deployed from a last-to-load basic TMS. Note the Start Offset detail, which is the absolute time in the waterfall when the request started.

Being dependent on the slow website content to load first, it takes this basic TMS almost eight seconds to trigger the analytics call. Meditate on that fact a bit longer: almost eight seconds for the analytics call to go out. What percentage of site visitors would wait that long on a given page for the analytics tag to have a shot at firing? How useful is web analytics that operates under such daunting conditions?

Now, you might argue that this website is an outlier and that there are valid reasons sometimes to fire the analytics tag after the content was served, and I would agree with you, but then we’d both be missing the point. I’m not suggesting that analytics must always load before the content does – there are pros and cons to each approach.

What I am saying is that website owners must have the freedom to choose for themselves when to load analytics, given the nature of their website. And that a basic TMS that is unable to load at the head without destroying user experience robs site owners of this freedom. It forces them to make an undesired choice: either load analytics too late and miss critical data, or avoid the TMS (that you paid for) altogether, hard-code the analytics tag to the top of the page and limit your ability to optimize data collection and–with it–your understanding of visitor behavior. Pick your poison.

To outperform your competition, you should continuously optimize your digital properties. And to make the right optimization decisions, you should continuously enhance your analytics by collecting and analyzing new (and valid) data sets. Compromise on analytics and your marketing will become less agile, and you’ll be falling behind the competition.

Analytics is too important to be quickly checked off during the TMS vendor evaluation phase. Companies should pay closer attention to how existing clients of each TMS vendor deploy analytics; what incremental value the TMS solution provides for their analytics use cases; and how comprehensively the TMS solution supports base tagging, page-specific tagging, event tracking and so on. More on that in future posts.


  1. says

    Any clue about which TMS is used in that example, Boaz?

    I know it’s tough to compare Analytics.js to Ga.js. However on my site, I’m delivering ga.js on the page within the head and Google Tag Manager serves Analytics.js directly after the opening tag.

    Ga.js tracking is sent around 100-500ms faster than Analytics.js but oddly enough, Analytics.js reports more visits!

    Can’t wait to see the whitepaper.

Leave a Reply

Your email address will not be published. Required fields are marked *