Launch Extensions – Overview

Launch, the successor of DTM, comes with a lot of APIs and is a lot more modular than DTM. You can add functionality to Launch via so-called “Extensions”.

Extensions can be used by your friendly marketer or anyone else using Launch to add new capabilites to the tag management setup. The idea is to encapsulate functionality into a nice and easy to use package.

Let me give you examples:

A — CEDDL – adding a data layer to our setup. I wrote about that not long ago, and it included a bunch of steps. Instead of telling you to go through those steps, I could write a “CEDDL Data Layer” extension that handles most of them. Sounds a lot like the “AEM Context Hub Tool” in DTM? Yup, and that one is also available as an Extension in Launch.

B — custom code to select the report suite dynamically. I do this a lot for a Swiss client. Every time I set up a Web Property in DTM, I add the Analytics tool, create a Data Element “Report Suite ID” with custom code that determines what the rsid should be, then add code to the “Customize Page Code” section in the Analytics tool that directs tracking accordingly.

For example B, I always paste the same code, and the dynamic selection of rsid is always based on the domain name of the current page. For each Web Property, I edit the domain name list in my code.

So, I could put the Javascript code into an extension, along with a UI that allows people to add domain names. How about that?

DIY

Part of the motivation for Launch has always been extensibility, and through that, scale. Since Tag Management sits at an important interface for all online businesses, it makes sense to make it as flexible as possible, and to open it up so that 3rd parties can extend it.

I shall therefore walk you through how you can write your own extension.

This will be the jump-off point for a mini series, as you might have guessed. I’ll explain some of the concepts today, then jump into the actual process in the other articles.

Because everything is easier to understand with an actual example, I shall walk you through the creation of an extension that does one very simple thing — provide a new type of Data Element.

My Data Element will be pretty simple: it will be a “constant Data Element”, i.e. it will be configurable with a value, and it will always return that value.

Structure

At a very basic level, an extension consists of two parts:

1. some HTML that will be shown in the Launch interface when you add or configure the extension, and
2. Javascript to be injected into the Launch library

When you create an Extension, you will likely provide both, the HTML and the Javascript.

Your HTML can be as simple or as involved as you’d like it to be. If you want to add half a dozen libraries, you can. Keep in mind though that someone using your extension in Launch is expecting a seemless experience, not the latest design craze. Keep it simple, I’d say, and unobtrusive.

Similarly, keep the Javascript as lean as possible. As soon as a user adds your extension to their setup, Launch will put your Javascript into the library and deliver it on all pages of the web property. Building an Extension that delivers an additional 200mb of Javascript into all pages might be fun, the Extension will likely be pretty unpopular, though.

Workflow

Remember how I keep writing that Javascript is essentially elaborate Voodoo? I have tried to avoid modern additions to the toolbox like the plague, my latest addition having been Sublime Text, and that was a couple of years ago. But now I have to get off my old horse and embrace some of the newer stuff.

For the development of extensions is heavily based on node.js, and to get anywhere with my own Extension, I have to install it.

Next step: scaffolding

Extensions follow a format, based on CommonJS modules. So there are a bunch of JSON files that you need to provide. You can follow the Quickstart and use the scaffolding tool, which is what I did. It’ll generate all necessary files for you.

Optional art work like icons may apply.

Next step: develop

Now is the time where you write actual code.

You will write the above-mentioned two different pieces of code, the UI part and the “what Launch will inject into pages” part. While the former will be shown in the Launch UI (so users can configure your extension), the latter will be minified and added to the JS that Launch generates when you build.

Next step: debug

I’m sure you are way better than me when it comes to writing HTML and Javascript, but I’m also sure whatever you write is unlikely to work first time round. So test you must.

To do so, there is a sandbox, which actually runs on your machine.

At this stage, you will likely enter an elaborate dance of coding, testing, learning experience, reviewing doc, and thinking very hard.

I shall leave you with that, and I hope you’ll be back for the rest of the mini-series, when we dive into specifics.