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.

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.

Agile!

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?