Skip to content

Why Organizations Struggle With Analytics (and How To Overcome the Struggles)

A person pulls a boulder up a steep hill next to the headline Why Organizations Struggle With Analytics (and How To Overcome the Struggles)

Many organizations struggle with digital analytics. Although most organizations have adequate tools and many have the right people, few understand how to develop a well-planned analytics process. The approach described in this video offers a road map to help your organization’s digital analytics work pay off in actionable insights. 

About the speaker: Adam Greco is an analytics industry veteran who has advised hundreds of organizations on analytics best practices and has written over 300 blogs and one book on analytics. He is a frequent speaker at analytics conferences and served on the board of the Digital Analytics Association.

Hello, my name is Adam Greco and in this session I’d like to share some of the struggles that I’ve seen organizations face when it comes to running successful digital analytics programs and how you can overcome them.
In my digital analytics career, I’ve had the unique perspective of working client side at a vendor and at consultancies.
This has enabled me to see digital analytics programs from multiple perspectives.

I’ve been associated with hundreds of digital analytics programs over the past 20 years, and I’ve seen organizations that succeeded and many that failed.
In fact, one of the roles I held at Amateur was that of saving troubled accounts.
If a client was fed up with using Omniture Psych Catalyst, then I’d be brought in to try to save the account.
I used to joke that I was the wolf of amateur like Harvey Keitel in the movie Pulp Fiction.
As I saw company after company struggle to be successful with Psych Catalyst, I began noticing patterns.
Therefore, in this session, I’m going to share what I learned and how I helped these struggling organizations overcome their challenges.
Before we dig in, I wanted to let you know that if you feel like you’re struggling, you are not alone.
Many organizations struggle with digital analytics.
Sometimes it seems like it’s just your company, but I promise you it isn’t.
Most organizations have the right tools and often the right people, but where they fall down is the overall approach or process they take towards digital analytics.
Many of us didn’t go to college to do this type of work, so we make it up as we go along.
While no process is perfect, the following is what has worked for me over the years and I hope it will provide you with a road map to help your organization be more successful with digital analytics.
The first step in the process is determining whether your team is a cost center or a profit center within the organization.
To determine this, you need to take a step back and understand why your team exists in the 1st place.
The odds are your team was started long before you join your organization.

Do you know why the organization first invested in digital analytics?

Do your stakeholders know why your team exists?

Do all of your stakeholders agree on this?

Does your analytics team currently cost the organization money, or have you found ways to show that you are a net positive financially?

These are important questions, especially during market downturns like the one we’ve all witnessed.

You need to think about how much time your team is spending simply running reports versus adding value and generating ROI.

Work with your senior leadership to agree upon why your team exists in the 1st place and whenever possible try to be a profit center versus of course versus a cost center.

Once you know your reason for existence, the next step is to understand the high level objectives of your digital properties, which may be websites or mobile apps.

I’ve seen many cases where digital analysis is happening at a super granular level, such as how many people clicked on this link.

That isn’t going to bring you very much ROI.

Instead, you need to always be revisiting why your organization even cares about its digital properties.

Identify the three to four reasons why they have a website or a mobile app.

One way to do this is to think about how your business would be negatively impacted if the website or mobile app completely went away.

Make sure you document these top three to four objectives and get agreement from your bosses and stakeholders that they are correct.

After that, you should prioritize them so you know how much time and money should be allocated to each objective.

Ultimately, you want to be spending your resources on things that are most critical to the organization.

This will also act as a shield to avoid doing lower priority work such as the ubiquitous how many people clicked on this link question.

Once you have your business objectives locked down, the next step is to go one level deeper with business requirements.

I’m often shocked at how few organizations take the time to proactively identify the business questions they need to answer via their digital analytics program.

Since business objectives could be high level, business requirements are a means of breaking them down into more manageable chunks.

Business requirements can also be used as a conduit to your detailed analytics implementation.

Each business objective can be broken down into a finite series of business questions that support the objective.

For example, if one website objective is to increase financial transaction self-service, then you might have questions such as what percent of transactions are being done via self-service today, which types of transactions are not being done today via self-service, and so on.

These questions help you achieve your higher level business objectives.

Business requirements can then be broken down into specific data points that can be collected on your digital properties.

To answer the requirement questions in the preceding example, we might set a metric each time a self-service transaction occurs and a dimension for the type of transaction.

If you are unfamiliar or unsure of how to create these business requirements, I’ll give you some tips.

First, review your current implementation and reverse engineer the data points you have into business questions, kind of like playing Jeopardy.

Next, leverage your team and past analytics requests to add requirements that you know your stakeholders want and have always asked about.

Once you have a decent requirements list started, you can conduct interviews with stakeholders and others at the organization to see what questions you may have missed.

I have found that by having a list initially and running it by them, it opens up the channels for bigger and deeper conversations.

If needed, you can walk through your website with stakeholders to see what questions arise as you click page to page.

Once you have a good solid list of requirements that you and your stakeholders are comfortable with, you can de duplicate them and get your stakeholders to sign off on them and assign priorities to each.

