Your Analytics Tagging Solution Starts With Your CMS

Use your CMS to build a Data Layer and Improve Data Collection for your Analytics Tool

The Data Layer isn't a completely new concept but it hasn't exactly become mainstream across websites at this point and time.  That said, tag management solutions have accepted data layers as a standard way to pass data from the presentation layer of a site into a tag management system.  Tools like Google Tag Manager and Adobe's Dynamic Tag Management have built in functionality to scrape javascript objects on a page.

Building out a data layer can be a complicated process, especially when tech resources are limited.  However, the first place to start is utilizing the functionality of a CMS to roll out a data layer. I've been fortunate to have worked with several Content Management Systems including Adobe's Experience Manager, Atex Polopoly, Sitecore, Umbraco and others.  Each one of these allowed for the opportunity to build out attributes about a page that could eventually be built out as a data layer.  Unfortunately, none of these tools come with a data layer out of the box.

The W3C has started defining standards for what a data layer should look like.  Back in 2013, the W3C released version 1.0 to the public on a standard data layer definition.  Additional details were released in the 0.5 draft in earlier 2013 about the standard data layer definition.

While these standard layouts are great, no two websites are the same and need to collect the same information.  When building out your data layer, remember that it should be built around being versatile for your business, yet organized. My recommendation is to start with the W3C standards and build out from there.

Before getting the development team on board, work on defining the information that you will need.  As a first step, start with what information is already accessible on the page easily.  Items such as a page title (document.title), page url (document.url) can be obtained without developer resources.  From there, think about what information is static on the page.  Start to define the static items on the page and think about how it varies from page to page.

Most objects that go into a data layer are meta data about the page, the user or the product being viewed.  Therefore, supplying page name, page url, page section and so on should be fairly straight forward.  Obtaining dynamic objects on the page should also be relatively easy.  Think of it this way, if it's already displayed on the page, it should be easy to add it to a data layer object.

Once the initial data layer has defined work with your development team to define each object and how it should be populated.  If an item is static to the page, work with the development team to create an input field in the CMS for these items.

In addition, work with developers to define what dynamic objects are needed such as, shopping cart information, internal search items and so on.  It may be difficult to manage these items in the CMS initially so technical resources will be needed to implement these dynamic objects into the data layer.  Long-term, being able to manage dynamic objects in the CMS will allow for incredible flexibility as you build out your data layer.

This should cover defining the data layer on page load, but what happens when you need to track events or actions on a page?  Different tag managers, handle this differently.  What I've found to be the most effective way is the ability to add a data layer onto individual elements on the page.  Therefore, if a page contains a video, you can add child objects to that video so that when it plays it passes those objects to the data layer. With some tag management solutions, this will just consist of adding an update call, with others you made need to work with developers to update the information in the data layer and calling the tag management solution after the update.

All of these items coming together, be sure to QA the data layer as it's being built and make sure that your tag management solution can handle the format being designed.

Remember that your initial data layer doesn't need to be perfect.  It's better to start collecting some information quickly than to delay the analytics collection and have no data for 1, 3 or even 6 months.