Data Layer, from business to technical scope – Part II
pujoljulia March 28, 2016

This is the second part of  Data Layer, from business to technical scope – Part I post. As promised in this second part I’ll go through the connection between our custom Data Layer and the Tag Management System, specifically to Dynamic Tag Management and Google Tag Management. If you’ve read the first part of Data Layer post you already know how construct your own custom Data Layer where add your variables (information about actions, products, user…) and methods (SET – To fill Data Layer values, GET – To pull them from TMS and HANDLE – To habilitate new functionalities). Cool!


3.Technical implementation (II)

The first thing where we’ve to put the focus is the methodology, and by methodology I mean who does what and how. You should keep in mind the big picture of the overall process to know the blurry line that exists between your and the web developers’ work, as it’s not always as clear as we would want. Based in my experience, I’d recommend you to follow the next approach (I hope the Tealium folks don’t get angry to me for using their images :P):


The guy on the left is our dear web developer who has to pick up the information from the page/app and store it into the Data Layer. In order to control the Data Layer structure, he will do it through our methods, the SET methods (remember, a SET method it’s just a function embedded into an object). Let’s say we’re working on an analytics implementation for a subscription site, and as almost all subscription business, there are three plans:


Let’s say also that when a user clicks over some of them, no page loads and instead of this, a subscription’s form overlay is displayed. As a good analysts we are, we want to track some stuff like the Click Through Rate over each plan or/and the Form Sent Rate, meaning “from all people that have clicked over some plan, how many of them have finally sent the form?” Make sense, isn’t it?

To get those rates, we’re going to ask to our dear developer that detects when the users click over some plan to store some information into the Data Layer when the click takes place. I know what you’re thinking, why do not detect this events through the tag management by using jQuery (or TMS UI)? Potentially (with more or less success) you can, but let me remember to you how dangerous is to detect events by yourself by DOM scraping technique, as if one day a new plan is added or the button class/id changed, your tracking will suddenly fail. Do this job by ourselves has to be the latest of all options.


Got an agreement about how we’ve to proceed, let’s do the most essential task, which is add the Data Layer on the page. There are two different approaches:

This is my preferred method, since avoids a lot of problems regarding load page timings. That script has to be placed at the top of the page, preferable after close the </head> and must to be also placed before the Tag Management’s script.

If we take a look again to the above methodology picture, you realize that makes sense that the Data Layer script be placed before Tag Manager, since the data, especially for ‘Load Page’ events, has to be there before the Analytics or any 3th party tag be fired.

This approach (basically the same Google Analytics uses for their track snippet) loads the Data Layer script with the asynchronous way. There is a lot of debate out there between synchronous and asynchronous way, but basically the main difference is that this tag creates a HTML script tag and push the Data Layer script into it, which allows to the document loads the snippet in parallel to the others page elements, which means that if something fails into the snippet, the page performance would not be affected (you may have to read this paragraph twice!).

Go through this way may have some problems regarding page load timings, so Tag Management Systems scripts loads faster than Data Layer script, meaning that at the time TMS fires some ‘page based tags/pixels’ which contain a few page information we’ve previously requested to the developer, may not be placed at that moment therefore we will send blanks to Adobe/Google Analytics, Data Management Platforms or whatever pixel that requires page information.

One way to successfully avoid this situation is to inform to the Tag Manager when the Data Layer is ready:

As you can observe it’s really simple, all we’ve to do is to add an extra self invoke function that sends a signal to TMS (‘push an event’ for GTM and ‘direct call rule’ for DTM) indicating that everything is ready. That will change a bit the TMS setting up, since the trigger in GTM instead of ‘All pages’ will be a ‘Custom event’:

GTM - Custom Event Trigger

And the rule in DTM instead of ‘Add a Tool’ will be a ‘Direct Call Rule’:

DTM - Direct Call Rule

This little change does not affect on the GTM deployment’s methodology, but in DTM there are downsides due to the lack of rules on the ‘Tools’ section. From my point of view this is a terrible design mistake of the tool, especially nowadays with the massive use of ajax-call-based frameworks, which force us to leverage on Direct Call Rules for page load event, losing all UI features of that section.

Note that both approaches contain “//” which is the URL direction that points to the JavaScript file that contains our custom Data Layer. By putting this URL we are basically telling to the browser, and therefore to the TMS, that now there is an access to the Data Layer variables and methods. Cool!

Now it’s developer’s time, so let’s take back our example at the Part I of this post. This is the Data Layer we’d already built:

Basically in this example I shown you what the developers should do in order to push clicks-video and adds product data to the cart:

Through these calls the developer is calling the ‘dataLayer’ object, asking for a setBehaviour/set Product methods (remember, methods are functions within objects that do something with data) and give to them some information. As we build up these methods, we can actually do whatever we want with the data once it is into Data Layer (before be sent to the Tag Management system).