Here’s an example of a requirements document.

You can see that we have identified some specific questions that need to be answered and that each question rolls up into an executive sponsored business objective.

We’ve categorized each requirement and assigned an owner.

This type of document is one that you can easily review with your stakeholders and executives and get common agreement or sign off.

This lets your team know that if they can answer the questions on this list, they will be helping the organization and that stakeholders will hopefully be happy.

It also minimizes the risk that your work efforts won’t align to your corporate strategy.

Unfortunately, instead of using business requirements and business objectives, most organizations I run into are running their program from a solution designed reference, commonly known as an SDR.

This happens all the time and is a terrible practice.

An SDR is simply a document that tells you what data you are collecting, but it doesn’t tell you why.

SDRS don’t help your end users and they’re often not kept up to date.

Instead, you should be driving your analytics program by website objectives and business requirements.

As previously mentioned, you can use your SDR to help you identify the business requirements, but you should never rely solely on an SDR for your analytics implementation.

Try to stay focused on your objectives and business requirements instead.

This leads to the next step in the process, which is the creation of a new type of SDR that I call a Requirements Driven SDR.

A Requirements Driven SDR is a document that maps your business requirements to the specific data points in your digital analytics implementation.

These data points help you answer business requirements or questions.

By creating a direct association between requirements and data points, you can see which requirements you have data for and which you do not.

Or you may find that you have data points that don’t relate to any of your business requirements, which begs the question why you have them at all.

The cool part about this process is that website objectives map to requirements and requirements map to data points.

So in theory you can map data points directly to business objectives, which can be useful.

As we’ll see down the road.

As we talk about the the requirements driven SDR, I’d like to take a slight detour.

This detour has to do with knowing your digital analytics tool and how to use it to address business requirements.

As demonstrated, the requirements driven SDR maps business requirements to digital analytics tool data points.

Unfortunately, the process of identifying the best way to answer business question in a digital analytics tool and which data points to use is not an easy one.

It requires that you fully understand how your digital analytics tool works and all of its features.

This is an area where I see a lot of organizations struggle.

If you choose the incorrect way to answer business questions, all of the work you’ve put into improving your analytics program goes out the window.

Unfortunately, most employees at organizations have only been part of a few analytics implementations and are not tool experts.

To make it even harder, there are no established or published best practices or guidelines on how to answer any given business question.

So whether it is through training or using consultants like me, it is important that you correctly translate your business requirements into the correct solutions in your analytics tool.

Getting back on track Once your team is created this requirements driven SDR and figured out the right way to architect a solution for each in your analytics tool, the next step is to score each requirement to see where you stand today.

Can you address 90% or only 50% of the business requirements that you’ve identified in the process?

The scoring of business requirements is relatively straightforward.

Since you now know what data points relate to each business requirement, you simply look for gaps where you have requirements that have no data points.

In some cases you will have data points, but the data points being collected are not working because of bad data quality.

As part of the process, you will need to audit your implementation and see what’s working and what is not.

You should be honest with yourself when it comes to the audit and the scoring of your requirements.

I will warn you that you may find that you end up with really low scores initially.

For example, you may only be able to fully address 50% of your business requirements until you add some new data points or fix existing ones.

And that’s OK At least you now know where you stand.

Here’s an example of business requirements with scores.

These scores can be added to your brand new requirements driven SDR.

Since your requirements are prioritized, you can even filter them to see what percent of critical requirements can be answered.

Here I’m showing two different types of scores.

The 56% represents A partial score to provide a general feel for where I’m at in the implementation.

The 33% score only includes cases where requirements are 100% able to be answered.

Having these views help you see where you are in your implementation, what’s missing, and what data points need to be added or fixed to boost your overall requirements completion rate.

Now that you have your requirements list and have it scored, it’s time to do some implementation.

This may mean implementing new data points or fixing old ones.

I often see organizations spend weeks or months implementing this is because they haven’t followed the proceeding process steps and focus their efforts on what is most important to the organization.

You shouldn’t do any implementation until you’ve done this requisite pre work.

This will help you be more efficient with what is often limited tech resources at your disposal and make sure that you’re using them wisely.

Another problem affecting organizations is poor data quality.

Too few organizations devote the time and resources to data quality that they should.

The reason data quality is so important is because you are asking those in your organization to trust you and your data to make critical business decisions.

If they don’t trust your team or your data, they will go back to making decisions based on their gut like they used to in the old days.

Unfortunately, one of the reasons data quality is so often an issue is because business executives don’t tend to care about it as much as they should.

They like to give data quality lip service, but they rarely put financial resources or head count towards it.

I think this happens because the development and launch phases of projects or website redesigns are far more exciting than the data quality phases.

However, I’m going to give you a trick to get your executives to care a little bit more about data quality.

Using the requirements driven SDR that we referenced earlier, identify which business questions your team cannot answer today because of data quality issues.

Those business questions roll up into high level website objectives that your executives do care about.

Therefore, you can triangulate and show them how a low level data quality issue could impact one of their business objectives.

This technique has helped me to get the attention of those executives who have the money and resources to fix data quality issues but aren’t using them the way they should.

