Tag Management Does Not Make IT Redundant
Here are a few quotes I found on the web regarding tag management and IT departments:
Relief of IT department bottlenecks – once the Tag Manager is deployed, new tags can be implemented directly by Marketing with no IT department involvement. This is a huge benefit for large websites, where IT is oftentimes a bottleneck.
IT Issues - when you use a TMS like 'Google Tag Manager' you are bypassing the IT department. If anything goes wrong, they can/will put all the blame on you.
Most solutions that require some form of tag management will likely fall within the jurisdiction of the marketing department. By decoupling the tag management process from the IT department greater control is handed to the specifically to the (digital) marketer which is logically where its should be in relation to this process.
Tag management saves money as marketers can swiftly make changes to vital assets without enlisting the help of the IT department. Less people and less time means less cost.
And of course there’s the home page of the Google Tag Manager website itself:
The problem in all these quotes is in the rhetoric. Don’t get me wrong, all of them make a valid point, but they also do their best to antagonize IT as a slow, antiquated, process-driven, bureaucratic, revenue-hating, nerd-monster, whose sole objective is to make life difficult for marketers.
XThe Simmer Newsletter
Subscribe to the Simmer newsletter to get the latest news and content from Simo Ahava into your email inbox!
The all-knowing marketer
Here’s how it goes. Marketer finds Tag Management Solution. Marketer finds out s/he can “create code” using fields and a graphical user interface. Marketer questions the need to ever again consult IT, because marketer knows now how to code. Marketer learns of jQuery. Marketer copy-pastes a bunch of jQuery into a custom tag. Marketer breaks website. IT nerds laugh in glee.
Tag Management Solutions (TMS) are, as I see them, in the gray area between the marketer and the IT department. Sure, they’re self-contained solutions for manipulating tags which the solution creates, and thus there’s usually little cause for concern, if the user doesn’t stray beyond the standard features. A marketer with a basic understanding of page templates, front-end logic, and JavaScript can work magic with a TMS.
At the same time, these solutions inject front-end code onto the site, they manipulate DOM elements, they make use of global variables, and they are often very tightly bound with server-side logic as well (e.g. with complicated eCommerce setups).
An operational scale this huge for any solution cannot and must not make the solution the sole property of any one party. There are many stakeholders involved in any tag management solution setup, and the process should not be botched by some misguided preconception of ownership (“this is my solution, and you are not allowed to touch it!").
Stop antagonizing IT
The key is to stop thinking of IT as a bottleneck, or as something you have to fight against in your day-to-day work. There’s a reason they are process-driven and take a long time to deliberate.
Quality assurance. A word unfamiliar to many marketers. Every large web infrastructure has a QA process in place, and it usually involves parallel environments (development, staging, live), a vigorous routine of testing (automated, unit, manual), diligent documentation, agile methods, punctual reporting, and a maintenance process.
If the marketer does not respect this, even I wouldn’t want them anywhere near the systems I am in charge of. Stéphane Hamel’s post Data Quality: Making It Simpler Doesn’t Mean It’s Simple touches upon this topic, and he makes many important and educational points about the inept marketer.
The important thing is to find common ground, to extend the IT processes to cover the TMS as well, and to work together in improving the usability, tracking, and performance of the website. This is not a one-team job, and with large websites it necessary involves IT as well.
Change the rhetoric
Here are my ten suggestions for making the deployment and use of a TMS more manageable to both the marketer and the IT department. These suggestions involve both parties.
-
Stop using antagonizing terminology (“disregard”, “circumvent”, “make redundant”), and switch to a more communicative and collaborative lingo (“complement”, “facilitate”, “cooperate”)
-
Extend quality assurance to the TMS as well, though it might be prudent to adopt a “lite” version to make things more manageable
-
Train the IT to understand how the TMS works
-
Train the marketer to understand how the IT process works
-
If necessary, make use of tag black- and whitelisting
-
Plan ahead, test and debug thoroughly, document diligently, and if you fail, make sure you fail early
-
Draft a process for going beyond standard features of the solution (DOM manipulation, using global variables, setting and reading cookies)
-
Periodically document and review changes to the website, so that your TMS won’t break if e.g. global libraries are updated
-
Run performance tests periodically on the front-end infrastructure, and fix any bottlenecks caused by the TMS
-
Keep up-to-date on the TMS development
-
BONUS: Have a beer together. Be friends.
As I see it, a good TMS doesn’t replace IT. It complements and facilitates their work, so that the often over-burdened department can focus on more critical things. However, a good TMS also needs a marketer who understands what the TMS is capable of, in good and in bad.
Of course, a change in mindset isn’t warranted solely from the marketer. The IT department must become more sensitive to the fast-moving pace of the marketer’s world, where changes to tagging might have to be done on a daily basis. This necessarily requires a level of compromise in QA, or the adoption of a lighter, more agile version of the front-end development process.
What are your thoughts on this dichotomy between the marketer and the IT department? Do you think a TMS should be solely in the marketer’s domain, or are you empathetic to the IT’s situation as well?
