×

View Content

First Name
Last Name
Direct Phone
Company
Job Title
Thank you!
Error - something went wrong!

Jason Thompson - How to Sell Your Boss On a Digital Data Layer

November 23, 2016

Slide 1:

Thank you to ObservePoint for putting this together. It’s a unique format that gives people that wouldn’t potentially have the opportunity to attend and industry event, to get together and hear from a really great set of speakers. We’ve already heard from some amazing speakers so far and there’s others still to come. Thank you to ObservePoint for putting this together, it is a great event and a great opportunity to learn.

If you’re in this session, which I’ve titled, “How to sell your boss on a new data layer,” my assumption is that you’re interested in data layers. Potentially, you’ve already approached you boss and you’ve tried to pitch a data layer to him or her and maybe getting some push back. Or maybe you’re just interested in a data layer in general. It’s a pretty hot buzzword that’s going around a lot and it seems very trendy. To set expectations, my presentation is going to be focused on arming you with the key benefits and counterarguments that you can use in your organization to have them help you to make the investment to deploy a digital data layer. While there’s a lot of great information about the depth and technical aspects to architecting and building a data layer, that’s not what this presentation is focused on. I really want to arm you, as the practitioner, with the information you need to move this project forward in your organization.

So if you’re like me and hundreds of other practitioners that I’ve talked to that are interested in moving forward with building a digital data layer in their company, you’ve probably been met with some kind of resistance. That’s because these projects re typically very hard to do and they take a lot of time.

Slide 2:

One of the things you may hear if you approach your powers that be is, “You know what, we’ve had analytics for a long time. The digital analytics space has been around for a number of years now.” And chances are you work for an organization that has been successfully running your digital analytics program for a number of years, so the argument of, “We’ve had analytics for years and we’ve done it it successfully without a data layer. Why do we need one now?”

I get it, it makes sense. To understand why this might not be a valid argument, one of the things we might want to do is look back at the history of analytics. See where we came from and where we are today to see why having analytics ten years ago without a data layer made sense, but why, today, it doesn’t.

Slide 3:

So if we look at a timeline of digital analytics, let’s go all the way back to the last century and let’s look at where this all began. The start of digital analytics was really around log file analysis. We were taking an artifact of what was already in place. Our web servers were kicking out a bunch of data and some smart people got together and said, “I think we can do something interesting with this.” We were able to go through that data and do things like; how many people are coming to our site? How many pages are they viewing? Maybe some basic pathing. It was pretty limited. There was not a lot of customization to the data, it was basically what we had available. Really basic site metrics primarily focused in the network administration space. We were looking at doing things like; how do we optimize our servers? How do we have faster page load times? Great things to look at, but really not the things that we’re looking at from a business perspective today as high value.

Hopping forward to last decade, and this is really where web analytics at the time—we now call it digital analytics—was born. This was the page tag or web beacon revolution. You had companies like Omniture and Webtrends and WebSideStory and others that came up with their own—and I’m calling it: dialect—JavaScript. Basically it was JavaScript, but each vendor had their own unique way of how that JavaScript was formed. To deploy a technology on your site, you would take these vendor tags and you would deploy it across your web properties. What this created was the opportunity to highly customize the data collection. We were moving away from just what we had to: we can start to get what we need. This was a great step forward in the progress or the process of digital analytics. One of the great outputs of this was marketers would really begin to consume the data. We were starting to broaden the breadth of how data was used in the organization.

However, a couple of the drawbacks of this approach is that development cost was high. We needed a developer that understood each vendor technology to customize and deploy these tags across our entire site. While that may have worked back then when we were talking about two or three vendors, it starts to break down today where we start to have a wide range of vendors that we want to use from an organizational standpoint. Not only that, but this approach created very siloed data. Each platform that we utilized as a business held its own, unique set of data that really didn’t work well together with other vendors. Again, that might not have been a bad thing in 2004 when we were utilizing maybe two or three vendors, but it’s a huge problem today. I’ll get into that a little more later.

