UPDATE: The wonderful devs behind Adobe Launch have seen this and may be willing to build it in natively to the product. Please go upvote the idea in the Launch Forums!
As discussed previously on this blog, Direct Call Rules have gained some new abilities so you can send additional info with the _satellite.track method, but unfortunately, this can be difficult to troubleshoot. When you enabled _satellite.setDebug (which should really probably just be called “logging” since it isn’t exactly debugging) in DTM or Launch, your console will show you logs about which rules fire. For instance, if I run this JavaScript from our earlier blog post:
_satellite.track("add to cart",{name:"wug",price:"12.99",color:"red"})
I see this in my console:
Or, if I fire a DCR that doesn’t exist, it will tell me there is no match:
Unfortunately, this doesn’t tell me much about the parameters that were passed (especially if I haven’t yet set up a rule in Launch), and relies on having _satellite debugging turned on.
Improved Logging for Direct Call Rules
If you want to see what extra parameters are passed, try running this in your console before the DCR fires:
var satelliteTrackPlaceholder=_satellite.track //hold on to the original .track function _satellite.track=function(name,details){ //rewrite it so you can make it extra special if(details){ console.log("DCR NAME: '"+name+"' fired with the following additional params: ", details) }else{ console.log("DCR NAME: '"+name+"' fired without any additional params") } //console.log("Data layer at this time:" + JSON.stringify(digitalData)) satelliteTrackPlaceholder(name,details) //fire the original .track functionality }
Now, if I fire my “add to cart” DCR, I can see that additional info, and Launch is still able to run the Direct Call Rule:
You may notice this commented-out line:
//console.log("Data layer at this time:" + JSON.stringify(digitalData))
This is for if you want to see the contents of your data layer at the time the DCR fires- you can uncomment it if that’d also be helpful to you. I find “stringifying” a JavaScript object in console logs is a good way of seeing the content of that object at that point in time- otherwise, sometimes what you see in the console reflects changes to that object over time.
Improved Logging for “Custom Event”-Based Rules
If you’re using “Custom Event” rules in DTM or Launch, you may have had some of the same debugging/logging frustrations. Logs from _satellite.setDebug will tell you a rule fired, but not what extra details were attached, and it really only tells you anything if you already have a rule set up in Launch.
For example, let’s say I have a link on my site for adding to cart:
var addToCartButton = document.getElementById("cartAddButton"); addToCartButton.addEventListener("click", fireMyEvent, false); function fireMyEvent(e) { e.preventDefault(); var myCustomEvent = new CustomEvent("cartAdd", { detail: { name:"wug", price:"12.99", color:"red" }, bubbles: true, cancelable: true }); e.currentTarget.dispatchEvent(myCustomEvent) }
With my rule and _satellite.setDebug in place, I see this in my console when I click that link:
But if this debugging doesn’t show up (for instance, if my rule doesn’t work for some reason), or if I don’t know what details the developers put on the custom event for me to work with, then I can put this script into my console:
var elem=document.getElementById("cartAddButton") elem.addEventListener('cartAdd', function (e) { console.log("'CUSTOM EVENT 'cartAdd' fired with these details:",e.detail) }, false);
[icon name=”info-circle” class=”” unprefixed_class=””] Note, you do need to know what element the custom event fires on (an element with the ID of “cartAddButton”), and the name of the event (“cartAdd” in this case)- you can’t be as generic as you can with the Direct Call Rules.
With that in place, it will show me this in my console:
Note, any rule set up in Launch for that custom event will still fire, but now I can also see those additional details, so I could now know I can reference the product color in my rule by referencing “event.detail.color” in my Launch rule:
Other tips
Either of these snippets will, of course, only last until the DOM changes (like if you navigate to a new page or refresh the page). You might consider adding them as code within Launch, particularly if you need them to fire on things that happen early in the page load, before you have a chance to put code into the console, but I’d say that should only be a temporary measure- I would not deploy that to a production library.
What other tricks do you use to troubleshoot Direct Call Rules and Custom Events?
[author] Jenn Kunz [author_image timthumb=’on’]https://33sticks.com/wp-content/uploads/2018/03/Jenn.Kunz_.jpeg [/author_image] [author_info]Jenn is an industry expert on Adobe Analytics, Implementation, Tag Management, and Data Layers. Her favorite video game is currently Horizon Zero Dawn, her favorite board game is currently Ex Libris, and her favorite books are the Stormlight Archive by Brandon Sanderson.
She is based out of Marietta, Georgia.[/author_info] [/author]