Blog Post:If you’re a member of the ever-growing digital marketing community, then chances are you’ve come across the term “data layer.” There’s been a lot of buzz about data layers throughout the industry recently, and with good reason. This past December, the World Wide Web Consortium (W3C) published its standard for implementing a digital data layer on a website. This W3C standard, which was the result of a collaboration among many leaders in the industry, represents a very important (and exciting) moment for the digital marketing community. Given the recent rise in popularity of enterprise tag management systems—including Adobe’s own amazing and free dynamic tag management (DTM) product—the deployment of a digital data layer on your digital properties makes collecting and handling your most crucial data points easier (and more powerful) than ever. Essentially, the W3C specifies a digital data layer as a JavaScript object that’s placed on the pages (or on specific events) throughout your website. At face value, that’s actually not unlike the “s” object that Adobe SiteCatalyst uses for its data collection. The main difference is that of structure. To further explain this point, let’s look at an example. I’ve included two code snippets below for an article page from a fictional media site “www.adamnews.com.” The first example follows the traditional method of SiteCatalyst data capture, which relies on the familiar props, eVars, and events. The second example shows what the same data points look like within a digital data layer. [caption id="attachment_21863" align="alignnone" width="557"]Example 1. SiteCatalyst coding for a www.adamnews.com article. Example 1. SiteCatalyst coding for a www.adamnews.com article.[/caption] [caption id="attachment_21862" align="alignnone" width="581"]Example 2. The digital data layer implementation of the same article. Example 2. The digital data layer implementation of the same article.[/caption] As you can see, there’s a solid structure to the elements within Example 2’s digital data layer. This structure is known as JavaScript Object Notation (JSON), and is handled by a Web browser in the same manner as the SiteCatalyst code in Example 1. JSON is a subset of JavaScript, so any browser (or device) that can read and interpret Javascript can do the same with JSON objects. Within the digital data layer, the typical props/eVars/events have been replaced by contextual elements that can be easily understood by developers and marketers alike. This helps reduce confusion when determining which variables are placed on which page, and fosters a universal understanding of your digital marketing strategy. It also globally defines your strategy’s framework. That is, the data layer becomes your standard for deployment—meaning that the coding structure will never change, unless new data elements are introduced. The digital data layer’s real power comes when you combine it with an enterprise tag manager, like our phenomenal DTM. When the elements of the digital data layer are captured and handled by an enterprise tag manager, they can be sent to any digital marketing tool that you host within your tag management system. So, while the above data layer elements can be easily mapped to the appropriate SiteCatalyst variables within DTM, you can also share those components with any other tool that DTM hosts! If you want to synchronize this data with SiteCatalyst, Test & Target, Audience Manager, or any third-party digital marketing tool that might benefit from the data, you can do it easily! To sum up—deploying a digital data layer is quickly becoming recognized as a best practice for collecting digital marketing data and sharing it in a standard method across all of the tools in your digital marketing arsenal. To learn more about how you can benefit from implementing a digital data layer—and about the power and flexibility that DTM provides—reach out to your Adobe Account Representative today! And, in an upcoming blog post, I’ll show you how the elements of a digital data layer are consumed by DTM and ultimately mapped to SiteCatalyst variables. Don’t miss it! Author: Date Created:March 13, 2014 Headline:Data Layers: From Buzzword to Best Practice Social Counts: Keywords: Publisher:Adobe

If you’re a member of the ever-growing digital marketing community, then chances are you’ve come across the term “data layer.” There’s been a lot of buzz about data layers throughout the industry recently, and with good reason.

This past December, the World Wide Web Consortium (W3C) published its standard for implementing a digital data layer on a website. This W3C standard, which was the result of a collaboration among many leaders in the industry, represents a very important (and exciting) moment for the digital marketing community. Given the recent rise in popularity of enterprise tag management systems—including Adobe’s own amazing and free dynamic tag management (DTM) product—the deployment of a digital data layer on your digital properties makes collecting and handling your most crucial data points easier (and more powerful) than ever.

