Should you really build an Adobe Launch Extension?

If you are using any solutions from the Adobe Experience Cloud family of tools, chances are you are also using Adobe’s Tag Management System, Adobe Launch. Launch works like many other Tag Management Systems (TMS), in that it can bring tools and code to a website without the need to change the source code of the website it is running on. This allows the users of the TMS, typically digital analytics or digital marketing teams, to be somewhat independent from IT and development teams when they want to bring technology, like onsite analytics or marketing pixels, to a page.

In Adobe Launch, Extensions are used to bring the actual functionality to the websites that it is running on. A good example for this is the Core Extension: This Extension allows us to run JavaScript code on the website (using the Custom Code Data Element or Action), listen for events like clicks or page loads, or provide information about the page, like the URL or HTML title tag. Without Extensions, Adobe Launch would not be able to do anything on a page. So whenever we think of Launch’s features, we are probably thinking about the features that are provided through Extensions.

One of the great things about Extensions is that every company using Adobe Launch can create their very own, private Extensions, and even offer them to other Adobe Launch users publicly through the Extension Catalog. This relatively open system allows companies other than Adobe to extend the functionality of Launch and make it easier for its users to use their tools. The result is a rich set of Extensions, some free and some paid, for users to choose from:

A regularly discussed use case for a private Extension is when companies want to standardize their implementations across multiple Adobe Launch Properties or when a small feature they deem crucial is missing. However, having developed an Extension myself and having inherited multiple old ones, I feel like the discussion is oftentimes skipping over whether or not building a private Extension actually is the optimal solution.

This post is aimed to help you evaluate what the best solution to certain challenges in Adobe Launch can be by showing what effort a private Launch Extension brings and what alternatives are available. To start things off, let me show you what it means to build and maintain an Extension. After that, we will discuss some typical applications and possible alternatives.

Building a private Adobe Launch Extension

Giving a full tutorial on how to build an Extension is beyond the scope of this post. Luckily, there are some pretty good tutorials available from Adobe (see this guide overview, this getting started tutorial, this introduction video, or this video playlist) to get you started. On a high level, the required steps can be summarized like below:

1. Evaluate use cases to justify developing a private Extension
2. Set up development environment on dev’s computers
3. Code and test the Extension locally
4. Upload the Extension to a Extension Development Adobe Launch Property
5. Publish the Extension privately
6. Install the Extension on all desired Launch Properties

Once you decide that building a private Extension is a good idea (after reading this post completely), the first challenge is to get your development environment set up. Especially on corporate computers, it can be really challenging to get all the required tools, like Node.js, in place and get permission to run a local development server. Running the required tools is especially challenging on Windows, which is likely all you have on a corporate machine (if you want to read up on my horrible experience running the tools on Windows read this bug report, which in itself was an incredibly frustrating experience).

If you managed to sweet-talk your IT into giving you the tools needed, the next challenge is to actually write the code needed for your Extension. A word of warning here: The levels of knowledge about Launch’s ecosystem and JavaScript skills required to build an Extension are much higher than what you might be used to maintaining Custom Code in Launch. You will have to build both the frontend and backend of the Extension, including all user interfaces and actual code that interacts with your page. On top of that, you also need to provide the correct metadata on which functionality your Extension includes and build the interface with the broader Launch UI. There is also a lot of command-line magic involved here. This stuff is non-trivial and has a steep learning curve.

Now, when you are satisfied with your Extension and have tested it locally, you need to upload it to a special type of Property in Launch, called an Extension Development Property. This again happens using the command line with the Adobe Launch APIs, which require a bunch of setup on the Adobe.io console, including managing certificates to sign requests. I don’t know why there is no user interface for those steps, but there just isn’t. Once you have it installed there, you can test it in the broader Launch ecosystem, especially in combination with other Extensions.

