Creating a Development and Testing Process for Google Tag Manager

Google Tag Manager (GTM) is a powerful and free tag management platform. It allows you to configure and enrich data sent to Google Analytics. However, unless you have a robust process for development and testing you will miss opportunities to improve data quality and insights from Google Analytics.

Access our FREE MEASUREMENT PLAN TEMPLATE

The free version of Google Tag Manager does not have a workflow and approval management process. It’s important to establish manual processes to minimise the risk of a data degradation data outage. The paid version of Google Tag Manager (GTM 360) does have a built-in workflow management functionality. This means changes can be more easily managed online.

1. Define your measurement plan:

Define your measurement plan by using a performance framework to align customer goals with metrics and optimisation activities. Optimisation expert Jonny Longden’s e-commerce performance framework allows you to achieve this by defining customer goals at each step of the user journey. This ensures metrics are close to the user journey and what to focus on in your optimisation activities.

Once you have completed this process, you will be in a better position to create a digital measurement plan. The plan should go into the detail of how you can deliver leading indicators, improve insights, data quality and your conversion rate. This might include items such as creating tags for important events in user journeys, implementing enhanced e-commerce, creating automated reports in Data Studio or implementing cross-domain tracking.

Apart from giving you a clear direction, the measurement plan should act as a guide to what you need to change or create in Google Tag Manager. This enables a discussion around priorities. It provides the business with a road map of what you want to achieve in the short to medium-term. Once your plan and priorities are agreed with stakeholders you can begin the implementation phase.

2. Create a Measurement & Tag Plan:

If you don’t already have a tag plan you need to create one now. Document your Google Tag Manager set up and the changes you make going forward. Documenting your Google Tag Manager set up and tags helps you keep a record of your progress and is vital for when staff turnover and promotions result in analysts moving onto other jobs and organisations.

You can download our free template for a combined measurement and tag plan here.

Create a tab for the following:

Overall:

• Your measurement plan which covers business goals, website goals, key metrics and targets

Tools

• List all the analytics (including GTM) properties/containers and advertising tools with their IDs for GTM for easy access.

Pages

• List all your page view tags with the corresponding URL for all the environments you are tracking.

Events

• Here you list all the event tags you have configured, including if they are live (see below).

Audiences

• Define all the target audiences you have set up in Google Analytics.

Testing GTM Tab

• Keep notes of tools I use and any tips for debugging GTM.

Creating a tag plan also encourages you to review existing tags when implementing changes to your Google Tag Manager container. It means that we don’t have to rely on our imperfect memory for justifying why a tag or other change was made.

3. Account Permissions for Google Tag Manager:

It’s recommended that you create one account for all the containers of a single organisation. This means you can manage container permissions from a single Google Tag Manager account. There are two levels of permission for an account.

User

This is the default and allows the user to view account information, but not change any aspect of the account.

Administrator

This allows users to create new containers and change user permissions for accounts and containers. Restrict such access to only a few senior people. Be careful about having a sole administrator because if the role of this person changes you could find yourself locked out of the account.

4. Set Container Permissions for Google Tag Manager:

The key to any good Google Tag Manager approval process is setting the appropriate permission levels at the container level. Account level changes should not be very frequent. Container level changes can be daily and sometimes even more often than that. Only give the ability to publish to a few people who fully understand how to use GTM.

Carefully consider the business needs of each user and use it to give them one of the following levels of permissions;

Read

This only allows users to view the container and browser tags, triggers and variables. It doesn’t allow users to test tags in ‘Preview’ mode.

Edit

This enables users to create workspaces and make changes to the container. Importantly it also gives them access to ‘Preview’ mode for testing. It’s useful to give third party agencies and developers this level of permission. It allows them to test GTM implementations without any risk they will break anything.

Approve

Gives users the ability to create versions, workspaces and edit tags, but not to publish. Most, if not all, your junior and senior web analysts should have this level of permissions to be able to effectively do their jobs.

Publish

This provides the ability to do everything, plus the rights to publish changes. Publishing rights should be given to only a few seniors to avoid changes going live or until they are ready.

Make sure you regularly review user’s permissions to ensure you remove people who have left the organisation or no longer need access to GTM.

It’s also good practice to be transparent with who publishes changes and the process you have for testing and approval. In some organisations a senior IT manager submits changes after the analysts get them approved. What’s important is that you have a clear and easy process which everyone agrees to and follows.

So, next I will discuss the process of making changes to Google Tag Manager. If you don’t have the paid version that comes with Google Analytics 360.

5. Agree changes and the environment:

Now that you have your tag plan you are in a better position to consider how to implement agreed changes to your GTM set up and the environment it can be tested in. Once you have a plan, you can add a description and other relevant details to your Google Tag Manager tag plan.

You will also need to decide which environment to test the changes in. If the changes relate to a secure section of the website. Such as the payment gateway, you will need access to a pre-production environment. This can be problematic if the environment is not close to the live environment. Often this means using UAT rather than DEV or SIT. Find out what you can get access to and if there are any differences between live and the environment you are testing in.

If you are testing migrating to GTM on your website make sure it does not go to the live environment before you have tested it. Otherwise you will be forced to publish the container into a live environment. You will also have no ability to make adjustments to the implementation in a pre-production environment. GTM environments do allow you to publish into a specific environment, but this this requires a different code snippet for each one.

I prefer to use a Lookup table to send data to different GA properties rather than having different GTM code for each environment. It’s much easier to manage releases if the code is identical in every environment. There is no risk of the wrong code being deployed to an environment.

6. Set up your workspace:

