I’m pret­ty new to the ana­lyt­ics field. My back­ground is in soft­ware devel­op­ment, build­ing web­sites and apps for ad agen­cies on behalf of big brands. As a devel­op­er 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 pat­terns. My sites were lean, fast, and clev­er­ly built. They were works of art. They were my beau­ti­ful babies.

In this con­text, it is not hard to see how “ana­lyt­ics imple­men­ta­tion” can become dirty words the web arti­san dreads to hear. You want me to scat­ter your inline scripts all over my beau­ti­ful markup? You want me to wedge some mys­tery JavaScript in the midst of my mas­ter­piece? When my web­site is so lean and beau­ti­ful, why you got­ta gum up the works? Get your grub­by paws off my beau­ti­ful baby, baby.

Take A Little DTM To Ease Your Troubled Mind

Adobe Dynam­ic Tag Man­ag­er was cre­at­ed specif­i­cal­ly to address the con­cerns of your most dis­crim­i­nat­ing devel­op­er. With DTM, you don’t need to lit­ter your busi­ness log­ic, inter­face code, or markup with extra event lis­ten­ers or data col­lec­tion calls. If your appli­ca­tion code is bro­ken up into dis­crete mod­ules that each per­form a sin­gle 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 cou­ple 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 nat­ur­al that our vir­tu­ous skep­ti­cism should lead us to won­der what black mag­ic DTM is per­form­ing behind the cur­tain in order to pro­vide us with this fan­tas­ti­cal­ly non-inva­sive ana­lyt­ics imple­men­ta­tion process. Because DTM takes so much work out of the developer’s hands, it rais­es ques­tions about how that work is being done. What cor­ners are being cut in order to make such a sexy prod­uct? What about per­for­mance?*What about best prac­tices?*

With these con­cerns in mind, I want to address some of the com­mon ques­tions and objec­tions that some­times arise from the con­cerned cit­i­zens of the web devel­op­ment community.

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

This may be the most com­mon objec­tion we receive. The DTM pro­duc­tion library weighs in at around 55KB. To those con­sid­er­ing mak­ing the jump to DTM, this can feel like a lot of weight to drop on top of an exist­ing page load.

This seems com­pelling: if you want to be faster, you got­ta drop some weight, right? Count those calo­ries. I’ve seen The Biggest Los­er. I get it.

But this num­ber (55KB) does not tell the whole sto­ry. First of all, DTM’s CDNs use gzip to com­press its assets on the fly. This means that your 55KB DTM JavaScript file comes down the pipe weigh­ing some­thing clos­er to 15KB. Not so scary right?

To gain some con­text for this num­ber, let’s start by vis­it­ing your web­site. In fact, we can start by vis­it­ing vir­tu­al­ly any web­site. I’m going to go to Google, the famous­ly sparse, prodi­gious­ly quick-load­ing search page. If we pull up our devel­op­er tools’ “Net­work” tab, what do we see?

Well, we see 11 requests of sev­er­al dif­fer­ent fla­vors. Most­ly images and JavaScripts. Google.com’s JS when added togeth­er weighs in at 380KB, which seems like a lot, but hey, Google gets a pass since those 380 kilo­bytes are pow­er­ing the most pop­u­lar 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 con­sid­er that num­ber for a moment. 90 kilo­bytes seems quite a lot for a page so visu­al­ly sparse. Let’s take a look at the image load for a more visu­al­ly com­plex web­site. The home­page for Teal­i­um (ana­lyt­ics provider and web­site weight loss advo­cate; the “Biggest Los­er” of tag man­age­ment providers) is pret­ty snap­py look­ing. Let’s shuf­fle 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 web­sites use too many images–we all love pic­tures and they have made the inter­net nice to look at. The point is that con­ver­sa­tions about the sup­pos­ed­ly camel-back-break­ing weight of a 15KB JavaScript file are hap­pen­ing in a con­text where no one bats an eye at >500KB of images. In oth­er words, the kilo­bytes tak­en up by images are gen­er­al­ly not sub­ject­ed to the same scruti­ny as JS kilo­bytes. Why is this? Prob­a­bly because the val­ue of images is imme­di­ate and self-explana­to­ry, while the val­ue of any giv­en JavaScript is more abstract.

How­ev­er, if 15KB of JavaScript helps you to effi­cient­ly and afford­ably accom­plish your busi­ness objec­tives and pro­vides you with valu­able insight into how your cus­tomers 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 ana­lyt­ics tool, and some ana­lyt­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.”

