Life with Adobe Launch 3/3: Classic Tag Management skills are not enough
What you need for developing Custom Launch Extensions
In the third part of “Life with Adobe Launch”, I look at the entry bar for developing a Custom Launch Extension in terms of skills and structure. Tag Management specialists tend to have some development skills, but rarely work in the same environments nor with the tools that full-stack developers do. Developing a Launch Extension changes that: You have to learn how to work with the tools of today’s professional developers. Thus, the entry bar may be high. It was for me. But I don’t regret it and learned so many useful things along the way.
In Part II, we looked at how a Custom Company Extension can help you scale a data collection standard across many sites and maintain flexibility at the same time. Now let’s look at the skills needed to start with Launch Extension development. You naturally need good JavaScript skills to begin with if you want to maintain any Tag Management System (TMS).
1. Need to know
You need to know how to work with:
a) node.js-based packaged apps (at least basics like the logic behind the file structure and how to require and use modules)
b) npm (Node Package Manager)
c) the command line (at least the basics)
d) an Integrated Development Environment aka IDE (I have fallen in love with the efficiency of the WebStorm/IntelliJ family)
e) private and public keys, especially how to use a JWT token from adobe.io to upload Extension updates.
2. Should know
Skills that are not 100% required, but make life a lot easier:
a) How to write batch scripts (you need only one to make the packaging and release process not a total pain, so maybe you find someone to write it for you (that was my “approach”, thanks, uncle Ben!))
b) If you want to work efficiently and e.g. not wait several minutes for every code change to propagate to your website, you need to know how to work with an HTTP Debugger like Fiddler. Then you simply switch to a local copy of your Launch library and change things in there before you push them to the Launch Development Property (you need a separate “Dev” Property just for Extension testing before releasing them to “normal” Properties).
c) Knowing how to work with a Git repository gives you version control over your code, i.e. you can easily roll back, work on an Extension with a team without running in “now I am doing changes, please wait” type of conflicts etc. (Actually this one should be under “need-to-know”)
d) Knowing how to use a JS documentation standard (e.g. JSDoc): Once your Extension has more than two or three modules, this helps massively with keeping an overview and leveraging the power of the in-line help functionality of the IDE (auto-fill help based on parameter definitions etc.). You will write your code at blazing speed.
When I started building my first Extension in late 2019, I personally was not a complete first-timer in any of these skills apart from the batch scripts and JSDoc, but pretty much a beginner in all besides 2b. And had it not been for “Uncle Ben” Wedenik, a smart Adobe Consultant and rice farmer from Slovenia (he claims he is from Austria), I would have needed a long time to get myself acquainted with this new world, I would have made many mistakes and I would still be inefficient.
Impostor syndrome, I hear you. You ask: How could you have worked so long in this field, even feeling like a TMS expert, without being familiar with all these seemingly “basic” skills of today’s developers?
Tag Management is rarely done by development teams
Maybe impostor syndrome is right. But looking at the people maintaining the TMS’s at the eight clients I worked for last year, only one or two (and zero among the Adobe clients) would have had the skills to get started with Custom Launch Extensions.
Adobe’s approach seems to be to make pro developers feel at home. But Tag Management is traditionally rarely at home in the dev team, even though it should not be done by people without good tech and dev skills. Many TMS Admins may thus feel overwhelmed and left out. At the one client where I developed the first Extension, only one out of the three TMS Admins have in the meantime had the time and grit to acquire the skills to do their own Extension work, while the others are left stranded working within the Launch interface. So Extensions can drive a wedge between your Analytics team members. So far, everybody had the skills to do at least some emergency fixes. Now, anything inside the Extension requires the girls with the special skills.
Hence, Custom Extensions are a place where you need a seriously professional and modern developer to do the initial teaching if your Tag Management team is like that of most companies. Adobe Consulting or an agency can help as well of course, but it is an initial investment to get started. But if you want to use Adobe Launch and have more than one or two websites to maintain, you have no choice in my opinion but to make this investment.
That being said, these skills are all super-useful in terms of career development because you will not only benefit from them when developing Launch Extensions. I grew a lot skills-wise thanks to all the things I learned during Launch Extension development (thanks to Uncle Ben again) and can apply them to work at other clients as well.
How do you get started?
If you want to get started with Custom Extension development, see the Launch Dev Docs. A recent webinar by Prof. Stewart Schilling in Dr. Adam Greco’s Search Discovery Education Community also featured a live demo.
The structural entry bar, a.k.a. your company network
Another entry bar was/is that many of the tools are not easy to get or heavily restricted in a typical company network. This is of course also due to the TMS folks usually not being part of the development team. Most clients I work for have severe limitations on what you can do from their company network, so we basically have to do all the Launch Extension development outside in a gray zone. Only limited npm, no Github allowed, authenticating to adobe.io is blocked, JSDoc cannot be installed, and much more. So a year after starting with Extension development, we still cannot deploy and test the Extension inside the company network. For me as an outsider this is not a big deal, but it can be a big limitation for insiders.
So depending on where you come from (developer in an open, unrestricted development environment? Or classic TMS dude/lady, not part of development team, restricted company network), the structural hurdles to get going with Extension development can be severe.
Summary: Yes, you can!
Part I detailed the inglorious history of Adobe’s Tag Management Systems and showed why Launch still has many of the scaling issues that DTM had. Part II revealed how Launch however offers a way out with a Custom Company Extension to enforce a global data collection standard across sites without stifling innovation. Part III now showed that you need some serious skills to achieve that, but nothing impossible. And worthwhile learning anyway. So: Yes, you can make Launch scale! And you can learn the skills for that! Try it!
