Adobe Launch: Naming Conventions

I’ve thought a lot about Adobe Launch naming conventions over the past year or two. I’ve always been very principled: name your rules after the action and keep your Data Elements semantic. That was how it was intended with Satellite (pre-Adobe DTM)… and architecturally, things haven’t changed that much. You still have Rules and Data Elements. I’ve worked with quite a few implementations and each one has a different naming convention. Some name rules after actions. Some name them after the tag. Many mix and match.

Fine. Whatever. It’s a name. But why is it worth standardizing? It will save you time. A LOT of time. More goes into it than just a name. With it brings efficiency. So… personally? I don’t care what you name your stuff. If you want to do things the hard way, go for it. For the rest of us, I’d like to stick my neck out and recommend a better way to operate.

A Brief History

In the early days of tag management, there was an arms race that few people outside of the business knew about. This race was between Tagman, Ensighten, and Tealium. Each platform raced to put out as many tag templates as possible. Tagman boasted that they supported over 300 templates. Tealium had some similar number. It got ridiculous. Buying a TMS based on the number of templates is like buying a race car based on how many stickers it has.

We didn’t want to play that game with Satellite. For one, there are thousands of marketing vendors out there with implementation requirements that are constantly changing. Two, instructing a team to deliver and implement a pre-made JavaScript snippet is much easier than instructing them to scan code, locate pixel IDs, and paste them into code templates. As a result, Satellite was built around rules instead of tags. It was a different way of thinking about implementations. While some of the concepts were shared between each TMS, Satellite was one of the few focusing on efficiency instead of vanity (tag templates).

What made the tool so efficient wasn’t just the philosophy on third party pixels, but how these tags and pixels were deployed. Rules were developed to reflect actions people take on the site. Those actions correspond with one or many different tags. Instead of a list of 300 line items for 300 tags, you have maybe 15 Rules that contain 300 tags. It was just more intuitive.

Why it matters

Your implementation should make sense. Unless you plan on jockeying it forever, it should be transferable to other analysts. This starts intuitive naming conventions. An intuitive naming convention means I know exactly how to find tags within rules. Launch’s Search functionality looks for rule names and not rule contents. Aside from using a tool like Tagtician (which doesn’t make sense to use when you’re in the Launch interface), we can’t easily find our tags out-of-the-box.

As an analyst, I want to be able to easily answer the following:

1. What tags are in the rule?
2. Where does the rule fire?

At the same time, I don’t want to create one rule for every tag. Let’s say that a landing page URL changes – I would have to go through each individual tag’s rule and change the condition one by one. That’s inefficient, tedious, and unsustainable. Not to mention it just creates a lot of bloat and excess in your Launch library.

From a Data Element perspective, I want to be able to find variables using some kind of human language that makes sense. Data Element naming is especially important because you’re stuck with that name. We’re simply trying to answer the question: What is it?

My Proposal

Naming Rules

The most effective naming schema I’ve come up with is the following:

Scope | Detail | Event Type(s) | [Tools Array]

The first 2 parameters (Scope/Detail) are effectively the semantic description of what’s happening. The Event Type is how the rule is technically triggered. This is critical to understand so you don’t create multiple rules that do the same thing. The last parameter is the Tool Array, which describes the tags that are in the rule. This lets us leverage the search utility in Launch to find rules that contain specific tags. Since changing the rule name doesn’t affect your implementation, we can use it to improve our tagging governance and make our lives easier.

When someone asks for you to remove a pixel, you aren’t digging around each rule where that pixel might exist. If you’re having trouble remembering what you named each tag, I recommend leveraging a spreadsheet containing what abbreviations correspond with what tool. Below are some samples of how this naming schema works.

Example: All Pages Load

If we were implementing a DoubleClick pixel on DOM Ready of every page, I might name the rule:

All Pages | None | DOM Ready | [DCM]

For the Detail parameter, I input “None”. You can leave it blank or remove it altogether; but if you ever want to export your rules and parse the data in a machine-readable format, putting a parameter there would be preferable. Now let’s say I want to add Adobe Analytics and Google Analytics to the rule, I’d rename it to:

All Pages | None | DOM Ready | [DCM,GA,AA]

The beauty of this is I can now search for AA in Launch’s rule search to find all the rules that correspond with Adobe Analytics. One important thing to note is you’ll likely want to have a glossary of the various abbreviations you’re using.

Example: Landing Page Load

Landing Page | Fall Sale | Window Loaded | [DCM,GA,AA,AT,AdSense,DCO,ETC]

Example: User Login

User Login | Successful Login | Data Layer Event | [AA]

Character Length Considerations

The first thing that came to mind was that a rule with a lot of stuff in it might exceed a character length. As it turns out, there isn’t much of one. Rule names can be ridiculously long. For instance, I fit 8,058 instances of the letter ‘a‘ in a rule before it throws an error:

I was also able to cram in 6,000 characters of lorem ipsum:

 

 

Naming Data Elements

Arguably, a standard naming convention for Data Elements is more important than that of rules. Once you name and use a Data Element you’re basically stuck with it. Changing it means you have to find and change the name of that Data Element across your entire implementation. That could be a major pain in the ass. I’ve seen several methods for naming Data Elements. Some use camel case (pageLoaded or isUserLoggedIn). If you’re leveraging a data layer, it’s tempting to use the JSON path (page.pageName, user.isLoggedIn). Others use straight-up semantic naming (Page Name, Login Status)

There are pros and cons to each of these methods. The biggest PRO of the camel case and JSON path is that they’re easy to remember, assuming they reflect the variable name. However, this locks you into the JSON schema. If you ever change it (which you will at some point), the name won’t make sense anymore… and now you’re stuck with a counter-intuitive naming convention. Semantic naming is fine, but you have to remember the exact terminology you used to describe the Data Element.

I recommend using a blend. Unlike Rules, we don’t need to talk about the technical “trigger” details behind the Data Element (like Custom Code or Query String). Those will likely evolve and will change. We’re keeping it simple here. Remember, your implementation should be transferable to any analyst… meaning it should make sense. In my experience, the best Data Element names have a hierarchy, but do not necessarily reflect the full JSON path. I’ve stuck to 2 layers:

Category | Label

Example: Page Name

Page | Name

Example: Page Language

Page | Language

Example: User Login Status

User | Login Status

Example: User ID

User | ID

Character Length Considerations

You won’t hit the character limit for Data Elements. But just in case…

…yeah, I don’t think there’s going to be a problem here.

Final Thoughts

Adobe Launch naming conventions matter. They’ll make your implementation transferable. You don’t want to become a dependency. While it helps with job security, a messy implementation will drain your soul and you’ll never grow your role to bigger or better things (because you’ll be stuck maintaining it). If your implementation is so complicated that you can’t use an intuitive naming convention, I recommend you take a step back and figure out whether it’s worth designing a more effective architecture. I also recommend consulting with your development team to come up with a more sustainable tracking process. Not sure how to do that? Reach out – I’ll be happy to chat.