Data Layer – Yet Another Reason

If your new year resolutions for this year included “help your friendly marketer be more successful”, I have something for you today.

It’s a fairly straight-forward thing to do, but it’ll help her big time: build a proper, solid data layer for her.

There are countless blog articles out there about the advantages of having a good data layer. There’s a standard we should all aim for (the W3C CEDDL), and it really is a no-brainer.

So why yet another article?

Process. The thing I haven’t written about so far is process.


This post is inspired by a meeting a couple of days ago.

Present were: two members of the Analytics team, two AEM architects (the guys who know how the site works), an ops manager, and a project manager.

The question was: “how do we put changes we made in DTM into the live site?”

This particular customer uses library download, i.e. the Javascript code generated by DTM is downloaded and then published in a workflow.

The question therefore becomes: “who pushes that button?”

And immediately the ops manager was steering the discussion towards “breaking the site” and “change management”, which is of course understandable.

But: it also means that the agility that marketing and other analytics users hope for is at least partly lost. Reviews and tests slow the process down. Code freezes affect the library download, too.


We ended up agreeing that there was a fundamental difference between setting up Data Elements and Rules in DTM and dropping Javascript code into it.

I think the ops manager and QA (absent) were agreeing that the former is very low-risk, while the latter would ideally trigger a review or test cycle.

Which leads me to the conclusion that the more you — the developer — provide relevant data in the data layer, the faster your friendly marketer will be able to use it, in the sense that her changes in DTM are going to be classified as low-risk.

For those of you who know AEM, the analogy would be authoring of content. Content authors use existing components to build new pages. Noone subjects those to a complete test cycle, because the components have been implicitly or explicitly tested and so we trust they’ll be fine.

The exact same applies to code generated by DTM.

If you build a data layer that allows marketing / analytics to do their thing with built-in DTM functionality, there is no reason to test every time.

So that’s good, right?


German expat living in Switzerland (formerly UK and France). Consultant and member of the Multi-Solutions Group at Adobe, working with the Digital Marketing Suite. Father of 4 girls.

Tagged with: , , , , , ,
Posted in DTM, Javascript, Opinion
2 comments on “Data Layer – Yet Another Reason
  1. […] a pre-requisite, I shall presume that your site is built with a CEDDL-compatible data layer, which means we can see product information in digitalData.product, digitalData.cart, or […]


  2. […] about the data layer? You have a CEDDL-compatible data layer, right? You should test that, no? Oh, yes, you […]


Leave a Reply

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

You are commenting using your 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

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 1,398 other followers

%d bloggers like this: