The Marketing Analytics Cycle

In this episode, we’re joined by Bartosz Schneider, Lead Professional Services Consultant at Supermetrics, and we’re digging into a super important topic today, and that is the marketing analytics lifecycle and how to deploy successful analytics that drives value.

You'll learn

  • What's the spectrum of data pain?
  • What are the stages of the analytics maturity model?
  • What are the opportunities and challenges at each stage?
  • How can companies ease the pain of data and analytics as they scale?

Subscribe to the Marketing Intelligence Show

Learn from Supermetrics' experts how to use data to fuel growth and maximize the ROI of your marketing spend.
Subscribe to the Marketing Intelligence Show



All right, we're back with another episode of the Marketing Intelligence Show, and we're joined by Bartosz Schneider, Lead Professional Services Consultant here at Supermetrics. And we're digging into a super important topic today, and that's the marketing analytics lifecycle and how to deploy successful analytics that drives value. And to kick things off, I want to dive into a story you have to tell. I don't know too much about it, so I'm quite intrigued to hear what you have to say about this, but it's something that you called the spectrum of data pain. So to kick things off, Bartash, can you tell us more about this story?

Bartosz Schneider:

Yeah, sure. First of all, it was mainly born as a buzzword to get people's attention. When I was giving talks about the topic, I had to host a session internally in Supermetrics about that and also gave a talk at the University about that. And I just wanted an edgy term so that people would listen to what I wanted to say.

So the spectrum of pain, of course, is a very edgy term, but in general, when you think about it, data management and organizing things can cause a lot of pain. And that whole idea about that came from actually my previous job before coming to Supermetrics and what I did nowadays, it's uncommon to stay for more than two years on average at one company. But what I did before coming to Super was I spent eight years in one company.

It's insane. And eight years in data in addition to that in the same area, but the different parts of the business. And I saw that company grow from reporting in spreadsheets to a data lake and the whole transition and all the ups and downs of going through that. And there was a lot of pain in that process.

And there's an anecdote I read once in a book. I couldn't quote it any more right now, I'm not reading too many of these business books, but it was disrupting analytics or something like that. The book itself had a very buzzwordy title, but it was competent. And there was a quote that some business analytics have found that 70% of data warehouse projects fail on the first attempt. And so I've been saying, I'm reiterating, there's a lot of pain in data management.

Try to define why I believe in that term. And so that's where this comes from, the whole thing. And it's really about, I believe, the pain isn't changing because maturing your business and maturing in your data setup has a lot to do with change management. And it's challenging on many levels. It's challenging because you're introducing new technologies that people aren't familiar with potentially.

And at the same time, you have to make sure that your organizational processes evolve and adopt this new technology. And so, you start with a simple setup. You outgrow your simple setup, like reporting on spreadsheets, for example. The pain starts because you have growing pain, and your needs don't fit into a spreadsheet anymore. And then your business or you as a person, depending on the size of your problem and company, is that you start looking for relief for your pain.

So you start looking at what's out there to move into in terms of doing better data analytics and finding other solutions. And you have to navigate this chaos of finding out the good next step on the next technology, introducing it again, adopting the processes, and then figuring out whether it works and keeping it alive.

And this happens over and over again because I found that, in my experience, it can happen first on a company level, then it can happen on a department level. So your overall company health metrics are now deployed, and now you have a reporting on C-level that works, but what about your marketing department? What is their data maturity on a more granular level? And then, how is the process on the IT level? How is your performance marketing working with data and what rules are they using?

Each of those almost like we also call it a fractal of pain because each point where data is deployed and solutions are used needs its own process and growth management.


Yeah, absolutely. And it's a great hook to get people in the spectrum of data pain. And at the same time, everyone can relate to that, and as you said, as companies grow, so too do their data and analytics needs. And the same thing happened for some marketing organizations in particular. And we speak a lot about marketing analytics maturity, along the same lines. And we also talk about everyone being on a marketing data journey.