Essentially, the W3C specifies a digital data layer as a JavaScript object that’s placed on the pages (or on specific events) throughout your website. At face value, that’s actually not unlike the “s” object that Adobe SiteCatalyst uses for its data collection. The main difference is that of structure. To further explain this point, let’s look at an example.

I’ve included two code snippets below for an article page from a fictional media site “www.adamnews.com.” The first example follows the traditional method of SiteCatalyst data capture, which relies on the familiar props, eVars, and events. The second example shows what the same data points look like within a digital data layer.

Example 1. SiteCatalyst coding for a www.adamnews.com article.

Example 1. SiteCatalyst coding for a www.adamnews.com article.


Example 2. The digital data layer implementation of the same article.

Example 2. The digital data layer implementation of the same article.

As you can see, there’s a solid structure to the elements within Example 2’s digital data layer. This structure is known as JavaScript Object Notation (JSON), and is handled by a Web browser in the same manner as the SiteCatalyst code in Example 1. JSON is a subset of JavaScript, so any browser (or device) that can read and interpret Javascript can do the same with JSON objects.

Within the digital data layer, the typical props/eVars/events have been replaced by contextual elements that can be easily understood by developers and marketers alike. This helps reduce confusion when determining which variables are placed on which page, and fosters a universal understanding of your digital marketing strategy. It also globally defines your strategy’s framework. That is, the data layer becomes your standard for deployment—meaning that the coding structure will never change, unless new data elements are introduced.

The digital data layer’s real power comes when you combine it with an enterprise tag manager, like our phenomenal DTM. When the elements of the digital data layer are captured and handled by an enterprise tag manager, they can be sent to any digital marketing tool that you host within your tag management system. So, while the above data layer elements can be easily mapped to the appropriate SiteCatalyst variables within DTM, you can also share those components with any other tool that DTM hosts! If you want to synchronize this data with SiteCatalyst, Test & Target, Audience Manager, or any third-party digital marketing tool that might benefit from the data, you can do it easily!

To sum up—deploying a digital data layer is quickly becoming recognized as a best practice for collecting digital marketing data and sharing it in a standard method across all of the tools in your digital marketing arsenal. To learn more about how you can benefit from implementing a digital data layer—and about the power and flexibility that DTM provides—reach out to your Adobe Account Representative today! And, in an upcoming blog post, I’ll show you how the elements of a digital data layer are consumed by DTM and ultimately mapped to SiteCatalyst variables. Don’t miss it!

24 comments
vvkshankar15
vvkshankar15

Hi,


Can some one explain how a plugin can be installed in DTM to collect additional data from a webpage. Though the webpage does not have sitecatalyst tags on itself.


Thanks,

Viv

AdamKlintworth
AdamKlintworth

@vvkshankar15 Hello Viv - what type of plugin are you referring to?  As long as the site has the DTM embed code on it, you can manage both the Adobe Analytics tool and other 3rd party code from within the interface.


If you're referring to a typical SiteCatalyst plugin, these can either be added to the core Analytics code within DTM (assuming that the site uses SiteCatalyst for measurement), or can be added as a DTM rule.  You mentioned that the site doesn't have SiteCatalyst tags - if you're trying to add a SiteCatalyst plugin to a DTM property that isn't using SiteCatalyst for measurement, you'll likely run into issues.  The overwhelming majority of SiteCatalyst plugins rely on the core SiteCatalyst code to function properly.


If you're referring to a 3rd party tag/plugin, these are almost always added as part of a DTM rule.  I typically create a rule and then add in the 3rd party code in the "Javascript/Third Party Tags" section.  Works fantastically.


Let me know if you have any other questions.  Thanks for reading!

JeromeChevreau
JeromeChevreau

@vvkshankar15 Agree with Adam. He is spot on.

