Life with Adobe Launch 2/3: Make it scale with a Custom Extension

How to ensure a centralized and scalable data collection standard across websites with a Launch Company Extension

Part I covered the rocky history of Adobe Tag Management Systems (TMS). It also showed that Launch still has many of the scaling issues of its predecessor Dynamic Tag Management (DTM). Fortunately, Launch offers a way out: Custom Extensions. So if you have multiple sites and want them to adhere to a common tracking standard, such an Extension is a must. Otherwise: innovation freeze and data quality disaster.

The problem

Your organization has multiple websites and you want to change one thing globally in all of them. The only options that Launch offers without a Custom Extension (like DTM) are:

  • stuffing all sites into one property (slows down your site, makes logic within this one property more complex => high risk of side effects)

This means you will:

  • either not innovate much or have only one or two sites benefit from that innovation

Furthermore, setting up the same global tracking standard in a new Launch property (e.g. for a new website) will be a painstaking exercise of “did I really not forget anything?” (and of course you will forget something).

In short, you you have the choice between broken data, stalled development, or wasted resources.

The way out

There is a way out though. It requires building your company’s own Custom Launch Extension. Architecture-wise, it is a beautiful and professional way of ensuring a global standard across multiple Launch properties. And even within one property, it can help considerably keeping things standardized.

Note that there is quite some initial effort, as building such an Extension requires useful skills which many TMS specialists nowadays (including myself) had not needed before. I will talk about this in Part III.

So what is a Custom Company Launch Extension?

There are public Extensions which you find under the Extensions “catalog” in any Launch property (e.g. the “Adobe Analytics Extension”), and there are private (Custom) Extensions which you build yourself and only work in your company (organization) account. You can make also a private Extension public (if you dare going through quite a process).

Any Extension extends Launch in the following way:

  • A main.js script is executed whenever the Launch library loads (so usually on every page). This and a configuration screen are the absolute minimum an Extension needs to have.
Example of a Data Element provided by a Custom Extension. Yes, I also think it looks awful, but I don’t want to bill more time to the client for learning how to use Adobe’s Spectrum CSS. I think Adobe should provide some easy-to-use layout standard here or simply make Extension views inherit the Launch layout.

All the Extension code is shipped with the Launch library code, so you need not worry about obstacles like Custom Code for Click Listeners needing to get downloaded first after the click (see Part I). It also means you should carefully weigh how heavy your Custom Extension should be.

So while the approach to load all Custom Code from a CDN is too much on one extreme, shipping all Extension code with the library seems to be on the other extreme. Thus, don’t add stuff to the library that is not really a global (cross-site) requirement.

Examples, please: What is the Custom Company Extension used for?

In short, the Custom Company Extension holds everything that should be the same in any Launch property. Some examples from actual cases:

  • Most importantly, it provides a standardized way to transform and enrich the data layer: e.g. it adds several standard variables, generates fallbacks for missing variables or older data layer standards. A common example are URL-based variables (URL Path, PII-cleaned URL Query String and Referrer, standardized stripping of high-cardinality URL Parameters to avoid “Low Traffic” in reports etc.).
The Custom Extension’s configuration page allows to set property-specific settings for the Consent Manager as well as Analytics tracking features.
  • It provides standardized Conditions (e.g. “must be on any of the company’s production hostnames” / “has at least opted in to tracking” etc.) -> very nice because this way a Condition becomes a central module, and if the logic inside this Condition changes (e.g. a new hostname is added), all rules that use the Condition will automatically have the new definition. An enormous time-and-nerve-saver.
Page Load Time Tracking is enabled by default in this Extension with one click.
  • It standardizes Error Handling (JS errors are sent to Adobe Analytics).

So why does this scale again?

When we now do a change to the global standard, we just update the Extension code in one place and release a new Extension version. In the Launch properties, we do not have to go through the copy-paste atrocity anymore, we simply click “upgrade” in the Extension overview page and then publish (after testing of course ;)). No chance that you accidentally miss one of the copy-paste steps. No redundancy. No reliance on Custom Code.

Standardization is great. But does this not stifle flexibility?

So am I forced to do everything the way the Extension prescribes? What if I have a website where 95% should be like the standard, but there is a good reason for an exception for 5%? An example is a website on which the URL paths (not the query strings) are completely cryptic (e.g. “”) and different for each user session. So generating the URL-based variables according to the standard makes no sense reporting-wise and would result in a lot of “Low Traffic”.

Such site-specific exceptions can be taken care of with so-called “Pre-Extension” and “Post-Extension” modules. They can be configured directly in Launch without requiring an Extension upgrade. They are simply inside a Launch rule that loads on on all pages. This rule contains a Custom Code Action with two functions inside, let’s call them preExtension() and postExtension().

You can do it differently, but this is our logic to ensure both a global standard and site-specific flexibility.

After receiving the data layer event, the first thing any Extension Action does is calling the Pre-Extension function. Within that function, you can e.g. add mapping logic for data that is only used on a specific site. For example, if only the Careers Portal needs a “Job ID”, it would be a waste to have a global logic in the Extension for the Job ID. The info that the Extension should map Data Layer variable “” to eVar457 and prop17 can simply be added in the preExtension() function for this single website similar to the following: myExtension.additionalMappings={ “”: “eVar457, prop17” }.

The Post-Extension module makes it possible to add “last mile logic”, so after the Extension has finished processing the data layer data “ETL” and just before any data is effectively pushed to its destinations, e.g. Adobe Analytics variables. A typical case is Analytics-only logic, where the data layer should stay as it is, but some additional Adobe-specific stuff is needed (like a certain Success Event). For the site with the cryptic URLs, this could be the place where you override eVars for certain URL variables, e.g. cutting off the cryptic part.

This way, the standard can be enforced and the benefits of the Extension can be used without sacrificing flexibility.

New site? Give me 10 minutes, please!

Need to onboard a new site with the Consent Manager plus Adobe Analytics standard tracking, supporting all the standard variables generated by the Extension? This would have been at least a day’s work in the past, full of error-prone copy-paste exercises. Now it can be done in less than ten minutes:

  1. Add the Custom Extension and set the checkbox for the Consent Manager.

If the website requires exceptions, you add a Custom Code action in that one mentioned rule to define the pre- and postExtension functions with your additional logic inside before the Extension Action from step 5. That’s it. A major decrease in setup work, and much harder to make a mistake.

There are different approaches to enforcing a company standard with a Custom Extension. This is just one example, certainly not the prettiest one. All I can say is that this Extension has helped stabilize the setup massively and made rolling out new websites a piece of cake — and most of all, we sleep better because we rarely experience the “did I really not forget to copy-paste anything?” fear anymore.


There are of course downsides: It is not as easy as before for people who are not familiar with Extension development to see what is actually going on in the code. Also the standardized mapping to eVars/props need to be made visibly clear in the Action Views, otherwise it is a black box (still a todo for me).

The entry hurdle for someone new to understand how our Launch setup works is thus higher. And you need a much wider skillset to build an Extension than what you usually need to manage a TMS. Most TMS folks including myself don’t/didn’t have these skills. But that’s the topic of Part III!