How you name your rules, events/triggers, tags and actions can have a big impact on the health of your TMS. You want to prevent duplicated conditions and logic as much as possible, to keep things simple, lighter, and less error-prone. You want to make things easier to find and easier to put into context.
Launch Rules, Events, Conditions, Data Elements, and ACTIONS
Let’s face it, the internal search functionality in Launch isn’t great. But there is much you can do to make navigation within Launch easier and cut down on duplicated logic.
For rule names, I often follow a format with some combination of the following:
category[: sub category] | trigger | [type (analytics or marketing)] | what the rule does/marketing vendor | load order | consent management category
For example:
- add to basket | “add to basket” event | analytics | s.tl | #50 | C0008
- all pages | page top | configure EDDL | #10
- all pages | “page view” event | marketing | verizon | #50 | C0004
- search: search results | “page view” event | analytics | set vars | #50 | C0008
Of course, it usually differs for every client depending on their needs. For me, the important thing is for rules with similar events/conditions to be together (all my search rules start with “search:”), to know what triggers it (page bottom? direct call rule?), and to have an idea of what’s inside. Here’s a simpler version:
Having it arranged this way already shows me for this property…. I have a lot of rules firing on that page view event. I could probably consolidate some of those into a single rule. I also see some inconsistency… one “page view” is lacking quotes, which makes the editor in me twitch a bit, and in that top one I didn’t specify s.t or s.tl beacon. But you know what? I can navigate this property pretty easily. And if I see an inconsistency, I can fix it as I go along. Some order is better than none.
Sometimes I only include the event order (eg, #50) if it’s something other than the default of 50. Sometimes we have analytics and marketing in the same rules so the standard has to adapt.
For events, I only change the name from the default if I had to customize it- page bottom is always just “Core – Page Bottom” (unless I changed the order, in which case I’d probably name it “Core – Page Bottom #1” or somesuch), but a direct call rule or something based on a CSS selector should always include that info in the name. For instance “click on .pdf links”, “DCR page view #25” or “payment modal enters viewport”. I won’t even be picky about following a standard… just keep it informative. If you changed the order (from #50 to, say, #1), then do note that. It makes troubleshooting so much easier.
Conditions should always have custom names. “Core – Value Comparison” is just not helpful… but “pageType of ‘search results'” is. Again, I’m not picky about following a standard… just make it so I don’t have to click into the condition to have an idea of what it is.
Action naming… this is where I get excited. Folks don’t take advantage of Action names nearly enough. Action names should include the marketing tag name and the scope. Within a rule, it might look redundant with the rule name (how many times do you see “All pages/Page Top” here) :
But if you search for a tag in the Launch’s search tool, those action names make a world of difference. Let’s say I’m searching for eVar63… this:
…is not helpful (by the way, please go upvote this feature request for better search functionality). I’d have to click in to each of those to find out what the context is to know which one I want to make my change to. But if I’ve added a bit of information to the action name, I can know exactly where it is taking me:
It’s a minor inconvenience when setting rules up, but if you have a complex implementation, it can make life so much easier.
For data elements, I tend to go much simpler. Some sort of categorization, then some sort of detail. If it suits the implementation, I might add more information about the source of the data. For example:
- search: term | QP
- search: number of results | DL
- marketing: cmpid
- content id: page name
I tend to always keep it lower case, since you have to have to right case when referencing a data element.
Don’t stop with good names, add even more info!
As I mentioned in my post on governance, it can be extremely helpful to include information about the tag within the tag itself, along these lines:
1 thought on “TMS Best Practices: Naming Conventions and Meta Info”