Our advice for staying safe with TMS

Tag Management Systems ( TMS) have proven their worth when it comes to implementing and managing data collection. Today, they have become the cornerstone of data strategies. There’s no shortage of advantages: TMS are more agile, more flexible, and more legible than other solutions. But not all Chief Information Officers (CIOs) consider TMS to be a perfect solution, as they see an open door to the outside, and thus as a potential site security risk.

Given these two differing perspectives, how can we be sure that a TMS is secure, without sacrificing its flexibility? Who can be trusted with managing this Trojan Horse? Do we have to closely examine each of the TMS scripts?

House keys

Would you lend your house keys to a stranger you met three minutes earlier at the supermarket? Probably not, even if he or she seems harmless. Managing TMS rights is kind of the same thing: the person (or people) who has the keys can do many things, including stealing data or modifying your site behaviour. What if, when your clients click on “Purchase”, they are redirected to a competitor’s site? What if a shady foreign group used a JavaScript cryptocurrency mining script?

For these reasons, those who have access to TMS must be clearly identified:

• Don’t use personal e-mail addresses: if an employee uses his or her personal e-mail address to access the TMS, he or she would still have this access even if he or she changes jobs. Professional e-mail addresses should always be used, so that if an employee leaves on bad terms his or her TMS access will be terminated when he or she leaves the company.

Note: You don’t need a Gmail account to use Google Tag Manager (GTM), you can link your @company.com address and use it.

• Avoid using aliases: they make it hard to trace modification history, as one alias could be used for multiple people. It is possible that aliases have access, but this should only be the case to give TMS access to individuals.

• Periodically review accesses and delete inactive accounts: if you are unsure, it is better to revoke someone’s access and restore it later instead of letting it collapse.

Managing rights also includes assigning “admin” rights: who is able to add new users?

The most obvious answer is to entrust this access management to the advertiser who holds the TMS contract. But often, centralising access like this is difficult for agencies, as they generally have several internal users which makes it challenging to obtain access for each person…Which is where common addresses (aliases) come into the picture!

It makes sense that the advertiser wants to keep control of its TMS, but allowing agencies to manage their teams’ access rights makes project management more fluid. Each provider is responsible for the way it uses the tool! Might as well choose decentralised management to avoid losing precious time when an urgent request for an upcoming campaign comes in…

Inside the Trojan horse

Once you have decided about how your TMS will be managed, what are some of the risks you should be aware of? How can you minimise or avoid them?

For the most critical sites (e.g. online banking), some TMS are able to authorise that only certain TMS tags be executed, via a dataLayer instruction. This “whitelist” is defined on the site, and prevents unwanted tags from being added with the TMS. It should be used carefully, because the implementation timeline is longer (it must be added to the whitelist by the CIO).

It is also possible to limit tag activation, so that only template tags are used. That is to say, you can prohibit custom Javascript tags. Nevertheless, this method means you may miss out on some KPIs which rely on non-native functions ( tracking HTML5 videos, for example).

Similarly, you must know all about your tags. What is the intention behind them? What is the related business demand? How old are they? Should they be deactivated at a certain date? Doing a bit of spring cleaning never hurts, and might lead to important discoveries, like malicious tags. Certain TMS deactivate these malicious tags as they go, which is helpful but not enough if you truly want to master your data. There are more radical solutions, too, like sing Content Security Policies (CSP) which will block calls to certain third-party domains (identified via black – or whitelists).

Once the tags have been placed on the site, you just need to make sure they work before publishing. Any Javascript you’ve added to the TMS can have a big impact on how the site works (loading time, library collisions, bugs). You must be sure to do a thorough quality check before publishing. This check should include:

• Testing content to verify that:

o The tags work properly (operational data collection).
o The site works properly (user experience is complete).

• Re-reading and starting production using a different person than he or she who placed the Tag.
• Defining a backup plan in case of holidays or absences to ensure someone is monitoring publication.

One thing is for sure: the TMS must remain flexible, and must continue to boost your digital marketing. For this, the CIO must be involved from the beginning of the adventure to guarantee site security. Technical teams have been asking security questions for a long time. Take this opportunity to get inspired and make sure your project is successful!

This article was originally published on Journal du Net, and translated from French by Niamh Cloughley.