Adobe Client Data Layer object name

[MattBlake]

Hi, I have a query about data layer implementation, more specifically the Adobe Client Data Layer as recommended for new and / or restructured data layer.

In brief... is there any benefit to using the object name adobeDataLayer?

We have existing data layers which use a different object name (digitalData) and it would be simpler to keep the object name (i.e. window.digitalData = window.digitalData || [] 

... but would doing this cause us problems or increase technical debt elsewhere down the line?

Thanks!

[Jennifer_Dungan · Accepted solution]

For what it's worth, I don't use Adobe's data layer... when I started with Launch, the Adobe Data Layer didn't exist.. .so we came up with our own solution... 

But on top of that, I am not a big fan of "event based" data layers.... I don't like the number of "links in the chain" that some actions have to go through:

• User clicks on element
• Click is detected then writes information to the data layer
• Launch then has to listen for the Data Layer Change
• Then read the information from the Data Layer
• The send the tracking call

All before the user is taken away from the page...While I don't have many click actions now (I prefer to use Activity Map for most items), this type of tracking is still needed, I would rather just have data attributes on the element that I can read directly on the click.

On top of the above, if your site is an SPA (single page application), the Data Layer will keep growing with each new addition.. so now you have to build in a data layer purge to keep it manageable....

While it's nice that Adobe does provide a solution out of the box... I don't see any problem sticking with your own solution....if it meets your needs, and prevents you having to do a lot of re-work (and learning a new Data Layer structure) then keep it...

Can I guarantee that it won't have a problem in the future and need to be redone? No... 
Can I guarantee that using Adobe's Data Layer won't also have issues that require it to be redone in the future? Also No....

As technology changes, there will always be the possibility that tagging will need to be redone....  We've seen it before...  (s_code > appMeasurement > DTM > Launch, etc)

[Jennifer_Dungan]

I should add... (in case I misunderstood).. you are asking about keeping your own custom data layer, rather than using Adobe's?

If you are talking about using Adobe's and renaming it.. so you are using their data layer with a custom name...  I would probably recommend against that approach.... 

I've not used it myself, but I believe I have seen other posts where some people experienced issues trying to use a custom name on Adobe's Data Layer.......

[yuhuisg]

If you're happy with your W3C-based digitalData data layer, then you can continue using it. A "data layer" is a storage of data and you can use any JavaScript type for it... as long as you know how to get data out of it! (E.g. I would find it really difficult to use an integer-based data layer! )

The Adobe Client Data Layer (ACDL) is Adobe's answer to the recent trend of event-driven data layers. Another commonly found event-driven data layer is dataLayer used in conjunction with Google Tag Manager.

Unlike @Jennifer_Dungan's reservations about such event-driven data layers, I actually appreciate them. In human-speak, they work like this: "when something happens, new data is made available." That something can be a browser event, a user event, maybe even an API sending a custom callback event, etc. When combined with the reserved "event" key, then you can reliably detect when data is available and use that data for known, specific purposes, e.g. to track a link click.

Given that they are event-driven, they work especially well with single-page app (SPA) websites, which are essentially one single web page. A data layer like your digitalData breaks down terribly because it'll be difficult to know when a new "page" is loaded.

Anyway, use what you're comfortable with, until/unless there's a need to move to another technology.