However, i just wanted to share another method that i came up with while learning the tool.

I created a dataElement which contains my function (need to return the object/function). Just call the dataElement using the _satellite.getVar(); whenever you need.


It comes really handy as certain scripts cannot be accessible from within the 'Customize page code' in the config area.


Cheers

pns77now
pns77now

Two questions

1) "Given the recent rise in popularity of enterprise tag management systems—including Adobe’s own amazing and free dynamic tag management (DTM) product" - wanted to know if this is a licensed or free product? 

2) Also, how is Data Layer typically used i.e. are the tags provided in each page of a website or usually on the homepage / landing page?

AdamKlintworth
AdamKlintworth

@pns77now Hello!  This is a free product for any existing customer of the Adobe Marketing Cloud family of products.  You would want to reach out to Adobe to understand licensing if not an existing customer.


Data layer placement varies, but most often it is exposed on each page of a site.  The reason being - all of your analytics (and other digital marketing) data will vary slightly as you move from page to page, so the data layer will change accordingly.  Many clients also will expose a data layer on event-level interactions (like clicking on interactive content) to also send that data into DTM so it can be shared among the tools you host in DTM.


The main difference between a Data Layer and analytics 'tags' is that the Data Layer is designed so its elements can be shared across ALL products (both Adobe and 3rd party) that are hosted within DTM.  This way, you only have to expose one set of data points on your site, and those points can be consumed consistently across all of your tools.


Hope that helps - thanks for reading!

JeromeChevreau
JeromeChevreau

Hi,

I have been involved with GTM and now will be using DTM. I would like to know the best practice when it comes to the datalayer's position on the page as there is not much documentation around.

Thanks

JeromeChevreau
JeromeChevreau

@AdamKlintworth @JeromeChevreau great thanks for your response but also to everyone who has contributed thus far. I wish there was better documentation on the tool. Is there any places where we can contribute to the community? I am currently editing certain untested plugins so it can work with my appMeasurement. Lastly, do you have a preference of where to add your plugins in DTM? i came up with 2 solutions but not sure if it is the best. I can share you the methods, if you would like, .

AdamKlintworth
AdamKlintworth

@JeromeChevreau @AdamKlintworth Hi Jerome - when it comes to plugins, I typically still include them in the s_code file within the Tool Management section of DTM.  Many of our clients have existing s_code file structures and plugins, and as such, we've found it more straightforward to leave them 'as-is' in the s_code file.


However - for new clients, I will usually leave the s_code as "managed by DTM" and then include any needed plugins in the "custom code" section within the Analytics tool configuration.  That way, you can reference those plugins within your ruleset as needed.  That has worked out well for me in the past.


Please feel free to share your solutions - I'm happy to review and provide feedback.  Thanks again for your comments!

JeromeChevreau
JeromeChevreau

@AdamKlintworth @JeromeChevreau hey Adam, thanks form coming back to me. I agree with you in terms of the plugins. I am taking the approach of getting all users with the library option "managed by DTM". I am currently putting the plugins in my custom code section too.

When playing around with DTM i also came up with a potential solution of having my plugins stored within a dataElement, this also allowed me to be able to use it to call certain plugins at any time.

Currently, i am updating certain plugins which haven't yet been tested with   the "AppMeasurement" library version.

I can share them with you if you like, if you are interested let me know of your email.

Thanks


AdamKlintworth
AdamKlintworth

@JeromeChevreau Hello and thanks for reading!  The position of the Data Layer depends on where (or when) you're going to be triggering your Analytics code and other tools.  Most often, we trigger Analytics code at the "bottom of page" - if this is the case, then the recommendation is usually to place the Data Layer (or to have it exposed and accessible by DTM) as high as possible in the <body> tag.  As long as it's there and populated so it can be consumed by DTM before other tools are triggered, you should be good to go.  Hope this helps.  Thanks!

asalerno
asalerno