Let’s move forward, out of last decade, to today. What are companies that are on the leading edge of digital analytics doing. They’re moving away from the page tag approach and they’re deploying their analytics through a centralized location, coupling the data more closely with their product. They’re doing this through the use of primarily tag management systems built on a foundation of a data layer. This has created cross-functional ownership across the organization. We still have high customization, which is fantastic. A few things are coming out of it: we’re reducing development costs, we’re redesign maintenance costs, we’re centralizing our data in a core data hub, really driven by business needs, and now we have people across the organization consuming this data.

This is really where we need to be. At one point in time, a few years ago, this may have been a nice thing to have, or a luxury. Today, it’s really becoming a requirement. As we go through the next couple of slides, I’ll start to document, or help you understand, why we really need to move to this approach.

Slide 4:

So your boss says, “Okay, I get it. You’re saying we’re old-school, we’re stuck in last decade—but honestly, I don’t get it. What’s the big deal because I come in every morning, I fire up my laptop, and my KPI dashboard is in my inbox. And if we have a major decline in our site conversion rate, I have this cool alert on my phone that shows up. So we’re good. I don’t know that last decade is all that bad, is it?” Well it kind of is.

Slide 5:

Here’s why. Last decade, the page tag approach, while it may have been effective than working with, as I mentioned, a handful of vendors, that’s no longer the case today. If you were a practitioner running an analytics shop back in 2004, you may have been managing one, maybe two—on the high-end, maybe three—vendor tags on your site. That’s just not the case today. In fact, go to your favorite website. Use a tool like Ghostery, or a similar tool, maybe I don’t know, ObservePoint—they have a great tool that allows you to audit all of the tags on a page—open up that tool and take a look. It won’t be a surprise to see 20, 30, 40, different marketing tags on any given site.

That’s why the paradigm of what worked in 2004 is starting to break down today. To help your boss visualize that, I’ve put together a simple slide of what it looked like last decade. Previously what we did with the page tag approach, was we had a digital property and every time we wanted to deploy vendor code to that property, we would reach out and say, “Hey Adobe, Omniture, give us your special JavaScript. BlueKai, Eloqua, Salesforce, fill in the blank.” And each one of those would then be tied into our web property.

This was starting to become very inefficient, I think you can quickly see that. So not only do we have to have a developer that understands each of these technologies, we have to make unique calls for each one of these platforms and each one of these separate tags needs to be maintained. Not only that, I’m sure you’ve found that a lot of these platforms utilize the same core set of data. If we’re sending half the data to Adobe Analytics that we’re sending to BlueKai or to Eloqua, why are we doing it three or four different times? It really should be done once in a centralized way. That’s becoming more and more of a requirement as we’re plugging more and more technologies into our marketing stack.

Slide 6:

It sounds like what you’re saying is that centralizing our digital data is a good idea, this is starting to make sense to me and in fact, one of the things that may come back is that your boss may say something like, “Hey, I’m sitting in these weekly planning meetings with the other executives and I’m starting to get really beat up by our development team. We’re utilizing a lot of their time and they have other things that they’re supposed to be working on. It seems like every other week, I’m getting a bit of a pushback from the development manager on how many hours we’re using of their time to deploy and maintain these marketing tags. So if this centralization could help reduce the load on the, that might be a good thing for me.”

Slide 7:

I agree, centralizing data through a data layer is a really great idea and here’s why. If we take that simple layout that we saw before, how we organize thing using the page tag approach, this is what it looks like today utilizing a digital data layer. Instead of having separate actions and functions going to each one of our vendors, we now having everything controlled through a common, digital data layer. The data layer is our data hub of all the data that is critical for the business to make informed decisions with. It’s all in one centralized location. Many companies are making use of a tag management system to help communicate that data layer with the other applications they have deployed in their marketing stack.

