Adobe DTM VS Launch
Adobe DTM VS Launch.
As you know, Adobe’s Dynamic Tag Manager (DTM) was replaced with Adobe Launch. One question you’ll want answered before migrating is: “What’s the difference between Adobe Launch vs. DTM?” The short answer: A lot… and at the same time not much.
Summary of Changes
Things are different, but parts are similar enough to where if you are a seasoned Adobe DTM practitioner you’ll have no trouble picking it up. I wrote up a list in my Early Thoughts post from the 2017 Adobe Summit, but that was before I got my hands on the actual platform. If you were a power user of DTM, I recommend checking out the Adobe Launch Cheat Sheet for updated console commands and some technical comparisons.
The concept of Companies and Web Properties remains roughly the same, at the moment. For each company, you still have a set of web properties.
RUMOR MILL ALERT
I have heard some folks close to the platform acknowledge the concept of web property inheritance. This concept suggests someone could create a parent web property that sets a certain framework of rules and then a set of children properties that inherit that of the parent. This is NOT a thing yet, though. It’s currently just a rumor that I am propagating… but would love to see that become a reality at some point!
The image above roughly shows the menu differences between Adobe DTM and Launch (8/2019 update: The Adapters menu option name has since been changed to Hosts). Embed options have split into 2 separate menu items… Adapters and Environments. This is because an Adapter determines where a library is hosted – which is totally different from defining what working environments your website has.
Publishing consolidates History and Approvals. This makes sense because each time you approve something, you end up having to go to the History page to press the Publish button… despite Approvals/History both being part of a publishing workflow.
Rules are split out into Rules and Data Elements. This was done because… you know… Data Elements are not rules.
Extensions were added to Adobe Launch, arguably delivering the biggest paradigm shift seen from DTM to Launch. To COMPLETELY trivialize it, Extensions are where you add and configure your analytics tools (you used to do that on the Overview page).
If you want to build out rules in Launch like you do in DTM, you can. It’s the same… but different… but still the same. Event-Based, Page Load, and Direct Call Rules still exist but have been consolidated into: “Rules”. A page load is an event, a direct call is an event, and so is a click – so why not just select them from an “Events” list? Rules are now set up like an “If… Then” statement: “If this happens, then take this action.” This frames rule-building into a context we’re all familiar with (I hope).
Outside of that, the interface should look somewhat familiar. Here they are side-by-side:
Pretty straightforward, right? Events are set up under Events, Rule Conditions are set up under Conditions – there are now rule Exceptions which will make life a LOT easier for everybody: “I want it to fire everywhere except for [here]” (8/2019 update: Rule Exceptions have been consolidated into Conditions, where you can select whether the condition is “Regular” [include] or “Exception” [exclude]). For the DTM users who remember toggling the “Apply Handler Directly to Element” settings, they’re gone: check out Aaron Hardy’s write-up on Medium for more details on that. Tool templates have been consolidated into “Actions”. That’s where you’ll configure Adobe Analytics, Target, Custom JS/HTML, etc.
Like I said before – you can keep operating like you always have in DTM. However, there is some game-changing modernization that will make your life MUCH easier.
- Multiple Event support
- Condition Exceptions (we reviewed this)
- Action sequencing
Multiple Event Support
With DTM, there’s no way to trigger something like a pageview on a single page app when the page loads OR when a URL history change event occurs. Adobe Launch solves this by letting you string together multiple event conditions. I can trigger the same rule based on any number of conditions. Note that there currently isn’t a way to toggle between AND & OR. You must use OR. Leverage Custom Conditions to create additional event dependencies.
Not a whole lot has changed with Data Elements. Everything you did with DTM you can exactly replicate in Adobe Launch. Aside from Extension support, you’ll be reminded of the standard set of out-of-the-box options alongside a few new ones. The biggest update you’ll find is support for the “None” storage length option. Aaron wrote another good article on the “None” storage length option. In short, it better accommodates single page apps (which was a huge gap with Adobe DTM).
At a very basic level, Extensions are tool templates for Adobe Launch. I’m completely trivializing its utility, but this is the only way to compare it with DTM. You added Adobe Analytics with the “Add a Tool” button on the Adobe DTM interface – with Adobe Launch, you click the “Install” button. For instance, if I want to implement Adobe Analytics within Adobe Launch, I would click “Install” below the Adobe Analytics extension. From there, I can configure the tool just like I did when I added one in Dynamic Tag Manager:
This one was a little too big to do a side-by-side with DTM. Hopefully you get the idea. There’s much more depth to Extensions that I won’t review in this post, but I recommend you check out this article that goes into a little more depth. The basics of it are this – it’s like an app store where anyone can create an application for Adobe Launch that extends the platform to make your life easier… whether that is adding new Data Elements or custom Rule templates that leverage Launch’s UI (like a Facebook Pixel template or LinkedIn Insight template). There are loads of opportunities with Launch’s extension and it would take an entire article to scratch the surface.
In Dynamic Tag Manager, everything is crammed into the Embed section. You have to decide whether you want to use Akamai or FTP for delivery. With Launch, you can choose Akamai and FTP for an implementation (choosing one for each environment). This is great because it lets you mix and match deployment methods! You can now use Akamai to host your implementation on any number of staging environments while your main code can be hosted locally. I have a write-up on Adapters vs. Environments to help you better understand what this means.
Speaking of big changes – Launch gives you the option to load scripts asynchronously (but you don’t have to!). That means it will not block the rendering of your page! With Adobe DTM, you needed 2 snippets – header and footer. Implementing just the DTM header script would cause all sorts of wacky stuff to happen. If you choose to load your libraries synchronously (like you do with DTM), you’re still okay. There’s also a way you can load your Launch library into your DTM file – so you technically don’t even have to swap your code out.
With Launch, everything is much more intentional and specific. The interface is also much cleaner and centralized. Instead of going from a rule interface to an approval interface to the History interface (questionably named…) then again to the publishing queue page… with Launch you’re managing everything simply from the Publishing screen:
The best part about this new workflow is that the library builds as you progress through each phase. That means you no longer have to refresh the page for 15-20 minutes waiting for the library to update! Apologies to those who used that wait as a nice bathroom break.
Adobe Launch is a different product architecturally, visually, literally… though it borrows all of the good metaphors from Adobe DTM. They’re different, but they also rhyme. I just skimmed the surface with this post, but if you’re having a tough time reconciling why you should switch to Adobe Launch – or whether you’re in for a lot of work – hopefully this gives you a good idea. Adobe Launch is still evolving and maturing their features. As they do, I’ll try to keep this post updated; but the fundamentals should remain.