And you start off with a relatively humble setup and then evolve over time, which is what we're going to get into in more detail here during this discussion, as the marketing analytics lifecycle that you've developed is really about explaining what that setup looks like at different stages as your company grows. And so, a good place to start is the first stage of this lifecycle. So could you tell us a little more about what that starting setup looks like?

Bartosz Schneider:

Sure.  I'm simplifying things a lot. I want to say that first because I'm trying to aggregate the spectrum of how people can work with data, but it's a dumbed-down kind of. But the whole design is along personas. You can define a persona first. So let's say an early maturity or low maturity environment could be an early startup or an owner-run business where the problem is contained, so to speak.

You have few people working with limited data; your business does not have huge questions that would need massive amounts of data to be answered, speaking maybe one to 20 employees in this maturity stage. And again, as I said, this pattern can repeat on different levels. So it can also apply to teams if you have a single person running a team or operating some part of your business that the same rules can apply to them.

But on a business level, it might be like you have one product, and you're focusing your marketing to drive sales. So something contained. And in that environment, most typically, people don't have a data background even. You're not managing a team of data analysts at that stage of your business yet. It's you, yourself, or your people who are marketers running the business or the operations, and you're trying to make data-informed decisions by doing what you can.

And typically, and from conversations with our customers at Supermetrics, the fact that the thing that people can do is something like operating a spreadsheet, or maybe you're an enthusiast, you know how to build your dashboard, and you have made your first attempts to visualize data as well in a tool like Looker Studio, but let's say it's mainly spreadsheet-driven because you know maybe how to do your finances in a spreadsheet, you've tinkered around with it.

Everyone at some point in their lives, I think, has touched this spreadsheet. So that's naturally the space where people start working with data, and classically is also the entry-level tool. So yeah, you might have Excel, Google Sheets where you input data typically manually or through automation already, like Supermetrics on a small scale, with very few data sources, and you have created a dashboard or so there. But most people get by just looking at data tables in spreadsheets at that point.


And what kind of questions or insights are companies at this stage able to ask and get, and how do they use their data at the beginning of this marketing data journey?

Bartosz Schneider:

So typically, I'd say the first thing you want to know is it's always the same question, how am I doing? Is the thing I'm doing the right thing that I'm doing? It's mainly about informing yourself about how your business is doing in your marketing. And for that, I'd personally, from an analytics experience, always recommend reducing to the numbers that really matter and the numbers that you influence, that you can decide.

And that's then typically you monitor your marketing spend. So just have an overview over time, marketing spends overtime on the platform of your choice. On a small scale, it might be that every marketing campaign is still handcrafted, so you're not using any automation. You're thinking of individual campaigns you want to run and want to see how they do.

So you should have a, let's say, Facebook Ads report with individual campaigns or maybe two at the time that are running, and you compare the numbers against each other. You track potentially how you're spending your budget. Are you still within budget for the month, or are you in danger of going over budget? And then, of course, the performance of the campaign is important at any stage, but at this stage, we might just, depending on what the goal of your campaign is, you track maybe, is it getting me the traffic? Is it a brand campaign focused on gathering traffic to the website you're running? Is it accomplishing that? What are the click-through rates on the ads?

Or if it's more a campaign focused on driving sales, maybe you're looking at numbers like, is this the campaign driving conversions through your integration on Facebook? Do you see sessions coming from that campaign? And potentially you also might be looking at your Google Analytics data and the marketing source report there to track how the marketing traffic drives user behavior on the website.

To summarize this, low-level kind of data management, everything, all the truth, fits into a spreadsheet, and your truth in data as use sources, meaning platforms, where the data comes from you, it's a handful.


Yeah, absolutely. So this is the starting point, and then your business grows, your needs evolve, and you're moving into more of a scale-up mid-market size company. Can you tell us more about this second step of the lifecycle?

Bartosz Schneider:

Yes. Let's assume your business is successful. The spreadsheet did a good job informing your decisions, and you've made the right ones. So you've expanded your business, and it's growing, and you're now really expanding into different marketing channels. It's not only contained, where you have a few campaigns running and monitoring them, the spreadsheet still works.

