Creating a Development and Testing Process for Google Tag Manager
A Step-By-Step Guide to Google Tag Manager Development & Testing
Google Tag Manager (GTM) is a powerful and free tag management platform that 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.
As 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. If you have the paid version of Google Tag Manager with Google Analytics 360 you will have built-in workflow management functionality and so you have an advantage that changes can be more easily managed online.
1. Define your vision:
Outline your vision and your strategy for achieving this by creating a web analytics plan. The plan should go into the detail of how you can improve insights, data quality and ultimately your conversion rate. Your analytics strategy should be closely aligned to the vision you have agreed with senior stakeholders. This might include items such as migrating to Google Tag Manager, creating tags for important events in user journeys, implementing enhanced e-commerce, creating automated reports in Data Studio or cross-domain tracking.
Apart from giving you a clear direction, the analytics plan should act as a guide to what you need to change or create in GTM. This enables a discussion around priorities and 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 Google Tag Manager Tag Plan:
If you don’t already have a tag plan you need to create one now so that you can document your Google Tag Manager set up and the changes you make going forward. Documenting your GTM 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.
Create a tab for the following:
- 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.
- The testing GTM tab is where I 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 GTM container. It means that we don’t have to rely on our imperfect memory for justifying why a tag or other change was implemented if we need to review a tag in the future.
3. Account Permissions:
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:
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, but container level changes can be daily and sometimes even more often than that. Only give the ability to publish to a few selected 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 as 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 already mentioned, plus the rights to publish changes. Publishing rights should be limited to only a few senior to avoid changes going live until they have been fully tested and approved.
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 manage submits changes to be published after the analysts get them approved. What’s important is that you have a clear and easy to understand 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 agreed a planned change you should add a description and other relevant details of any new tags to the GTM 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 closely aligned to the live environment. Often this means using UAT rather than DEV or SIT, but 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 and will 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 being implemented for each environment.
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 planned 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 version.
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 be presented with the conflict resolution tool which forces you to make logical choices.
7. Plan your change:
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 required 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 GTM 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 and a GA – Pageview tag should be displayed 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.
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 refreshed 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 has been implemented or it has been changed for some reason you will need to go back to your developer to get this corrected.
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 unexpected 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 and so be careful to check that the workspace only contains your approved changes.
If necessary, 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 all the approved 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 the change implemented. 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 as expected. 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 GTM click on ‘Version’ on the top navigation tab and this will display all the versions of the container. You can click into the 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 encountered 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.
To enrich Google Analytics data and improve data quality it’s essential to have an agreed process for GTM development and testing. This encourages you consider what your vision for web analytics should be and how you plan to achieve that vision. If you don’t consider these issues you are likely to lack focus and will miss 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.
Such an approach 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.
Thank you for reading this post. Please leave feedback below on this post so that I can understand any questions or suggestions you may have.
- About the author: Neal provides web analytics and CRO consultancy services. He has worked in many sectors including financial services, online gaming and e-commerce retail. He has helped brands including Hastings Direct, Manchester Airport Group Online, and Assurant Ltd to improve their digital marketing measurement and performance.
- Neal has had articles published on website optimisation on CXL and Usabilla.com. As an ex-market research and insight manager he also had posts published on the GreenBook Blog research website. If you wish to contact us please send an email to email@example.com. You can follow us on Twitter @conversionupl, see Neal’s LinkedIn profile or connect on Facebook.