Data Elements vs Data Layer

Have you used a Tag Management system yet? And a Data Layer?

Both are good ideas in our business, for a variety of reasons.

The one I think is most relevant in this context here is that defining a Data Layer makes a lot of requirements, possibilities, assumptions and limitations explicit. I think in a situation where marketing and web development have to collaborate, explicit can only be good. The alternative is often expletive.

Anyway, I don’t think I have to convince anyone here. So let’s look at something that is related but not immediately obvious: Data Elements in Dynamic Tag Management (DTM).

Dynamic Tag Management

DTM is one of the Tag Management system out there, and it happens to be the one that Adobe uses. It used to be called Satellite before Adobe acquired it. These days, it is part of the Adobe Marketing Suite and free to use for any customer. Which means when Adobe Consulting deploy any of the Marketing Cloud solutions, we default to DTM.

And that means that there are a growing number of sites out there using DTM, and the probability that you (as a developer) will run into DTM is going up slowly.

In the general sense, that shouldn’t make a difference for you. You still embed a little bit of Javascript to bootstrap the tag management, and you still work with a Data Layer so whoever uses the tag management system has access to their data.

Now here’s a question for you: have you ever thought about how exactly the tag management system accesses your Data Layer?

You’re writing the name of the current page into some Javascript array object, like so:

	dataLayer = {'pagename':'Homepage'};

But how exactly does a marketer or whoever is using the tag management system get that value out?

Data Elements

In DTM, that answer has to do with Data Elements. They are one (often the easiest) way of getting that data and using it.

Here is what the definition of a Data Element looks like in DTM:

The Data Element has a name (“Page Name”), a type (“JS Object”), a path (ha! See! That’s how we read from the Data Layer! “dataLayer.pagename”), a default value (empty in this case) and a persistence setting (“Pageview”).

This looks very straight forward, but what we’ve done here is to tell DTM that we have a Data Layer, and that one of the pieces of information in our Data Layer should henceforth be known as “Page Name”.

So?

Yup, good question. What’s the point?

The point is that we have now enabled the marketer to very easily reference the name of the page when they set up any tool (Adobe Analytics, for example).

Let me show you.

DTM works with rules, event-based, on page load or custom. Normal tracking happens during page load, so with DTM your friendly marketer uses a “Page Load Rule”.

Within the rule, she defines what the different “Tools” should do, like so:

You can see that for Adobe Analytics, DTM defines that the Page Name (the most important attribute for a page, no less) should be set to “%Page Name%”.

What’s great about this is that your friendly marketer can just type a percent (“%”) into any field, and DTM will show a list of available Data Elements that she can use.

She effectively doesn’t have to think about where the data comes from at all, which can only be a good thing.

Notes

Remember that drop down that was set to “JS Object” in the definition of the Data Element?

We can set that to something else and get our data in different ways.

We could set it to “CSS Selector” and specify the path to an element in the DOM, then select what exactly we want to take from that element.

Or we might set it to “Cookie” and read the value of any cookie that we have access to.

This has the same effect as reading the cookie into a variable using Dynamic Variables, but it does it in Javascript, i.e. before the tracking call is sent, which means you can access and maybe modify it.

We could set the type to “URL Parameter”, pretty much like the getQueryParam plugin does.

And finally, we could set it to “Custom Script”. That will produce an editor, in which we can put any Javascript we want.

This is where we put our convoluted logic that parses the URL and sets a page name. Even though the Adobe consultant told us not to.

Two Data Layers?

In a sense, DTM comes with its very own, built-in Data Layer. Data Elements are the attributes. Your friendly marketer has direct access to those attributes and DTM allows you to define them as complex as you wish behind the scenes. Everyone’s happy.

The obvious question then is: why do you (as a developer) have to create a Data Layer that sits on your site, in your pages?

My answer to that — and it might be unqualified because I have not been a developer for over 10 years, and when I was I programmed in C on Palm OS and later in Java — is yes.

Why?

Because the trickery you can do in DTM with Custom Script will eventually come back and bite you. And there is nothing bad about a Data Layer that you make, because it makes things explicit. Explicit is good.