Welcome back to Data Quality Foundations! This is lesson two of four, and today we tackle a deceptively simple idea that trips up even experienced analysts: before judging the quality of any dataset, we need to know what question we are trying to answer. In the previous lesson, we established that data only needs to be good enough for its intended purpose. Now we will put that principle to work by learning how to match data to a specific business question, and how to spot the gaps that could lead us astray.
It is tempting to start a project by diving straight into whatever data happens to be available. But working with a dataset simply because it exists is a bit like grabbing random tools from a toolbox before knowing what needs fixing. We might get lucky, but more often we waste time or reach the wrong conclusion.
A better approach is to start with the business question. Once the question is clear, we can work backward to figure out what data we actually need. This simple shift in thinking helps us avoid analyzing the wrong information and makes the entire quality evaluation much more focused.
Not every dataset is a good fit for every question. Consider a company that wants to know: "Which marketing channel brought in the most new customers last quarter?" To answer that, we need data that links each new customer to the channel that acquired them, along with dates that fall within last quarter. A dataset containing only product inventory counts, no matter how clean and complete, simply cannot answer that question.
The table below shows a few business questions alongside the type of dataset that would be most useful:
| Business Question | Most Relevant Dataset |
|---|---|
| Which product had the highest return rate this year? | Order and returns records with product IDs and dates |
| What is our average customer support response time? | Support ticket logs with timestamps |
| Are employees in Region A more likely to leave? | HR records with region, tenure, and exit status |
The takeaway is straightforward: relevance is the first quality check. A dataset can be accurate, complete, and up to date, yet still be the wrong dataset for the question at hand.
Once we have a dataset that seems like a reasonable match, the next step is to check whether it contains the specific fields (columns) needed to answer the question. Think of each field as one piece of evidence. If a critical piece is missing, our answer may be unreliable or impossible to reach.
Let's say our business question is: "Do customers who use our mobile app spend more per order than those who don't?" To answer this, we would need at least these fields:
- Customer ID — to identify individual customers
- Order amount — to measure spending per order
- Channel or platform — to distinguish mobile app users from others
If the dataset tracks orders but does not record which platform was used, we simply cannot split customers into the two groups the question asks about. Recognizing this before starting the analysis saves us from drawing shaky conclusions later.
Most real-world datasets contain many more fields than any single question requires. Having extra fields is not a problem in itself, but it can become a distraction. When we sit down with a dataset, it helps to quickly sort the available fields into two buckets: relevant to this question and not relevant to this question.
For example, if our question is "What is the average delivery time by region?", a shipping dataset might contain these fields:
| Field | Relevant? |
|---|---|
| Order date | ✓ Yes |
| Delivery date | ✓ Yes |
| Customer region | ✓ Yes |
| Customer email | ✗ No |
| Product color | ✗ No |
| Shipping carrier | Maybe |
Notice that Shipping carrier lands in a gray area. It is not strictly required, but it could add useful context. That is perfectly normal. The goal of this sorting exercise is not to be rigid but to build the habit of thinking about relevance before diving into analysis. Fields that clearly do not relate to the question can be set aside, keeping our work focused and our conclusions stronger.
In this lesson, we learned that evaluating data quality starts well before any analysis takes place. The first and most important step is to clearly state the business question and then check whether the available data is actually relevant to it. We practiced thinking at two levels: choosing the right dataset for a question, and verifying that the necessary fields exist within that dataset using a quick field coverage check.
Now it is time to put these ideas into action! In the upcoming exercises, you will match business questions to the datasets best suited to answer them, identify missing fields that could undermine an analysis, and sort fields by relevance for a given scenario. Let's sharpen that relevance instinct!
