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.The great thing: you can then administer all tracking you want to do via Data Elements and the fields in the “Adobe Analytics” section of the rule.
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:
- Wait for the “normal” tracking on the page to fire
- delay a bit more
- track our data
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.
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
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.linkTrackEvents if you use
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!