Launch? Launch!

A recent, non-representative poll on twitter urged me to write introductory articles about Launch, the new tag management element in the Adobe Experience Could. I presume I won’t be the only one, but I will abide anyway, and so here is the first of a bunch of articles on Launch.

(It was really hard to commence this series of articles without making the obvious joke, but I think I made it. I am very smart.)

Out with the old!

If you have been working with Analytics, Target, Audience Manager, or even Experience Manager or Media Optimizer over the last couple of years, chances are you have been using Dynamic Tag Management, shortened to DTM by almost all of us.

DTM came to the Experience Cloud via acquisition, as so many parts do. It replaced “Adobe Tag Manager”, which it, even in ATM version 2, easily blew out of the pond.

DTM was different from a lot of the TMS that we had seen before. It was quite a lot simpler, too, and yet we have all done some pretty amazing and sometimes convoluted stuff with it.

For it to be truly integrated with the Experience Cloud, it was lacking one big aspect: an API, a way to automate it, drive it from other solutions.

Rather than bolting an API to the existing DTM, product management decided it was time to rewrite the whole thing, and so they did.

In with the new!

Launch, officially announced at the Summit in March 2017, is at the time of this writing (Nov 2017) in the process of being rolled out in stages.

It is currently fairly unlikely that you have access to Launch, but you should probably see it in your Marketing Cloud interface.

The teams that build Launch follow a “release early, release often” approach, which means that they are adding features all the time as well as enabling more people to use Launch.

Here is what I like about it:

Launch has been designed around APIs. Pretty much everything can be extended or programmed. For you, the most tangible result of that are the “Extensions”.

DTM had this concept of a “Tool”. There were tools for Target, Analytics, the Marketing Cloud ID Service, Google Analytics, and a couple more. Those tools had been written by Adobe engineering teams.

For Launch, there are no Tools, but anyone can write so-called “Extensions”. Extensions can take over the role of Tools, and they can do much more. Just to make that explicit: there are two amazing new things going on here:

1. Launch can be extended, and anyone can write Extensions! This should remove a major bottleneck, and I really hope we’ll see some awesome 3rd-party-Extensions. Right now, there are already a bunch of them.
2. Those Extensions can do a lot of things: they can define what was known as “Tools”, but also create new Data Element types, Rule types, and a lot more. If you are currently doing something in DTM using Custom Code, chances are you could write a pluggable Extension instead.

As of now, there are 23 Extensions available in the library, from “Core” to LinkedIn, and from “Pixel Loader” by 33 Sticks to Facebook and Youtube.

The other big new thing: the deployment process has changed completely.

DTM used to have a “staging” and a “production” version of code. A site would embed the “production” library for the visitors, and when I wanted to change the setup, I would use the DTM Switch plugin to change to “staging” (just for me) and happily hack away.

With Launch, there are at least three environments: “dev”, “staging”, and “production”. If you want, you can add more. The process allows you to bundle changes, then push the bundle through multiple approvals and builds. This should make it easier for teams to work on concurrent changes, and it helps formalise the process.

(Note that this does not change my opinion on what to deploy on your sites! Always deploy production libraries!)

One aspect of the environments: they deliver the Javascript via “Adapters”. In DTM, you are able to choose between Akamai-hosted and self-hosted Javascript. Launch takes the concept further and provides Adapters. What’s really cool is that each environment uses a specific Adapter, meaning that you can use Akamai on dev and staging, and at the same time self-host for production.

My hope is that the browser plugin (whichever) will take those into account, allowing me to use Akamai-hosted dev while working on a production site.

Always more

There are of course more changes.

One that I like is that Launch bundles all the Javascript it generates, then delivers a minified, single JS file. That should make it faster, and it should make those pesky warnings in Chrome go away.

The interface has been completely rebuilt, and it looks and feels a lot more modern.

Under the hood, everything is new, as mentioned above. The different APIs can be used to integrate Launch into a bigger deployment mechanism, for example, or you could theoretically drive Launch from a system that manages your business requirements and translates them into tag manager configuration. (Come on! Someone build that, please!)

My colleague Jeff Chasin has answered a bunch of frequently asked questions in his Legacy DTM and the new Launch – a closer first look article, which like anything Jeff writes, I can only recommend whole-heartedly.

So far for a short introduction. I have started building an extension pretty much on the day I gained access to Launch, so along with more posts on how Launch works, and how you can work with Launch, expect some on the inner workings and the creation of extensions. This will be fun!