You may now also be concerned about brand marketing. You need to monitor your return on ad spend on individual initiatives you're doing on different marketing channels. So it could now be top-of-funnel, mid-funnel campaigns, and bottom-of-funnel campaigns, all of those things. You might be starting to experiment with these channels.

Going back to my previous employer, the experiences that I had there in the marketing analytics team were the best transition. The company was moving from advertising on Google Google Ads and running SEO to a marketing department where, when I last had 60 employees, I covered five different online marketing channels across the funnel.

You might be getting into that at this stage, just starting to see what other opportunities online marketing can have for you. And, of course, it's increasing the information and data you can get because the sources, like every source of marketing or every marketing platform you spent money on, also give you data back. Everything needs monitoring on its individual level.

You want to make sure that campaigns are running and compare the performance of marketing channels against each other. You start having an organization that does that for you at this point; I doubt that it's a job for a single person anymore. So you might have employees that share the work or split it, and then you start getting a problem that you did not have before with the fragmentation of your marketing stack and its maturity growing into multiple channels; you're getting that problem that then typically is called the single source of truth and democratization of data and knowledge kind of because you have to align realities between different people.

So imagine when you get your marketing team into the weekly meeting of the departments in one room, they have to be able to talk about the same KPIs, goal definitions, and metrics, and everything has to make sense.

And it's a problem in my hypothetical maturity spectrum that starts creeping up if you're not aware of it, that you might run into an issue where people talk about different realities because data is distributed. Different people have different spreadsheets now, so who knows what they're doing there?


Yeah, absolutely. This is a podcast, so you can't see me, but I was smiling and nodding while you were talking. I think many people, particularly marketers, will relate to this, and as you grow, you start searching for that single source of truth, and people have their own reports, and it gets a bit more fragmented.

The first step was about the spreadsheet as your holy grail of marketing reporting and analytics. So let's dig into the setup for the second stage, then. What does that look like, and how do you build that up?

Bartosz Schneider:

Yeah, at this point, the spreadsheet still has not lost its charm yet. So it can still serve and be a good tool. The humble spreadsheet is a very powerful tool if you know how to use it. So let's keep it still in the kind of stack of analytics, at least to some degree. But the issue with spreadsheets, and again this is going to emerge at this point, potentially, maintaining them is a pain.

As long as it's one person keeping it under control and knowing what each formula does, and if you have some experience setting up reports and spreadsheets, you'll have structured them well, and there you can contain the chaos and spreadsheets. But as soon as you enter an environment where multiple people are creating reports, it can get very quickly to a stage where making changes to those Google Sheets or Excel is going to be painful.

You have cascading functions. It's going to be painful. If you've ever seen a big controlling spreadsheet or a master marketing report where multiple data sources come together, these things can be quite heavy, and making changes to them is a full-time job sometimes. So we have to keep the spreadsheet for now, but it's starting to lose some of its shyness, put it that way.

And the other aspect that I mentioned was the sharing, or what I said earlier, with the democratization of data that you have typically in organizational structure in which reporting on results to people who have not built the report is becoming a thing. In the weekly marketing meeting, you report on your team's or your channel's performance.

And in that case, at the latest, you'll be getting into data visualization at this stage. So building dashboards because humans can visualize data better than a table of numbers if it isn't obvious. So at this point, I'd say definitely you need to choose a dashboarding tool. Sure, you can still build charts in spreadsheets, and that's fine, but if you want to have an infrastructure also for sharing these reports with people and opening up to people in your company or across your teams, that's something like Looker Studio is probably going to be part of your setup at this point because you can author a dashboard, you can share it with people, you have control over who has access to edit it, who has control access, who can view it. And so it's just very convenient to share insights through tools like that.


Good stuff. And then, I guess from here, the third and final stage is for larger companies heading towards the enterprise side, larger marketing agencies. So I'm intrigued to hear more about this third and final stage. What does that look like, and what's the background?

