How to Succeed with Self-Service Analytics, Part II: Know Thy Customer

How to Succeed with Self-Service Analytics, Part II: Know Thy Customer

Read - How to Succeed with Self-Service Analytics, Part I: Pitfalls and Paradoxes

Although self-service analytics sounds like a win-win proposition, most projects go awry due to unexpected complexities, paradoxes, and misconceptions. That is what we learned in part one of this series. This article explores a fundamental tenet of self-service analytics: know thy customer. 

Most companies think that the essence of self-service analytics is a tool. That’s because software vendors do a great job of equating self-service with their products. Although tools can empower business users, they don’t produce positive results if they aren’t tailored to each individual, their role, behavior, and preferences. 

The dirty little secret of self-service analytics is that one size doesn’t fit all.

The dirty little secret of self-service analytics is that one size doesn’t fit all. There are as many types of self-service as there are individuals in an organization. An old-school executive who reads printouts of Excel reports might think self-service is viewing an online dashboard; a business manager might think it’s the ability to modify a report or dashboard with a point-and-click interface; a data analyst thinks it’s the ability to create data sets and dashboards without IT assistance. 

Classification. To succeed with self-service analytics, it’s imperative to create an inventory of business users and classify them into groups. This classification scheme becomes the basis for how you configure data sets, analytical tools, and data access permissions. It also informs how you organize your data analytics team and design your data architecture. Knowing and classifying your users is a critical first step toward self-service success.

Where to Start?  

When we work with consulting clients, we request three things: a current schematic of the data architecture, an organization chart that identifies data analysts and their managers in each division and department; and a user classification scheme. If lucky, we might get a printout of current data architecture, and sometimes we get a data analytics org chart, but we never get a user classification scheme. 

How can you serve people if you don’t know who they are or don’t even know if they exist?

How can you serve people if you don’t know who they are or don’t even know if they exist? With consulting clients, I’ve spent an entire day at a whiteboard mapping out who produces data artifacts in every department of an organization. We usually never finish. My underlying message is: “Get out there and meet these people--they are your customers!” Moreover, these data producers also happen to your most endearing advocates or zealous critics—they can either make or break your data analytics program. 

Classifying Users. As a shortcut, Eckerson Group offers a classification scheme that has proven to reflect user demographics at most organizations. It divides users into two categories based on whether they consume or produce information: casual users and power users. It divides each camp into two categories: casual users consist of “data consumers” and “data explorers” while power users consist of “data analysts” and “data scientists”. (See figure 1.) 

Figure 1. Eckerson Group’s User Classification Scheme 

Casual Users. Data Consumers are casual users who consume reports and dashboards as is without modification. They generally represent about 60% of all data users. Data Explorers, on the other hand, are casual users who occasionally want to modify reports or dashboards to create a new view of existing data. Data Explorers represent about 30% of all data users. 

Casual users don’t want self-service in the true sense of the phrase: the ability to create data sets and reports from scratch without IT assistance. Their job is not to do lots of analysis or create reports and dashboards; their job is to make decisions. As such, what casual users really want is “silver service”—the ability to consume content that is highly tailored and pre-digested to meet their decision-making needs. That means either the corporate data analyst team or a local data analyst needs to create a custom data set (i.e., data mart), a business model, and a report geared to the casual users in the department. 

Power Users. Unlike casual users, power users desperately desire self-service. For decades, they have had to beg, borrow, and steal data from the IT department and use Excel and Access to manipulate the data crumbs they assemble. Due to lack of true self-service, they can spend upwards of 80% of their time finding, cleaning, and integrating data rather than analyzing it. Self-service reporting, analysis, data integration, and analytics tools are a huge boon to the power user community.

Because of their voracious appetite for data, power users exert an outsized influence on corporate data strategies.

Because of their voracious appetite for data, power users exert an outsized influence on corporate data strategies even though they only represent 10% of data users in an organization. The majority of those are Data Analysts who create budgets, conduct pricing analysis, design incentive metrics, evaluate campaigns, and generally exist to answer any ad hoc question from a business leader. Their counterparts are Data Scientists who combine strong data skills with statistics and computer programming who create powerful descriptive and predictive models from large volumes of historical data. As experts in artificial intelligence, they are currently in high demand even though they only comprise about 2% of data users today. 