The specification document clearly states at the bottom of page 3: This specification was published by the Customer Experience Digital Data Community Group. It is not a W3C Standard nor is it on the W3C Standards Track

redaxel
redaxel

Hello Adam, when is your next blog post coming? We're looking forward to understand how to map this data layer to data elements within ADTM.

sitty
sitty

Stumbled upon this post today...wondering if it is ok to set the main data layer variable in a pageload rulein DTM, then setting the individual variables on page? We are currently trying that and for some reason the variables we are mapping are not being passed.

aneter9
aneter9

Can you please let me know that how can I capture the event using Adobe DTM and Data layer? Can you please  let me know more about framework to handle multiple evnets as well as links?

AdamKlintworth
AdamKlintworth

@aneter9 Thanks for the post!  If you're talking about Success Events, I typically like to use a variable within my Data Layer that is set to either an arbitrary value, or even the value of "true."  An example would be something like "event_application_start=true".  Within DTM, you would then create a Data Element to bring in this value from your Data Layer, and then build a corresponding rule based on the existence/value of that Data Element.  Remember - rules in DTM are typically built on actions taken, so success events are perfect for building rules like this.


Can you provide some more info on handling links?  The typical method to handle link (or "click") interactions is via the event-based rules in DTM.  Hope this helps out!  Thanks for reading.

pjuska01
pjuska01

Hi Adam - Great primer.


Version 1 of the specification leaves events fairly open-ended.  The first challenge we encountered was, "How do we implement the W3C standard for *events* (ie Add To Cart, Add to Wishlist) and hook them up to Omniture events (ie scAdd) via DTM."


A Best Practice tutorial in this vein would be of great benefit to our team.


Thanks!
Paul

harshvkabra
harshvkabra

Hi Adam, Quick question, how do we map 's.products' variable in DTM. May be, I am missing something here but I could not find the products(s.products) variable in DTM UI to map.

AdamKlintworth
AdamKlintworth

@harshvkabra  you are correct - currently, DTM does not have a built-in way to reference the products variable.  However, it can be added by using the "Custom Page Code" feature within the rule that you're using to capture it.  Optimally, you will want to bring in the different components of the Products variable as data elements (SKU, price, quantity, etc.) and then construct the variable by using the _satellite.getVar syntax.  Here's an example:


var p_id=_satellite.getVar('Product ID'); //assumes you are setting data element "Product ID"

var p_price=_satellite.getVar('Product Price'); //assumes you are setting data element "Product Price"

var p_quantity=_satellite.getVar('Product Quantity');


window.s.products=";"+p_id+";"+p_quantity+";"+p_price;


One thing for above - make sure to use "window.s" as that will set the proper page-level scope.  Hope that helps!  Thanks for reading.

ndrez
ndrez

Will it also work if we create the DL after the page load? Or, is it crucial to have the DL in the DOM in the moment when the JS snippet for the header is included? 

LeoGarb
LeoGarb

how would I reference such an object in data element's path?


for example, I'd need an element for pageName. What would I do in DTM?

AdamKlintworth
AdamKlintworth

@LeoGarb  great question!  If you look at the data layer example that's shared in this post, the 'pageName' element would be referenced as "digitalData.page.pageInfo.pageName."  It basically follows the hierarchical structure of the data layer that you've implemented and each section is separated logically using the "." character (if using a JS object).

AdamKlintworth
AdamKlintworth

@mhlassoued this is absolutely possible today using DTM.  In my followup blog post (which is coming soon), I will show exactly how to do this within the DTM interface.  It's awesome!!

mhlassoued
mhlassoued

WOW. DTM will manage and maintan the W3C DL structure? Do you think soon we will be able to just define the W3C DL and then (from the DTM UI ) just much the objects/properties to our eVars, props, and events??? This is my dream from couple of months and i think it's SO possible ;)

stevemiles
stevemiles

Nice article - this is exactly what I'm looking to achieve with our DTM implementation. Can't wait for the next part!