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.
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.
At a very basic level, an extension consists of two parts:
- some HTML that will be shown in the Launch interface when you add or configure the extension, and
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.
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
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.