Bartosz Schneider:

Already in the previous stage, depending on the complexity and your vision, you might have run into problems with keeping the truth, the truth. And so data warehousing is another concept that might already have been considered, or you might have introduced that on a small scale, but at least at this stage where we're really talking about agencies or big companies, data warehousing is almost a necessity.

And to maybe again, the drawback to my anecdotal evidence on my previous job where basically in the eight years that I've spent there, we've migrated data warehousing first and then introduced the concept of the data lake because the organization required that kind of data management infrastructure to keep its processes alive and be able to make good decisions that are informed by data and not the gut feeling of some managers.

So what do I mean by that? In the marketing context, it's really about the point where your data sources and the different marketing channels you're using generate data that's too big to fit into any tool other than a database. Every spreadsheet has a limit, which is exceeded as soon as you dive deep into your data. Maybe you're AB testing marketing campaigns or creatives against each other. To determine whether version A or version B performs better, you need to pull data on that granularity level of your performance KPIs, and that data is bigger than before because it's more granular. You have way more details.

You may want to explore different audiences and see how marketing performs for different audiences in different regions, different devices. At this point, you are also analyzing your web tracking data.

So be it Google Analytics, Adobe Analytics, or first-party data that you might have from your web service that you're running. All of that can lead to better-informed decisions for your business at this stage. And if the business has done its homework and has grown well, it will also have scaled up its abilities to mine that data for information.

So you might have analysts whose job is to uncover interesting bits and pieces from all that available data and even form decisions. So also, their work will be much easier if they can get their data to analyze from one single source of truth or sometimes, which is why it's also sometimes called the single source of data for your company.

And so data warehousing is just the concept that you create one central kind of a bit of business infrastructure, I used to call it, where everything that is potentially useful for data analysis for your business is stored and accessible.

And so you solve the problem of fragmentation that is crept in at the earlier stages. With scaling up, everyone was starting to get their own data, into their own spreadsheets, potentially creating their own versions of business reality. And the data warehousing part is trying to solve that problem mainly by centralizing the management, applying business logic centrally, and defining KPIs in one place for everyone else to consume and draw from.

So that every report that uses your data warehouse as a source theoretically, in an optimal scenario, has the exact same numbers and exact same kind of ground truth for everything. And of course, on top of then, we still key Looker Studio as a visualization tool, but it also, at some point, Looker Studio's capabilities for enterprise analytics run out of steam, and we'd then start looking at tools like Power BI, Tableau, Qlik Sense, all these really BI tools, the name business intelligence is in there for a reason.

They have features that make them more suitable for larger-scale employment in an organization than the humble Looker Studio, which is free. So that's what data warehousing really is. Data lake is then the next iteration in scale. But if you're interested, I can talk about that as well, but that was a long monologue for now.


No, that was a great overview of the challenges, background, and what you can do with that data and the setup. It would be interesting to hear the next evolution you spoke about, going from data warehouse to data lake. So you expand on that. It would be interesting to hear.

Bartosz Schneider:

Yeah, it's a paradigm in data that kind of people come up with new terms every few years. And data lake and lake house were one of that. You also sometimes hear data mesh. It's more like concepts that try to find solutions for new problems that again emerge with scale. And that can be, for example, in a data warehouse.

Let's talk about technology for a bit so that I define what I mean about by that. A data warehouse, in my term, would be you're running a database, it can be an on-premise database, but typically nowadays everything is hosted in the cloud. So let's say you're running a data warehouse in Google BigQuery or a data warehouse in the Snowflake Database, so something like that.

And these databases, when I explain that to our customers on consulting calls when they're still new to the concept, I say that it's like a spreadsheet on steroids, backed up with the most powerful computer you can think of. And so you can do everything and calculate everything you want on these databases and your stored data. So that gets you an analogy that kind of works if you don't have another concept of databases. But storing data in a database has the same advantages and disadvantages as storing data in a spreadsheet. You can do that. That's one advantage.