In this example, you can see that we have the data layer communicating with our tag manager, and now we’re reaching out and we’re having our marketing application subscribe to that data. We have Adobe Analytics, we have BlueKai, Eloqua, Salesforce. Again, please keep in mind that this is a very simplified approach. Chances are you’re running many more marketing tags than this, but now they’re subscribing directly to this data. It’s much more efficient. We can utilize much less from a development resource perspective to make this happen. It’s much more efficient from an application level. If we’re concerned about page load speeds and user experience on the site, having a centralized methodology for pushing data to each of these marketing technologies is going to help address that issue as well.

If you’re reading the body language of your boss, it might look like you’re starting to make some headway. Centralizing this data, reducing development time, these are all starting to sound like some really great ideas and things that we can use in the organization to help sell why we need to invest in this project.

 

Slide 8:

You get a little sense of fear in your boss because gears start clicking and he or she probably starts saying, “Well, you know, this sounds great. I love what you’re describing here, but it sounds complicated, and honestly it sounds like it’s going to cost us a lot of money to pull off.”

 

Slide 9:

And that’s true. The data layer project is an expensive investment. It’s expensive because it takes time, it takes people, and it takes money to pull off. One of the biggest mistakes that the organizations make is they undervalue, they under budget what it takes to get a data layer project in place. They say, “We can pull this off with half a developer in six weeks and we’ll be done.” Unfortunately, those projects typically end in failure and the data layer project gets a stain on it. From my perspective, having seen many data layer projects deployed across very large brands, the three things that will make a project successful is one: having the budget in place to pull off a very complex project. That means money to attract talent to help build it, retain outside resources, or realign internal resources that can help you build, design a data layer from a business standpoint. Ultimately, this is a business function. The data layer is meant to serve as the core set of data used by the business to inform the business of the key measures they need to operate.

Secondarily, you need people. The people that we’re talking about here is development. While in the long term, we have great promise of savings from a development perspective, up front, this is going to greatly ramp up the amount of development resources needed to pull off a project like this. That’s because the key pieces to getting a data layer deployed live within the development framework. Having development resources assigned to this project and prioritized, will be key to making this project go. Having this as a side project and constantly pulling developers off to have them work on other projects is a recipe for disaster.

And finally, time. I know we all want to get to this point where we have this great data layer, we’re using it as a foundation that we’re going to build this amazing marketing stack on top of, but it takes time. A lot of organizations don’t want to hear that, especially if you’ve invested hundreds of thousands of dollars already in licensing fees for these marketing technologies, the last thing you want to hear is, “Well, it’s going to take us half a year to get to the point where we can really get these things running to the level that we expect.” But that’s the reality. Again, having seen many of these projects executed from beginning to end, on average these projects are taking anywhere from four to six months.

That expectation should be set up front. Again, this might be a tough thing for the business to swallow, but I’m a firm believer in being very transparent, not only in the benefits that the business will see, but the cost that they’ll need to invest in order to make this project go. However, this is an investment that if done right, if you build a solid foundation that you can build your entire marketing stack on top of, you will see massive, massive benefits. Not only in the short term, but in the long term as well.

Slide 10:

So your boss is saying, “Okay, you know this is starting to make a lot of sense to me. You’ve kind of hinted around a few benefits. You’ve mentioned things like reduced development costs in the long term, which I like because I don’t like going to these planning meetings and being told that I’m using too much of the company resources to make marketing tags, I like that. We spent a lot of money on marketing technology and they’re not talking to each other. We have a DMP and it’s not talking to our digital analytics platform and neither one of those is talking to our optimization platform. I was at a conference last week and they were showcasing that if these things could all talk together, that’s the promised land. And it sounds like that what you’re telling me is that if we deploy a data layer, it’s going to give us that opportunity to connect all of these systems together. So we can break up some of those data silos and really start to see the real return on investment that the sales reps promised us when we were looking at these.”

