Article

What makes a good data analytics question?

Why is it so complicated to get it right? What makes a good data question?

Picture of author and link to their profile
Thibaut Collette

May 6, 2020・4 min read

Words on whiteboard

Let's take some time to share insights about the data analytics question itself. Why is it so hard to get it right? And actually, what makes a good data question?

Why is it so hard to ask a good data analytics question?

First of all, a non-technical user can ask data analysts help about a specific dashboard/KPI, or a product research or an operational issue being investigated. This list is actually never ending. The scope of expected answers from one data question to another can vary drastically. Most of the time, to make things worse, answers are not unique (answers contain their own bias — more on our other article, Counter the most common biases with data).

Data literacy [1], described as the ability to read, work with, analyze, and argue with data, is often a limiting factor for data usage in companies. Business users are not the ones to blame. Data tools usually are. From the beginning, they’ve preferred to focus on the engineering side and rarely provided specific UX to help both data novices and experts simultaneously.

Finally, interactions around data are a new kind of human communication, and as such they suffer from most of the common human communication issues: hidden/unspoken facts, unadvertised assumptions or distinct knowledge framework (between requesters and analysts).

What makes a good data question?

A good data question will limit as much as possible the biases created by miscommunication.

When knowledge frameworks differ too much, because of background or experience, it’s important to say the extra words in order to limit the potentially wrong assumptions made by the counterpart.

Concretely, it means that a description must support the question itself.

From our experience, 4 main elements should appear in this description.

Context

The context is the why the question is asked. What was the process that required this question to be answered? With this context, analysts can make sure they frame the problem as expected. Also, it will allow them to leverage their history and provide a more relevant and complete answer.

Examples: “We want to assess our current Spain launch. We specifically would like to compare it with the launch in Italy last year.” / “Customer Support seems to receive a growing number of issues for our “Website” category. Can we get a quick assessment of the actual impact and if possible the reason of this change?” / “According to the last analysis, fraud on our API cost us 2M€ last year. What can be done data-side to minimize this loss?”

Potential outcomes

Alongside context, potential outcomes bring critical information to data analysts. How will this data be used? What decision can derive from the results? With those outcomes in mind data analysts can understand what is at stake and the criticality of the decision. Based on their experience, they can then wander in the data and provide the additional input that will help make an even better informed decision.

Examples: “This piece of data should finalize our investor deck” / “Goal is to make a decision about the new warehouse. Should we open it or not?” / “Based on the results, we will keep or remove the button on the product detail page”

Recipients

For a given context, the results of an analysis can be shared with audiences from different sizes or seniority: C-level, Finance or Marketing or Product teams, a single Team member, partners or 3rd-parties…
The same answer will be understood differently by people from different horizons. Once again, human communication at its finest. Listing the recipients of an analysis allows the analysts to put themselves in their readers’ shoes, and hence adapt their deliverables and messages (in terms of technical details, vocabulary, conclusions, etc.).

Examples: “This will be shared within the Finance team” / “We plan to communicate this information to our whole user base”

Deliverables

When someone comes and asks for a “simple extract”, it feels easy to specify file format. But no matter the type of analysis, requesters will always benefit from spelling out the expected deliverable. Those details also help analysts plan and allocate resources accordingly.

Examples: “Can we get the plain figure” / “I believe we can work together on a complete report” / “I would need this chart to include it in the sales deck”

This to say, context is king.

When asking a data question, requester has to make sure the context is crystal clear. Data analysts should continue to ask follow-up questions, refining context, recipients, deliverables and outcomes. But the earlier those appear clear in the conversation the higher the chances to make every one happy, productive and to reduce biases.

How do I make it happen in my company?

Simple steps can help you start in the right direction:

  1. Publish a simple and yet already useful data request form either as a Google Form, a Typeform or a Slack webhook.
  2. Share internally a few case studies of previously done analysis. This can take between half a day and 3 days to complete but can get you off on the right foot and help Business Users know more about your teams’ work. (Important: include analysis from various complexity)
Husprey Logo

Learn more about Husprey

Husprey is a powerful, yet simple, platform that provides tools for Data Analysts to create SQL notebooks effortlessly, collaborate with their team and share their analyses with anyone.