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.
Just look at the code…
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:
Your friendly marketer then uses that DCR.
- 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!
This is where Direct Call Rules really shine, this is where they should be used!
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.tl()), consider calling a DCR, instead.
(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.)
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?