What Is a Data Layer?

My team and I spend a lot of time helping companies implement analytics tools and other tracking pixels on their websites. And quite often, we run into questions like these:

• “We’ve been using Webtrends, but could you help us switch to Adobe?”
• “Here’s a new pixel for our new remarketing program. Could you tell us what we need to do to install it?”
• “We’ve redesigned our booking engine. What do we need to do to make sure tracking is still working?”

These are the bread-and-butter challenges for analytics implementation. Back in the old days (meaning, like, two years ago), we’d usually need to write up new instructions for each tool, provide detailed data validation for each new pixel, and spend many hours of our clients’ developer resources (and consulting dollars!) handling these changes. All that, just to replicate tracking that was already in place in a slightly different format!

It seems like there should be a better way…and there is – it’s called a data layer.

I like to think of data layers as being similar to a patch bay in a music studio. You’ve got a bunch of outputs (from microphones, amps, etc.) and then a bunch of inputs (like your mixing board, monitors, and recording devices). Instead of snaking dozens of cables from device to device, which inevitably get tangled – and good luck if you need to make any changes later – a patch bay lets you wire each input and output to a dedicated slot on the back of your patch bay. Then you can take small cords and plug output A into input D, like an old-time telephone switchboard operator. It’s far easier to make changes, and you can keep all of the wiring out of sight and out of mind.

A data layer, in essence, is the same thing (only better!). It consists of a standardized format for your developers to output all of the info that you need for tracking in a user-friendly JavaScript object. Then, usually with the help of a tag management system (TMS), we can interpret that data and send it out in all directions to the various analytics tools in your toolkit.

Let’s take a sales confirmation page as an example. You might have 10 different tracking tools, each with their own special complexity, on this page. All of them want to know that it’s the sale confirmation page, the order ID, and how much revenue you made; some of the tools also want to know which products were sold, plus a bunch of other info about the shipping details, discount amounts, etc.

Unfortunately for your developers, each tool wants the data in a different format. So they need 10 different sets of instructions covering the unique quirks of each tool. And, if a new developer comes in and needs to modify anything or copy this tracking over to a new system, THEY need to read 10 manuals, too.

With a data layer, on the other hand, the developers just send one signal that basically says, “This is a sale confirmation page. Order ID = 12345. Revenue = $200.00. Product = blue widget #5.” Then in the TMS, my team can route the relevant data to each of the various pixels.

This makes it much easier to maintain, because any new developer can look at the code and understand what’s supposed to go into the “order ID” field. And if he or she can get that right, then all 10 of the tracking pixels will continue to receive the right data.

In the past year or so we’ve been involved in many implementations that have switched to a data layer format, and I’ve been impressed with the results. It’s easier for the developers, leads to quicker deployment, and makes it a lot easier to maintain even complex implementations over time. I wouldn’t be surprised if within a few years the best CMS tools output one automatically…but there’s no reason to wait for them before making the switch.