DTM can react to things that happen on pages, like when people click or something comes into view.
A relatively new feature is that it can also react to custom events (of the CustomEvent variety), and I want to show you how to make it do that.
I’d also like to add a slightly convoluted solution that perfectly fits what Wazowski would call “simple – yet insane!“
The use case, in case your friendly marketer wants you to explain it, is that sometimes, things happen on your site that are not triggered by a click or an interaction, and that DTM needs to be able to detect those.
An online shop in Germany that I work with uses events because some of the information they track is not available at page load time. Instead, the page loads some product data asynchronously.
When the data has finished loading, the page triggers an event using jQuery’s
trigger() method, which I guess is a common scenario. That event pretty much signals “all data is available now.”
Our challenge is that the usual “Bottom of Page” timing for Page Load Rules is likely (but not always!) going to be too early.
So how do we track that?
Yes, we can!
We can use an Event-based Rule, as I will show you. Alternatively, we could use custom code that is loaded in a Page Load Rule, but executed at a later stage (
setTimeout, anyone?). I think using an Event-based Rule is the better solution. It allows your friendly marketer to work with the rule as she’d usually do, whereas with custom code, she’d have to come to you for changes.
So let’s make an Event-based Rule.
There are two things about this rule that set it apart:
- The Conditions, and
- the “Tracking” settings in the Analytics section.
Let’s start with the Conditions section.
I have selected “custom” as the “Event Type”, then invented a name “myCustomDelayedPageLoadEvent”. I have also specified “#content” in the “Element Type or Selector” field, because that field is where I will dispatch my event on. Note the little “[x] Apply event handler directly to element” tick box… for me that was a prerequisite, the rule wouldn’t fire without it.
What I have done so far: told the rule to fire when a CustomEvent called “myCustomDelayedPageLoadEvent” is detected.
Now let’s take a look at the “Analytics” section of the rule.
This is a departure from normal best practice. Event-based rules are often used to track actions, and they almost invariably use
s.tl() for that, precisely because it “does NOT increment a pageview”.
But in this case, the Event-based rule is tracking the page load for me, so I set it to use
But Jan, you’ll say, won’t I have two page views then, every time the page loads?
Yes, you will. But I’ll show you how to suppress the original tracking that DTM wants to send on each page. We’ll get to that next week.
For now, all I want to say is that you can now treat the Event-based rule as your normal Page Load rule, with everything that means. Go ahead and fill in the analytics section, set “variables” to your hearts delight. Go and add custom scripting, if you feel the need to! Go and implement!
The Missing Piece
Something is missing, isn’t it?!
How does the Event-based rule ever fire?
Well, that’s your job. You have to put the code into your side that creates and dispatches the event. As simple as that. Think about it like adding code that calls Direct Call Rules, but more versatile.
If you want to test your rule, or just the firing mechanism, you can do so in the console.
var myev = new CustomEvent("myCustomDelayedPageLoadEvent"); document.getElementById("content").dispatchEvent(myev);
This should do the trick.
The Final Frontier
Let’s take this further. On a site that asynchronously loads content or data on all pages, we can build a mechanism based on the above that sort of allows us to track almost normally.
Next week, I’ll post an article that will describe the end-to-end solution. I have split this up because otherwise this would have been awfully long, and because both articles would have been less clear.
A question? How is this better than just calling a Direct Call Rule? Well…
For once, you have separation of tools. The web site code fires events, it doesn’t call
_satellite.track(). That in itself is worth it, if you ask me.
Secondly, you can have multiple rules trigger on a single event, doing such things as tracking a purchase with Analytics, affiliates, and other tools. The site developer has to fire the event, that’s all. What you do with it in DTM is your thing.
I would also venture that some sites do already use events, so all you have to do with DTM is “hook into them”. The alternative would be to ask your front-end developers to add
_satellite.track() calls. Try see how much they like that…
Frankly, there is no need for Direct Call Rule usage outside other rules anymore, but I’ll get back to that.
A very, very long time ago, I read an interview in a German music magazine. The people behind The Art of Noise were describing how they got their hands on a Fairlight sampler, locked themselves into a studio, and subsequently spent a lot of time doing things with it that were not in the manual. I like that spirit, and I hope my colleagues in engineering, product management, and support forgive me for treating DTM the way I do.