Reference – DTM Load Order

As you all know (I hope), there are about a dozen or so places in DTM where you can open an editor window and happily put Javascript code which DTM will later execute on your site if the conditions are met.

This is a very powerful feature which I love dearly.

When you love someone, it is a good idea to try to learn how they work. The same goes for features you use a lot. For this particular feature, that means finding out in what order (if any) all these snippets of Javascript are being dealt with.

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)

More Detail

So I made a test page.

I built the simplest web page ever, added DTM to it and a couple of lines of Javascript that all use console.log() to output when they get called. This is the page:

In DTM, I built 5 Data Elements and 4 Rules.

1. A DE that always returns “j” (using custom Javascript, of course), which I used as a condition in my rules,
2. 4 DEs that returned a static value (again using custom Javascript) which I used in the 4 Rules,
3. 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 console.log() calls.

In terms of Javascript snippets, that gave me:

• 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):

Awesome? Yup.

Lines that start with “SATELLITE:” are generated by DTM in debug mode, and the lines starting with “page:” are in the page itself, but everything else is some line of Javascript somewhere in some rule letting us know it just did some work.

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!

Order (no)

Before I go into any details, let me share my two big takeaways.

First: there are pieces of Javascript that might not execute at all. And some that won’t matter.

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!

Details

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.

Conditions

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

A little surprise when you compare sequential and non-sequential Javascript blocks: the sequential blocks come before their non-sequential friends for Page Rules that fire at “Top of Page” or “Bottom of Page”, but it is exactly the other way round for rules that fire at “DOM Ready” or “Onload”.

That reflects the order in the chart, so I really shouldn’t have been surprised, to be honest.

Also: all Javascript blocks are loaded in extra files when their respective rules fire, with two exceptions: sequential Javascript blocks in “Top of Page” & “Bottom of Page” rules seem to be embedded in the core DTM code.

Analytics 1

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!

Analytics 2

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.

Javascript in those “Javascript/Third Party” blocks is different.

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!”

Event-based Rules

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!