Finally, we are at the point of the process where we can actually do analysis.

It may feel strange to you that we are this far along and haven’t even talked about conducting analysis, but that’s because the proceeding work was done to ensure that the analysis we eventually will do is correct and important to the organization.

When it comes time to doing analysis, I recommend approaching it like the scientific method.

Your goal is to support the website objectives, which are normally around some type of conversion.

Work with your team like a scientist, to identify hypotheses that can be used to improve the conversion and other metrics that your executives care about, and use data to test those hypotheses.

Be sure to work on initiatives that drive ROI for your team.

One analogy I like to use when it comes to analysis is that of a thermometer versus a thermostat.

Inexperienced analytics teams are like thermometers in that they’re simply reporting what is happening, but superior teams are like thermostats and that they can find new and inventive ways to testing hypotheses and just good old fashioned rolling up their sleeves doing analysis to dial to change the dial and generate whatever is more conversion for your business, whether that’s orders or leads.

You definitely want to be a thermostat, not a thermometer.

When it comes to analytics, some organizations don’t do a great job of training their end users so that they can be effective consumers of the data.

Unfortunately, your team can only be in so many places at once, so it’s important to make sure that your users know how to use the data that you’re collecting and they may not know your implementation or tools like your team does, so things that may seem easy to you can be difficult for them.

To mitigate this, I suggest you go back to your trusty requirements driven SDR and train them on business requirements instead of tools or data points.

I often hold office hours or create short training videos by business requirement so that they can learn in context.

For example, once I wanted to teach a client how to build a sequential segment in Adobe Analytics.

To do this, I showed them how to answer one of their burning questions.

How often are visitors conducting chats and then right away doing right after doing on site searches?

Basically to see how often they’re on site searches aren’t asked answering questions and people are resorting to chat, which cost them a lot more money.

They were so excited to get the answer to this question that they didn’t even realize that all along they were learning how to do segmentation in Adobe Analytics.

You can also choose to make different analytics data sets such as advanced or beginner ones and provide access to users based on their skill level.

This is a way to ease people into your implementation and not overwhelm them at 1st.

And in some cases I even force clients to pass an exam on their implementation before they get access to data.

If you don’t do this, then sometimes you have people out there who are like walking around with a loaded gun but not knowing how to shoot.

Another part of the process that is often forgotten is the notion of executive support.

You need to have people at your organization who have your back and will be able to help you get the resources you need to be successful.

Part of getting executive support comes naturally if you follow the preceding process steps.

If you’re doing a good job and generating ROI for your organization, they’ll probably love you.

But it’s important to go out of your way to make sure that your leadership knows what your team does, how it adds value, and how it is helping the organization.

You or someone on your team needs to be a cheerleader for analytics within the organization.

If there’s data that your leadership cares about, find a way to build business requirements around that so that you can bake that into your implementation.

And be sure that your executives understand the high level trends that your team is seeing so they can always drive action where needed.

As we wrap things up, I hope that you can see how the preceding process steps can help mitigate the common struggles that organizations typically encounter.

You may be thinking that no one would be able to go through all these steps at an organization.

However, I have seen this over and over be successful for company after company.

So if we look at these particular process steps that we went through, you’ll see that there’s a lot here.

It’s about 10 steps we went through.

Believe it or not, there actually are a lot more, but these are the most important ones.

Many of these steps build upon each other.

So I recommend going in this order that I shared today.

And I’ll admit this process is pretty detailed.

It’s pretty methodical and can take some time, but believe it or not.

I have had super sceptical organizations go through this process multiple times and once it works, it’s an amazing thing to see as I shepherd them through the process.

My kind of favorite time is when afterwards they come to me and say I don’t know how we did this before the old the old way because this just makes so much more sense.

It’s also important to keep in mind that many of the preceding steps will will require a lot of work initially, but once you’re doing things the right way, keeping it updated is actually not that much work.

It’s simply involves periodically adding new requirements, architecting a few new solutions in your tool, doing a little bit of extra implementation, and then QA.

If you follow this approach, I assure you that it’ll help increase your chances of being successful in digital analytics.

If you want more information on this process, I’ve written an entire blog series that has much more detail about each of the steps.

You can use the QR code shown here to get right to the beginning of the blog series.

Thank you so much for attending this session.

I hope you found it helpful.

If you have any questions, feel free to use the QR code here to connect with me on LinkedIn, or you can contact me directly using the contact information shown here.

I’ll also be answering questions today on Measure Slack if you want to ping me there.

Again, thank you so much for attending.

About Digital Analytics Association Content

The DAA, a membership organization dedicated to fostering community, advocacy, and professional development for data analytics teams, ceased operations in May of 2024. Much of the evergreen content the organization created and curated will live on thanks to the Content Marketing Institute. Note: As the DAA content ages, links may break and presenters' titles may change, but the concepts remain sound.

Browse the DAA content archive.
See the latest analytics content from CMI.
Learn about the 2024 Marketing Analytics & Data Science conference.
Join the Digital Analytics Society group on LinkedIn.