Adobe Launch Coding Standards

This post is part of a series about auto-tagging

Adobe Launch TMS allows you to use built in features to deploy tags on your website. In some instances, you will be required to write some JavaScript custom code as the tagging features are not enough to achieve your requirements.

By injecting JavaScript code directly on the website, there is always risks that your changes can bring a functionality or the whole website down.

Several best practices should be followed by your tagging team to minimize these risks.

JavaScript Style Guide

You should always first check inside your organisation if a JavaScript style guide has been defined. If there is one it is always a better choice to use your organization one than to use an external one.

If there is none then you can try to adopt one that is shared online. In most cases your team will not have enough skills or knowledge in JavaScript to define one from scratch. One safe choice is to use the one defined by Airbnb.

try/catch

It is acceptable for your code to fail, but it is never acceptable to break a functionality or the whole website. To prevent this, you should always wrap your custom code in Adobe Launch custom code editor between try/catch. You should always provide a meaningful and unique error message, which should allow you to easily troubleshoot your issue.

Make sure you document which name to give the error. We for example decided to only use e for our try/catch.

try {
    if (typeof event.details.test !== 'undefined') {
        return true;
    }

    return false;
} catch (e) {
    _satellite.logger.error('Failed in rule 123', e);
}

notice that Adobe Launch provids its own instance of logger. Ideally it should be used as the error will only be displayed if Adobe Launch debug mode is enabled.

Self-documenting code and minimal complexity

Self-documenting code is a best practice, where your code is written in a way that requires little to no comments. A rule of thumb is that it should take 30 seconds to have a good understanding of what your Adobe Launch tag does, otherwise it is poorly written or too complex.

There are a lot of articles that are about this subject so you should take some time to go over them and find the right balance for your team.

Bad

function generate(a, b) {
    return a + '-' + b;
}

var id = generate(a, b);

Good

function generateApplicationId(productName, randomNumber) {
    return productName + '-' + randomNumber;
}

var applicationId = generateApplicationId(productName, randomNumber);

Do not repeat yourself

DRY principle is all about creating reusable code and tags that can be reused in your Adobe Launch web property.

It is normal for your stakeholders to provide you the code snippet from the marketing provider to deploy on your website. The easy approach would be to create a rule in Adobe Launch to deploy this code snippet providing specific event and conditions are met. However, this will create a lot of code duplication on your side which will increase the size of your Adobe Launch js file and it will also be a nightmare to maintain.

In this situation you should always pause and analyse the code snippet provided to you. You can for example use a code comparison tool which should indicate what is the difference between them. In most instances it will be IDs related to your org and campaign. Now that you have isolated this, you can either create a Direct Call Rule to be called each time you want the specific marketing pixel to be fired or create a private extension for this marketing pixel. You can use data elements to generate the correct ids to be placed in the script.

Public extension

Adobe Launch has a concept of public and private extension. Public extension is usable by any Adobe Launch users/companies. Private extension is the one developed by your company and only available to your company.

I will strongly advise against using public extension. In my organization we had 2 instances where such public extensions broke the functionalities of a website. You should only trust extensions developed by Adobe itself, any others you should review their source if available. If no github repo is provided, remove the .min at the end of your Adobe Launch JavaScript library and you should see exactly what the public extension is all about. I have seen public extensions using eval function which is a security and performance risk.

You should instead write your own private extensions and publish them. Using private extension instead of DCR is all about DRY principle and maintainability. While a DCR will follow the DRY principle, it will be harder to maintain across multiple containers. With an extension you will always know which version you are using. The update process will be simpler as your can release your updated extension and publish the new version in Adobe Launch build.

By following the coding standards, you will simplify your tagging implementation and it will be easier to maintain over time. This will also show to stakeholders that while your team is not bound by governance, you still take the necessary precautions to assure the security and performance of the code you deploy on the websites.