This is a very powerful feature which I love dearly.
There is a chart in the documentation that shows how DTM timing looks like relative to the browser’s view of the page life cycle. That is a good start!
But I want more! Always more! (That’s not true, but it reads nicely)
So I made a test page.
console.log() to output when they get called. This is the page:
In DTM, I built 5 Data Elements and 4 Rules.
- 4 Page Load Rules that fired at “Top of Page”, “Bottom of Page”, “DOM Ready”, and “Onload”, respectively. They were pretty identical, except for the text in the
- 1 snippet per Data Element, so 5, plus
- 4 — 5 snippets per rule (custom condition, sequential JS, non-sequential JS, Custom Page Code in the Analytics section, plus the “top” and “bottom” rules had a
<script>tag in a sequential HTML block, so 18
for a total of 23 scripts. Wow!
Then I held my breath, opened my browser and the console and opened the page.
I took a screenshot of the resulting console output (actually, I took a lot of those. In the beginning, I thought I could capture all the permutations. I gave that up pretty quickly. Then I started colouring it in and noticed little errors, and so on… there is work in this screenshot, ladies and gentlement, please appreciate it accordingly!), made it more visually appealing and started analysing what happened.
Let me show you the screenshot (you might have to open it full screen):
Every single one of these lines represents an opportunity to do something with your page. I am obviously most interested in the Analytics aspect of this, so every one of those lines represents a place where you can capture data!
Before I go into any details, let me share my two big takeaways.
In my case, the Custom Page Code in the Analytics section of the “Onload” Rule did never fire.
The reason for that: this code works a lot like the old
doPlugins() method, it gets called just before the tracking request fires. And if you look closely, you can see the “SATELLITE: Adobe Analytics: tracked page view” message is actually above the lines written by the “Onload” rule.
Even some of the code in the “DOMReady” rule gets executed after tracking has happened, which means I should not rely on those locations for anything to do with Analytics.
Second: do not rely on the order!
As you can see, there is a decent amount of “interleave”.
The “JS in custom script in data element (bottom)”, to take one example, appears quite some time after the other snippets in that rule.
If you are a developer, you sometimes use shortcuts similar to the concept of inheritance in OO languages: you write a value into some variable and then somewhere else overwrite it for specific situations.
A remote control app for an RC car might have a variable for current driving direction (“forward”/”reverse”). I would bet you that in most implementations, that variable gets set to “forward” per default, and only overwritten with “reverse” when the RC car actually goes backwards.
No? Well, maybe you have to be a bad developer to do that. I can certainly affirm that I do it like that.
Btw: the rules I built were made without any overlap on purpose. I had only a single rule fire per point. If you have multiple rules fire at “Bottom of Page”, you get more of this.
So the learning here is: do stay clear of anything that could lead to race conditions. Avoid it like the vampyre avoideth the Sun!
If you haven’t got much time, feel free to leave now. The rest of this article will be about the details. I’ll keep noting them down until I bore myself, at which point this article will unexpectedly break off.
There is a nice pattern in there where for every rule, we can see the two conditions and then DTM tells us that the rule fired.
Funny enough, the order of the two checks is not always the same. It matches the order in the UI, simple as that.
Sequential v Non-sequential
That reflects the order in the chart, so I really shouldn’t have been surprised, to be honest.
You can see two instances of “SATELLITE: Adobe Analytics: set variables.” before “SATELLITE: Adobe Analytics: loaded.”
So what happened to those variables set before the load?
Might be worth a test.
Note though that it might be dangerous to use
s_gi() in your rules! It might not be there yet!
I mentioned above that Analytics fires a tracking request before all other scripts have completed, and I think that is perfectly reasonable.
“Tools” in DTM are more than just names. They come with their own settings, UIs, and — crucially — knowledge about processes.
For Adobe Analytics, the tool knows that it has to collect data from potentially more than a single rule, merge it all together and then finally track.
Have you ever wondered why you don’t get one tracking request per Page Load Rule? Well, the Tool handles concurrent rules, thank you very much.
The code in there has no connection to the Analytics Tool, so the Tool doesn’t wait for it. You can clearly see the JS blocks of the “DOM Ready” Rule come up after the tracking.
So that’s ok.
And what about the “Onload” rule? That has code in the Analytics section after all?
I’m guessing here that DTM trades off timeliness against completeness, but I am not sure. Could also be that it just decides “Oh, I have done tracking on this page already, am not going to do that again!”
As you can see in the screenshot, I built my page so that I could also instrument a link.
It might be interesting to see how Event-based Rules behave.
For now, though, I am quite happy with my test, and before I do actually bore myself, I’ll leave you with one piece of advice (a repeat, but important):
Do not rely on the order!