You Need a Data Layer

We’ve talked about how relying on CSS Selectors is unsustainable. We’ve reviewed the most efficient and sustainable way to implement a data layer. It’s worth taking a step back to review why one would implement a data layer in the first place. So many organizations don’t have one and it’s incredibly difficult to scale this. There are many reasons for this, too. Here are a few among a much larger list:

• Vendors are independently managing platform development
• Divisions in your company operate in silos
• Lack prioritization
• It’s easy not to
• Feels expensive

The best treatment is education and evangelism. That’s easier said than done. The intent of this article is to provide easy ammunition to pursue a data layer in your organization. I want you to feel confident in telling your stakeholders that a data layer reduces annual maintenance cost by 50% annually, increases your utility as an analyst by 38%, increases speed of deployment, improves the accuracy and depth of your data, and makes your organization smarter. You are crazy if you choose to not implement a data layer. Skeptical? Let’s walk through it in painful detail.

Reduce maintenance cost

So you’re saying we should spend our hours to implement this data layer thing… even though it would be a lot faster/cheaper if you did this in your TMS?

If an implementation was a one-and-done operation then this would be a fair assumption. Sure, a data layer increases data accuracy, depth, and cleanliness… but I could spend 40-50 hours writing rules to clean up the data because the site and the data will never change. If your website and marketing never change then you don’t need a data layer. For the other 99.99% of us, we have to manage change on a daily basis. In lieu of micromanaging our implementation all day every day, we often settle for just OK data and just make sure the important stuff is still accurate.

This would be useless if we couldn’t estimate cost savings of a data layer. In the first year, you could expect to spend 50% less on maintaining your implementation. Here’s my calculation. Yes, I know I’m totally misrepresenting your unique one-of-a-kind business that’s solving problems no one else has ever encountered (wink). Feel free to copy the sheet and plug in your own numbers. There are variables that affect this calculation:

• Development efficiency
• Analytics team efficiency
• Staff turnover
• Development cycle length
• Team size
• Tagging density

The worse these variables look, the more expensive any approach will be. This is insanely magnified if you aren’t leveraging a data layer. Do you have a fast development cycle? Add a coefficient to those maintenance costs.

Reduce silos

A data layer requires definitions of key metrics… or at least it should.

What does revenue mean to you? Profit? Include shipping? Taxes?

How are you measuring product purchases? Do bundles count as one product? Multiple?

What does success mean to each department? How is all of this prioritized?

All of these questions require the same thing: conversation. It’s simple, but often we fall into complacency. Sure, you know what matters to your business. Still – ask around. People have different interpretations of metrics and success. When you discover discrepancies, start another conversation. Operating under different definitions is counter-productive.

Speaking the same language is a critical component of defining your data layer and ensuring your organization doesn’t operate in silos. If each division is aligned on the definition of success, you’ve established a North Star. A data layer won’t cure your organization of silos, but aligning on definitions is a very good place to start.

It doesn’t stop there.

To their infinite credit, the development team wants to do what’s right. They feel deadlines. They see the output of most of their work. For the past 5 years, they’ve perceived that everything has been going great. Why? We could do a better job at communicating how it affects us and the business. A development team doesn’t feel the breath of a CMO when data isn’t trustworthy.

A data layer should also initiate conversations with developers. It’s important they understand the implications of the work beyond a superficial “It’ll help our team.”

Implement better stuff faster

Without a data layer, you’re either coding or you’re settling. You’ll write code to scrape values from the page and drop them in a pixel. You’ll write code to scrape the title of an article. It’s going to take a lot of code to scrape all of the product information from each page. Good luck ever handing it off, too. It’s your code to maintain!

A data layer exposes more options in a user-friendly format. I will stop short of saying you’ll never have to write code again. That’s bullshit. You’ll write LESS code, though. That’s a good thing. Your data will be more accurate because it will be consistent. You’ll push stuff to market faster because you are spending less time on stackoverflow. That’s a win.

Increase your value to the business

Did you miss the part where you reclaim 38% of your time per month? Time maintaining code is time you aren’t spending thinking about your business. That’s time you aren’t spending browsing Reddit or playing Tetris – both are more fun than fixing tags and adjusting reports. Hopefully you’re adding more value to your business with the extra 38%. Congratulations. Your time is now worth more. There’s no pride in spending days maintaining an implementation. There’s maybe a pat on the back at the end of the year because your company has no idea what you’re capable of. They hired you because you can do cool stuff with data. Spend this time doing that.

You’re also in a good position to help out your fellow stakeholders! Remember you can implement better stuff faster? Remember you agreed on those consistent metrics? You’re now worth more to everyone else. Pass your raise on to me – I’ll send you my address.

Identify Diminishing Returns

Sometimes a data layer doesn’t make sense. One obvious case is when you’re tracking a “disposable” website – one that lives in its own universe and will never be updated. One case that I’ve seen more often is when when we want to tag a lot. A whole lot. Like, everything. Everything that’s implemented must also be maintained. When you ask for too much, the work might not get prioritized. Scopes for small projects can spiral out of control. If you’re having trouble justifying a data layer, take a few steps:

Prioritize the work

It helps to filter the signal from the noise. Maybe your development team has plenty of resources but you’re on a tight deadline. Prioritizing what’s most important will ensure something gets done. I recommend setting a high/medium/low priority if you’re running into issues getting the work scoped because of timing.

Be consistent

Consistent documentation will ensure your development team doesn’t have to relearn YOU. If you’re consistent with what you want to track – and consistent with how you communicate your tracking needs – there will be no surprises when new projects pop up. Developers will be able to better anticipate (and scope) what needs to be done.

Help them care

We should all care about why we’re building stuff. Stakeholders and developers should care because their hard work is helping answer some hypothesis. You’re not the only one who cares about that hypothesis. As a developer, I want to know what comes out of the work I put in. Communicate the value their work will deliver like their job depends on it.

Final Thoughts

Are you currently using a data layer? Congratulations. You probably aren’t spending all day maintaining an implementation. Hopefully you’ve had conversations with your stakeholders and are using consistent definitions. You’re also implementing at a high velocity. Now what? If you’re using the W3C method, prepare to migrate to an EDDL. If you’re on Adobe Launch, the Data Layer Manager is currently the only accessible way to do it. Done all of that? Great! You’ve earned a promotion from TMS jockey to analyst!

I do want to address a few things before closing this one out. First of all: will this blog post solve all of your problems? NO. I want to help you justify implementing a data layer – period. If your development team and site architecture is a complete mess, a data layer will not fix that. Will it help? Yes, it will. This takes work, though. It takes effective communication. If you’re having trouble, you could always hire me and we’ll make it happen. If this article didn’t convince you, 33Sticks wrote a very similar article 4 years ago. They also wrote a case study. Aaaaand here’s another from the great Jenn Kunz. While they’re good friends, I do not represent 33Sticks. They just happen to have a lot of great content out there.

The bottom line is this: you need a data layer. I spent weeks agonizing over this blog post and feel like it still isn’t sufficient. I tried to prove it out with numbers and while they aren’t perfect, what is? Every organization is different. Writing 5 lines of code takes some people 5 minutes and others 5 days. The point isn’t to be perfect – the point is to get this work prioritized because it deserves to be prioritized. Use these estimates to get the work prioritized. By implementing a data layer, you and your company will prosper.