category[: sub category] | trigger | [type (analytics or marketing)] | what the rule does\/marketing vendor | load order | consent management category<\/em><\/p>\n\n\n\n For example:<\/p>\n\n\n\n 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:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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. <\/p>\n\n\n\n For events<\/strong>, 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.<\/p>\n\n\n\n Conditions<\/strong> 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.<\/p>\n\n\n\n Action<\/strong> 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) :<\/p>\n\n\n\n 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:<\/p>\n\n\n\n …is not helpful (by the way, please go upvote this feature request<\/a> 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:<\/p>\n\n\n\n It’s a minor inconvenience when setting rules up, but if you have a complex implementation, it can make life so much easier.<\/p>\n\n\n\n For data elements<\/strong>, 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:<\/p>\n\n\n\n I tend to always keep it lower case, since you have to have to right case when referencing a data element.<\/p>\n\n\n\n As I mentioned in my post on governance<\/a>, it can be extremely helpful to include information about the tag within the tag itself, along these lines:<\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" 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 … Read more<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[23],"tags":[],"_links":{"self":[{"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/posts\/755"}],"collection":[{"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/comments?post=755"}],"version-history":[{"count":5,"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/posts\/755\/revisions"}],"predecessor-version":[{"id":833,"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/posts\/755\/revisions\/833"}],"wp:attachment":[{"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/media?parent=755"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/categories?post=755"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.digitaldatatactics.com\/index.php\/wp-json\/wp\/v2\/tags?post=755"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"](\"https:\/\/www.digitaldatatactics.com\/wp\/wp-content\/uploads\/2022\/06\/image-30.png\")
<\/a><\/figure>\n\n\n\n<\/a><\/figure>\n\n\n\n<\/a><\/figure>\n\n\n\n<\/a><\/figure>\n\n\n\nDon’t stop with good names, add even more info!<\/h2>\n\n\n\n
<\/a><\/figure>\n\n\n\n