And that’s true. There’s a lot of amazing benefits here. We’ve kind of danced around of few of them, we’ve kind of hinted at a couple more, so let’s go through what I think are the top four benefits to deploying a data layer. I would use these four points as your talking points when you’re speaking with your management team, when you’re trying to sell this internally, and you really should look at this as a sales and marketing effort. That’s one of the things that a lot of analytics practices fail to do is, they say, “We’re internal, we’re going to push this out and they’re just going to take it because we can tell them what they’re going to do.” Again, another recipe for disaster there. Analytics organizations should look at their goal as partly a sales and marketing role, and they need to convince and sell their idea to the organization to get buy-in. I would use these four concepts, or these four benefits, as a way to get buy-in from the greater organization—executives, marketing, development—to invest in your data layer project.

Slide 11:

The first benefit that I want to highlight is: critical marketing and analytics code can now be deployed much, much quicker and to our environment. Why is that important? It’s important for a lot of reasons, but I’m going to highlight one reason: marketing organizations like to run really, really fast. One, I just think it’s in their DNA, but two, marketing organizations like to take advantage of topical and timely events. If they have an opportunity to capitalize on something that’s happening now, they want to run as fast as they can and do it now, with or without the support of the analytics organization. That’s not necessarily a great long-term strategy, but let’s look at why they take that approach.

In the old-school way of page tagging, this is typically what would happen when a marketer would run and event, let’s say—and I’ve seen this happen in the real world—your marketing team came to you and said, “We’re going to run a half million dollar Facebook buy and we have some marketing tags that are going to support that. One, from a reporting perspective, and two, from an optimization perspective so we can fine-tune this campaign as it runs over the next couple of weeks.” Typically, what would happen is that request would go into some queue, JIRA or whatever system you’re running, and it’d probably sit there for a day or two, eventually someone would come around and prioritize it, and they would say, “Okay, let’s see, the developer that works on those types of projects is on another project right now, but he’ll free up in a week, and then he’ll get started on it, and then we can align this with our following release. So in two to three months we’ll have you tag out into production.”

Typically, what happens is the marketing organization says, “Great, we’re going to go ahead and move forward without your support. We can’t wait for that.” That’s problematic in that, one, they’re going to release a huge campaign—half a million marketing buy—without any real way of being able to measure the impact of that campaign. But I think more importantly, they don’t have any real kind of visibility into that campaign. They’re on a set it and forget it type of mentality. However, if they have the analytics team’s support, they could tweak and fine-tune that campaign as it was running.

Once we have the digital data layer in place, that becomes much more of a reality. The request bypasses that whole process of having to figure out the guy that has this tag, is he on a project or not? We’re done. The developers have already put in the hard work. To lay the foundation to provide the business with the information and data they need to run, and in this case, to run a big marketing campaign. So we bypass the whole process, we plug your marketing tags directly into the data layer and you realize ROI now instead of later. The time value of money aspect is huge here.

Slide 12:

The second benefit that I want to highlight is: the greater flexibility we will have when it comes to testing out new marketing technologies. What do I mean by that? If you’ve been in the pace long enough, you’ve probably seen it at one time or another, that slide that gets passed around that shows the marketing landscape. The one that’s like a four quadrant grid with 150, 200 different logos smashed into it trying to help you visualize how crowded and complicated the marketing landscape is. And it’s true. As a business, as a marketing organization, how does that impact us? We want to constantly be utilizing the product, and the product mix within our marketing technology stack that’s going to give us the best possibility to achieve and be a front-runner when it comes to business. That historically has been really hard.

As new technologies come online and weekly—even daily—we’re seeing new vendors pop into the space, it’s really difficult to try them out. Again, going back to the previous slide, it’s a two or three-month process to get them plugged in. That has become very cost-inefficient and not effective, and typically those projects are denied and we just go on using what we use. Once we’ve got the data layer in place, running proofs of concept with new technology becomes much, much easier to do—affording you the luxury to plug in new technologies, vet them out to see if they’re the right fit for the business, or if they can be ignored from the rest of the noises out there. This is a huge benefit, especially to marketing organizations that constantly want to stay on the cutting edge of the new technologies that are in the space.

Slide 13:

