Adobe Launch Tagging Standards

This post is part of a series about auto-tagging

Tagging Standards will allow you to set up a set of rules for your tagging team members to follow. By following them we will ensure that the content of your Adobe Launch container is secure, maintainable, and reusable.

Naming Convention

As a member of the tagging team, a big part of your daily job involves working inside the Adobe Launch interface. Without proper naming, you will soon realize that it is very difficult to maintain over time.

Example of good naming convention:

• use camelCase when possible. This is particularly useful for data elements and direct call rules. Try to avoid snake_case or PascalCase
• never use a single character to describe the web property, rule, data element, or a build
• never use trailing or leading underscores (except if it refers to_satellite object)
• acronyms and initialisms should always be capitalized or all lowercase
• inactive rules and data elements should be prepended by zzz so you can filter them out easily. You can apply same for the web properties that are disabled.
• if a data element is linked to a specific type of configuration then make sure to add it in the name. i.e: instead of facebookEventName, use marketingFacebookEventName. This way you can easily filter on all marketing configurations to find what you need.
• avoid using abbreviations, use self-documenting syntaxes. i.e: instead of fbEventName use facebookEventName

Web Property

Each Adobe Launch property should have a clear name. It should describe either the project or the platform on which the web property is deployed.
In most companies, the TMS will be shared between multiple sections of the business and there might be more than one tagging team using Adobe Launch. It is a good idea to add a descriptive part that relates to the business.
Also, consider using a descriptive state of the web property.

i.e: P - Project 1 - LIVE: in this example P refers to the personal section of the business, Project 1 refers to where the container is deployed, and LIVE indicates that the container has been published to production at least ones.
i.e: C - NSA - BUILD: in this example, C refers to the corporate section of the company, NSA to the code name for the platform New Simple Application (which is referred as NSA internally), and BUILD indicates that this web property was never published to production and has most likely not yet been tested.

Publishing Builds

Make sure to set a build name as informative as possible.
Avoid single words like "fixes" or "tweaks".
If your build is linked to an internal ticketing system like JIRA, make sure to add it in the build name, maybe between square brackets for syntax purposes.

i.e: Add Adobe Analytics for product 1 journey
i.e: [JIRA-1] Add facebook marketing pixel

Rules

The rules naming convention is important as it will save you time when you are debugging. I have seen Adobe Launch builds that used rule name as "Global", which means that it is impossible to understand, by just looking at the debug logs, what this rule does.

A good rule naming syntax would be:

Rule type -- Event type -- Web site location where it is deployed -- Actions -- Version

i.e: PLR -- PT -- Brand1 - Product1 checkout section -- AA|AT -- v1: in this example we can clearly see the intent of the rule where the rule is a page load rule loaded at page top for Brand1 during the checkout process of Product1. Adobe Analytics and Adobe Target code is loaded as part of this rule.

Events

The following syntax should be used:

Extension Name -- Event type -- conditions

i.e: Core -- Page Bottom
i.e: Core -- Click -- Call me back button

Conditions

The following syntax should be used:

Extension Name -- Condition type -- Evaluation

i.e: Core -- Value Comparison -- isValidDomainAndSubdomain = true
i.e: Core -- Value Comparison -- productName ~ ^.*premium$

Actions

The following syntax should be used:

Extension Name -- Action Type -- Details

i.e: Core -- Custom Code -- Facebook conversion pixel
i.e: Adobe Analytics -- Send Beacon -- s.tl

Data Elements and Direct Call Rules

Follow these syntax rules:

• use camelCase
• no single characters - self-documenting name
• no trailing and leading underscores (except _satellite)
• acronyms and initialisms should always be all capitalized, or all lowercase

i.e: Correct data element names pageName, productName, productCode etc...
marketingFacebookEventName is better than facebookEventName
i.e: Correct DCR names would be: loadFacebookCore

Do not repeat yourself principle

You should always take a step back when deploying third party code using your TMS. The marketing team is usually not technical. It will always provide you a big snippet of code to deploy via a rule to track their marketing campaign.

If you take a step back and analyse the code, you will notice that 99% of the code provided for each marketing campaign is identical and only one or two part of the code are custom IDs. At that moment you should apply the DRY principle and create reusable tags and data elements. Replace the IDs by custom code to call your data element that will return the correct ID.

It is also a good idea to transport this custom marketing pixel implementation into a private marketing extension for Adobe Launch. This way you can provide an easy and friendly interface for your colleague to use to deploy any marketing pixels. It also becomes easier to maintain as you will need to update the code version of the marketing pixels once by updating the extension.

Small builds

Try to avoid creating huge builds with a lot of changes. In most cases you can split your builds in smaller chunks. This will speed up the peer review and approval process and assure better quality.

As you follow these tagging standards you will see that overtime the quality of your tagging eco system will increase. As the quality increases, so will be your peer review process and your testing/debugging exercise. The complexity of your implementation should also decrease.