Absolutely nothing?
This article started as a side note in the article about delayed page load tracking, but I feel it deserves a bit more space. Side notes are so easily over-looked! And when they are, they wither away, hidden in the cracks of our memories, obscured by bigger things, better things, things that demand attention and push the side notes away. Not fair!
Direct Call Rules used to be side notes in my mind. I mentioned them a couple of times on this blog, but usually only in contexts like “better use an Event-based Rule than a Direct Call Rule”.
Until the July release of DTM, they were necessary in situations that can now be handled more elegantly with CustomEvent triggers and EBRs.
In a sense, they used to be a necessary evil that is no longer needed.
From the ashes
Maybe that necessary evil image stood in their way.
Let’s think back to the delayed tracking I wrote about in July…
The concept works nicely, and it is flexible enough, but it has one really big, dumb drawback.
Remember how we say that with the rules and Data Elements in DTM, it can be possible for your friendly marketer or someone in her team to fiddle with the tracking herself? Do we think she could do that with the code for delayed tracking? Highly unlikely.
![[Screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2015/06/150703-delayed-tracking-script.png){kind=tracking}
I mean the concept is fairly easy to understand, right? But you still have to put Javascript code into it to assign “variables“, and you have to think of adding those “variables” to s.linkTrackVars and s.linkTrackEvents.
Frankly, this is not what we want to do.
Here’s what we should do instead: use DCRs!
You — the developer — build the delay loop, as described. Inside the loop, you call a DCR, like so:
_satellite.track("myDelayedDCR");
Your friendly marketer then uses that DCR.
Three advantages:
- You don’t care about what the rule does, really. And you shouldn’t. Your job is to make sure tracking is triggered, let her do the rest.
- Your friendly marketer can now use the DTM UI to define what is tracked and how. That she can do!
- DTM (like most Tag Management systems) was built to allow not-so-technical people to change Javascript-based parts of the site. Using the UI, they can do so much more safely than if you had them wade into code.
This is where Direct Call Rules really shine, this is where they should be used!
Quick recap:
Page Load Rules are used for everything that should be tracked when pages load.They are also useful to inject any kind of Javascript into the page, especially Javascript that should be executed once per load.
Event-based Rules are used for things that happen on the page. That can be user interactions (clicks) or program-driven events.
Direct Call Rules can be used within other rules. If inside your PLR or EBR you want to explicitly call tracking (s.t() or s.tl()), consider calling a DCR, instead.
Makes sense?
(An example might be: if you are doing delayed page load tracking and you are 100% sure that you will only ever have to fire one single rule, you can ignore the Custom Event and just use a DCR and call it directly.)
Note
Craig Scribner makes an even stronger case for DCRs: the post has a nice example that illustrates what I wrote here, and then he recommends using DCRs instead of EBRs in general. I don’t think I’d go that far. The underlying problem Craig had looks to me like: “if you don’t make things explicit, developers will stumble over them”. And yes, using DCRs will force developers to make things explicit.
But I think there is no technical solution to what is essentially a social problem (communications), which means that you must find a process. Any process. And within a process, EBRs should/will work.
Maybe we really need TDD, so things like this don’t break easily.
What do you think?
Web Analytics for Developers 
Jan, How do you feel tagging can be accomplished under a page written with React? Does this type of environment scream out for DCR only simply because of a virtual DOM? any thoughts? We are moving from a conventional site to one written with React — Thanks
LikeLike
Hi Glenn,
Good question, and not an easy one to answer.
Ask Craig Scribner, and he’d surely suggest using DCRs. But EBRs would work, too, if you hook into element changes, or if you send events from React. The advantage of EBRs is that you can have more than a single EBR listen to an event. Good for things like 3rd-party tags…
Conversely, DCRs are easier to build, test, and maintain.
LikeLike
Good post and illustrating the use case Direct Call Rules were probably made for in the first place.
I personally use Direct Call Rules a lot, but more to make up for the interface deficiencies of DTM’s “Rule-based approach” which is sold as a superior method, but in my experience, it is the opposite, at least the way DTM has implemented it: It makes it impossible for me to see which third-party tags are actually implemented and in which rules without going into each rule and opening the “third-party tags” section.
Even worse, if I want to fire the same tag by two or more different rules, I would have to drop the tag’s code once into each rules (and of course when there is a change, I need to change all these files individually).
So instead of that, I put every tag into a Direct Call Rule which turns my “Direct Call Rules” section into what in other Tag Management Systems I have as a simple “list of tags”. That way I have an overview over which tags are actually on the site. The rules then simply fire a Direct Call with a number (e.g. _satellite.track(“D1200”) – all Rules start with a prefix and a number, e.g. “D1200 – AdWords Conversion Tag xyz”, so it is easy to conclude from D1200 to what is actually firing just by going into the Direct Calls section).
Downsides of this:
1. I makes overview and irredundancy better, but I still have to keep a separate documentation to have a good and fast-to-read overview over which tags are fired by which rules.
2. I am increasing server calls to DTM: One call for the one-liner tag in the Page/Event Rule which fires the Direct Call (e.g. _satellite.track(“D1200”)), and another one for the Direct Call (the tag itself).
3. Doesn’t work for synchronous third-party tags, as Direct Calls seem to be always asynchronous.
So after 2 years with DTM, I am still struggling to find a smoother system.
LikeLike
I’m definitely a fan of the Direct Call rules as well, with EBRs you have the major issue of dealing with cross-browser support and testing, and using a combination of PLRs and EBRs results in code that isn’t very self-documenting, something good developers should always shoot for. I still document all my rules and what data elements they need but it’s far less tedious than dealing with a combination of PLRs and EBRs. Like Lukas I just find it much easier to see the entire overview of what our rules and tags are with virtually everything in DCRs. In our case, we also have desktop and mobile sites that are fairly different (the mobile site being a single-page app) making DCRs ideal for a solution that works seamlessly across both sites. Quite simply, the combination of a good data layer and use of DCRs just makes for a far more elegant and less brittle solution. The main issues are not much different than you describe on the delayed load post with making sure you only fire one DCR per page or deal with cross contamination issues (obviously more of an issue with single page apps).
LikeLike
Thanks for the input, Mary Jo!
It turns out lots of people like DCRs. I am surprised, tbh.
Cheers,
JAn
LikeLike
How to know whether direct call rule is fired or not , also which direct rule is fired with out using DTM plugin , because DTM plugin is not working for some sites build using AEM
LikeLike
Hi!
All you have to do is to set DTM to debug. You can do that without the plugin! _satellite.setDebug(true); does the trick.
Might want to check Jim’s DTM Cheat Sheet for more gems like this: http://jimalytics.com/tag-management/updated-dtm-cheat-sheet/
LikeLike
I want to create a Direct Call Rule For a Ajax driven Page. The page loads asynchronously on the basis of number of parts searched i want to fire a direct call rule when all the parts are searched can you please illustrate with one example it would be really helpfull…
Regards
Chinmay
LikeLike
Hi,
That does sound like a post that I should write one day indeed.
Thanks for the suggestion!
LikeLike