I’m pretty new to the analyt­ics field. My back­ground is in soft­ware devel­op­ment, build­ing websites and apps for ad agen­cies on behalf of big brands. As a devel­oper I was painstak­ing in my atten­tion to the archi­tec­ture and imple­men­ta­tion of the sites I built. I used the right tools, the best prac­tices, and the smartest patterns. My sites were lean, fast, and clev­erly built. They were works of art. They were my beau­ti­ful babies.

In this context, it is not hard to see how “analyt­ics imple­men­ta­tion” can become dirty words the web artisan dreads to hear. You want me to scatter your inline scripts all over my beau­ti­ful markup? You want me to wedge some mystery JavaScript in the midst of my master­piece? When my website is so lean and beau­ti­ful, why you gotta gum up the works? Get your grubby paws off my beau­ti­ful baby, baby.

Take A Little DTM To Ease Your Troubled Mind

Adobe Dynamic Tag Manager was created specif­i­cally to address the concerns of your most discrim­i­nat­ing devel­oper. With DTM, you don’t need to litter your busi­ness logic, inter­face code, or markup with extra event listen­ers or data collec­tion calls. If your appli­ca­tion code is broken up into discrete modules that each perform a single well-defined func­tion and you want to keep it that way, I salute you, and DTM is here to help you accom­plish and main­tain your design goals. All you need to do is add a couple of script tags, and you’re done.

Too Good To Be True?

Good web devel­op­ers are a skep­ti­cal bunch. While this is one of our many estimable qual­i­ties, it is natural that our virtu­ous skep­ti­cism should lead us to wonder what black magic DTM is perform­ing behind the curtain in order to provide us with this fantas­ti­cally non-inva­sive analyt­ics imple­men­ta­tion process. Because DTM takes so much work out of the developer’s hands, it raises ques­tions about how that work is being done. What corners are being cut in order to make such a sexy product? What about perfor­mance?*What about best prac­tices?*

With these concerns in mind, I want to address some of the common ques­tions and objec­tions that some­times arise from the concerned citi­zens of the web devel­op­ment commu­nity.

DTM is such a big JavaScript file! It’s going to increase my load times significantly.

This may be the most common objec­tion we receive. The DTM produc­tion library weighs in at around 55KB. To those consid­er­ing making the jump to DTM, this can feel like a lot of weight to drop on top of an exist­ing page load.

This seems compelling: if you want to be faster, you gotta drop some weight, right? Count those calo­ries. I’ve seen The Biggest Loser. I get it.

But this number (55KB) does not tell the whole story. First of all, DTM’s CDNs use gzip to compress its assets on the fly. This means that your 55KB DTM JavaScript file comes down the pipe weigh­ing some­thing closer to 15KB. Not so scary right?

To gain some context for this number, let’s start by visit­ing your website. In fact, we can start by visit­ing virtu­ally any website. I’m going to go to Google, the famously sparse, prodi­giously quick-loading search page. If we pull up our devel­oper tools’ “Network” tab, what do we see?

Well, we see 11 requests of several differ­ent flavors. Mostly images and JavaScripts. Google.com’s JS when added together weighs in at 380KB, which seems like a lot, but hey, Google gets a pass since those 380 kilo­bytes are power­ing the most popular web page in the world, right?

Screen Shot 2014-03-11 at 2.57.00 PM

But what about those images?

Screen Shot 2014-03-11 at 3.01.24 PM

Those images add up to 90KB. Let’s consider that number for a moment. 90 kilo­bytes seems quite a lot for a page so visu­ally sparse. Let’s take a look at the image load for a more visu­ally complex website. The home­page for Tealium (analyt­ics provider and website weight loss advo­cate; the “Biggest Loser” of tag manage­ment providers) is pretty snappy looking. Let’s shuffle our way over yonder.

Screen Shot 2014-03-11 at 3.17.13 PM

Whoo boy! 793KB of (gzipped) images! That’s a bunch. You could load DTM fifty times over and still not reach that kind of load.

The point here is not that websites use too many images–we all love pictures and they have made the inter­net nice to look at. The point is that conver­sa­tions about the suppos­edly camel-back-break­ing weight of a 15KB JavaScript file are happen­ing in a context where no one bats an eye at >500KB of images. In other words, the kilo­bytes taken up by images are gener­ally not subjected to the same scrutiny as JS kilo­bytes. Why is this? Prob­a­bly because the value of images is imme­di­ate and self-explana­tory, while the value of any given JavaScript is more abstract.

However, if 15KB of JavaScript helps you to effi­ciently and afford­ably accom­plish your busi­ness objec­tives and provides you with valu­able insight into how your customers are using your web prop­er­ties, what are you going to do? Ditch the JavaScript, or use one less jpg?

Okay, maybe DTM is not so big, but still: it’s loaded in the top of the page. While it loads, it blocks everything else on the page from loading.

