Adobe Launch vs Google Tag Manager: GTM vs DTM
Background: We recently worked on a project to migrate Search Ads 360 (SA360) tags from Adobe Launch (DTM) to Google Tag Manager (GTM). It was a refreshing change to learn a new tag management system (TMS). Hence, we wanted to share what we had learned.
If you are a GTM implementation specialist looking to start working with DTM, here are things to be aware of regarding Adobe Launch vs. Google Tag Manager.
Different Terminology
- Workspaces = Libraries
- Trigger = Rule (and Blocking Trigger = Exception Condition)
- Tag = Rule Component
- Variables = Data Elements
- Templates = Extensions
- Events = Direct Calls
- Tag Priories = Rule Component Sequencing
- dataLayer = digitalData || adobeDataLayer
- Versions = Rule Reversions (more about this later)
- Containers = Properties
Instead of {{Variables}} you need to use %Variables%.
Also, console.log(“GTM msg: xxx”) becomes _satellite.logger.log(“DTM msg: xxx”).
Different Methodology
DTM is based on Rules (which contain Tags/RuleComponents).
GTM is based on Tags (which contain Triggers/Rules).
This is kind of “upside down” and takes a bit of getting used to! Also, there’s no tab on the left side to access tags – they can only be found by drilling into a Rule, or searching for a Rule Component name.
Change control is done at a Rule Level rather than at a snapshot of Tag/Trigger/Variable level. Hence, each change to a Rule creates a version/revision, which can be restored.
Unlike GTM, it’s not possible to bulk restore a bunch of Rule changes in one go – only one-by-one in each Rule 🙁
Different AutoEvents & Native setCookie
To use DTM’s autoEvents, you need to install the Core Extension. This then enables listeners.
DTM autoEvents are more extensive than GTM, with onChange, field selectors and HTML5 video. However, a native YouTube listener was notably missing, and the HTML5 video listener attaches 3 events for play, pause, and stop – rather than do this in 1 listener, which would be more JS efficient.
DTM has a native setCookie and the ability to change the scope of dataLayer fields to page/session/cookie, which was nice. However, I found this feature misused in the container that I inherited. A OneTrust consent cookie was accidentally set to session scope, and a Pathname variable on AJAX was incorrectly set to page scope rather than no-scope. Also, if cookies are set on the user’s machine, it increases the chance that the TMS is marked as performance/targeting rather than necessary.
GTM does have a native setCookie within sandbox JS – it’s just not a native function.
Publishing flows
Both DTM and GTM support workspaces/libraries. DTM requires using workspaces/libraries, whereas GTM makes it optional.
DTM has better access controls around each environment, which I wish GTM would add! However, using 2 GTM accounts for LIVE and DEV/STAGING provides a workaround for the lack of access controls at the environment level.
The Adobe Analytics template automatically routes traffic into Development, Staging and Production, which the GA4 tag should natively do (rather than using a lookup table for accountID per environment).
DTM requires workspaces/libraries to be assigned to make it active/inactive when in Development, which is a strange concept! Furthermore, deploying from Development >> Staging or Staging >> Production causes the workspaces/library to be automatically deactivated on Development, which means that if multiple Analysts are working on Development, then its necessary to do a check-in/check-out process, which is a pain! GTM does not have this issue.
I was surprised to learn that it is impossible to restore a version/library in the past! The only options are to create a new library and individually restore each rule or use comment/uncomment to activate/deactivate code. Also, DTM only allows rollforward/backwards of the past 5 published versions/libraries. GTM allows any version to be deployed, even ones from 5 years ago.
Auto-configuration
GTM has a fantastic bulk import feature and allows tags to be merged to build a set-up rapidly.
DTM does support 1-click coping of Rules and linked components between Containers/Properties, but the lack of bulk import is a real drawback. Furthermore, GTM supports this using selective export and import, so DTM has no advantage here.
I was able to find a 3rd party tool that bulk exported the set-up to a Google Sheet, but there was no API to send this data back in 🙁
- https://workspace.google.com/u/0/marketplace/app/aep_launch_inspector/444323512075
- https://www.simoahava.com/tools/gtm-tools-by-simo-ahava/#how-to-get-it
Debugging
Both GTM and DTM have Chrome extension to help with debugging:
- https://chromewebstore.google.com/detail/tag-assistant-companion/jmekfmbnaedfebfnmakmokmlfpblbfdm
- https://chromewebstore.google.com/detail/launch-and-dtm-switch/nlgdemkdapolikbjimjajpmonpbpmipk
- https://chromewebstore.google.com/detail/deprecated-tag-assistant/kejbdjndbnbjgmefkgdddjlbokphdefk
- https://chromewebstore.google.com/detail/adobe-experience-platform/bfnnokhpnncpkdmbokanobigaccjkpob
When working with 2 properties/containers, I found the launch-and-dtm-switch chrome extension returned the wrong value, so I used a resource replacement tool instead.
- https://chromewebstore.google.com/detail/resource-override/pkoacgokdfckfpndoffpifphamojphii
DTM uses a console log output, whereas GTM uses a live pop-up window.
The GTM debugger is significantly easier to use, giving it a MASSIVE advantage when QA testing.
Interface and Speed to use
DTM feels like the GTM v1 interface. It’s very clunky. There is no option to delete rules/tags, and hence, dead tags are often shown when searching. Also, I found myself frequently filtering for active tags when this should be the default.
Deploying tags Development >> Staging >> Production is a slow process, as it takes 5 minutes to generate a build, push the build to Staging, and generate again. Push to Production and generate again. This might take only 15 minutes, but this waiting time adds up when doing frequent changes. In GTM, it takes less than 2 minutes to push from DEV >> PROD.
The inability to reuse triggers or blocking rules and the need to replicate Tags in multiple places are real drawbacks of DTM. They affect tag governance and site speed, resulting in a bloated container/property.
I “took for granted” GTM’s ability to see all variables and tags linked to a variable. The inability to see this in DTM is a real pain, especially for things like an FB account ID.
Summary
It was surprisingly easy to move from GTM to DTM, as most of the logic is the same in both TMS systems.
I did encounter 2 issues. I incorrectly read the DTM RegEx trigger rule as OFF when it was ON, and a grey-on-grey ghost button did not help! Also, assigning a workspace/library to development is not necessary in GTM, and this was non-natural, but I got used to it.
I was perplexed by DTM targeting enterprises but, at the same time, not supporting merged workspaces. This resulted in a bottleneck and tags having to be restored from PROD in order to rebuild the library. Also, the failed-to-build library issue does not exist in GTM, and it has better support for accepting/declining merge changes.
I did not find any killer features in DTM, and even the more advanced triggers can be replicated using jQuery libraries in GTM. Also, community templates such as OneTrust were more advanced and recent in GTM than DTM, and the inability to fork a community template was sadly missing. GTM has a much larger community template library and free-to-use API plugins.
There was one small feature in DTM that I wish GTM would do: static links for Tags and triggers. When doing TMS audits in a Google Sheet, linking directly to the Tag within GTM is useful. DTM supports this, and when migrating tags, I added the URL link to the equivalent DTM rule in the GTM trigger as a TMS comment to improve the cross-TMS paper trail.
GTM does have a workaround: bulk export a container snapshot into a new container, set this container to read-only mode with no active workspaces, and then link to the Tags & Triggers there. This works because the workspace ID in the GTM URL causes URL links to fail. Thus, in DTM notes, I just had to use the GTM tag or trigger name and a URL link to the GTM historic snapshot rather than the live GTM container.
Newer features, such as consent mode, are not natively supported in DTM. There was a section for consent categories within the Experience Cloud extension, but this did not support the cookieless ping Google requires.
My suggestion
Hence, I conclude that GTM is still the better TMS, and it is much easier for marketers to use. Thus, my recommendation to the client was to either:
- Wait for Adobe to introduce a V3 interface for DTM.
- Move all non-Adobe tags from DTM to GTM, then set GTM as the primary TMS and DTM as the secondary TMS.
I welcome your comments below…
- GTM Tag Diagnostics: Check the Quality of Your GTM Container - 03/07/2024
- Adobe Launch vs Google Tag Manager: GTM vs DTM - 01/07/2024
- The Future of GA4: Where do we go From Here? - 25/06/2024