Bringing clarity to Adobe Launch using Call Traces
The Adobe Experience Cloud (AEC) comes with its very own Tag Management System (TMS). With Adobe Launch, by Adobe, implementing a basic set of AEC tools like Analytics or Target is quick and easy. That ease of implementation regarding Adobe’s own tools comes with the possible downside of having to put in more work for non-Adobe tools. Depending on how important those Adobe tools are to you, Launch might be your first choice as TMS regardless.
Unfortunately, Launch is not ideal when it comes to more complex setups. For example, having a chain of actions that needs to be executed in a specific order can require some manual workarounds, like putting steps into separate rules. The same is true for guaranteed conditional execution within rules, which requires either custom code actions or branching rules into multiple others. I have seen setups with literally hundreds of rules because of those restrictions.
So, how can we stay on top of this complexity? First, by using Direct Call Rules (DCRs) to trigger other rules within Launch. It’s the only officially-supported way how Adobe wants us to chain rules together. When we do that, we can access the history of which rules have happened before a certain later rule and send that information to our Analytics system. With that information, it’s easy to debug complex, conditional call chains to see where data is going missing. We are going to build a chain like this within a Data Element:
So, let’s get started!
Collecting information about rule execution
First, we start by creating three rules for debugging. The first should trigger by itself (Page Top in my example) and call the following two rules via Direct Call. The second rule is invoked by the first rule and will call the third rule, which will trigger an Adobe Analytics page view beacon. Here are my three rules:
Now we want to take a look what information is available to these rules when they run. Every Launch rule has access to an object called “event”, containing some metadata about the rule. To take a look inside that object, we put a custom code action into the first and second rule to log that object to our browser’s console:
Build this into a Library and push it to some environment. In the browser console, you should now see something like this:
The first output already shows us the basic structure of the event object. It has a $type attribute, showing the extension and type of the used event (in this case, “core” is the extension and “library-loaded” the type of event). What is more interesting to us is the $rule object, which holds both the rule id and the rule name as attributes. This name is exactly what we are looking for!
Now with the second rule we can see some of the magic that Launch is doing when Direct Call Rules (DCR) are used. Since this is a DCR, it has an “identifier” attribute, showing which specific name has been used for the rule. But more importantly, it has a new attribute called “detail”, which contains all of the information about the first rule:
If we would call even more rules after that second rule, those would also contain all of the call history in an ever-growing nested object. Now we could just use this in a custom code action like we already did, but there is an even launch-ier way.
DRY with Data Elements
Using a custom code action for our endeavor would have some serious downsides, since we would need to put that code into every rule that is sending out data. That would not scale very well and would be horrible to maintain. But luckily(?) we can put custom code in Data Elements! And since Data Elements are evaluated every time they are used in a rule, they are very dynamic in how we can use them. Yet the best thing is: Data Elements have access to the same event object that the underlying rule uses!
So we will use a Data Element to hold our Call Trace. What we need is a custom code Data Element that checks if the event object contains a “detail” attribute, loop over that attribute and chain all the different rule names together. I’m not a JS expert by any stretch, but here is what I came up with. Feel free to replace the separator from ” > ” to anything you want:
if('detail' in event){
var callchain = loopDataElementDetail(event.detail) + " > " + event.$rule.name;
}
else{
var callchain = event.$rule.name;
}
function loopDataElementDetail(detail){
var callchain = detail.$rule.name;
if('detail' in detail){
callchain = loopDataElementDetail(detail.detail) + " > " + callchain;
}
return callchain;
}
return callchain;Save this code to a Data Element, give it a good name and throw it into an action that sends out some data (I use my trusty Adobe Analytics) so we can check the result. I’ve run this with twice in two ways, one with three steps and one skipping step 2. This gives me those nice Analytics calls:
Nice! In Analytics, we would now see that two page views happend and could correlate them to the execution in two different ways. We could also go a bit farther (tracking the rule id into a list var, then classifying the id with the Launch API) or add more details beyond the rule’s name. But with this little code and just one Data Element, I’m already quite happy with the result.
Conclusion
Staying on top of your Launch implementation is a challenge, but I think with this new data point we can have a good tool for debugging our implementation. Using this new tracing method, we can easily correlate missing or wrong values to changes in the involved rules and their order. Since a lot of companies already track the Launch library version, this Data Element adds another tool to your data-quality toolbox.
As always, let me know what you think about this post and have a nice day!
German Analyst and Data Scientist working in and writing about (Web) Analytics and Online Marketing Tech.