Adobe’s Dynamic Tag Management (DTM) is one of my preferred tag management system (TMS) tools. It’s simple, no frills design is a refreshing change from the competition.

I appreciate the ease of use, but, above all, I love the flexibility it offers.

Out of the box, DTM provides seven integrated analytics tools and services:

Basic implementation of these integrated tools is simple, and can often be performed by less technical users, and those who would rather avoid the task of working with JavaScript. Moving beyond a ‘basic’ implementation will no doubt require additional technical skills, and perhaps even the occasional foray into coding with JavaScript.

For me, however, moving beyond the basic implementation approach is where the draw of DTM lies. Working outside of the integrated tools enables me to get the most out of DTM and the flexibility mentioned above.

Consider the following scenarios:

• Your company is interested in tag management, but hasn’t fully ‘bought in’.
• You are convinced that a TMS is the right direction for your site, but you aren’t sold on a particular platform/vendor.
• Your company is thrilled about moving to DTM, but wants to move quickly, and replacing existing business logic from your analytics JavaScript library with custom rules and data elements is too big of a task to take on right now.

The common concerns in the above scenarios are speed to market and code portability. Both of which are extremely valid. In the gotta-have-it-now world we live in, the importance of being flexible and agile cannot be overstated.

This is where I find benefit in the customizable nature of DTM.

Rather than configuring an integrated analytics tool (if using Adobe Analytics or Google Analytics), DTM allows you to create a custom page load rule to deploy your analytics logic. You simply copy and paste your existing JavaScript library into the “JavaScript / Third Party Tags” section of the rule, and you’re in business!

This approach provides a number of benefits:

1. Portability – If you already have a custom analytics JavaScript library on your site today, it can be copied and pasted into DTM. If, for some reason, you determine DTM isn’t for you, your time investment has been minimized.
2. Speed to Market – The number of custom DTM data elements and rules – Page Load, Event Based, and Direct Call – is limited, eliminating the need to translate existing logic into tool-specific features.
3. Flexibility – It’s DTM, so you still have access to all of the awesome features! You can control timing of when your analytics logic loads and executes. You can break your custom analytics library into DTM data elements and rules when/if you are ready. You can begin loading other tags on your pages… The list goes on!

There are some drawbacks, of course:

1. Library Management – The option to allow DTM to manage the core analytics library (the obfuscated s_code / AppMeasurement logic) is not available with this approach.
2. Content Loading – Anywhere your analytics logic loads, it ALL loads. So, if there is page-specific, or action-specific logic in your analytics library, it will execute on all pages loading the library. (A standard DTM implementation would allow you to segment out such logic and specify exactly when and where it should load.)
Personally, depending on your needs, I feel the benefits of this approach greatly outweigh the drawbacks. Is it right for every implementation? Certainly not. However, it might be right for yours!

This is one way I like to DTM. How do you DTM?

To learn more about DTM and Adobe Analytics check out our Adobe Analytics Implementation Service.