If all of your tests succeed, you then need to privately publish your Extension. This involves some more command-line shenanigans (again, why no UI?) and will finally make your Extension available on your other Launch Properties under the same Experience Cloud Organization. On those other properties, you will then find your Extension like any other in the Extension Catalog, from where you need to install it and build a Library which you can then release. This is how my own Extension showed up in the Catalog:

This whole process took me quite a number of weekends for the Extension you can see on the screenshot above. And as you can see, I’m already at version 1.0.4, meaning that I have run through this tedious process more than once to fix edge case issues while stakeholders where banging on my door, demanding the quick solutions they are used to from other requests. It was a fun learning experience, but I would think twice about doing it again. Which brings me to…

Why you may want to (but shouldn’t) build your own Adobe Launch Extension

With this clear picture of what it takes to initially build a custom Adobe Launch Extension, let’s go through some of the reasons people might want to build their own Extension. Below every reason, I’ll then discuss pros and cons for each. Let’s start with the, in my experience, most prevalent one:

1: You try to reduce maintenance effort and increase homogeneity for standardized implementations

The reasoning behind this point is usually quite simple: Once companies start using a standardized approach for, for example, tracking users with Adobe Analytics, they want to keep their implementation standardized across more than one Launch Property. If the surrounding systems, like a data layer, are also standardized, why not choose a central approach to managing the code for all implementations at the same time?

In my personal experience, a key reason for this sentiment is that implementations like this are overly reliant on Custom Code, be it in Rule Actions or Data Elements. For example, you may have designed your data layer in a suboptimal way, which requires you to transform data before it can be used. Because you know how to do those transformations in JavaScript, you choose to use Custom Code components, which lead to a lot of overhead if changes need to be rolled out globally across multiple Properties.

There are two misconceptions in here: The first one is that custom JavaScript code is the best approach for certain transformations. For example, you may want to track the list of teasers on a page into a List Variable in Adobe Analytics, but the data layer provides an Array instead of the string you need for the Adobe Analytics Extension in Launch. You then decide to concatenate the Array using a Custom Code Data Element or, even worse, a Custom Code Action in a Rule. In doing this, you completely missed that Launch recently got a big update to the Core Extension that allows for exactly this transformation without any Custom Code! There are other examples where an existing Extension can do exactly what you need, like returning values on a condition with the Core or Mapping Table Extensions.

The second misconception is that a custom Extension will make it easier or more straight forward to roll out changes. As I’ve outlined above, the process to build and update an Extension is super involved and complex. And even if you have the changes published to your company’s Extension Catalog, you will still need to go through each and every Property, update the Extension, build a Library that includes the updated version, and release it on all properties. That is still a lot of manual work on every Launch Property!

So instead of building an Extension for this case, I would recommend to take a good look at what the existing Extensions in the Catalog offer and go with their functionality instead. Custom Code can be avoided in a lot of cases, which makes your Launch setup even more approachable for less technical users. When it comes to effort to roll-out changes, I’ve been quite efficient using the copy feature between properties or just manually going through each one that needs changes. Remember, you have to do the same thing with a private Extension too!

2: You try to reduce the need for Custom Code

This may feel a bit weird to read after the first point. Wasn’t too much Custom Code an issue a second ago? Absolutely. And I’m the first one to support any effort get have as little Custom Code as possible in Adobe Launch, as it’s super hard to maintain and control. And yet, the drive to reduce Custom Code may urge you to put the same functionality into a private Extension.

To give you an example for this case, imagine you try to assemble the Product String for Adobe Analytics in a Data Element. Because of how your data layer is structured, you require some transformations that are currently done in Custom Code. To get rid of this, you decide to put the same code in a private Extension, which at least hides it from the end users in the Launch interface.

In my eyes, this is taking the effort to reduce Custom Code a bit too far. Instead of reducing complexity, you are actually increasing complexity significantly and maybe completely exclude anyone but yourself from maintaining the implementation in the future. That’s not ideal.

