Tag management is a lot like preparing for a long road trip. If you don’t plan your route before you start, you end up driving around aimlessly, hitting dead ends and never reaching the most satisfying destination. But, if you use a map to plan your route before you begin, your travels become easier, more efficient, and more fun.
So how do you create a tag management roadmap?
It’s not difficult when you break the trip down and follow the stops along the route. By following our guide, your tag management journey will make reaching your final destination a much smoother ride.
The five main components of a solid tag management methodology are briefly outlined below.
When setting goals, the aim is to thoroughly answer the question, “What do we want to accomplish?” In order to formulate an answer, you need to start with the end in mind. You need to know what you are building towards, and what types of constraints are being faced in order to inform your approach at each stage of the process.
To begin that process, you must determine what the business requirements are and what work has already been accomplished. In other words, identify the pain points and determine what you currently have to build upon.
For example, if the site already has a solid data foundation for analytics, let’s build on that for other tagging and data collection. Or if your company is bound by certain legal and compliance requirements, let’s build upon those for our policy.
Some goals you may have are: migrating tags to a Tag Management System, improving the performance of your website, building out new marketing or advertising capabilities, compliance and legal clean-up (privacy), and developing a sustainable architecture for multiple sites. We explore these items in greater depth below.
Your goal may be to move all tags to a new Tag Management System. If this is the case, then you need to determine a few things: What are the capabilities and limitations of the selected TMS? What sorts of tags are we moving? Who are the teams that will be impacted and have an investment in this endeavor?
Another potential goal is a new analytics platform or a new corporate initiative into first-party data collection. Maybe the goal is a drive to start folding in more third-party data for better targeting. Or maybe marketing is falling in love with A/B testing. Whatever the main goal of the organization, it’s going to dictate where you go and what you focus on. If it is a new platform, you need to determine what the tags need to ingest and if it is possible to make that happen as it stands right now.
Compliance and user privacy are hot topics currently in the news. New data collection and opt-out regulations in Europe are reshaping the way organizations think about tracking, cookies, and behavioral analysis of users. Your site may have other restrictions that you must adhere to, such as many of the sites for products being targeted towards children. The legal ramifications of what is being tracked are important factors that need to be considered before you move forward.
We often talk to clients who say, “I want to audit my site and know everything that this being tracked and all the data points that are collected”. Our response: “Why?”
You are auditing in order to gauge where you stand in relation to an overall goal. If you don’t have those goals defined, (step one) then we have nothing to “audit”. For example, you wouldn’t audit your compliance process unless you knew what it means to be compliant, would you?
An audit with no frame of reference is busy work. The result is a massive data set and no direction as to what to do with it. You need to know why you are auditing and what is being looked at. Then you can see where you stand in relation to the ideal end state. What you will collect and analyze will depend upon what you are optimizing towards.
Below are some of the things you may want to consider for your tag audit.
There are many different aspects of tags that can contribute to poor site performance. You may want to look at the volume of tags on the site and determine the answers to the following two questions: How large (size) are the requests? How many requests are being sent?
Browsers have limits as to how many concurrent requests can be sent at one time. If you have a large volume of requests (compounded by them having high latency figures) the ‘road’ may be full and cause data collection and site load issues.
Another consideration when looking at performance is the amount of data being sent and received. The one constant limitation for all users of your site is going to be bandwidth. You can determine what type of device/connection is used by most of your users and optimize to that. You’ll also want to determine if tags are blocking the load of the page and how much CPU is being used by different platforms.
Before you can migrate tags, you need to make sure you understand the following parameters: What tags can be loaded in our TMS? What needs to still be loaded from the page source itself? Where should they be on each page?
Based upon these considerations, you’ll want to then map out what data points are being collected and analyzed as a part of the audit process. You can then fill in the blanks and determine where you stand and next steps.
By defining the goals in step one and understanding what is being optimized for, we can now analyze the data points most relevant to accomplishing your goals. Start with a Tag Inventory to identify the different platforms on the site. From there, determine how each is playing into your desired outcome. If it’s data collection for analytics, analyze the data points being collected and actions being tracked by those tags. If it’s performance, look at the effects of each tag request on page load time.
You need to determine what compliance means for your business. Questions that are important to answer include:
Depending on the answers to the questions below, you’ll need to be looking at different aspects of the audit.
A Tag Policy is a general documentation of what tags are allowed and required to be on the site. This starts by looking at the tag inventory generated in the audit process. I highly recommend that you focus initially on the tags that you can control (the tags that are loading either from the source or directly from the TMS). Below, we have laid out the three steps to creating a tag policy. The end result of creating a Tag Policy is a document that outlines the “rules” of the site. These are your governing principles upon which the architecture is built.
Determine what tags need to be removed outright. This could be old marketing tags from platforms that are no longer in use. The tool set changes as different initiatives are pushed, the team changes, and media campaigns or partners are swapped. Tracking for each of these is always in flux and needs to be cleaned up or streamlined.
Determine what tags on the site are not loading in the manner in which they are supposed to. Maybe it’s a re-marketing platform that should be managed within the TMS but is loading from the page. Maybe it is an analytics platform that should be on every page of the site. No matter the reason, there are going to be changes; define what the behavior “should” look like so you can then begin fixing.
This where you’ll start looking at the performance of tags and how critical the functionality is to the business. You’ll also want to start considering if different teams are using different platforms for similar purposes. If so, why use two different partners for re-marketing? Instead, you need to determine how efforts can be combined and efficiencies can be created in the tag architecture.
Piggybacking is when one tag on your site is loading within others. This can have implications for performance as well as compliance.
The architecture is the nitty-gritty of the tagging and data blueprints. In the Tag Policy, you defined the different platforms that should be loaded and where. Now you map out the data requirements we need for each platform.
An Important Note: We call this the “architecture” because it is both art and science. There are requirements, yes, but also art in the sense that it can be “clean” and built in a way that is best suited to the unique business.
Most often this is going to be your digital analytics platform. Every site is going to be using something like Google Analytics, Adobe Analytics, Coremetrics, etc. to collect visitor behavior on the site. These platforms track all visitor interactions, collect all of our acquisition information, and more.
The great thing is that there is usually plenty of documentation for the existing analytics platform(s). It is not uncommon to see an analytics master guide or solution design document that is almost a hundred pages in length. Leverage this document and layer additional data requirements for other platforms on top of this.
Once you have all of these data requirements, you need to start thinking about where these data points will be surfaced and made available for use in the various tags.
Next, you will want to architect your data layer. Begin by translating your data requirements into a data layer architecture that works best for your analytics platform.
Then fold the additional requirements for other third-party tags into the data layer documentation and finally build out the TMS in accordance with the data layer specifications.
While the data requirements, data layer, and TMS configuration are 90% of your architecture, there are some other considerations. For example, some platforms may need to be loaded on the site or configured in your eCommerce platform. The implications and requirements for each of these will be specific to the platform. In many cases, the tracking that is done for these platforms can be managed within the TMS while the actual functionality is run on the page.
This all falls under the Tag Architecture. Creating the data blueprint will go a long way in both simplifying initial implementation but also creating a sustainable environment for all future tag requests and implementations.
Now that you have set your goals, completed a thorough audit, created a complete tag policy, and designed your architecture it’s time for implementation and maintenance. There are three parts within the maintenance loop: Implementation and fixes, testing and validation, and alerting for issues as they arise during ongoing maintenance and monitoring.
The first step is to do the full implementation. The requirements created in steps 1-4 are now given to the development team and actually implemented.
Initial implementation needs to be a solid foundation that you can build on top of as new functionality is rolled out and requirements change. There can be no “band-aids” applied during implementation.
Future iterations of your tag management should be enhancements and fixes and it is important to keep this loop aspect in mind when designing and implementing. Fixes will occur when things change in the back-end architecture and requirements of the business change. The one constant in business is constant change, so we need to be ready to address these new requirements and continue to build upon the solid base we created during design and implementation.
You are testing two things here: First, you’re checking results against the tag policy. Second, you are testing and validating against the tag architecture and data requirements.
When validating the tag policy, you need to ensure that only allowed tags are loading on the site. You also need to ensure that required tags are always loading on the correct pages. Finally, you need to ensure all data that should be collected is always being collected.
Ongoing monitoring requires that a sustainable monitoring process is in place. A “regular audit schedule” is insufficient and not a truly proactive approach to monitoring. Regular audits can end up causing more headaches than they fix, so make sure the monitoring process is continuous and addresses issues as they arise.
Addressing issues as they arise is critical and therefore it is important to ensure the resources are available when needed. There is nothing worse than realizing there is an issue by not having what you need in reporting when the business needs it most. Therefore, it is important that all relevant parties understand the process for communicating issues and which resources are responsible for fixing those issues.
The alert process requires that the appropriate resources are proactively being made aware of the issues that arise in the ongoing testing and monitoring. It is much easier to be made aware of issues as they occur and know the resources are in place to perform the fixes as opposed to being reactive.
The alert process is the way to ensure the testing and monitoring loop remains closed. Alerts lead to fixes and implementation, ensuring the cycle remains continuous and proactive!