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
| Sections | Detail |
| Rule type | EBR: event based rule PLR: page load rule (top, bottom, domloaded ...) DCR: direct call rule Multiple types of rule should be separated by a pipe |
| Event Type | PB: page bottom PT: page top WL: window load (onload event) DE Change: data element change CLICK: click event on a DOM element It will be up to you to set your own acronyms for each event type Multiple events should be separated by a pipe |
| Location | The syntax for Location should be as follow: Brand - Page Name - Item interacted with 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 Examples: AA: Adobe Analytics AT: Adobe Target FB: Facebook pixels Custom: anything that is a custom code and does not fall inside any other action category type 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.
| Sections | Detail |
| Rule type | EBR: event based rule PLR: page load rule (top, bottom, domloaded ...) DCR: direct call rule Multiple types of rule should be separated by a pipe |
| Event Type | PB: page bottom PT: page top WL: window load (onload event) DE Change: data element change CLICK: click event on a DOM element It will be up to you to set your own acronyms for each event type Multiple events should be separated by a pipe |
i.e: PLR|DCR -- PT|directId -- Brand1 - Section1 - Page1 -- AA|AT|FB -- v1
This rule is both a page load rule type and direct call rule type. It can either be triggered at page top and in some instances by trigger the direct call id directly. It should only be executed if it is triggered for webpages that have brand = Brand1 AND siteSectuib = Section1 and pageName = Page1. Once condition are met, 3 actions should be done: one for Adobe Analytics, one for Adobe Target and the last for Facebook
hope this helps.
Related Conversations
