Organize your Data Collection: Tags Rules

[#1]

Introduction

I've worked with hundreds of Adobe’s clients over the years and have analyzed just as many different data collection setups.  One constant theme in my analysis is that every client has a unique way of deploying (what is essentially) the same data collection solution. 

If a client's solution is doing exactly what it is supposed to do, then I won't make much of an effort to “rock the boat” in terms of their implementation.  However, I will intervene and try to provide guidance to those clients that either struggle to address their implementation pain points or would be open to making changes to help bring their already-solid implementation up a notch in quality.  

During these engagements, I bring as much detail and organization to my solutions as possible while trying to make them simple enough to follow, all with the following goal in mind: Once I'm done working on a client's solution, anyone who comes on board afterwards to analyze and update the solution can do so without the need to ask me what I've done.   

As part of that goal, I've come up with a set of guidelines that I use in all my Adobe Data Collection solutions – one of which is described in this post.  Specifically, I will provide my ideas on how to organize your Adobe Data Collection Tags (aka Launch) Rules.  As you build out your Data Collection solution, I know that following these best practices can help your implementation become more scalable and easier to follow. 

Note: This post focuses on only web-based properties, as the concepts here don't fully apply to mobile app-based properties. 

The Building Blocks

To start off, I need to emphasize the fact that every Tags rule consists of these three building blocks: 

• Events: An identifiable event that takes place on a web page that causes the rule to trigger 
• Conditions: Conditions are evaluated after an event triggers a rule and will determine whether the actions contained in the rule will be executed  
• Actions: Actions specify what the rule is ultimately meant to track/execute/etc. and will run after an event triggers the rule and the rule's conditions are met 

Since each rule consists of "events", "conditions", and "actions", labeling the rules with a naming convention that encapsulates those three items is a huge step to bringing organization to the implementation setup.

One of my clients uses such a naming convention as seen in the following (small) list of rules in their Tags property: 

• Library Loaded ~~ All Pages ~~ Get Adobe ECID 
• ACDL formError ~~ All Pages ~~ webSDK update XDM/sendEvent (formError) 
• ACDL formStart ~~ All Pages ~~ webSDK update XDM/sendEvent (formStart) 
• ACDL formSuccess ~~ All Pages ~~ webSDK update XDM/sendEvent (formSuccess) 
• ACDL linkClick ~~ All Pages ~~ webSDK update XDM/sendEvent (linkClick) 
• ACDL modalOpen ~~ All Pages ~~ webSDK update XDM/sendEvent (modalOpen) 
• ACDL pageLoad ~~ All Pages ~~ webSDK update XDM/sendEvent (pageView) 

As a small aside, "ACDL" refers to the Adobe Client Data Layer and the value that immediately follows the word "ACDL" points to the event contained in the ACDL push method's payload. 

Explaining the Building Blocks

Each rule name contains: 

• The event that triggers the rule at the beginning…  
  • "Library Loaded" (i.e., Page Top) 
  • "ACDL [eventName]" 
• Followed by a delimiter - I use the arbitrary value of "~~" 
• Followed by the condition(s) that will be evaluated once the event triggers the rule.   
  • "All Pages" means the rule has no conditions. 
• Followed by another delimiter ("~~") 
• Followed by a summary of the actions that execute once the event triggers the rule and the conditions are met.   
  • "Get Adobe ECID" points to code that calls the Adobe Web SDK's "getIdentity" command 
  • "webSDK update XDM" updates the XDM payload (i.e. an XDM variable-based data element) 
  • "sendEvent" refers to the Adobe Web SDK's "sendEvent" command while the value that follows in parentheses (e.g. "pageView", "linkClick", etc.) refers to the value of the XDM eventType field that is to be included with the sendEvent command's payload 

More Building Blocks for Larger Solutions

Most data collection solutions are much larger in scope than the example above. However, larger solutions can still leverage the same type of organization in the names of their Tags rules.  

For example, another client has the following four rules that trigger at the same time (i.e., when the Tags library loads at the top of the page): 

• Library Loaded (0) ~~ All Pages ~~ Load cookie consent manager & TrustArc library 
• Library Loaded (10) ~~ All Pages ~~ Deploy JavaScript Functions/Get ECID/Set TrustArc Flags        
• Library Loaded (20) ~~ Advertising Cookies enabled & Path!=buy-now ~~ Deploy 3rd Party Tags 
• Library Loaded (30) ~~ Advertising Cookies enabled & Path=home ~~ Deploy 3rd Party Tags 

You'll notice that each "Library Loaded" instance is followed by a number in parentheses.  This number points to the Order in which the rule runs its actions in relation to the other rules that are triggered at the same time.  The client needs the first rule (with "0" in its name) to execute its actions before the second rule (with "10" in its name) executes its actions.   After all, it's obvious that the "TrustArc library" needs to load first before we make any attempt to "Set TrustArc Flags".  😊  

Clarify Your Rules

Sometimes, the "events ~~ conditions ~~ actions" naming convention for Tags rules need to be fleshed out a bit more.  In those cases, I like to add something at the very end of the rule name that provides more explanation/detail.  For example, many Adobe Target deployments require a "Library Loaded" (Top of Page) rule that executes the Web SDK's sendEvent command with the eventType of "Decisioning Proposition Fetch".   Using my approach, the name of the rule would look something like this: 

• Library Loaded ~~ All Pages ~~ webSDK:Update data variables/sendEvent (Decisioning Proposition Fetch) 

Anyone unfamiliar with deploying Adobe Target code on a website might look at the name of that rule and wonder what it is meant to do.   To help mitigate such confusion, I would change the name of the rule to something like this instead:

• Library Loaded ~~ All Pages ~~ webSDK:update data variables/sendEvent (Decisioning Proposition Fetch) (for requesting Target personalization) 

Consolidate Your Rules

I want to emphasize an additional idea: You should minimize the number of rules that you add to a Tags property; specifically, you should combine all rules that are triggered by the same action and use the same order/conditions.   In a real-world example, I've seen a case where a Tags property contained five different rules that had the same setup as follows: 

1. All the rules were triggered by an ACDL push with the event name of "pageView" 
2. All the rules used the same order of operations value ("50" by default)  
3. All the rules had no conditions (i.e., "All pages" met the condition) 

Each of the different rules did have different actions tied to them, but since the rules (in relation to each other) had no specific order of operations, they absolutely could have been combined into just one rule (to rule them all?).  In other words, the following rules (with the following real-world names)…  

• 3rdParty - [Adobe DSP & Everesttech] 
• 3rdParty: AA, UA, AW, Tubemogul, Bing, HotJar, Surveys, Epsilon, Pinterest, FB, Twitter, Adobe DSP, Everesttech – pageView 
• Pageview 1a: All Pages[Tags=GA, FB] 
• PageView: All Pages [US | Tags=Pinterest] 
• Pageview: All pageView events [GoogleAds] 

…could be combined into one rule that is named the following: 

• ACDL pageView ~~ All Pages ~~ Custom Code: Deploy 3rd Party Tags 

Furthermore, if all the actions in these different rules were deployed via custom Javascript code, we could even combine the code from each of the individual actions into one big block of code that would be contained in a single action!  

Conclusion

In short, when it comes to the names of your Tags rules: 

• Keep them organized 
• Make sure they have enough detail 
• Make sure they're simple enough to follow.  

I’ve personally seen clients that have benefited from following these concepts.  Their implementation is now more comprehensible and easier to maintain for their marketers and developers that weren't part of the initial setup.   

I'm certain that following these guidelines will help set you up for success as well.  Of course, if you have your own ideas that have worked for you, feel free to share them in the comments below.   More than anything, what is most important is that you have any good system in place and that you just stick with it.   Thank you for reading!