When to use and when NOT to use DTM

When to use and when NOT to use DTM

A while ago, a customer requested a call with me to discuss one issue. Usually, I get more technical questions, but this time, he wanted to have my input regarding something completely different. The developers had realised that they forgot to include a JavaScript library in the website and they could not add it immediately, due to code freeze. They thought of an alternative solution: load it through DTM. My customer, from the marketing department, was not sure whether this was possible or acceptable and, therefore, wanted to know my point of view.

I must admit that, initially, I was a bit perplexed and did not know exactly what to reply. This was the first time I received this question and I had never thought about it. However, I quickly came with a proper answer and this is what I suggested. It must be noted that this is my personal perspective, not Adobe’s.

In order to reply to this question, you must first think about governance. Who manages DTM? Who owns DTM in the company? What is the purpose of using DTM? I think that DTM is a marketing tool, managed by the marketing department, used to deploy marketing tags in a website. So, if the new piece of code that needs to be added to DTM is requested by the marketing department, then it will probably make sense to use DTM; on the other hand, if it is the IT department requesting the addition, I would recommend against using DTM for it.

Technically, it is possible to deliver any JavaScript (and even HTML) through DTM. However, the fact that it is possible does not mean that it should be done. Think about the following questions when adding a piece of JavaScript that was not requested by the marketing department: who owns that piece of code? who updates it? who fixes it if stops working? who is to blame if it is inadvertently removed? what happens if DTM is removed? The marketing team will not want to take any responsibility of code they do not even understand.

So, to summarise, from my point of view, here you have some cases that are suitable for DTM and cases that are not:

  • In DTM:
    • Web Analytics tags (like Adobe Analytics)
    • Optimisation code (for Adobe Target, for example)
    • DMP tags (AAM also has a module in DTM)
    • Third party re-marketing tags
    • On-site surveys
  • Not recommended in DTM:
    • Generic JavaScript libraries (for example: jQuery)
    • Website functionalities (chats, UI effects)
    • Code that needs to be executed in a very specific location of the page (i.e. not at the top or the bottom)
    • CMS libraries

Can you think of any other case that would fit in one or the other case? If so, please, leave a comment!

2 thoughts on “When to use and when NOT to use DTM”

  1. I’ve run into the same situation a number of times, where IT needs a last minute bit of “help”, be it during a code freeze or right after a major build. My view is go ahead and use DTM, at least as a short term patch, until IT can address it properly. For one it gets the immediate issue resolved, thereby preventing further complications which is a company benefit. Second, I’ve found it a fantastic way to enhance our analytics team relationship with IT. I’ve used DTM to make some short term patches that have saved our IT group lots of late nights and expenses trying to scramble for an emergency build, instead allowing them to handle the changes in a timely, orderly manner at a later point. I’ve also made fixes which benefits our customers immediately, instead of them having to continue to see issues until IT could put a new build out.

    In general I agree with your list of when to use DTM. But I don’t agree that DTM is necessarily a Marketing tool; that depends upon the organizational setup. In our company the analytics group owns DTM, and we are not part of Marketing. For us it’s more of a code deployment tool to be used for certain situations and needs, which mostly involves marketing focused stuff. If we can occasionally use it to help out other parts of the company, be it IT or someone else, until a better solution can be put in place then all the better for the company and our team.

    • I agree that as a “last minute bit of help”, DTM can be used. This can even be positive, as solving IT problems can later help getting IT support in other matters. However, I would be very concious of the possibility that short term patches end up being approved code, i.e., never moved to the right place. My other concern would be governance: someone needs to take ownership of the tool and if you add code that you do not understand, who maintains it? who fixes the errors? who is responsible in case it breaks something? All I am saying is that all of these needs to be very carefully considered.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.