Adobe’s Dynamic Tag Manager has always given developers a chance to define exactly when a rule was called, by firing _satellite.track("insert rule name here"). This is called a Direct Call Rule (or DCR). They didn’t always get a ton of product love- after all, Event Based Rules don’t require work from developers and have so many more options- but many DTM users used them heavily because of the control they provided and how incredibly straightforward they were.
From my view, they historically had a few major downsides:
- Multiple DCRs couldn’t “stack” to form a single Adobe Analytics beacon, meaning you couldn’t have one DCR set your global variables and another set more user-action-specific variables.
- You couldn’t apply additional conditions (e.g. “don’t fire on the page with this URL”)
- There was no good way to clear out your variables so they wouldn’t persist from beacon to beacon
- You couldn’t pass additional information specifically scoped for Direct Call Rule. For example, if you fired
_satellite.track(“add to cart”), you had to make sure your overall data layer/data elements were already set up properly to show WHICH product was added to cart.
I’ve talked about how happy I am that Launch solved the first three points (here and here) but I’ve finally had a reason to try out how Launch handles #4.
You can now pass extra parameters into your _satellite.track function, like this:
_satellite.track("add to cart",{name:"wug",price:"12.99",color:"red"})
Then, when you set up a rule that fires off that direct call:
You can access the information on those parameters like you would access a data element, by referencing %event.detail.yourObjectHere%:
Or, if needed, in your custom code for that rule by just accessing event.detail:
You could even have a multi-leveled object:
_satellite.track("add to cart",{product:{name:"wug",price:"12.99",color:"red"},location:"cart recommendations"})
In which case you could reference %event.detail.product.name% or %event.detail.location%.
That’s all there is to it! Go ahead, fire this off in your console, and see our rule at work:
_satellite.track("add to cart",{name:"wug",price:"12.99",color:"red"})
I’ve seen this work in DTM recently, too, though I’m under the impression that may not be fully supported, perhaps (EDIT/UPDATE: it would appear this is NOT currently possible in DTM). Either way, this great enhancement can simplify data layers and Launch implementations and removes the need for a lot of previous workarounds.
[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]
Fantastic, worked like a charm! Thanks Jenn
Hi Jenn,
that was what i was looking for.
But i have a scenario here, clients had shared the evars and props to update the data and no info on the rules.
i don’t have access to the launch but need to implement the props and evars in my website,
Any suggestions from your end..?
Hm, if you don’t have access to Launch then there’s not really a good way to do this that I can think of. Launch is sort of an essentially piece of turning data on the site into analytics beacons. Even if there were a way to do it, I suspect it’s something that SHOULDN’T be done… it would defeat a lot of the purpose of Launch and any efforts to govern the implementation through Launch.
I wonder if there’s a chance to use how Launch is already set up- for instance, if they already have rules and data elements in Launch and you just need to know how to send data into them? If you use something like Tagtician, you may be able to see what they currently have set up and see if any of it would help you towards your goals? If they don’t already have anything in there for what you need, though, I’d push back for access to Launch.
Hi Jenn,
Great post, super helpful!
We are about to transition from DTM to Launch during the next few months. Now, we are adding some new features were using this way of passing additional information would be a good solution. The satellite.track() call is in place and working. When using Launch, I can get to the additional data as described in your post. It works like a charm. However, when setting it up in DTM, the satellite.track() call works but I can’t get to the additional data using %event.detail.xxx% in the Adobe Analytics configuration.
Do you know why that is and if any additional steps must be taken to get this to work in DTM also?
Thanks,
Tomas
Alas, I need to update the post- it would appear this is NOT possible in DTM, despite some old rumors to the contrary. I’m sorry for the confusion!
A developer needs to measure the number of times that a visitor adds a product to their shopping cart on an e-commerce site. The cart add functionality of the result in an error when the visitor pushes the ‘Add to Cart’ button if a quantity has not been entered. What type of Dynamic Tag Management rule and condition allows the developer to track cart adds?
A. An Event rule that will fire whenever the submit event occurs
B. A Direct Call rule that occurs immediately after a product is added to a visitor’s cart
C. An Event rule that will fire on the click of the “Add to Cart” button
D. A Direct Call rule that is set to fire on the click of the “Add to Cart” button
i am actually preparing for adobe exam could you please help me out with the asnwer!!I personally feel direct call rules cant be used in this particular scenorio!Am i right?? Anyways thamkyou!!
Direct Call Rules are actually great for things like submits/errors, because they let the developer communicate to DTM (or Launch) directly from their existing validation code. Basically, the developers are already checking for those error conditions- it’s ideal if you can have them add a Direct Call to the existing logic.
Because it seems to be the only option that allows for the developer’s validation/error-checking to occur (rather than attaching things to the user action of clicking/submitting the button, which happens before any of that validation occurs,) I’d go with answer B.