Imagine you hit a roadblock while trying to tackle a complex piece of analysis, using a python function or designing your first data organization. What do you do? Of course you start with an internet search, but what do you do when you’re really stuck? I like to phone a friend. In this post I explore my favorite learning style – learning from others – and the steps to building your own analytics brain trust. I have used this approach to solve many challenges (including building an Analytics team from the ground up) and I believe it can be almost universally applied.
A data warehouse Service Level Agreement (SLA) is an important building block for a data-driven organization. To help get you started, in part one I introduced a data warehouse SLA template - a letter addressed to your stakeholders. In this post I walk through the meat of the SLA template: services provided, expected performance, problem reporting, response time, monitoring processes, issue communication and stakeholder commitment. If you have not already read part one, I highly recommend reading it first!
Yes, if you want to build a truly data-driven organization your data warehouse needs a Service Level Agreement (SLA). At the core of any data driven organization is trust - your stakeholders must trust that when they need data, it will be there and it will be accurate. Without trust in the data warehouse, your organization will be less likely to use data to drive decisions big and small. In my previous post Reporting is a Gateway Drug I explored reporting as a tool to build a trusting stakeholder relationship. In this post I explore trust through the concept of a data warehouse SLA. In part two I explore the people, process and tools you need to successfully implement the SLA.
Data warehouses are not just for business intelligence (BI) anymore. You can maximize the value of your data engineering, data science, and analytics work by investing in building out a multi-use data-platform that serves business users, Analysts, Statisticians, and intelligent applications. In my last post, data-dies-in-darkness, I described how you can improve your organization’s data quality by exposing more data to more people. You can stretch this idea even farther by expanding the stakeholders of your data warehouse to include intelligent applications.
I love doing reporting. Well I don’t actually love doing reporting, but I love what it can do for an Analytics team. If executed well, reporting can be the gateway drug, resulting in an organization that is completely addicted to its Analytics team. If executed poorly, the Analytics team can turn into a team of reporting monkeys - we all know what that is like. Here is some advice on how to use reporting as a means to create strong stakeholder relationships in your organization.
The fastest way to doom an Analytics team (and any hope of building a data-driven organization) is to present data and analyses that are often flawed or inconsistent. When people don’t believe they can trust the data, they will stop using them (and, if you are an analytics leader, you might be soon looking for a new job).
Attribution is a tough challenge that is top of mind for every Marketing and Analytics leader. While marketing strategies and technologies may have evolved, the most important question has not changed - Is our marketing working? The right attribution solution should help you answer that question. But how do you find the right solution? Unfortunately, there is no turnkey attribution solution that perfectly solves all of your measurement challenges. Each business has unique attribution challenges and there are a seemingly infinite number of vendors and methodologies. As a result, I created a framework to navigate the increasingly complex multi-touch attribution market, understand the trade offs between solutions and identify the optimal attribution solution.
People often ask for advice about building out an analytics organization – How to structure the team? What skills to hire for? Do we need engineers? What about data scientists? How big should the team be? Unfortunately, there is no easy answer to these questions, because the best analytics team is the one that best supports the organization and its specific needs. To make things even more complicated, A) different organizations have very different needs and B) your organization’s needs today will be very different from its needs in the future. In this post I will discuss some of the different dimensions that are import to evaluate when thinking about how to structure an Analytics team.