A lot of people discuss about Tag Auditing and Monitoring. While both are important parts of a comprehensive Tag Governance Policy, it is also necessary to develop organizational processes to ensure proper compliance with the policy. After all, why invest time and money into auditing and cleaning up the tag architecture to just let it get unruly all over again?
The tag implementation process begins with a request to add a new tag. It is important that, regardless of who is requesting the tag be added to the site, several pieces of key information are provided. We will cover the necessary information for a request in the second section of this review.
Once the request is submitted with the required information, it is time to review the tag in question. This needs to include a review from the compliance, privacy, and performance perspectives. Once the go ahead is given from each of the required teams, the actual implementation phase can begin.
For the tag implementation, this should follow the general process outlined by the development team for site releases. Oftentimes the tag implementation process is able to be more dynamic and is not reliant on strict release schedules like site changes are, but a testing and QA process should still be followed. The implementation of tags should have a defined owner, be that an individual in a small organization or a team in a larger one. This is important to ensure tags are not indiscriminately added to the site, leading to governance and performance issues.
For testing, ideally there is a staging/dev environment for each domain. This should contain a unique Tag Management Container instance (either a unique container or a unique environment) specifically for the staging domain. Here the tag can be implemented and tested to ensure that both data is being collected as expected and that there are no unexpected impacts on user experience.
Business/Context Information in the Request
- Pixel Group Name: This should be the name of the tag provider. E.g. Facebook Pixel, Google Analytics, Adobe Analytics, Krux, etc.
- Number of Pixels: The number of unique tags included in the request. For many platforms there will be a general all-pages tag but then additional tags for tracking specific events on a site. This will be true for media tags, analytics tags, and many marketing tags. The number of tags included in the request allows the implementation team to better understand the scope and provide accurate estimates for time-to-deploy.
- Brand: Helpful in a multi-brand organization, this allows you to understand all of the sites/domains on which the tag needs to be implemented. Often you will have one tag type that needs deployed across several sites. Here you can simplify this request all in one process.
- Owner: The business owner of the platform associated with the tag. This should be the individual that owns the relationship with the third-party and is responsible for any clarifications necessary when it comes to deployment requirements as well as future updates to the tag/platform.
- Agency: If the request if from a third-party agency (likely in the case of media tagging), the agency name and primary contact at the agency should be included. Similar to the business owner above, this person will be responsible for future questions about the tag implementation and if the platform is still needed in the future.
- Business Description: A quick description of what the tag is used for and the business value of implementing the platform. This will help in the general Tag Governance Process to see if there are any opportunities to combine efforts across platforms and reduce the technical debt of tags on the site.
- Tag/Pixel Life Cycle: There must be a start date (the date the tag needs to be deployed) and an end date associated with each tag. Many media tags will only need to be implemented for specific campaigns or initiatives. If there is a known end date for these campaigns, then the tag should be removed at the conclusion. If there is not a defined end date then we recommend having the “end date” set to either 12 or 18 months from the time of implementation. This will force a review of the tag at the defined interval and goes a long way in reducing the risk of legacy tags remaining on the site when they are no longer needed.
- Additional Requirements to Consider:
- Legal/Compliance Approval: Depending upon the system being used for the management of tag implementation requests, it might make sense to have a checkbox to indicate legal/compliance review and approval of the tag in question. With the privacy environment becoming more strict seemingly every month this review and approval is imperative for your organization.
- Performance Approval: All tags being implemented on your website should be reviewed for performance impact on the site. At the end of the day, data collection matters little if it hinders the user experience of your site. A checkbox indicating the review and approval of the tag being requested for performance considerations can be added to more easily manage this process.
- Security Approval: As has been seen regularly over the past several years, data breaches are a big issue when it comes to digital security. It is possible for malicious code to be introduced to a site via a javascript tag. Security should review and approve all new tag requests for new platforms being introduced to the site to ensure no malicious activity will take place.
QA Process for Implementation
Following the approval of a new tag to be added to the site, we move into the actual implementation phase. The QA process should follow the framework followed by the site development team. This does not mean that tag deployments must be included in the regular site release schedule. Oftentimes one of the main benefits of utilizing a Tag Management System is the ability to be more dynamic than site updates and reduce the time to deployment. Tags should still be reviewed in the development/staging environments just as on-site changes are and considered as regular site usability testing is happening in those environments.
If you are using a Tag Management System to deploy tags (and if you are not, you should be), we advise clients to have a unique container or environment dedicated to the development/staging environment for all sites. Initial tag configuration should be done here to reduce the risk of any implementation issues affecting user experience and/or data collection. Configure the tag based upon the requirements defined in the technical documentation, publish to the development/staging environment, and do testing to ensure the tag is firing, required data is passed, no js errors are thrown, and user experience is not negatively affected. Using a Tag Auditing Platform such as Tag Inspector can help significantly in this process.
Once the implementation team has published and completed initial QA in staging/development, it is ideal to have someone from the technical team of the vendor being implemented to then do a round of testing and provide final approval. This can help clear up any issues and ensure data is collected as expected from the time the tag goes live.
Following the final approval to deploy, publish the same configuration to the Production environment/container. A final phase that is often overlooked is to then do some final verification and testing in the live environment. Check to make sure the tag is behaving as expected and, finally, sign off on the implementation.
Once fully live, it is important to have a regular review and monitoring process in place to be aware of any future site changes that affect your tag architecture. Here again, a tool such as Tag Inspector can automate and greatly simplify this process.
Documentation for Tag Governance
Following the above processes will get you a very good start to maintaining your Tag Governance Policy. It is also important to get and organize several pieces of documentation throughout the implementation process to stay on top of Tag Governance. These documents will include any contracts with the vendor associated with the tag, technical documentation about the tag, any Data Sharing Agreements in place, the Tag Implementation Request documentation, and any documentation from the review process of the tag/platform.
Keeping all of these documents organized and in one central portal for Tag Governance will make future review and audit processes much simpler. You must always have visibility into the platforms on the site, data being collected, and timelines for removal to ensure the tag architecture stays optimized.
Follow to learn about data analytics, data science & other tag implementation strategies.
Source: Tag Inspector
Also Read:
Migrating from Dtm to Launch | Tableau Consulting Services 