Quick Tip: Delayed Tracking with DTM

Sometimes you find yourself in a situation where you need to track something outside the normal way.

Examples can be when you want to track data that is not available directly on page load, such as product availability.

Easy: use DTM

In theory, this should be easy: Just make a Page Load Rule, set “Trigger Rule at” to “Onload” under Conditions, and Bob’s your uncle.

Trigger Rule at Onload

But alas, sometimes this is not good enough. Sometimes you need to wait a bit longer, specifically if the site you are working with uses asynchronous loading of data.

There is an added bit of complexity with situations like these. You have to make sure there are no “race conditions”.

A race condition is when two pieces of code execute independently and do not always do so in the order you need.

The standard tracking on your page could be slow for whatever reason, and your delayed tracking could happen earlier. That could pretty much mess up tracking.

So what do we do?

Yes: use DTM

The answer is still to use DTM, but let’s make sure we deal with the race conditions. We will have to do three things:

1. Wait for the “normal” tracking on the page to fire
2. delay a bit more
3. track our data

The third thing is easy, we have done it before many times. But 1 and 2 deserve some more attention. Luckily for us, Javascript comes with two handy methods: setInterval() and setTimeout().

While setInterval() allows us to execute code repeatedly (like checking for something, maybe?), setTimeout() is good for executing code after a bit of time, once.

One question left: how do we know the tracking request has fired?

You can check for the existence of an object named “s_i_<rsid>”, which gets attached to window when the tracking call goes out. That is probably the easiest way.

So, without further ado, here is the complete code:

Delayed Tracking Script

Some of that needs a bit of explaining, I guess.

In lines 1 – 4, I load the necessary constants from Data Elements.

The rsid is an obvious one, and I’ll use “Check Interval” as the interval length for the setInterval() call, and “Delay Time” as wait time for setTimeout();

I have set “Check Interval” to 100 and “Delay Time” to 1000.

Meaning: the code will check every 100 milliseconds (10 times per second) whether tracking has gone out, then wait 100 milliseconds (1 second).

I used Data Elements for these constants because I’ll potentially be having multiple of these rules and I want to be able to change the times centrally.

Lines 9 & 10 check for the existence of that “s_i<rsid>” element.

Lines 12 – 17 cancel the interval timer plus the watch dog (more later).

Lines 20 – 25 are where your tracking code goes. You can set props, eVars and events here, then you must call s.t() or s.tl().

Don’t forget s.linkTrackVars & s.linkTrackEvents if you use s.tl()!

In lines 30 – 33 I define a second timeout. It waits 10s then calls a function that kills the interval. I don’t want that check to run on forever, and the assumption is that if after 10s no tracking has happened, it probably never will.

You could argue that this should happen much earlier than after 10 seconds, and I’d say you’d be right.

I hope this’ll help someone, and let me know if you can see any improvements!