How­ev­er, 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’ brows­er cache, cre­at­ing a triv­ial delay in page load times on suc­ces­sive page views (gen­er­al­ly <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 try­ing to increase the speed of a page load, over­all page weight is a major con­sid­er­a­tion, but there are oth­er vari­ables to consider.

To under­stand the life­cy­cle of an HTTP request, con­sid­er the fol­low­ing: if I want to car­ry a box from one side of the room to the oth­er, there are a few things that will dic­tate how quick­ly this can hap­pen. First, I have to walk over to the box from where I am stand­ing, pick up the box, and then car­ry that box back to the point where I start­ed. 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, trav­els to point B, then returns to point A, this time car­ry­ing a heavy load (the response). Con­se­quent­ly, the actu­al geo­graph­ic loca­tion of the request com­put­er in rela­tion to the response com­put­er will affect the time it takes to serve up content.

In order to facil­i­tate faster load times, dis­tri­b­u­tion of con­tent to client com­put­ers can hap­pen via con­tent deliv­ery net­works (CDNs), which are serv­er cen­ters dis­trib­uted around pop­u­la­tion clus­ters. When I make a request for an image host­ed on a CDN, that request will be dis­trib­uted and returned via the clos­est geo­graph­i­cal server.

DTM pro­vides this func­tion­al­i­ty right out of the box, and it does this using best-in-indus­try CDN ser­vices. If, how­ev­er, you wish to use a dif­fer­ent CDN or even your own servers, DTM pro­vides you with the flex­i­bil­i­ty to choose oth­er 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 ser­vices that involve an inter­ac­tion between a client com­put­er and a serv­er where a core appli­ca­tion is host­ed, there are always lots of deci­sions to be made about which computer–the client or the host–does the heavy lift­ing. It is easy to imag­ine that DTM could have been built as a much small­er JavaScript library run­ning on the client com­put­er that inter­act­ed with a robust “mid­dle­man” serv­er that processed data and then sent it on to ana­lyt­ics data col­lec­tion ser­vices (like Site­Cat­a­lyst or Google Ana­lyt­ics). And in fact, there are sev­er­al tag man­age­ment sys­tems that fol­low this pattern.

But there is a def­i­nite rea­son DTM chose ear­ly on not to opt for the man-in-the-mid­dle approach that these oth­er com­pa­nies have jumped into: By putting a pro­cess­ing serv­er between cus­tomers and ana­lyt­ics ser­vices such as Site­Cat­a­lyst or Google Ana­lyt­ics, these com­pa­nies cre­ate a sin­gle point of fail­ure for the col­lec­tion of ana­lyt­ics data; if their ser­vice goes down, your data is gone. Since DTM is dis­trib­uted and cached across all client com­put­ers, it is impos­si­ble for it to “go down” in this same sense.

By for­go­ing a mid­dle­man, DTM not only removes this sin­gle point of fail­ure, but also becomes essen­tial­ly trans­par­ent from the point of view of data col­lec­tion ser­vices. These ser­vices wrote their libraries in JavaScript (see Google Ana­lyt­ics’ ga.js and Site­Cat­a­lysts’ s.js), and DTM is a JavaScript library that speaks their lan­guage and facil­i­tates their use. DTM works so well with these libraries and ser­vices because it was built with the same phi­los­o­phy and oper­ates on the same plane–JavaScript run­ning in a brows­er 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 lis­ten for vir­tu­al­ly any kind of event occur­ring with­in the DOM, by default, it does not do this by attach­ing events to every sin­gle ele­ment to which it wants to lis­ten. Rather, it uses a tech­nique for lis­ten­ing for brows­er events called “event del­e­ga­tion.” This way of lis­ten­ing uses a prin­ci­ple of the browser’s DOM API we will call the When Chil­dren Make Noise, Their Par­ents Hear It prin­ci­ple. What this prin­ci­pal sig­ni­fies is that, if an event hap­pens on an ele­ment that has a par­ent (i.e. a “child” ele­ment), this event does not fire on the child ele­ment and then call it a day. No–this event “bub­bles” up to the clicked element’s par­ent ele­ment, and then it goes up on to that element’s par­ent ele­ment, and so on, until it reach­es the final par­ent. This is where DTM lis­tens. In this way, DTM “del­e­gates” the task of lis­ten­ing to the par­ent, and then itself deter­mines how best to deal with the received events.

DTM understands me.

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

That being said, the “upsides” of DTM were tar­get­ed and devel­oped with the exact­ing con­cerns of peo­ple like me–web devel­op­ers and soft­ware architects–in mind. As a result, DTM is a tool that I believe any mar­ket­ing team and devel­op­ment team can be con­fi­dent adding to their tech­ni­cal toolbelt.

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