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:

[Screenshot]
Definition of a Page Name Data Element
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:

[Screenshot]
Data Element used in Page Load Rule
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.

[Screenshot]
List of Data Elements in Field
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.

[Screenshot]
List of Data Element Types
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.

[Screenshot]
Data Element Type CSS Selector
Or we might set it to “Cookie” and read the value of any cookie that we have access to.

[Screenshot]
Data Element Type Cookie
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.

[Screenshot]
Data Element Type URL Parameter
And finally, we could set it to “Custom Script”. That will produce an editor, in which we can put any Javascript we want.

[Screenshot]
Data Element Type Custom Script
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.

14 thoughts on “Data Elements vs Data Layer

  1. [quote]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?[/quote]

    Because it makes you independet from changes at your HTML-Code or your Paramaters or your Cookies. It helps to be clear on wich variables you definitely want to be filled by content from your backend system.

    Like

  2. Pingback: With DTM you don’t need Plugins! – Part 1 | Web Analytics for Developers

  3. Pingback: Einfach v Flexibel v Stabil | Webanalyse auf Deutsch

  4. Pingback: With DTM you don’t need Data Elements | Web Analytics for Developers

  5. Pingback: Quick Tip – One s_code.js for Multiple Sites | Web Analytics for Developers

  6. Pingback: “Data Layer on the fly” | Web Analytics for Developers

  7. Just wanted to point out that the datalayer structure you have up there won’t work with dataLayer.pagename (at least it didn’t when i tried). I know you probably just have it up there as an example, but there are lazy people like me who copy paste code samples and thinks it would work… 😉

    Like

    1. Pressed send too soon..

      It worked when i removed the [] brackets, making the datalayer a data object rather than array.

      But again thank you for the post, yours is by far the clearest and the easiest to understand out of them all.

      Like

  8. Pingback: Direct Call Rules – what are they good for? | Web Analytics for Developers

  9. Pingback: TDD – Testing Data Elements and Page Load Rules | Web Analytics for Developers

  10. Pingback: Basic Tracking – Remix (contains DTM) | Web Analytics for Developers

  11. Pingback: What to Test | Web Analytics for Developers

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s