Over a year ago (after the 2019 Adobe Summit) I offered to chat with anyone on the phone about data layers (that offer still stands, by the way). One such conversation was with my friend Yehoshua Coren, who you may know better as Analytics Ninja. He spent a good chunk of the call trying to get me drunk. Another chunk was ranting about how GTM has been doing this EDDL stuff for YEARS! He is right, of course. There was one point where I disagreed with him – it was about leveraging HTML5 data attributes. He insisted that these were critical to an effective data layer. I’m hard-headed so I fought him on it… like I do with everything (just ask Hussain Mehmood about what constitutes a sandwich).
My argument was that mixing design patterns sucks and adds complexity to an already-difficult process of getting stuff like a data layer implemented. That’s because HTML5 data attributes is yet another development design pattern, which takes time to explain to other analysts and development teams. I still think I’m right. HOWEVER, I believe the complexity of it might not outweigh its benefit and scalability. So it’s time for me to eat crow. I still believe the EDDL is the best data layer. I also think using HTML5 data attributes in conjunction will scale better than any other data layer methodology out there.
What the heck is an HTML5 data attribute?
An HTML5 data attribute is used to store data in inline HTML code on your website. Here’s an incredibly bare W3C reference. Here’s a solid article from Bounteous that talks about it in the context of Google Analytics. I really dig this article. Let’s say you have a link that’s on your website (you probably have like a billion of these):
<a href="/learn-more">Learn More</a>
In reality, the developer will probably just create a selector in some common JS file to execute the .push() function… which totally defeats the purpose of a data layer. Instead of making our developer friends cry, let’s use HTML5 data attributes:
<a data-zone="top nav" data-link-text="learn more" href="/learn-more">Learn More</a>
Whoa, look at all that detail! I can now leverage these attributes in my Launch rules! With these data attributes, we can add however many layers of information we want to these links. Okay, I know what you’re thinking…
How is this better than using the EDDL on every link?
Someone is still dropping the data onto your page. Don’t developers still have to do this for every single link? NO! This is a fully-powered CMS-driven MACHINE! Well, hopefully. The cool thing about these data attributes is that these elements can inherit attributes input by content authors. If you have a nav object or component, any click element within that object could be automagically assigned a data-zone of “nav”. These attributes are managed and modified in your CMS, which means content authors can put whatever information they might find useful (within reason).
Do I NEED to use this?
NO. You don’t. It’s VERY easy to fall down a rabbit hole and collect too much data when you use this. Please remember that you can still use activity map to produce a heat map of where users click. There are still some secondary or tertiary actions that you’ll want to track. Sometimes there’s a TON and you’ll get caught in a development bottleneck each time if you try to track all of these via the EDDL. HTML5 data attributes is supplemental and will help reduce headaches long-term.
When should I use EDDL vs. HTML5 data attributes?
I know many of my readers are just now starting ramping up on the EDDL and you might be thinking “Great, so do I need to start over?” NO! KEEP GOING! This is intended to be used alongside your EDDL. In follow-up posts I’ll show you how to document and best integrate these data attributes into Adobe Launch. Long-term, we want to collect data responsibly.
I’m all for adding HTML5 attributes for things like click tracking. It’s the method I use which has been very successful when implemented properly. One of the things we struggle with is “who is responsible for Click Tracking”. IT likes to say “that’s the Analytics teams job”, content people just close their eyes and cover their ears and run away screaming, and the Analytics implementation team says we can’t handle the volume and constant upkeep of managing click tracking on a constantly changing site.This finds a nice balance.
– Limited automation to only track what the business owner wants. Too much automation ends up with a “track every click” concept which just creates a data mess.
– Much less risk in breaking tracking as the content and designs evolve. This is the number one issue we normally see, where we use CSS selectors to target elements. For sites that regularly change/evolve that becomes incredibly unstable rather quickly which results in crappy data.
– Most IT devs really don’t like EDDL (at least in my experience), and it’s a chore to convince them to implement them consistently. Adding a couple element attributes is much more straightforward.
– Some content is regularly updated by non-hard core devs, people who have been taught some very basic html to make simple updates. Asking these people to advance to EDDL type work is a stretch, but teaching them how to add a simple attribute or two to an element is fairly simple and easy to remember.
– It puts the control of click tracking onto the product/content owners, where if handled properly provides them with required data in a quicker and more efficient manner.