The other advantage is that it's available for processing, like a new spreadsheet. So you can apply formulas, run calculations of it, and use it as a source to fuel your dashboards and draw charts.

The disadvantage is that you're storing data in a table. So it has, first of all, storage costs on databases is a thing in the cloud. So you're running your BigQuery, paying storage fees to Google. If you're running your database in something like Snowflake or Redshift, you're paying for the database running because it's essentially an application that's always on. You may leave your computer on with Excel running all the time in the background, performing tasks while you try to do something else. Kind of the same analogy.

And hey, most people never reach that maturity or that problem, and it's fine, but if your data grows really big, it can. Depending on the size of the company and again the number of data sources and granularity, and whether you have first-party data from your service or your business processes also being stored somewhere, it can get too big to store everything all the time in such a database.

And then, we introduce the data lake concept, where a business can create a data lake where it's basically a storage layer. Think of it that — my analogy for that's to think of your Google Drive or your computer's hard drive where you have folders with files. You can throw stuff in these folders with files, you can throw your photos into random folders on your computer, and you'll only open them when needed.

So similarly, a data lake is a kind of dump where all the company data is stored in files, unstructured, unsorted, or slightly sorted, but it's mainly for storage. It's way cheaper to store vast amounts of data in something like an Amazon S3 bucket or Google's Analog for that cloud storage. And you only pull data from that lake into an analytics database when you need that or only the data you immediately need for a certain application.

And it has advantages in that it lowers your cost or optimizes your cost for running your analytics infrastructure. So the database is only processing data that you're actually using for a specific use case while also having the flexibility to store any data in the data lake itself or storage that you might want to access in the future on any level of granularity.

So that is kind of, I think only the biggest companies have that problem, and especially, I think I have not seen a company have that marketing data problem — most get a data lake for different for other reasons and then choose to also put their marketing data into the data lake because that's the best practice. You should have everything in the same infrastructure, but it's really for the biggest needs only.


This is cool. This is great to get the whole overview of that journey, from the humble but powerful spreadsheet to a complex data lake. And one thing I'd love to ask one thing, and just thinking back on your experiences at your previous company and working with some of our customers. Marketing needs to be the driver of change between each of these steps and moving up and upgrading and advancing that stack. What advice would you give marketing leaders to drive that change, get the buy-in, get data teams on the same page, and get business owners aligned? How should marketing teams make that change between every stage of this lifecycle?

Bartosz Schneider:

That's a very good question. I'd give away free consulting services with the answer, but let's do that. I'd rather that people do this right than have problems later that need fixing. So all of these transitions are... First, I'll admit this is difficult; maybe that's advice number zero that I'd give.

Whether you're a marketing leader or the humble marketing executive whose basically job is to run the campaigns, let's all admit that this is a complex topic. It needs preparation and honesty because we all make mistakes. It's better to admit that early on that, this stuff is difficult because we're talking about you need to think about the future and future problems that you might have if you grow while not having them yet but having different problems.

And this is a forward-thinking that's very hard and challenging for the customers that we've met, and I've talked to and looked at their setups; the recurring pattern that I see actually contains two main problems.

There might be more, but let's talk about the main problems. Number one is to get an honest feeling of your scale of data and data problems. And that might be difficult because you might need someone to tell you that from the outside. But I mean that I've met customers who were reluctant to consider data warehousing for their data problems because they could not see that their problems were outgrowing their spreadsheet or Looker Studio environments.

It's a conversation that I have over and over again. It's basically me going to check out a customer setup and looking at their analytics needs, looking at their incoming data, and seeing how they try to fit two big problems into a too-small solution.

So there is a moment when you outgrow your spreadsheet at your Looker Studio, and the sooner you start thinking about how you can transition to a data warehouse, pretty much the only option at that point, the better for your own organization and yourself because it's just like, hey, admit that you need a change. And the moment where you reach that, are you and your teammates annoyed by dashboard loading times?

