I honestly feel that this article is a total rip off of others work but I didn’t find any summary about “advanced” Adobe Launch capabilities anywhere so I decided to create my own list of things I discovered along the way of working with Launch. I have gathered the different information that I have found during my time working on Launch implementations, so most of the element below have anything to do with me but lots to do to other people, so kudos to them.
If you find that I missed anything worth mentioning, feel free to comment it.
This one is an easy one because there is an official Adobe article about it, however, it is hidden in the official documentation in between all of the reference object form Launch.
The best way to learn about it is a hidden post on medium : https://medium.com/adobetech/launch-library-monitoring-hooks-c674d16deae3. Thanks to Aaron Hardy for the nice explanation.
You can use monitor hooks to keep track on which rules have been fired on your website. However this functionality is not recommended on your production environment for possible future discrepancy on this API.
Self hosting Launch Library
This article is coming from Jenn Kunz (33sticks) and explain how you can still build your library in a host managed by Adobe but download the library to host it on your own domain.
When discussing self-hosting option, it usually involves fancy IT setup to retrieve library built on some sort of pull requests.
But before you go into that frenzy, Jenn solution is simple and easy to implement and you can just try if that would be enough to realize this manual implementation.
Additional Parameters to Launch Direct Call Rules
This one is pretty famous already but it may be helpful to anyone starting with Launch, you can pass additional parameters to Launch Direct Call Rules.
Also now the Direct Call Rules can be attached to several rules. It used to fired only the first rule defined by it.
And because we already linked Jenn Kunz, I will just do the same here and link the 33sticks article that explains everything very clearly.
Launch Load Order
At some point, with any Tag Management System (TMS) you are wondering what is the load order of the different component. You can obviously do a lot of tests in order to find out this.
But you can also read Jan Exner Blog post about it: https://webanalyticsfordevelopers.com/2019/05/07/reference-launch-load-order-with-an-extension/
Promise support in Launch
Launch provide lots of flexibility for building your implementation, you can use sync or async mode on your implementation. You can define rule order to define priority on rules that fire at the same time (or with the same event).
This is awesome but you can never be sure of the rule order, especially in a rule, if they do some kind of network call that takes some time. In async mode, it is pretty tough to understand what is really going on.
Recently (May 2020) the Launch team gave a really good news for the community. The support of promises in Launch and its default implementation for the action sequence definition.
If you want to know more about the change, I will encourage you to look at the post from Ben Robison.
btw: This was already the case for Adobe Analytics, each Set Variables action was actually a promise. This was ensuring that the “send beacon” action wasn’t fired before you finish setting your dimension.
This one part hasn’t been tackle from what I know but it is about resource loading. So let say it might be my contribution to this list of thing to know.
When you Launch script is running, you may see other different requests going out from the network tab.
Something like :
Some of you may be wondering what those are, and most of you are most likely knowing those are different actions you have set in your rule(s) that are executing.
What Launch is doing is externalizing the resource in another js file and then loaded it up when the condition are met. Pretty efficient in reducing size of your main library loaded.
What you may not know is that not all of your action are being handled this way.
When your event is “Library Loaded” (page top), your script is hosted in the main library (the one loaded first). That makes sense because Launch will try to fire that script as soon as possible, loading it from external resources will queue it with the other resources being loaded from the page.
All of the other events (click, Window Loaded, DOM Ready, etc…) are going to host your script externally.
OK, true, you may have known that…
But did you know that the Analytics “Set Variable” action are actually all integrated within your main library load ?
Independently from the event selected, Launch host the custom code set in the “Set Variable” actions in the main Launch library.
That ensures a better and more efficient tracking.
Therefore, if you are doing lots of custom code in your “Set Variable” actions, it will increase the size of the main Launch library.
Also, even though Core “Custom Code” and Custom Code in Analytics “Set Variable” are looking the same, they are not behaving the same way.
China exception (for the time being)
For the last note; I have been recently made aware of the china CDN situation for Launch.
At the moment (May 2020), the “managed by Adobe” hosting method is not hosting your library into China. It is usually delivering the library to your china website from the Singapore CDN.
This comes with delay on the on page load time because the scripts will need to go through the firewall.
As described in the post, the solution for the time being would be to self-host in your china server (if you can).
For that, you can jump back to the “Self hosting Launch Library” paragraph.
Or you can wait because a solution is being worked on by Adobe now.