If possible, create a separate workspace for each change in GTM. If like me your organisation has the free version of GTM you have to work with a maximum of three work spaces. This allows different team members to work simultaneously and independently to configure and test tags so that you can deliver changes without having to wait in a queue.

When a user in another workspace publishes a change to create a new version you will get a notification to update your workspace. You will have to accept this update before you can publish any changes and create a new container.

However, none of the changes in your workspace will be published when another workspace publishes changes. If the new version creates any conflicts with the changes you have made in your workspace you will see ‘Conflicts Found’ message on the Workspace Overview page. By selecting a conflict, you will have the conflict resolution tool which forces you to make logical choices.

7. Plan your change:

Investigate how best to implement your change by using reliable sources such Simo Ahava’s blog and other high-quality content, such as Measure School and AnalyticsMania.com. Be careful about copying any JavaScript without getting one of your developers to review it first.

Inspect any elements you plan to tag by opening Google’s Developer tool by pressing F12 or right-clicking on the element. You can often use a CSS selector such as the ones shown below to identify a unique element on the page in GTM. However, where you have multiple identical buttons or some other element on the same page you may have to ask a developer to add unique ID to the source code.

8. Configure GTM:

In your individual workspace you can now make all the changes to variables, triggers or tags. You can save any new tag etc or edits without any change going to the live environment. Changes only go live to the production environment when you publish them.

9. Use Preview Mode to Validate Change

In the workspace select ‘Preview’ mode which will refresh the page and allow users to go into debug mode. If you are already in debug mode, you will need to refresh the page.

Now go the website linked to the Google Tag Manager container (in the same browser) and refresh the web page. If GTM has been implemented correctly a new window at the bottom of the browser will automatically open. A GA – Pageview tag should be showing in the summary tab.

The window has separate tabs for Tags, Variables, Data Layer and Errors. If your new tag does not fire check the ‘Variables’ tab to see if the data you are expecting is available to GTM. If you click on the new tag in the ‘Tags’ tab you will be able to see which, if any, of the trigger conditions were met and can adjust accordingly.

Possible Problems

If the window does not open or the pageview tag does not fire, there may be a problem with the implementation of GTM. Check that you are in the correct GTM container and that you refresh both GTM and the web page that you need to test.

If this still doesn’t work, then right-click on the page and select ‘View Page Source’. Then press ‘ctrl’ and ‘F’ at the same time and enter ‘GTM’ into the input box. This will take you to the GTM script and you can check that the container ID is correct. If the wrong GTM script shows or if changes have been made you will need to go back to your developer.

Use Google’s developer tool to developer console to enhance your debugging skills. For details of how to use the Chrome developer console check out this excellent post from Optimize Smart.

10. Check Google Analytics ‘Realtime’ console:

Now go to the Google Analytics property for the environment you are testing in (e.g. DEV, SIT or UAT), select an appropriate view and check ‘Realtime’ in the vertical navigation on the left. You should see the page view in the ‘Content’ tab and any events in the ‘Events’ tab. Remember to use a view that does not exclude internal IP addresses if you are working in the office as otherwise your actions won’t shown up in the console.

11. Update Tag Plan:

If everything is working according to plan you can review your tag plan an update it if necessary. Make sure you document any changes or problems with implementation to assist future analysts with understanding the rationale behind your approach.

12. Seek Approval:

You can now seek approval from the senior analyst or manager who has authority to publish changes. This should involve communicating the nature of the testing undertaken, any adjustments that you had to make as a result of the testing and outline any risks about publishing the changes.

13. Publish Changes:

If the approver agrees with the changes and the result of testing, they can publish into the appropriate environment. If more than one person has been using the same workspace there is always a danger you may publish something by mistake. Be careful to check that the workspace only contains your changes.
You can remove other changes by clicking on them in the ‘Overview’ tab and select ‘Abandon Change’. Only ever publish changes that have been approved.

To publish the changes, you must be in the workspace where the changes were made and click on the ‘Submit’ button. Now complete the title and description of the changes about to be published. This should outline in simple language the nature of the changes so that anyone checking different versions can understand what is changing. if you are working in multiple environments select the correct one before proceeding. You can then click ‘Publish’.

14. Check Live Data:

Go to the ‘Realtime’ GA console for the same environment to check data is being collected. Then go to the website to double check the changes are working correctly in ‘Preview’ mode.

15. To Reverse Changes:

If you need to reverse a change to Google Tag Manager click on ‘Version’ on the top navigation tab. This will display all the versions of the container. You can click into a version to see the details of what was changed.

If you want to revert to a previous version, then click on the three dots on the far right for the version you want to revert to. Then select ‘Set as Latest Version’ and then confirm by clicking on ‘Set as Latest Version’.

16. Amend Tag Plan:

Review the change and document which tags or changes are now live. Add some notes if necessary to explain any problems you found and your rationale to help anyone reviewing the documentation at a later date. It will make you look good if you can instantly refer to issues in a few months or years time.

Conclusion:

To enrich Google Analytics data and improve data quality it’s essential to have an agreed process for Google Tag Manager development and testing. Using a performance framework ensures you align customer goals with key metrics. This in turn can be translated into an effective GTM tag plan.

If you don’t carefully create a measurement and tag plan you more likely to miss relevant opportunities to enrich data collection and improve data quality. Such an approach has the additional benefit of allowing you to derive better insights from Google Analytics.

Establishing a well defined process for performance measurement will improve confidence in data from Google Analytics and demonstrate that you have systematic process for GTM development. This will help to enhance the standing of web analytics in your business and encourage discussions with other teams about collaboration and reporting.