That's one example where we need to change something. When we try to open our Looker Studio dashboard, it takes an annoying two minutes to open up and load. You might get by that for a while. You sit there and bear it and then have patience. But this is a symptom that you're already outgrowing the capabilities of the tool of choice that you have right now. Or Google Sheets, for example, when you execute a formula, it takes painfully long to process the number.

These are trivial things to watch out for but are the earliest symptoms you can spot. Other things to notice are, are you arguing about which number is right a lot in your company or your team? I've had that happen to me, again, talking about the past where we had meetings with several people in the room and high-ranking managers only to discuss whether that number or that number was the right number of sessions because we were comparing to different sources of sessions against each other. It never went anywhere because both were true, only that the definitions differed.

So there were different definitions of sessions, or you name your metric here, and we had a back-and-forth of never finding a consensus of what number was right. So that's again like a growing pain symptom that you should see and be honest about taking the next step. As the number two symptom or thing to watch out for when making these changes, anecdotal evidence is very technical.

Make sure you have a campaign naming convention in your marketing setup. This may be trivial to some listeners, but I should have started a tally of counting how many companies I meet who have a bad or no naming convention. And I'm not trying here to blame anyone. I've seen this happen so often that it's very obviously a systemic issue.

If you're a big company working with marketing agencies who run your marketing in different markets worldwide, making these agencies align and use the same taxonomy for campaigns is challenging. If you're an agency yourself and you have 50 account executives that run the ads, you have to make sure that 50 people use the same naming convention when they set up campaigns.

It's an organizational challenge. Plus, you should come up with naming conventions when you're still looking at spreadsheets. Now, should you think of how I want to structure my campaign and ad names? What do I want to put in there? What delimiter should they have?

Very practical things that you can do right at the very beginning, and it will last you for the next 10 years, people don't think about, and it's so trivial to do right but so challenging at the same time. My advice is, really; maybe someone is listening to this now and thinking, what the hell is this guy talking about?

But think about it when you start pulling data from 10 different marketing channels into a data warehouse. You want to run every data transformation automatically. You're going to be extracting information from that naming campaign with code, so SQL code, and you need to set up that naming convention so a computer can do something to it.

My recommendation is to get a campaign naming builder or tool somewhere. Makeup one yourself in a Google Sheet. It can be as easy as every item in the naming convention should be split by an underscore, and you can always add more stuff to the end of the string. Just keep the order of things the same, and then you will have a very smooth experience with data warehousing and processing the data in the future.

And one last thing to end all this is, my advice would be to save time, money, and energy on coming up with how to introduce the cool thing that everyone else has. Think about making the right choice for your business and how you can introduce it so that people are using it and you can get value out of it.

Get a data warehouse for more than just the sake of having one if you're not able to find someone who can own it, who can run it, people who can access the data, and also how you can communicate insights from your fancy data stack to the people who are running the business, to the executives looking at reports to the campaign managers, optimizing campaigns.

This effort concerns the entire organization, and you need to manage that change, and whoever drives that transition has the whole work to make it held and impact other people's lives positively.


Yeah, absolutely. And this is super good to hear and reassuring as well to hear about the journey and the challenges. And for me as well, kind of just hearing you talk, it also reminds me of my time in Supermetrics in that I've been here, well, not quite eight years as you were at your previous company, but like four and a half to five. There were just three to four of us in the marketing team and about 25 to 30 in the company, and now we're what, 300 plus, 330 plus in the marketing team. We're a global team across multiple continents. We're a multi-product team in the company now.

And the change in our needs has been dramatic. And we have an analytics team, a data team, and complex greater needs, and the change in our set-up has been amazing over this time. So yeah, for sure. We're all on a journey, and there are always challenges to figure out and so forth. So super good. So, Bartosz, I want to thank you so much again for joining us on the podcast today.

Bartosz Schneider:

Oh, it was a pleasure to be here.

Turn your marketing data into opportunity

We streamline your marketing data so you can focus on the insights.

Book Demo