What is a Data Layer?
Over in my Tealium iQ and the Adobe Client Data Layer article, I loosely defined the term “data layer” as follows:
A data layer is a JavaScript object with a collection of key:value pairs. The object is referenced when building analytics and martech beacons/requests, reducing the need to scrape page content, cookies, or other fragile data sources. This accessible, predictable, central source of data is most commonly created and populated early in the page load process, often not changing until the next page load.
I also included thoughts on what many refer to as an “event-driven” data layer, or EDDL:
An event-driven data layer is typically built as a JavaScript array, accepting new values and information as the data becomes available. As data is pushed into the array, the data layer updates. This approach allows for dynamically enhancing and modifying the data layer throughout the user’s page experience. Any resource watching for updates is immediately notified and able to act (eg// trigger analytics beacons) or ignore the event.
Subsequent conversations led me to believe not all data layers are created equal: There are static javascript objects, arrays, and emitted events. There are custom SDKs, APIs, and other approaches. What are the differences? What makes one static, another event-driven, and others some combination of the two? What makes something not a data layer, or not event-driven?
Data Layer Types
Static Javascript Object (The Original One)
- The original data layer was a static Javascript object as defined at the top of this article. It is typically defined and populated as part of the page load, with no additional updates without a page refresh or navigation event. Any updates that do occur will be made quietly, without notifying the page of the change.
- Tealium’s utag_data, for me, fits in this category. (utag_data and utag.data are not the same, by the way. They coexist and even complement each other, but serve different purposes.)
- I try to avoid this approach, but recognize it’s not always possible. In those cases, we’re forced to lean heavily into custom eventing capabilities in our TMS (assuming a tag manager [TMS] is in place). Whether through native TMS features or mountains of custom JavaScript, the static object gets dressed up as something more powerful.
Javascript Array — EDDL (The Gifted One)
- Leveraging the Javascript array’s native .push() capability enables the development of an event-driven data layer (EDDL). Some EDDLs (eg// ACDL) are intelligent enough to persist certain values as they are pushed. Others require pushing all required information each time an update occurs. What stands out with EDDLs, though, is that you can subscribe to them. You can monitor them for changes and act — or not — as soon as those changes occur.
- I call this “the gifted one” because, for my money, it typically handles everything I need. And, with open source options like the ACDL, I know exactly what to expect. Aside from implementing the .push() actions, very little custom coding is required to accomplish what I need.
Custom Emitted Event (The Forgetful One)
- In Javascript, we’re all familiar with element.addEventListener(). We use this when tracking click events, mouseover events, scroll events, etc. We can also use it as part of a custom data layer approach. Pairing the event listener with emitting a custom event — perhaps named “dataLayerEvent” or similar — allows us to react immediately any time new information is presented.
- I call this “the forgetful one” because, by itself, it is forgetful. Unless you build custom logic to persist data passed via the custom event, the data is only available when the event fires.
- What I like about this approach is that it’s both vendor- and platform-agnostic and is available in any Javascript-supporting environment without the need for additional third-party libraries. It is also easy to subscribe to the events from any tool or service.
Custom SDK/API (The “Is it Really a Data Layer?” One)
- While I personally never think of a vendor’s SDK or API as a data layer, recent conversations have me considering a change of mind. The best examples here relate to Javascript APIs native to the most popular tag management systems (TMS). The way these work is you’re expected to bake the vendor-specific method calls into your codebase, calling them directly. When called, similar to the Custom Emitted Event above, you pass in a payload containing your data layer. In some cases, it’s the full data layer. In others, you pass in enhancements to a static data layer that’s already live on the page. For example:
- Tealium iQ (TiQ) has the utag object that supports utag.link() for event tracking and utag.view() for page views. Passing a data object parameter with each of these method calls enables real-time enhancements to your data layer. However, the enhancements will not persist beyond each individual call.
- Adobe Launch/Tags has the _satellite object that supports _satellite.track(). Similar to the TiQ events above, the method accepts a data layer parameter. Also similar to TiQ, any data layer enhancements are isolated to the event call.
- When it comes to the SDK/API method, I caution against it. Does it work? Sure. Is it worth hard-coding unnecessary vendor-specific code into your site’s codebase? Not in my opinion.
So Much To Consider — What do I do?
I’m sure there are numerous alternatives to the above approaches. It’s possible that you, the reader, may have custom-built a superior solution. If so, I’d love to hear about it!
Until then, my preferred approach is to implement a proven EDDL with vendor-agnostic benefits that avoid littering my codebase with vendor-specific method calls and other logic. From there, I let the TMS do the work of listening for EDDL pushes and deciding what to act on (load rules/conditions, tag/beacon firing, etc), and what to ignore. This approach encourages simplicity and ensures accuracy in today’s dynamic web environments.