The third benefit that I want to highlight is one of data integrity. This may be shocking, but a third of companies out there are paying licensing fees for marketing technologies that no one in their organization is using. They’re literally sitting on the shelf collecting dust. And that’s because people don’t trust the data. It doesn’t matter how big the name is of the brand, it doesn’t matter how much money you’re paying for licensing fees, it doesn’t matter how great your analytics team feel the implementation is, if the end user doesn’t trust the data, they’re not going to use it. This is a huge problem because we need to drive user adoption to be able to do the things that we want to do with an ever-increasing complexity in our marketing organization.

One way to do that and address this directly, is with a data layer. By deploying a data layer, we move the critical data needed to run the business away from the vendor, and more in alignment and coupled with our digital property. We’re no longer speaking vendor speak. We’re no longer tying things directly to a vendor, but now our data collection is coupled tightly with our application. This is critical, if for no other reason, as our site matures and ages over time, the data layer matures with the site. It’s no longer a side-job or an afterthought. A data layer alone will drastically reduce this number and increase trust in data, driving an increase in that trust and user adoption, which will go a long way in helping to complete your marketing initiatives.

Slide 14:

Finally, and I saved the best one for last here, if we use no other argument than this one, this one has some first numbers you can put behind it, and this should be your silver bullet for how you convince your organization to make the investment. This is a real world study that we conducted with a large retailer, and what we did is we took a fairly popular vendor marketing tag whose implementation was medium level of effort. There are definitely marketing technologies out there that are much more complex than this to implement, and there are a lot out there that are quite a bit easier than this to implement. We wanted to take something that was middle of the road to get an idea of how much could we save by investing in a data layer.

We put together our technical specs that were provided by the vendor, and we went to the development team and said, “This is what we need deployed. We need it configured per this specification and we need it deployed across the entire site. How long will this take you?” they came back with an estimate of 170 hours. Having been in the space a long time, it was pretty spot on. Let’s jump down to the bottom, this is the actual time it took to configure and deploy the tags: 37 hours. Not only was the time cut drastically, the level of work was shifted. The 37 hours didn’t even fall to the development team, it was the digital marketing team that did that effort. If we do some back of the napkin math here, this project alone, we’re looking at 20 to 30 thousand dollars in savings, just for this project. That is massive. You can quickly see as we do other projects, as we look at maintaining our technologies, this data layer is doing to more than pay for itself in a very short period of time.

I think it makes sense. We’ve probably convinced our bosses at this point, but let’s review the four critical benefits of why we’d want to deploy a digital data layer. We talked about improved speed to market. Extremely critical in this crowded landscape of technology vendors that we can get things out quickly and we can run at the speed of our marketing organizations. We can pilot new technologies as new optimization and personalization, and lately, data science type tools come online. We want to be able to try them out. We can do that now with our data layer. We no have increased trust in the data. We’re now coupling that data tightly with our web properties and it’s going to increase the trust in our data, driving user adoption up.

And finally, and really the piece that should seal this deal is the cost savings are massive. We saw one example of a real world study we did with cost savings of 20 to 30 thousand dollars just for a single project. This makes sense. I hope you can help convince your boss that this is the right way to go. It’s no longer a nice thing to have, you really need to be here. I’m passionate about this topic and I would love to answer your questions or continue this conversation. You can go out to our website, 33sticks.com, we have a lot of great information on data layers. Or you can track me down directly, probably the easiest way in on Twitter, I’m @usujason. I would love to chat and answer any questions that you may have.

Previous Article
Choose Your TMS (1 of 3): Adobe Dynamic Tag Management
Choose Your TMS (1 of 3): Adobe Dynamic Tag Management

This article discusses Adobe DTM as a tag management solution.

Next Item
Launch by Adobe & ObservePoint: A Data Quality Feedback Loop
Launch by Adobe & ObservePoint: A Data Quality Feedback Loop

Learn how you can use ObservePoint to test your Adobe Launch implementation to ensure every tag is firing c...