If there really is a need to transform data through JavaScript, I recommend you should embrace what Launch offers natively. Custom Code Actions and Data Elements should always be a last resort, but at least they offer a transparent and light-weight way to execute code outside of other Extensions.

3: You (think you) are missing some simple functionality

I can vividly remember being at this exact point of thought myself. A while back, Launch had no native option to join an Array, slice a string, or perform other very basic operations that are needed in the daily life of any tag manager (the person, not the tool). Especially when you know how to do those simple things in JavaScript, it may seem like a good idea to “just create an Extension for it”. This is exactly why I wrote my own Extension from the screenshot above.

As with the points before, you may want to check whether those transformations are actually still not supported by Launch’s Core Extension. And if they are, you may do what I’ve done: Instead (or in addition to) creating my own Extension I’ve created a feature request for the Core Extension. In there, I tried to a) explain my need and b) bring in more people to chime in. A bit later, I even created a pull request to bring those features I wanted to Launch.

So instead of having to maintain my own Extension with those features, I’ve helped Adobe to offer the features I needed and even brought, in my eyes, value to the broader Launch community. This comes with the added bonus of me not having to create the same Extension in all future companies I may work for, so you could even call me selfish for this. Oh, and it also means my face is now featured on the front page of that Github repo as contributor number 10:

While this was certainly a learning experience for me, I can just recommend you to do the same! If you know how to write Extensions, why not use your skills on my feature requests for two new actions or for more flexible conditions?

4: You (or someone on your team) really want to write “real” code

Again, this point is quite close to my heart. There are a lot of people who work in analytics or tag management who have worked in web development before. Some even have a background in programming and computer science or want to become a full-blown developer. If you have someone like that on your team, why should they not write their own Extension to solve for point 3 (or even just to give them a nice project as incentive)?

Besides the enormous amount of effort it may take to enable that team member to even write an Extension (like, if your company uses Windows computers) you need to keep maintainability and the broader skills among your team in mind. Here are some questions you can ask yourself to check if you should really support this:

• How long will it take that one team member to create the Extension from nothing, including getting the environment ready?
• Who else, except that one team member, knows how to maintain an Extension reliably?
• How are you going to manage the code and certificates required for the Extension?
• Who will take care of the unexpected emergency fixes while that one team member is on vacation?
• What happens if that one team member leaves your team to become a developer?

Depending on who is in charge of the Extension (the dev team? the analytics team? someone else?) chances are quite high that you should not build dependencies on an Extension with questionable long-term support. The good news here is that, looking at the last paragraph of the previous point, you can allow your team member to instead contribute to someone else’s Extension or even the Core Extension. This will be a great learning experience, put the maintenance on someone else, and will look great on that team members CV! It also shines a fine light on your team and your company to support open source projects.

Conclusion

So, as you may have guessed, I’m opposed to most reasons why an individual employee, a team at a company, or a company itself may want to code its own private Extension for Adobe Launch. In my experience, there are plenty of more reliable, scaleable, and community-centric alternatives to taking things in your own hands.

Of course, if you are a tech vendor, you absolutely want to enable customers to use your tools through your own Launch Extension. In this case, make sure the Extension is part of your long-term product road map and well understood and supported. Providing such an Extension is a prime way to enable your customers to implement or test out your tools without much hassle.

On top of that, if you are an agency or consultant, you may want to use the Extension Catalog as some great promotion for your business. After all, there are some companies I’ve personally first heard about in the Catalog, so it definitely works as a way to let the world know about your business. This of course comes with the same requirements in terms of long-term support and quality than any other Extension, so make sure you don’t jeopardize the trust of your users!

I’m curious to hear about your own opinion and experiences on this. Have you ever inherited an Extension or had to build one yourself? I’m curious to hear about your thoughts. As always, have a great rest of your day!

Frederik Werner

German Analyst and Data Scientist working in and writing about (Web) Analytics and Online Marketing Tech.

2021&2022 Adobe Analytics Champion

EMEA Adobe Analytics User Group Lead

www.frederikwerner.de/