The short answer is yes.
We’ve talked before about how important it is to have a clearly defined methodology for how you and those in your company will use your tag management system (TMS). We’ve worked with clients who didn’t take that step and what happened was they ended up developing a point solution approach. They created a new deployment condition or rule for every new element of data they wanted to collect or marketing vendor they wanted to deploy.
Un-optimized set ups like this lead to management nightmares and are very difficult to maintain. Instead of rehashing a conversation we’ve already had about optimizing how you use your TMS, this conversation is meant to warn you of going too far to the other side and over optimizing the use of your TMS.
One condition to rule them all.
We’ve recently worked with a couple of clients where their analytics implementations were deployed through a TMS and when we started looking, we saw that there was a minimum number of rules to collect data for fairly robust analytics reporting. As we dug deeper we found that each rule was designed to handle multiple conditions and variations.
On the surface the analytics implementation looked clean and streamlined. It looked easy to manage as part of a TMS configuration that was also responsible for deploying marketing vendor tags. As we began to look under the hood, however, it became apparent that it wasn’t very clean. These few rules relied heavily on custom JavaScript to evaluate what the visitor was doing and generate the required analytics tracking. These rules were also rife with hacks in order to limit the number needed.
Another type of “unmanageable”
The problem we found with this methodology was that the rules relied very little on the functionality of the TMS itself and primarily on the logic in the custom code. This presents issues that make this set up just as unmanageable as the scenario I laid out at the start.
The goal of a TMS is to lift the burden from development resources, however, only those with a development background could make modifications, additions, or solve issues. To add to that, these clients didn’t have developers familiar with the analytics vendor, so having them make updates was further complicated.
The average user of a TMS was not able to manage the implementation, defeating the purpose of the system. In the end, the TMS didn’t really solve the client’s business problems, it just shifted them from one system to another. It’s like a pendulum moving from one side to another.
As you’re designing your TMS methodology, make sure that you’re not pushing the pendulum from one extreme to another.
[author] Jim Driscoll [author_image timthumb=’on’]http://i2.wp.com/33sticks.com/wp-content/uploads/2015/08/9239556033_a7e5c89228c15928b3f0_192.jpg?w=192 alt=”Jim Driscoll”[/author_image] [author_info]Jim is a senior consultant on the Solutions Engineering team at 33 Sticks who brings 15 years of solution design and technology implementation experience, with 9 years focused on web analytics and digital marketing technologies. He is a fitness enthusiast and avid sports fan. He also thinks he can play golf.[/author_info] [/author]