Custom Code Actions in Launch

This is a guest post written by @ursboller (maker of launch-parser.com)

Using Adobe Launch as a tag manager has really changed the way we handle the implementation both for Analytics as well as for marketing tags. Since the beginning we followed the “no custom code challenge” and we use a private extension just for some of our most common code snippets (see “No Custom Code – is an Extension the answer?“).

But there are situations where we can’t get rid of the custom code – as hard as we try. The most common use case for custom code are marketing pixels which we use only on certain pages. That means, we can’t include any official extensions but need to write our own code to inject the desired Javascript on the right pages. In these cases we have rules with a “Custom Code” action to handle all the logic of injecting the pixels.

Adding a “Custom Code” action

The “Custom Code” action is just like any other action in the core extension and allows you to write your own javascript. I don’t go into detail here because there is a help doc written by Adobe where you can find a lot of useful information. When the rule gets triggered, the custom code is injected into the website and executed.

For a simple test of a “Custom Code” action I created a new rule which is executed on a click on a header link (H2 tag). The custom code itself is just an example and will do some logging (better use _satellite.logger).

Now I will test my rule to see what happens. Injecting the library on my page and clicking on the header text, I can see the execution of the rule in the console.

Behind the scene

But what happens when the rule gets triggered and the action executes? To keep this blog short (and not too technical), Launch adds some Javascript to the website which gets executed immediately.

There are a few things to be aware of: first, the code injected depends on how you set the setting “execute globally”. In case you don’t turn it on, Launch adds a function to the website and calls this function. But if you set it to “execute globally”, the code is not encapsulated in a function but just added to the website as raw code.

That means, your code might potentially clash with other code on the website if “executed globally” – I recommend using a prefix for any variable you define to have a bigger chance of not breaking anything. Here is an example showing the difference:

There is another thing to be aware of – just have a closer look at the code above. Launch does not minify the code you write in the “code editor” (at least not currently). The only thing that’s missing are the comments. Therefore, be careful what variable names you use…

External library files

The third point (and the main reason I’m writing this article) is the “external file” behavior. In most cases I’ve seen so far the custom code is excluded from the main library and put into a separate file. In my example above, the rule in the main library looks like this:

You can see that there is a source path to the rule file and marked as “isExternal” in the code. If I check the contents of the file in reference, I can find my custom code:

That means, for every single action of the “custom code” type you generate an additional file. And this file needs to be downloaded before it can run on the client! But there is an exception mentioned in the help docs:

Rules using page top or page bottom events: Code from custom actions is embedded in the main Launch library.

Launch help docs

That means in all other cases than “page top” and “page bottom” you have some potential delay for the user (download file). And worst case, the browser stops execution if it takes too long and the user wants to see the next page (for example within exit link tracking).

Wouldn’t it be great to have a way forcing Launch to put our code in the main library? Unfortunatelly, there is no option to “include in main library” right now. But it’s still possible – let me show you two options

Option 1: move code to conditions

The first option is moving the code out of the action and into a condition. The reason is that custom code in conditions is always included into the main library (because it might be use on “page top” or “page bottom” and therefore needs to be present as early as possible). In my example I can change the rule as shown in the next picture:

As you can see, the condition has the desired code and returns “true” at the end. But lets check if the code is really in the main library now:

It worked! No additional file on rule execution, all included in the main Launch file. But this solution has some drawbacks:

• The rule is difficult to understand for anybody else working on the same Launch property. There is “action” code within the “conditions” and maybe worse, there is no “action” at all (not really needed as in my test example). If somebody else has a look at the rule he might decide that it is not needed anymore (since it has no “action”) and will decide to delete the rule.
• Think of a rule which should only execute on other conditions: in this case, the new (fake) condition must always be at the end! If you’ve ever tried to change order of conditions/actions, you will know that this might easily go wrong.

Option 2: force to library

Luckily, there is another option to force our code into the main library. As written above, the code is always in the main library on events “page top” and “page bottom”. All we need is adding the “page top” event – and conditionally kill the rule execution right afterwards. Sounds crazy? Maybe, but it works:

Any rule triggered in Launch has automatically an “event” object passed along. The “event.$type” will tell you, what the name of the “event” is that triggered the rule. (Remark: it really is “$type”, this is not a typo). To be sure it works, let’s check the main library again and inspect the new rule:

Nice! The code is now directly in the main library without any reference to an additional file. But does it really only execute on the link click and is “killed” on “page top”? let’s check the console and click the link:

Great – it all worked as expected: on “Page Top”, the “condition value comparison was not met” (marked red). But on the click of the link later on, the rule exececuted successfully, displaying my custom code (confirmation “rule fired”, marked green after everything has finished). That means, we are really able to get rid of any additional file loading! and more over, with proper naming of the additional event trigger everybody can understand what happens within the rule (if not, you can still add more text to the name of all the single items or add some comments on the right side).

Summary for “Custom Code” actions

“Custom Code” actions are really nice to inject some javascript to the website – just in case you don’t want to take part in the “no custom code challenge”. But as described they have some drawbacks and you might consider using fancy workarounds. So here are some important points as a summary:

• Really needed? Only use custom code if you don’t see any other option. Maybe there is an excension which you can use.
• Execute globally? Only turn on this option if you need to. And if you do, use a naming convention to prefix your variables to prevent messing up with other code snippets on the website
• Clean coding? Whatever you use in your custom code actions is not minified. so check your code and use clever names for variables and more.
• Prevent external files? In case you don’t want any external files with some custom code, you might consider forcing Launch to include all code in the main library. In this case I recommend to use the “fake” event “page top” with a condition to kill rule on the “fake event”.

I hope this blog gives you some more insights into “Custom Code” actions within Launch. Happy to hear any comments and maybe other (better?) solutions for the issue with external files.