Using a tag manager does come with consequences on your web pages loading speed. In a previous post, we’ve pointed out that this impact can’t be limited to the asynchronous loading of the embedded tags, and that your tag manager can become a serious problem for your website performance. So now it’s time to explore a few best practices about tag management so that this tool could meet its marketing goals without compromising your webpages’ speed. With the help of L’Oréal’s Digital Ad Tech Manager and several experts.
Be aware of tag management impacts on web performance
In many cases, awareness of tag managers’ potential impact on web performance is lacking. “Generally, these stakes are not enough taken into account,” concedes Christophe Caulet, Digital Ad Tech Manager at L’Oréal. Georgene Nunn (marketing consultant/blogger) makes a similar observation: “Many people in charge of TMS [Tag Management System, NDLR] are non-technical, and in my experience, the performance and load time of websites is neglected outside of technical teams unless there is serious lag that’s generating complaints from users/visitors“.
“With great power comes great responsibility!“
According to Tom Bennet, (Builtvisible – London), tag managers can even quickly become a real Pandora’s box: “In my opinion, tag managers have dramatically lowered the barrier to entry, so to speak. This is particularly true in organisations where the GTM container is owned exclusively (or almost exclusively) by the marketing team, with limited oversight from the development team. Being able to inject code so easily results in people becoming far less critical when it comes to deciding what is necessary / justifiable“.
This observation, shared by all the people we have contacted to prepare that post, leads to one main recommendation: implement – and use – a tag manager does require cooperation between marketing and development teams.
Shared stake between marketing and development
In other words, as a marketer, you shouldn’t consider the tag manager as a way to bypass the technical teams. While this type of tool should obviously speed up/flexibilize the process of adding and managing your tags, we do not recommend using it without collaboration with development. And not only because a tag manager is an easy JS scripts injector…
According Christophe Caulet, this necessary collaboration starts with a cross-department dialogue, as he explains on his blog: “Your media, marketing and IT teams will have to redouble their efforts to find the right compromise between ‘advertising and marketing performance’ and ‘display and loading performance’ in order to best meet the challenges of customer knowledge without degrading the user experience“.
At the core of this discussion, you will find arbitrations such as “adding such script slows down my site by X%, but it improves my sales by Y%”. But first of all, each department will have to “agree on KPIs to be measured about web performance, but also about marketing,” underlines the Analytics expert.
By the way, such reasoning really sounds like the performance budget method we’ve been promoting for years on this blog!
Here’s one more interesting testimonial from Josh West on AnalyticsDemystified: “I’ve […] seen clients have more success because tag management tools have broken down walls not only between IT and marketing, but also between individual teams within marketing as well – because when you have a solid data layer, everyone can benefit from it. Ranking priorities between the analytics team and the display team, or between the social media team and the optimization team, no longer means the loser must wait months for their work to be completed“.
The Data Layer sits in international waters
Excerpt from Google Tag Manager Can do What? | SMX London
“The Data Layer sits in international waters,” explains Tom Bennet. “By gearing your implementation around a Data Layer – and by working with your development team as opposed to using GTM as a convenient backdoor – it’s possible to reap many additional benefits which are less widely appreciated.” A collaborative way of deploying GTM he has talked about at SMX London indeed. With, for the record, a “gift” for the technical teams: a JS errors tracking in Google Analytics made possible thanks to the tag manager!
Beyond the helpful mapping of the data to be used by the tag manager (that could be a really good idea by this GDPR period!), including the development team while setting up the Data Layer will ensure an optimal integration of the tag manager, preventing from the most common pitfalls (such as those mentioned by Google Tag Manager). You can also find many helpful resources about Data Layer, like Phil Pearce’s Google Tag Manager Book, with whole pages dedicated to Data Layer structure and naming convention.
Note that the time you’ll invest in building a “good” Data Layer, making it independent of any platform or technology, brings you an extra benefit: it dramatically lowers tag switching costs!
One more advantage of using a Data Layer, noticed by Georgene Nunn: being able to switch more tags to asynchronous from synchronous loading (and then improve your web performance). “My general experience is that anything which is sensitive enough to require synchronous loading can likely be aided by a Data Layer. E.g. passing transaction data from one page to another and then to a script for tracking. A data layer can be added to safely pass that information so the tracker can still be loaded asynchronously and fire when ready“.
Choose the right tags
For a good “tag recruitment”, you’d better make each script pass a real interview! For example, the JS Manners site summarizes the major questions to be asked in terms of performance, stability, maintenance… 3rdParty.io pushes the approach even further by testing whether scripts follow the best practices regarding performance, security, etc.
In a perfect world, you should test your scripts within an integration environment, but this is not always possible. It is sometimes necessary to integrate directly into Production. If so, do it according to very specific criteria. For example, you can first make the tag inactive unless a “myGTMnewTagTest=enable” cookie is set. This way, only you can test, before extending the test to others.
Note that at this stage, you can fully measure the impact on web performance with Dareboost. Our test tool will indeed allow you to inject this same cookie! You can even make a comparison with and without the cookie (and therefore the script) to gauge its impact.
Remember that before using a third-party script, you have to test what happens when the script is loaded, but also if it fails. Even if the tag provider is renowned, you have no control over the network conditions or proxies configured on your users’ networks.
You can prevent from those kind of issues by testing your web page with Dareboost while blocking the tag request (using our Blacklist option). You can also simulate a third-party content failure by redirecting its domain to a “black hole” domain, such as blackhole.webpagetest.org using our DNS mapping feature.
One more testing possibility when you are in Production environment: check if the script spawns requests to other domains, by using http://requestmap.webperf.tools/ for example, to get an interesting graphic overview.
Obviously, don’t forget that tools like Google Tag Manager provides a Preview mode and a debug console “to test the deployment of your tags internally or externally by sending a test link (preview>share),” as Franck Scandolera reminds it in his best practices to manage GTM.
The consultant also insists on the crucial importance of properly organizing, from the creation of your GTM account, by respecting the following basic rules:
- 1 account per company and 1 container per site/application (pre-prod|prod)
- the adoption of a naming convention for tags, macros and rules. “This is the best way to save time and avoid unnecessary duplication of GTM components. The naming structure should allow you to clearly identify what it covers“.
A common sense rule that we also recommend to our customers, when naming their page and user journey monitoring in Dareboost!
Rigorous tag management
Once your tag manager is implemented, the main challenge will lie in its continuous administration. The key element is to have a very detailed list of scripts and dependencies and to update it regularly. The tag manager interface – and the implementation work mentioned above – should then be helpful, preventing you from any problem of double tagging, tag updates, etc. Information is the key to negotiating with internal and external stakeholders.
The other challenge: to have a good intervention plan to be ready to disable any tag in case of unforeseen events: traffic peaks, incidents, changes in conditions of use.
In this context, the designation of a “tag manager owner” may be a good solution. At least that’s what Georgene Nunn recommends. “Tag management is not ‘set it and forget it’ technology. Someone should stay on top of making sure that tags are being used optimally“.
What would be the mission of a tag manager owner?
- Keep the tags up to date, by maintaining a record of what tags are being used, and keep in touch with those vendors and/or developers to make sure the latest (stable, usable) versions are deployed through the TMS.
- Keep the tags clean, and remove any tags which are no longer relevant. “If, for example, your company changes analytics programs, the old analytics tag should be removed when the new one is installed so there isn’t unnecessary loading“.
- Stay aware of web performance: “The TMS owner should stay in touch with the technical team, or have site performance alerts delivered to them. Tags can fail or cause site issues and the TMS owner should be prepared to pause or remove tags or rules if it means keeping the site running smoothly. It’s better to lose some data than to lose customers“.