Menu

Tag Management Does Not Make IT Redundant

Just by the virtue of adding a tag management system like GTM, you do not have the right to circumvent your organization's IT processes. Successfuly tag management incorporates the IT into the development work.
Simo Ahava in Analytics on #Google Tag Manager , #it department , #tag management solution Non-AMP version

Here are a few quotes I found on the web regarding tag management and IT departments:

Original text here

Original text here

Original text here

Original text here

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.

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.

  1. Stop using antagonizing terminology (“disregard”, “circumvent”, “make redundant”), and switch to a more communicative and collaborative lingo (“complement”, “facilitate”, “cooperate”)

  2. Extend quality assurance to the TMS as well, though it might be prudent to adopt a “lite” version to make things more manageable

  3. Train the IT to understand how the TMS works

  4. Train the marketer to understand how the IT process works

  5. If necessary, make use of tag black- and whitelisting

  6. Plan ahead, test and debug thoroughly, document diligently, and if you fail, make sure you fail early

  7. Draft a process for going beyond standard features of the solution (DOM manipulation, using global variables, setting and reading cookies)

  8. Periodically document and review changes to the website, so that your TMS won’t break if e.g. global libraries are updated

  9. Run performance tests periodically on the front-end infrastructure, and fix any bottlenecks caused by the TMS

  10. Keep up-to-date on the TMS development

  11. 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?