Since DTM needs to be able to load any kind of analyt­ics tool, and some analyt­ics tools need to be loaded at the top of the page, DTM also needs to load at the top of the page. There­fore, it’s true that DTM is “block­ing.”

However, this block­ing occurs only the first time DTM is loaded on your site. Every time there­after, DTM will be loaded from your users’ browser cache, creat­ing a trivial delay in page load times on succes­sive page views (gener­ally <50ms).

Screen Shot 2014-03-11 at 4.22.11 PM

But the size of DTM isn’t the only thing that matters. What about the speed and reliability of delivery?

When you’re trying to increase the speed of a page load, overall page weight is a major consid­er­a­tion, but there are other vari­ables to consider.

To under­stand the life­cy­cle of an HTTP request, consider the follow­ing: if I want to carry a box from one side of the room to the other, there are a few things that will dictate how quickly this can happen. First, I have to walk over to the box from where I am stand­ing, pick up the box, and then carry that box back to the point where I started. How long this takes is deter­mined not only by how heavy the box is, but by how far I am from the box in the first place.

It works the same way with HTTP requests: The request goes from point A, travels to point B, then returns to point A, this time carry­ing a heavy load (the response). Conse­quently, the actual geographic loca­tion of the request computer in rela­tion to the response computer will affect the time it takes to serve up content.

In order to facil­i­tate faster load times, distri­b­u­tion of content to client comput­ers can happen via content deliv­ery networks (CDNs), which are server centers distrib­uted around popu­la­tion clus­ters. When I make a request for an image hosted on a CDN, that request will be distrib­uted and returned via the closest geograph­i­cal server.

DTM provides this func­tion­al­ity right out of the box, and it does this using best-in-indus­try CDN services. If, however, you wish to use a differ­ent CDN or even your own servers, DTM provides you with the flex­i­bil­ity to choose other options.

Why load so much JavaScript anyway? Why not just use a smallish JS library that sends all my analytics requests to a server that will process them there?

When build­ing appli­ca­tions and services that involve an inter­ac­tion between a client computer and a server where a core appli­ca­tion is hosted, there are always lots of deci­sions to be made about which computer–the client or the host–does the heavy lifting. It is easy to imagine that DTM could have been built as a much smaller JavaScript library running on the client computer that inter­acted with a robust “middle­man” server that processed data and then sent it on to analyt­ics data collec­tion services (like Site­Cat­a­lyst or Google Analyt­ics). And in fact, there are several tag manage­ment systems that follow this pattern.

But there is a defi­nite reason DTM chose early on not to opt for the man-in-the-middle approach that these other compa­nies have jumped into: By putting a process­ing server between customers and analyt­ics services such as Site­Cat­a­lyst or Google Analyt­ics, these compa­nies create a single point of failure for the collec­tion of analyt­ics data; if their service goes down, your data is gone. Since DTM is distrib­uted and cached across all client comput­ers, it is impos­si­ble for it to “go down” in this same sense.

By forgo­ing a middle­man, DTM not only removes this single point of failure, but also becomes essen­tially trans­par­ent from the point of view of data collec­tion services. These services wrote their libraries in JavaScript (see Google Analyt­ics’ ga.js and Site­Cat­a­lysts’ s.js), and DTM is a JavaScript library that speaks their language and facil­i­tates their use. DTM works so well with these libraries and services because it was built with the same philos­o­phy and oper­ates on the same plane–JavaScript running in a browser on the client computer.

DTM is going to put crazy amounts of event listeners all over my page! That will drag down the performance of my UI.

Although DTM can listen for virtu­ally any kind of event occur­ring within the DOM, by default, it does not do this by attach­ing events to every single element to which it wants to listen. Rather, it uses a tech­nique for listen­ing for browser events called “event dele­ga­tion.” This way of listen­ing uses a prin­ci­ple of the browser’s DOM API we will call the When Chil­dren Make Noise, Their Parents Hear It prin­ci­ple. What this prin­ci­pal signi­fies is that, if an event happens on an element that has a parent (i.e. a “child” element), this event does not fire on the child element and then call it a day. No–this event “bubbles” up to the clicked element’s parent element, and then it goes up on to that element’s parent element, and so on, until it reaches the final parent. This is where DTM listens. In this way, DTM “dele­gates” the task of listen­ing to the parent, and then itself deter­mines how best to deal with the received events.

DTM understands me.

I want to be clear: DTM is not “perfect,” and any tech­ni­cal solu­tion has its upsides and down­sides.

That being said, the “upsides” of DTM were targeted and devel­oped with the exact­ing concerns of people like me–web devel­op­ers and soft­ware architects–in mind. As a result, DTM is a tool that I believe any market­ing team and devel­op­ment team can be confi­dent adding to their tech­ni­cal tool­belt.

If you have any ques­tions about DTMs archi­tec­ture or tech­ni­cal details not covered here, please reach out to us–we would love to hear from you.