The Dilemma of Data Explorers

In my opinion, Data Explorers are the hardest group of business users to support. That’s because although 80% of the time, they consume reports and dashboards as is, like Data Consumers, the other 20% of the time, they want to act like power users and do ad hoc analysis and query generation. The challenge is that most Data Explorers don’t have power user skills or can’t remember how to use advanced features of a self-service tool. Fortunately, new AI-infused BI tools are tailor-made for Data Explorers: they let users submit queries using keywords and natural language instead of using SQL or query generation tools. They also automatically surface insights from algorithms that run against queried data in the background.

Over time, we expect the percentage of Data Explorers to increase significantly as more computer- and data-literate individuals enter the workforce and companies become more data-driven. We expect more casual users will dive into data to explore root causes and remediation strategies. As AI becomes the new BI (see our report by the same name), Data Explorers won’t have to work as hard to create ad hoc views of data. 

Applying User Classifications

With a user classification scheme in hand, data analytics leaders can more easily select analytical tools, define permissions, create data architecture, establish training and support services, and establish a business engagement strategy. 

Tools. Eckerson Group often uses the matrix in figure 2 to help data leaders evaluate their data and analytics tools portfolio. A decade or more ago, a company might need to purchase a different product from a different vendor for each type of user. Today, it’s possible to purchase a data analytics platform from a single vendor to support most, if not all, user requirements. Whether that’s a wise decision is another matter. 

Figure 2. Tools Portfolio By User Type 

Permissions. It’s critical to purchase tools with granular permissions. Because tools today supply a broad range of functionality and provide access to large and diverse sets of data, it’s important to configure a tool environment so it’s tailored to user needs by role and individual, if necessary. For casual users, it’s important to “dumb down” the tool so certain classes of users are not overwhelmed by features and functions they don’t need. That’s a recipe for undermining user adoption.

Permissions are especially important to avoid the proliferation of conflicting reports and dashboards. By default, permissions should prevent business users from publishing reports and dashboards to others. They only gain authorization to publish reports to colleagues or other groups when they pass a certification test and or demonstrate their mastery of data analytics concepts and techniques and show they understand internal policies and standards governing the publication of data. 

Data Architecture. Permissions also extend to the data architecture. Each class of business user gains access to a different layer of the data architecture.  The conceptual data architecture in figure 3 shows that Data Consumers access applications (i.e., reports, dashboards, and custom applications), while Data Explorers access those applications 80% of the time plus a domain-specific business model of data (i.e., semantic layer) 20% of the time. They use the semantic layer to modify or extend existing applications. 

Figure 3. Mapping User Types to Data Architecture 

Similarly, Data Analysts most often (80% of the time) access a business view, but occasionally (20% of the time) pull data from also subject-oriented tables in a data hub (i.e. data lake, data warehouse, data fabric). Data Analysts use the flattened subject-oriented data to craft custom data sets for analysis purposes. To create data pipelines and analytic models, Data Scientists will query a data hub most of the time (80%), but when necessary, they will extract raw data from a staging area. Both Data Analysts and Data Scientists use a triumvirate of self-service analytic tools: a data catalog to find data, a data prep tool to combine data, and a visualization tool to analyze and share data. 

Other Considerations. A user classification scheme is also critical for creating suitable training and support programs that foster adoption, not confusion. A scheme is also critical for creating a data analytics center of excellence. Power users are the “eyes and ears” of a corporate data analytics team in the business units. Their managers generally form the Working Committee of a Data Analytics Council and they run the Community of Practice that gathers power users from across the organization for regular meetups and other activities.


Data leaders who launch self-service analytics programs without knowing their business users risk unleashing chaos. Data leaders need to canvas the organization and understand who produces what information for whom and where. They then need to classify business users based on their information needs. Finally, they need to use that scheme to drive tooling, architecture, governance, training, support, and organizational decisions. The next article in this series will show how to ensure self-service doesn't create a panoply of conflicting reports.

Read - How to Succeed With Self-Service Analytics, Part III: Trust But Verify New Reports

Wayne Eckerson

Wayne Eckerson is an internationally recognized thought leader in the business intelligence and analytics field. He is a sought-after consultant and noted speaker who thinks critically, writes clearly and presents...

More About Wayne Eckerson