The Definitive Tag Management Guide

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, efficient, and fun. So how do you create a tag management roadmap?

An Overview

The five main components of a solid tag management methodology are briefly outlined below.

  • Goal Setting

    This is where you define what you want to accomplish. Unless you determine where you want to go before you begin, you may run out of time and money before you reach your destination.

  • Tag Audit

    This is an assessment of both the technical and business states. The task at this stage is to answer the question “what does the current landscape look like?” so you can determine how to move forward. In order to map the current landscape, you will need to understand: Where am I now? What tags are we dealing with? How are the tags loading? What data is being collected? What data do we need? What is the goal of our website? Which team needs what technologies?

  • Tag Policy

    For the platforms we are working with, we need to determine what should be happening. Using the results of the Tag Audit as a foundation, plot out the ideal tag structure. Define the tags that are allowed, the tags that are required, and then how and where each should be loaded. A typical outcome of this exercise is many instances of team members asking “what’s that platform?” and “that is still on the site?” If something isn’t in use or its origins are unknown, plan to remove it!

  • Architecture

    Now that you have defined the tags/pixels that should be on the site, it’s time to dig deep into the requirements by asking: What data is necessary? What interactions should be tracked? Do we make everything that we need available? After defining the data points required for each tag, you need to architect a data layer to make it all possible. We will get further into the data layer in subsequent guides, but think of it as a toolbox where all the tools needed for marketing, media, and analytics (data) are organized for use. Define what these requirements are and map them all out for implementation.

  • Maintenance Loop

    This stage is broken down into 3 steps:

  • Implement + Adjust

    Where we put our architecture in place! In the first go around, this may require building the entire house. In the future, it will be adjustments for new requirements or small fixes, kind of like redecorating or fixing any leaks in the roof.

  • Validate

    Test, test, test! We want to make sure everything we have implemented is working and collecting data as intended.

  • Alert

    The implementation of ongoing monitoring. There should be a process in place for ongoing validation of key items. Site changes are always happening, so you need to be aware if these have unintended effects on data collection. With full automation, alerts are configured to let you know when anything breaks. When these alerts are raised, we loop back to the implementation and adjustment stage to fix, test, and monitor again.


Goal Setting


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.

  • Tag Migration

    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?

  • Performance Improvements

    Organizations are starting to realize that the cavalier attitude they’ve had for years towards tags and javascript on their site is having a negative effect on the user experience. So, if your goal is to really look at the platforms being used and seeing where you can consolidate efforts to clean up the architecture, this will affect the way you approach the process and information going into that policy and architecture.

  • Building Out New Capabilities

    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.

  • Privacy: Compliance + Clean Up

    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.


Tag Audits

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.

Tag Migration

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.

Privacy + Compliance

You need to determine what compliance means for your business. Questions that are important to answer include:

  • Can only certain data points be collected?
  • What is included in the privacy policy?
  • What kind of data sharing agreements are in place and with whom?

Data Collection

Depending on the answers to the questions below, you’ll need to be looking at different aspects of the audit.

  • What data points are necessary and are they being collected? What data points are shared across different platforms? What are the most critical platforms that should be executed first?
  • What interactions need to be tracked? Do we need to be looking at certain user actions on the site, certain pages, how is the site broken up?
  • Are there other tags that are slowing this data collection process and need to be de-prioritized?

Tag Policy


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.

  • Step One

    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.

  • Step Two

    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.

  • Step Three

    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.

  • A Special Note on Piggybacking

    Piggybacking is when one tag on your site is loading within others. This can have implications for performance as well as compliance.You will need to determine if piggybacking is known and then ask if it is necessary. If you find a really poor offender, what should be the remediation: Remove it outright or get the data sharing agreements and Privacy Policy up to par? This will depend upon the value of the platform.


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.


Start with the Neediest of All Your Platforms

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.

The Data Layer

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.

Other Considerations

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.

The Maintenance Loop


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.

  • Implementation and Fixes

    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.

  • Testing and Validation

    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.

  • Alerts

    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!

Now that you have the complete roadmap, create an account to get on the road (and don’t forget to enjoy the ride)!