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 our learnings.
If you are a GTM implementation specialist looking to start working with DTM. Here are things to be aware of when it comes to 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, and it’s possible to restore a version/revision.
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, and 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, it increases the chance that the TMS is marked as performance/targeting rather than necessary if cookies are set on the user’s machine.
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 the use of workspaces/libraries, whereas GTM makes it optional.
DTM has better access controls around each environment, which is something I wish GTM would add! However, using 2 GTM accounts for LIVE and DEV/STAGING provides a work-around for the lack of access-controls at 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 option is to either 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 version/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 GoogleSheet, 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 return the wrong value, so I used a resource replace tool instead
- https://chromewebstore.google.com/detail/resource-override/pkoacgokdfckfpndoffpifphamojphii
DTM uses a console log output, where GTM use a live pop-up window.
The GTM debugger is significantly easier to use and this give it a MASSIVE advantage when QA testing.
Interface and Speed to use
DTM feels like the GTM v1 interface. Its very clunky, there is no option to delete rules/tags and hence dead tags 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 5mins to generate a build, push the build to Staging, generate again. Push to Production and generate again. This might take only 15min but when doing frequent changes this waiting time add-up. In GTM it less than 2mins to push from DEV >> PROD.
The inability to re-use triggers or blocking rules, and having to replicate Tags in multiple place is a real drawback of DTM. It effects both tag governance and site speed and result in a bloated container/property.
I “took for granted” GTM ability`s – to see all variables and tags linked to a variable. The inability to see this in DTM is a real pain, especially for things such as a FB accountID.
Summary
I found it surprisingly easy to move from GTM to DTM, as most of the logic is the same in both TMS systems.
The bits I did encounter 2 issues – I incorrectly read the DTM RegEx trigger rule as OFF when it was ON, a grey-on-grey ghost button did not help! Also, assigning a workspace/library to development is not necessary in GTM and this this was non-natural, but I got used to it.
I was perplex by DTM targeting enterprise, but at the same time not supporting merge workspaces. This resulted in a bottleneck and tag having to be restored from PROD in order to re-build the library. Also, the failed to build library issue does not exist in GTM, and is has better support for accept/decline 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 more 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 1 small feature in DTM which I wish GTM would do. That is… static links for Tags & Triggers. When doing TMS audits in a GoogleSheet – it useful to link directly to the Tag within GTM. DTM does 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 work-around which is to bulk export a container snapshot into a new container, set this to container to read-only mode with no active workspaces and then link to the Tags & Triggers there. This works because its the workspace ID in the GTM URL that cause 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 Experience Cloud extension, but this did not support cookieless ping required by Google.
Hence, my conclusion is that GTM is still the the better TMS, and it alot easier for marketers to use. Thus, my recommendation to the client; was either
- wait for Adobe to introduce a V3 interface for DTM
- move all non-Adobe tags from DTM to GTM and then set GTM as the primary TMS with 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