Adobe Launch Tagging Standards
Tags: javascript, adobelaunch, tagging
Published: 2021-12-21 12:48:41

> 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
```

|Sections| Detail |
| --- | --- |
| Rule type | **EBR**: event based rule<br>**PLR**: page load rule (top, bottom, domloaded ...)<br>**DCR**: direct call rule<br>**Multiple types of rule should be separated by a pipe**|
| Event Type | **PB**: page bottom<br>**PT**: page top<br>**WL**: window load (onload event)<br>**DE Change**: data element change<br>**CLICK**: click event on a DOM element<br>It will be up to you to set your own acronyms for each event type<br>**Multiple events should be separated by a pipe**|
|Location| The syntax for Location should be as follow:<br>`Brand - Page Name - Item interacted with`<br>Each section can have more than one value, each value will be separated by a pipe|
|Actions| You should define your own acronyms for the action types you will deploy. Stick with the same acronyms across all of your web properties<br>Examples:<br>AA: Adobe Analytics<br>AT: Adobe Target<br>FB: Facebook pixels<br>Custom: anything that is a custom code and does not fall inside any other action category type<br>**Multiple actions should be separated by a pipe**|

> 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.