Executing DTM at the top of the page

If you have been developing websites for a while, you will know that one of the typical recommendation is to execute as much JavaScript as possible at the bottom of the page. This is nothing new and Yahoo recommended it in 2007. The reason is very simple: JavaScript code tends to add a delay, both when loading the JS file and executing it; so, moving it towards the bottom, you make sure the HTML is loaded and the page is rendered before starting to execute any JavaScript. The user believes the page is loaded a bit sooner than when it is actually fully loaded. DTM knows that very well and this is why you have to add the two pieces of code: one at the top and one at the bottom of the HTML.

This approach works very well in most cases. DTM loads first the code that needs to be at the top of the page, but then allows you to defer the rest of the loading and executing at the bottom of the page, like Adobe Analytics, Adobe Audience Manager and 3rd party tags. This is the typical recommendation. The risk of this recommendation is that some page views might be lost, if the user moves away too fast.

However, there is one particular case where this recommendation fails very often. I was working with a well known British newspaper, helping them with the migration from another Web analytics tool to Adobe Analytics. They wanted to run both tools, side by side, for a short period of time, to make sure the numbers did not change too much. To our dismay, Adobe Analytics was showing a much lower number of page views than the other Web analytics tool. We realised that the problem was that Adobe Analytics was executed at the bottom of the page, as per the typical recommendations. The homepage of newspapers tends to be massive, taking many seconds, even minutes, to fully load. This means that the code at the bottom has the risk of not being executed, if the user clicks on a link or closes the browser tab after quickly reading the headlines.

The only solution in this case is to reorganise the code in a slightly different way:

  • The DTM header code needs to be moved to the bottom of the <head> section, ignoring the recommendation in DTM of pushing it to the top.
  • The DTM footer code should still be at the bottom of the <body>  section.
  • Add the data layer before the DTM header code.
  • Configure the Adobe Analytics tool to be executed at the top of the page.
  • Set all Page Load Rules that will be setting analytics variables to be executed at the top of the page.
  • The Data Elements used for Adobe Analytics cannot use CSS selectors.

This solution guarantees that the analytics code is executed most of the times, at the expense of delaying for a few hundred milliseconds the load of the page.

4 thoughts on “Executing DTM at the top of the page”

  1. Hi Pedro – found your article in a Google search. We are noticing the same trend in our situation. Would we have to set our Page Load Rules to all execute at Top of Page if we made this change? We have a very “touchy” setup with DTM with our tags – it took quite a bit of work by both on-shore and off-shore consultants to get it to execute properly. Changing even one rule to load differently breaks that rule. (It’s hard to explain, but this was a huge pain point for us right before we launched out site) Any thoughts on just changing Load Library to Page Top to improve data capture in AA? Thanks.

  2. “This solution guarantees that the analytics code is executed most of the times, at the expense of delaying for a few hundred milliseconds the load of the page.”

    Those few ms can become seconds on a 3G mobile connection. And every 100ms delay can translate in sales lost (this is a know fact). I would say that tracking your users like this vs the performance impact that can lead to lost sales is quite important.

    There are other techniques one could follow to fix the performance and not loose the analytics part as you say.

    So I would take with a pinch of salt this blog post.

  3. Nice point @Radu. We have a similar issue with DTM 30-40% of visits unrecorded per day vs Google Analytics (feel like we should have never switched from Signal). We will still be trying this approach, but also be keeping a very close eye on Mobile load times. Will post again with feedback of our test.


Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.