Taking back the subscription example (by which we get paid!) the developer should do a couple of calls, something like that:

In this case those two calls are simply filling the Data Layer with events information, however on the next posts I’ll share with you some extremely powerful methods (cookies management, scroll percentage view, user connection times…), but by now this example is enough to show you how to pick up and manage this information with Dynamic Tag Manager (Adobe Tag Manager) and Google Tag Manager.

Before you go through this explanation, I strongly recommend to read Jan Exner’s Blog as he writes good tips and tricks about work arounds with Dynamic Tag Manager.

One of the things that I really love about Dynamic Tag Manager is its ‘Data Elements’ (like ‘variables’ in GTM slang) which allow to build a really solid and straightforward data infrastructures. The advantage over GTM ‘Variables’ is that DTM ‘Data Elements’ just are executed if they are called, which means we can use them for do something without expect any ‘return’.

It may seems that this is not a huge advantage but believe me, it is (please read this post). Like with JavaScript functions, some times we may don’t want to return anything and maybe we just want to change some variable on the Data Layer, inject some event listener that executes once, take some variable parameter and saves it in a cookie or whatever action without expecting any return. With GTM unfortunately you just cannot (well, you should place the code into custom HTML tags and start to play around with rules and order tag firing… which is a mess), as its internal loading process goes several times over the ‘variables’ even them have not been called.

In the next posts I’ll cover the differences between DTM and GTM, but now let’s focus at how to read the Data Layer values from DTM. Remember, Data Elements are just variables that store a value so that then it could be used on DTM interface (pssst! they are just local variables into DTM object). There are different kinds of ‘Data Elements’:

data elements interface

As most of TMS systems, DTM allows to read information from different places of the browser/page, for example HTML pieces by scraping the DOM through CSS selectors, JS Objects (and has to be an Object since this option cannot execute a method into an object), Cookies or URL ‘GET’ parameters. Cool! These out-of-box features will allow us to rapidly gather all needed information but, as always, the interesting part comes up when the platform is able to manage a custom JavaScript snippets to take (or not) information and do with it whatever we want.

As I said before, Data Elements have to return (or not) something, in that case, as we want to read the Data Layer variables we need the ‘return’, so we gonna use this information across all DTM interface. Remember that the developer has already stored the data through SET methods and we’ve also created the GET methods in order to access to the private information on Data Layer (if this point is not clear for you, please read about private methods here), so we just have to invoke this methods in order to achieve this data.

Remind when we reproduced that process on the Chrome’s console on the Part I of this blog:

debugs Data Layer

Then we just need to reproduce that at the DTM interface, so let’s say we want to save the product’s category to a Data Element (select the Custom Script option):

Data Element Name
Custom Javascript Data Element DTM

Once we save this Data Element, it is available across the whole DTM interfaces by both UI features (writing ‘%’ at the text boxes) and code as well:

UI features

Data Element DTM User Interface


Data Element DTM code

Through the code’s way you will be able to manage the Data Elements’ values across all places where DTM allows to place JavaScript snippets (actually almost everywhere).

Like with DTM, you should keep in your bookmarks the Simo Aha’s Blog, so he’s the most reputable GTM blogger. The process in GTM is pretty much the same than in DTM but instead of using Data Elements let’s use variables, specifically custom JavaScript variable:

GTM variables

Again, like with DTM, this variable will be available across GTM interface by both UI features (writing ‘{{‘ at the text boxes) and code as well:

UI features

GTM Variables


GTM code variable

But in that case you won’t be able to debug easily this variables from de browsers’ console, as GMT assigns them a ‘gtm’ + timestamp value, which means there is no certain way to debug them except with the GTM preview mode or by console.log() method.

At this point the process is almost complete, developers have dropped the information on Data Layer and we have picked it up from the Tag Manager, just remains to send this data to the different platforms, subject that will be covered on next posts.

If you’ve read and understood all the technical process, now you can starting to realize how far you can go by building your own agnostic Data Layer platform . As a final advice, please don’t go straight away to the technical implementation without before to go through Goals Definition and Data Processing steps, as those two points will reveal what structure your Data Layer has to take.

4.Data Analysis

Data analysis is what all of this is about, we have gone through all points to arrive here, and once here I sadly have to tell you that I’m not the right person to teach you in this field. Data Analysis discipline is rising to unimaginable points being able even to predict user behaviour, so I’m pretty sure there are a lot of blogs over there talking about data models, correlations, predictions and stuff like that, but remember, before to start with Big Data, you’ve to learn about Small Data, which means to have a proper analytics implementation.

What you will find in this blog regarding Data Analysis is little tricks and tips that I’ve learned analyzing data into Google or Adobe Analytics and ways to export data to visualization tools to monitor data in real time and react quickly.

So, do you have a different approach about how Digital Analytics structures have to be deployed?


Your comment

Your email address will not be published. Required fields are marked *