I recently gave a talk at the Google Analytics Conference Nordic 2015 on how we went about implementing Google Tag Manager on a set of web applications. The focus of my talk was on documentation and routines, rather than the actual implementation of Google Tag Manager — which is really easy. This is a summary of that talk.

Data is everywhere and there are ever more applications and web services that provides solutions for collecting that data and generating insight based on those data. Most of these services are third-party services that relies on a service that you don’t have direct control over. Implementing these services exposes you to risks and knowing those risks is where your IT-security department is of great help. In order to make the process as smooth as possible, there are three key take aways;

Be honest
Be prepared
— and document everything

Why Google Tag Manager?

Using plain and regular Google Analytics works fine for most web applications in terms of generating usage statistics and insights. It is a reliant work horse. However, once you want to influence the quality of our Google Analytics tags and events without involving your IT department, it becomes a bit of a challenge. The same goes for if you have several applications, and you want to change a custom dimension or any other common attribute across all applications.

Having a clear understanding of why you want to implement Google Tag Manager in general makes it easier to provide arguments for the implementation per application.

This general description of why you want Google Tag Manager in general should then be expanded to include a list of all applications and the specific reasoning behind why you want Google Tag Manager for this particular application. In doing this, you also know what data is available for each of the applications you want to add Google Tag Manager to, both what the application generates and what the user enters and adds to the application.

Information that should be documented

  • Name of client
  • Does it require authentication?
  • List of customer supplied information
  • List of system generated information
  • Who’s responsible
  • Has GTM-implementation been approved by the business unit?
  • Has GTM-implementation been approved by IT-security?
  • The reason for implementing GTM

Knowing what is available and what’s exposed, you can start to decide whether or not you actually want to allow collecting that specific data.

Access control

All user accounts with access to your Google Tag Manager should be manager through Google Apps for Work, that goes for both internal users and external consultants. There should be no personal gmail-accounts in your setup or shared accounts. You don’t want personal gmail-accounts in your setup because you can’t control the security settings of those accounts, such as password policy. But more important, you need to be able to revoke access for users who should no longer have access. Google Apps for Work gives you one place to manage all users.

Having this process documented makes it easier to introduce new people to our organisation and explaining why we do things the way we do, and it is also easy to audit and revise whenever you want to.

Document who can view, edit and publish new versions of your container, and why does user have this access? For external consultants, there should also be a internal representative who’s responsible for auditing the access list for the consultants.


For the most part, this is no big deal. If you have publish-rights in Google Tag Manager, you are free to publish any predefined tag component without having to ask for permission. The only thing we require is that all new components – be it a tag, variable or trigger – follow our naming convention. The naming convention should be well documented and understood before allowing people editing your container.

Custom HTML or JavaScript tags, however, should require a bit more leg work. We have defined four steps you have to take before it can be published to our production environments.

  • Implementation of the code
  • Testing of the tag/script in staging environment
  • Code review and test — performed by relevant developer
  • Release to production — performed the person who implemented the code, in cooperation with a relevant developer.

For each of these steps, there should be a person or role that has the main responsibility and who’s responsible for the execution, and who should be informed about the changes.

3rd-party code has two additional steps, requiring needs analysis as to whether or not you really need to involve a third party. Sometimes you can just as easily host code yourselves that does what a third party can offer. There are some truly great libraries out there that are licensed in a way that allow you to use them without going through too many loops and hoops.

Once the code has been verified, tested and released to production, export a copy of the latest container and store it for internal review and as documentation of what has changed. List what has changed, who did it, who verified and a description of all tags, variables and triggers. This will allow you to go back and see what has changed and if we can remove these 3rd-party code snippets.


Make sure you have information about all applications and their data, a good rationale for implementing Google Tag Manager, and that you know how yo handle your access control.

Be honest
Be prepared
— and document everything