The 2017 Adobe Summit week flew by and boy are my arms tired… okay strike that awful joke from the record. Summit was exhausting, to be sure. One of the most relevant announcements was the introduction of Adobe’s complete rewrite of the TMS Adobe DTM titled Adobe Launch. I went to a few presentations that walked us through the entire workflow and wanted to share some early thoughts about it.
The name “Adobe Launch”
Who cares about a name, right? It makes sense. You launch stuff. It’s a launch pad for user-created extensions (we’ll talk about these later)… yadda yadda yadda. Adobe wants to depart from the Adobe DTM brand – because it’s a totally different tool. I’ve already heard:
“So how do we launch… Launch?”
This might get a little annoying after a week or two. “Launch” is a very frequently used term. Speaking of which, try Googling “Adobe Launch”. Yeah, SEO’s going to be a battle. I think people would have been okay with leaving it as “Adobe DTM” and “Classic DTM”.
Rule creation makes a lot more sense now. Page Load Rules are now grouped with Event Based Rules (because a page load is technically an event that occurs in the DOM). The if…then syntax just completely makes sense. They also added rule Exceptions as part of the conditions so you slackers don’t even have to use Regular Expressions. Google Tag Manager was a little ahead of its time on that one, I guess. Otherwise, structurally, it’s very similar to today’s DTM.
Publishing Workflow & Libraries
Currently DTM supports 2 environments – staging and production. Launch will default to 3 environments by default but will support any number of environments. So if you have a localhost, dev, pre-staging, staging, post-staging, pre-prod, pre-pre-prod… you get the idea. Each environment will have its own set of tracking code that can be individually toggled to be hosted on the cloud, FTP, or file download. This is a fantastic addition that many teams were surely wishing for.
Adobe also introduced Libraries. These are the equivalent to the GTM’s workspaces feature. You can batch rules, data elements, etc into these Libraries and deploy them into various environments independently. This has been a much-needed feature for teams with multiple DTM users.
So then there’s the approval workflow. The approval workflow is very pretty. It has a nice drag-and-drop interface that progresses libraries between workflow phases. It even lets you know when the library has actually been BUILT (so no more refresh/_satellite.buildDate spamming). This is an excellent addition sitting in the middle of a relatively abstract approval workflow. In the workflow you’re making a few decisions:
- What rules go into the library?
- What environment will this library correspond with once approved?
These are very straightforward questions; but if you have 5 environments, 4 libraries, and rule dependencies affecting multiple libraries it can get pretty complex pretty fast. That said, I think they did the best they could do given the constraints.
Adobe Launch announced the inclusion of Extensions. These are basically plugins that add on to Launch’s interface. Not happy with the UI? Build an extension to change it. Have to constantly write scripts over and over to trigger an event? Build an extension. Want to implement Coremetrics? Build an extension. Adobe has made the tool completely modular. In my opinion, this is brilliant. Not only does it increase the breadth of tool coverage, but also outsources a lot of work and puts it in the hands of publishers (even if the publisher is the Adobe Analytics team). This makes a LOT of sense and is a very welcome addition.
The Open API
So the speakers at Summit kept selling this as the “big gun” of Adobe Launch. From an analyst’s perspective, I’m more cautiously optimistic. It turns
DTM Launch into a sandbox. While this is nice, it has the potential to create a lot of noise. In one session an audience member asked about API security and governance. The response was “With great power…”. While that’s a laugh and while this could be a cornerstone feature, I’m not yet convinced that this won’t create more work for the Launch team by forcing them to curate, debug, and ultimately support an amalgamation of modules using the API.
I consider myself relatively responsible but it adds another talking point for other TMS platforms. It adds complexity and signals a turn towards a more developer-dependent implementation process. I only bring this up as a thing because so many pitches sold DTM as a tool that is “so easy a marketer could use it!”
One great part of the API is that users can basically export their rule library (very similar to GTM). While it’s one of the best features of the Tagtician extension, I’m happy to see them build something in-house that helps with documentation.
tl;dr 9/10 rating. It’s great and I’m looking forward to getting my hands on it. The new features make total sense for Adobe and the users. My only point of concern is API governance. If there really is a big development community around this open API then there needs to be something that helps keep things organized. Additionally, with more flexibility comes a greater degree of complexity. This isn’t necessarily bad but it does seem that Adobe is pivoting from the “so easy a marketer can do it” position.
Nice write-up Jim!
I’m giving it a 10/10 for now. Since we’re all making semi-informed guesses at this point, I wanted to share where my mind is going on the topic. I came away with a little different take on the ease of use for marketers, the extension platform, and open API.
IF we see broad participation of vendors, agencies, and practitioners in development of extensions, Adobe Launch will be more friendly than DTM for non-technical marketers and analysts. With a good data layer in place, a non-technical person should be better able to set up 3rd party tags. Analysts should be better able to bring data (into AA, GA, etc) from 3rd party tools like BazaarVoice, Rich Relevance, Monetate, etc. (assuming that an extension for these products will emit events and provide data).
I view the Launch API as being a really great thing (and I get that you do to). I already have a ton of use-cases for the API in supporting my clients, but I don’t know that it will make anything more difficult for non-technical users. I consider it as just another great add to the Adobe I/O ecosystem. My prediction is that 90+% of Launch users will never touch the API (unless they are using something that was built for them using it) – just like 90+% of Adobe Analytics users will never write code using the AA reporting API.
My take on the “Great Power / Great Responsibility” topic is also a little different. Since the product is being developed in an “API first” manner, it follows that the API will expose the very same endpoints that will be in use by the Launch end user interface. Knowing this, we should be able to generalize in saying, “If a thing can be done in the Launch UI, it can be also be done using the API”. I expect that the team has coded API request validation into the server side, knowing that the API will be exposed. If this is true, we can probably expect that the API will not have operations outside those in the Launch UI.
Aside from the API, I agree that there is some potential support woes for users of 3rd party extensions. I’m hoping that there is an ability for users of extensions to provide ratings and reviews in the extension marketplace. I also hope that there will be an ability for extension creators to charge a nominal fee (as is done in app stores and other extension marketplaces). These two things will allow extension shoppers to make informed decisions and independent extension providers a revenue stream to support their work.
Thanks for your perspective, Stewart! Regardless of outcome, I’m still itching to get my hands on it. I also agree that 90%+ will likely never touch the API. I’m interested to see what people come up with. Heard some folks mention the idea of uploading SDRs into Launch. Should be interesting.
How do you do this in Adobe Launch?
The goal is that I want to compare the actual Adobe Launch implementation of the data elements/rules definitions against the requirements spreadsheet that I had handed to the Adobe Launch developer to configure specifying the data element names/rules + definitions on where they were to be defined etc.
In other words, I wanted to audit the implementation against requirements.
For downloading an offline copy of the library I tried these 2 approaches :
1. You can use the tagtician chrome extension to download a JSON extract of your library. This can then be converted in to excel of anything you need.
However, the tagtician extension seems to require you to be on the site page where the adobe launch embed code is instrumented? Is this true? If I didnt yet deploy it to a site, is it still possible to view the contents of my library in terms of events, data elements, rules, extensions
2. When I download the offline Zip after turning on Archive option in the environment, it gives me a bunch of .js files. It does not give me JSON. Should I add everything in my working library (which is now an upstream resource) or does it understand to include the data elements, rules, extensions into it automatically inheriting them?
Also, when I set up the library with Archive option, it does not make use of the path (URL) that it is a requiresd field where it says it will keep a copy of the library each time it is built. I had configured that URL to point to a Google Drive directory . I didnt know what else to put in there.