Since its initial release in 2017, Adobe Launch has come a long way. The extension library is growing steadily and there are new features being added over time. Another great element of Adobe Launch is that its product team is actively involved on #measureslack and takes feedback from the community seriously.
Adobe Launch has even added new features which grant the ability to:
- Republish previous libraries
- Copy entire properties
- Leverage an event-driven data layer (EDDL)
- Add comments to rules, data elements, extensions, and libraries
While the Launch product itself is constantly evolving and new features are being added to make deployments easier and faster, there is one thing that will always require strategic planning and discipline: the creation, documentation, and enforcement of a naming convention.
Why Do You Need a Naming Convention in Adobe Launch?
Adobe Launch does a solid job pre-populating rule actions, conditions, and events. You might have noticed that whenever you select an extension and action/condition/event type, the name is populated automatically, following the syntax [Extension Name] – [Type].
By simply looking at your rule configuration, you already have a pretty good understanding of the event types, conditions, and actions being used in that particular rule. Plus, this naming convention is automated and easy to look at.
Now, let’s talk about areas within Launch where such an automated naming convention doesn’t exist. Namely in:
- Data Elements
They all have one thing in common: YOU need to provide the name.
And most likely not just you, but several teams and individuals, internal and external.
Teamwork makes the dream work—I don’t disagree with that statement. But I also think that establishing and documenting a naming convention enables teams to navigate more comfortably within your organization’s “way of doing things.”
I’d even argue that it’s generally better to have an internal playbook (that you can love, hate, criticize, and improve) than not to have an internal playbook in the first place. Such a playbook ensures that the organizational knowledge doesn’t disappear with people leaving the company. Even better, it can be a handy resource for onboarding new people as well.
Having a standardized naming convention is a win-win situation for all parties involved. Teams and individuals don’t have to make up names on the fly and your Launch property will remain nice and tidy at the same time.
Let’s take a look at the different areas one by one and share some of the best practices we have developed over time for our clients.
Disclaimer: By no means is this the only “right” way to name things in Launch.
Property Naming Conventions
Assuming it’s not the first time you’ve logged into Launch, the list of properties is the first thing you’ll see. A compelling naming convention is key to quickly identify the purpose of a Launch property and more frankly, to know which property to use for the tracking scenario you are about to implement.
If your organization owns multiple brands—each with its own tech stack, teams, and tracking scenarios—feel free to incorporate the respective brand into the property name.
In this case, we use the syntax [Company] – [Brand].
If your business and your digital presence are structured into different regions, each with their own tech stack, teams, and tracking scenarios, you can include the region identifier in the property name as shown below. This follows the syntax [Company or Brand] – [Region].
If your digital presence includes multiple platforms, e.g. you have a website and a mobile app, feel free to include the platform in the property name itself. That way, you can quickly identify the purpose and platform of each property.
The syntax for this method is [Company or Brand] – [Platform].
If you are in Launch every day, you probably know that there is a column to sort the properties by platform.
While I agree that this feature comes in handy once you are actually in the Launch user interface (UI), the nature of the consulting business requires us to often debug and understand the fundamental tracking set up before we even get access to the tools.
In this case, all you have to use is your debugger, which will show you things like property name, library build date, extensions, etc. This use case shows that if you have the chance to add some meta-information about the property in the actual property name, you should take advantage of it.
Depending on the size and structure of your organization, you’re likely inclined to use a hybrid solution and to leverage a combination of the introduced property naming conventions.
See below a scenario where the company Bounteous owns three brands:
Brand A has a separate web presence for the two regions:
Brand B manages the following platforms globally:
By following our suggestions, your naming convention for this scenario would look similar to this:
Rule Naming Conventions
Alright, we established a solid naming convention for our properties. Let’s move on to rules. So far, our clients like the two following approaches the most:
Including Rule Elements
A single rule consists of:
- An Event – Which serves as the trigger
- A Condition – To narrow down when the trigger should or shouldn’t fire
- An Action – To set variables or to fire custom code or marketing pixels
Now, it might be overkill to ALWAYS include all three of those elements but depending on the use case, a combination of them can be useful.
Let’s say you want to fire two different events for pageviews on two different site sections. Instead of leveraging one rule and custom code, you chose to implement one rule for each site section. In this case, you could name your rules as follows:
Just by looking at the rule name, it’ll be crystal clear when and where these rules are supposed to fire.
Including Tracking Categories & User Actions
The most common approach amongst our Launch implementations typically follows the simple syntax: [Tracking Category or Trigger] – [User Action]
We take this approach to first, group together rules of the same tracking category:
By default, Launch sorts rules by their name. If you don’t know what rule you’re supposed to look for, you can simply browse through the aggregated list and get a general understanding of the implemented tracking scenarios. In the screenshot above, our three categories are:
- Site Search
Pretty easy to spot, right?
Secondly, it also makes rules searchable.
Let’s say that after generally browsing the rules, you’d like to take a closer look at a specific category. You can simply filter the rules by searching for the category that they are prefixed with, e.g. you can take a look at the eCommerce-related rules only by searching for “eCommerce.”
Take a look at our examples below:
Example: Ecommerce Tracking
Example: Form Tracking
Example: Search Tracking
Hopefully, the Launch product team will introduce a native way of grouping together rules in the near future. Google’s tag management solution Google Tag Manager (GTM) solved this problem with the folder function.
In Launch, data elements can be referenced:
- In the UI, using the
- In custom code, using the
_satellite.getVar(“data element name”) syntax
To prevent reference issues due to capitalization and spacing, we lowercase (most of*) a data element’s name and avoid spaces. Unfortunately, this is necessary because Launch internally identifies data elements not with an underlying ID, but with the actual name instead.
We use a (mostly*) lowercased, colon-separated naming convention, which contains:
- The extension abbreviation
- The data element type
- A searchable detail
Our data element syntax looks as follows:
[extension abbreviation] : [data element type] : [< searchable name >]
Including Extension Abbreviations
For the first part, the extension abbreviation, we came up with the following values:
Including The Data Element Type
Including A Searchable Detail
Let’s take a look at those two examples:
1. Retrieve the cookie “my_cookie”
For demo purposes, I didn’t include the data layer’s root object in the name in order to avoid truncation in the screenshot. In an actual implementation, I’d include the data layer’s root element and name the data element cr:jsv:yourDataLayerRootElement.page.pageName.
Consistency is Key in Adobe Launch
Having a consistent naming convention will greatly benefit your Launch implementation. Adobe Launch offers a reliable option for automated naming convention for events, conditions, and actions and we like to use the same casing and delimiter for naming our properties and rules.
For naming our data elements, we eliminate whitespaces, replace them with a colon instead and stick to identifying elements like the exact name of a data layer variable or a cookie.
As established earlier, there is no one-size-fits-all approach for naming and organizing your Launch implementation. For an alternative way of naming things, take a look at Jim Gordon’s naming convention. Spoiler Alert: He uses pipe-delimited values and brings extension abbreviations into the rule names.
If you are interested in learning more about how we use Launch, check out our Adobe Launch Best Practices.