Data quality: is the data fit for the question? · B01

Before you start

You will be able to

Define the six dimensions of data quality (accuracy, completeness, consistency, validity, timeliness and uniqueness) and give a business consequence of a failure in each.
Explain how duplicates, missing values, invalid values, inconsistent codes and time zones distort a metric, and calculate the size of the distortion in simple cases.
Assess whether a dataset is fit for a stated purpose, and say what would make it fit.
Identify who produces, owns and uses data in a business, and where in the data lifecycle quality problems enter.
Identify the quality problems in a raw export by dimension, without changing it.

Review first

Types of data — You need the unit of observation, identifiers and the levels of measurement, which decide what counts as a valid value.
Collecting data: sources, samples and bias — Measurement bias and non-response are quality problems that start when data is collected.

Fictional case A fictional coffee business founded by Ana Lim. It starts as a catering and barista-training service, opens its own cafés and an online shop for beans, and plans a canned cold brew.

The idea

Fictional case

On the morning of 1 December Ana opens three reports on November and finds three different numbers. The shop’s dashboard shows 435 orders. The order export she downloaded at 10:00, after the app’s overnight sync, has 448 rows, one per order, or so it claims. The payment provider’s monthly report lists 431 card payments. Before she can review the month, she has to decide which number to believe, and why the others differ.

No dataset is perfect, and none needs to be. The useful question is the one the UK government’s Data Quality Framework puts at the centre of its definition of quality: is this data good enough for what I want to use it for? The Framework calls this fitness for purpose. The same file can be good enough for one decision and useless for another, so quality is always judged against a use.

This lesson gives you the vocabulary for describing what is wrong with data, shows how each kind of problem moves the numbers a business watches, and ends with a first look at a raw export. Repairing the problems is the subject of B02 Data Cleaning and Preparation.

Six dimensions of data quality

A data quality dimension is one aspect of quality that can be assessed on its own. Practitioners commonly use six, from a 2013 paper by DAMA UK, the UK chapter of the Data Management Association; the UK government’s Framework adopts the same six. Each asks a different question of the data, and a failure in each has its own business cost.

The six dimensions, with Lantern examples (fictional)
Dimension	The question it asks	Lantern example	What it costs the business
Accuracy	Does the value match reality?	A customer ordered 4 packs; the export says 40	Sales overstated; too much coffee roasted
Completeness	Is every required value present?	Orders with no e-mail address, although e-mail is required	Receipts and delivery updates can’t be sent; orders can’t be linked to customers
Consistency	Is the same thing recorded the same way everywhere?	One region written North, north and Nth	Regional totals split three ways; reports that contradict each other
Validity	Are values in the expected format, type and range?	A rating of 9 on a 1–5 scale; a quantity of −1	Averages pulled off; calculations fail or mislead
Timeliness	Does the data reflect the period it describes, in time for the decision?	A report run before the previous night’s app orders arrive	Decisions made on a month that is still incomplete
Uniqueness	Is each real thing recorded only once?	The same order exported twice	Orders and revenue overstated

The dimensions overlap, and one problem often touches several. Two rows for the same order break uniqueness; if the two rows give the order different quantities, they break consistency too, and at most one of them is accurate. Naming the dimension is not an end in itself. It tells you what to check, which numbers are at risk and, later, which repair applies.

Where quality problems come from

Data passes through stages, from being planned and collected to being used, shared and finally archived or deleted. The UK Framework calls this the data lifecycle and asks organisations to assess quality throughout it, not only at the end. Problems can enter at every stage, and they are cheapest to stop where they enter.

Quality problems can enter at every stage of the data lifecycle. The stages are those of the UK Government Data Quality Framework; the examples are Lantern’s (fictional).

In depth

How quality problems move a metric

A business rarely cares about a single wrong cell. It cares about the numbers built from the cells: orders, revenue, average order value, the average rating, a region’s share of sales. Each kind of problem distorts those numbers in a characteristic way, and knowing the pattern tells you which figures to distrust.

Duplicates inflate counts and totals. A duplicate record describes the same order as another row, so every count and sum that includes both is too high. If November’s export holds 448 rows for 435 real orders, a count of rows overstates orders by $(448 - 435) \div 435 \approx 3.0\%$ , and revenue by a similar amount. Averages are subtler: duplicates move an average only when the duplicated rows are unlike the rest. If a sync fault tends to repeat large orders, the average order value rises too.

Missing values bias averages when what is missing differs from what is present. A missing value leaves a gap, and the gap matters less for how big it is than for which values fall into it. If ratings were missing completely at random (whether a rating is missing has nothing to do with the customer or the order), the average of the ratings that exist would be a fair estimate of all customers’ ratings, only less precise. Lantern’s ratings are optional, and subscribers rate far more of their orders than one-off buyers, who tend to be less satisfied; the average of the ratings given then describes subscribers more than customers. The challenging example below puts a size on it, and B02’s lesson on missing values shows how to test and handle it.

Invalid values pull totals and averages. A rating of 9 typed for a 4 raises the total of the ratings by 5, so among 50 ratings it lifts the mean by $5 \div 50 = 0.10$ stars: enough to turn a fall into an apparent rise. A quantity of −1 recorded for a returned pack reduces the month’s pack count, and a placeholder price of 0 drags down the average price.

Inconsistent codes split groups. If the North region appears as North in 120 orders, north in 15 and Nth in 8, a report grouped by region shows North with 120 orders instead of $120 + 15 + 8 = 143$ , and two extra “regions” with a handful each. North looks $23 \div 143 \approx 16\%$ smaller than it is, and anyone ranking regions may rank them wrongly.

Time zones move orders between days and months. Lantern’s platform stores every order time in UTC; suppose, as in the worked examples, that Lantern’s local time is five hours behind it. An order placed at 21:30 local time on 30 November is stored as 02:30 UTC on 1 December. Nothing about it is inaccurate, but a report that groups orders by the UTC date files every order placed after 19:00 local time under the next day, and on the last evening of a month, under the next month. Daily patterns shift, and month totals gain the previous month’s last evening while losing their own.

Late data understates the latest period. Had Ana pulled November’s figures at 07:30 on 1 December, before the app sent its overnight orders at 09:00, the last night of November would have been missing from every number in the report. This is a timeliness failure, and it always bites the most recent period, which is usually the one a decision is about.

Fitness for purpose

Because each problem distorts particular numbers, the same data can be fit for one purpose and not for another. Judge fitness by asking which dimensions the decision depends on and how large an error it can tolerate.

Is Lantern’s order export fit for the purpose? (fictional)
Purpose	Dimensions that matter most	Fit as it stands?
Monthly revenue for Ana’s review	Uniqueness; validity of amounts; orders assigned to the right month	Not yet: it will be once duplicates are removed and dates are taken in local time
E-mailing every November customer about a product recall	Completeness and accuracy of e-mail addresses	No: customers with missing or mistyped addresses would not be told
Average satisfaction of all customers	Completeness of ratings, and whether the missing ones differ	Only with care: ratings are optional and given mostly by subscribers
Planning tomorrow’s packing staff	Timeliness; dates in local time	Only if the data arrives by morning and days are counted in local time

Tolerance matters as much as the dimension. For Ana’s monthly review, revenue within 1–2% is good enough; for the tax return, the figure must be exact. For a product recall, a single missing e-mail address is a customer who isn’t warned. State the purpose and the tolerance before judging the data, otherwise every dataset either looks fine or looks hopeless.

Measuring quality

Each dimension can be turned into a number, which makes quality something you can track. Completeness is the share of required values that are present; uniqueness is the number of distinct keys divided by the number of rows; validity is the share of values that pass their rules.

Two cautions. Measure completeness only against values that are required: Lantern’s rating is optional, so a blank rating is not a defect, while a blank e-mail address is. And keep accuracy apart: it can only be measured by checking a sample of records against their source, for example 50 orders against the payment records. B02’s lesson on profiling and validation turns these measures into a full set of rules.

Who is responsible for quality

Quality problems are created by people and systems, so responsibility has to be assigned to people. Three roles appear in most organisations, under various titles. Data producers are the people and systems that create the records: the checkout form, the staff who type in catering orders, the app’s sync with the platform. The data owner is the person accountable for a dataset: for deciding what it should contain and what its definitions are, who may use it, and how its quality problems are resolved.

Data users, such as analysts and managers, judge whether the data is fit for their purpose, report the problems they find and state the limitations in what they publish. Larger organisations add specialists, often called data stewards, who look after definitions and quality day to day. The UK Framework speaks of data leaders, data practitioners, data owners and users; the titles vary, but someone must be accountable for each dataset.

At Lantern, Ana owns the shop’s data, the shop platform and the app are its main producers, and Ana and Lantern’s analyst, Jun Park, are its users. The roles matter because problems are cheapest to fix where they enter. A checkout form that refuses an order without an e-mail address prevents every future gap; an analyst who looks up missing addresses by hand fixes one month and must do it again the next. The UK Framework’s principles point the same way: commit to data quality, know your users and their needs, assess quality throughout the lifecycle, communicate quality clearly, and anticipate changes that will affect it.

Looking before fixing

The first step with any new dataset is to look at it without changing anything. The explorer below opens the raw export of Lantern’s orders for March to June 2026, the file that B02 cleans, in inspect-only mode: you can sort columns and read the summaries, but not alter a value, and it lists the issues it detects. For each issue, name its dimension, the figure it would distort and the question you would ask Ana; then say what the file alone can’t show, such as whether a value is accurate or whether the export was complete for its period.

Resist the urge to correct anything. Some odd values are genuine (a café can order a lot of coffee at once), some are errors, and deciding which needs evidence. That is the work of B02.

Formulas

Completeness of a required field

\text{Completeness} = \dfrac{\text{Values present}}{\text{Values required}} \times 100\%

$\text{Values present}$: Non-blank values on the rows that require onecount
$\text{Values required}$: Rows on which a value is requiredcount

Assumes. Only required values count. For an optional field, such as a rating, report the share filled in and don’t call the blanks defects.

Overstatement caused by duplicates

\text{Overstatement} = \dfrac{\text{Rows counted} - \text{True records}}{\text{True records}} \times 100\%

$\text{Rows counted}$: Rows in the file, duplicates includedrows
$\text{True records}$: Distinct real-world things (orders, bookings) the rows describecount

Assumes. Applies to counts. A total is overstated by the value of the duplicated rows divided by the true total.

Divide by the true number, not by the inflated count.

Effect of one wrong value on a mean

\text{Shift in the mean} = \dfrac{x_{\text{wrong}} - x_{\text{right}}}{n}

$x_{\text{wrong}}$: The value recordedunits of the variable
$x_{\text{right}}$: The value that should have been recordedunits of the variable
$n$: Number of values in the meancount

Assumes. The number of values stays the same: the wrong value is corrected, not removed.

The smaller the dataset, the further one error moves the mean.

Worked examples

A first example: Two repeated rows in a day of orders

Fictional figures

The export for Wednesday 18 November 2026 lists the eight rows below, one per order or so it claims. How many orders were there really, and how far off are the day’s order count, revenue and average order value if you take the rows as they are?

Lantern’s order export for 18 November 2026, first eight rows (fictional)
Row	order_id	Time	Channel	order_total ($)
0	LC-11630	09:12	web	28.00
1	LC-11631	09:40	app	41.50
2	LC-11632	10:05	web	55.30
3	LC-11631	09:40	app	41.50
4	LC-11633	11:20	web	19.50
5	LC-11634	12:02	app	58.00
6	LC-11635	12:45	app	33.00
7	LC-11634	12:02	app	58.00

Test the key. There are 8 rows but only 6 distinct order_ids. Row 3 repeats row 1 and row 7 repeats row 5 exactly: two duplicate records, a uniqueness failure.
Count. The rows say 8 orders; there were 6. The count is overstated by $(8 - 6) \div 6 \approx 33.3\%$ .
Revenue. The rows add to $28.00 + 41.50 + 55.30 + 41.50 + 19.50 + 58.00 + 33.00 + 58.00 = 334.80$ dollars; without the two repeats, $334.80 - 41.50 - 58.00 = 235.30$ . Revenue is overstated by $99.50 \div 235.30 \approx 42.3\%$ .
Average order value. From the rows, $334.80 \div 8 = 41.85$ dollars; in truth, $235.30 \div 6 \approx 39.22$ . The average moved too, because the two repeated orders ($41.50 and $58.00) were larger than the day’s typical order.

Answer. Six orders, not eight. Taken as they stand, the rows overstate the count by about 33.3%, revenue by about 42.3% ($334.80 against $235.30) and average order value by $2.63 ($41.85 against $39.22).

What it means. Duplicates always inflate counts and totals; they move an average only when the repeated rows are unlike the rest. A real export is far longer, so the percentages are usually smaller, but the pattern is the same, and a key test (distinct order_ids against rows) finds it in seconds.

A harder example: Whose satisfaction does the average rating measure?

Fictional figures

An extract of 200 Lantern orders contains 60 subscription orders and 140 one-off orders. Rating is optional. Customers rated 48 of the subscription orders, with an average of 4.6 stars, and 28 of the one-off orders, with an average of 3.5 stars. The draft report says “average rating 4.19 stars”. Is the rating data fit for the claim “our customers rate us 4.2”? What should the report say?

Measure the gap. $48 + 28 = 76$ of the 200 orders were rated, $76 \div 200 = 38\%$ . Ratings are optional, so this is not a completeness defect; the question is whether the rated orders represent the rest.
Compare who is in the data with who is in the population. Subscription orders are $60 \div 200 = 30\%$ of orders but supply $48 \div 76 \approx 63.2\%$ of the ratings: subscribers rated 80% of their orders ( $48 \div 60$ ), one-off buyers 20% ( $28 \div 140$ ).
Reproduce the draft figure: $(48 \times 4.6 + 28 \times 3.5) \div 76 = (220.8 + 98.0) \div 76 = 318.8 \div 76 \approx 4.19$ stars. It is correct arithmetic, weighted heavily towards subscribers.
Estimate the all-orders figure. If, within each group, the orders that were rated are like those that weren’t, weight each group’s average by its share of orders: $0.30 \times 4.6 + 0.70 \times 3.5 = 1.38 + 2.45 = 3.83$ stars, $4.19 - 3.83 = 0.36$ stars lower.
Judge fitness. The ratings are fit for “subscribers rate us 4.6” (48 ratings from 60 orders) but not, as they stand, for a single figure about all customers. The one-off average rests on only 28 ratings, and the assumption that raters represent non-raters within each group is untested.

Answer. No. The 4.19 describes mostly subscribers, who give 63% of the ratings but place 30% of the orders. Weighted by orders, the estimate is about 3.83 stars, on an assumption the report must state. Report the two groups separately, with their counts: subscribers 4.6 (48 ratings), one-off buyers 3.5 (28 ratings).

What it means. Nothing in the ratings is invalid, duplicated or inaccurate; the problem is which values are missing. That is why quality is judged against a purpose: the same ratings are fit for one claim and unfit for another.

Applied: a business decision: Which day needs an extra packer?

Fictional figures

Ana wants to add a packer on the busiest day of next weekend. Last weekend’s report, grouped by the date of each order’s UTC timestamp, shows 36 orders on Friday 27 November and 40 on Saturday 28 November, so the report says Saturday. Lantern’s local time is five hours behind UTC. The platform can also give the orders in five-hour blocks of local time, below. Which day should get the packer?

Orders by local time, 26–28 November 2026 (fictional)
Local time	Orders
Thursday 26 November, 19:00–24:00	6
Friday 27 November, 00:00–19:00	30
Friday 27 November, 19:00–24:00	18
Saturday 28 November, 00:00–19:00	22
Saturday 28 November, 19:00–24:00	5

Work out what the UTC report counted. Five hours behind UTC means local 19:00–24:00 is 00:00–05:00 UTC on the next day. So the report’s “Friday” is Thursday evening plus Friday up to 19:00 local, and its “Saturday” is Friday evening plus Saturday up to 19:00.
Check the report’s figures: Friday (UTC) $= 6 + 30 = 36$ ; Saturday (UTC) $= 18 + 22 = 40$ . Both match, so the two views count the same orders; only the definition of a day differs.
Count by local day, the day the packers work: Friday $= 30 + 18 = 48$ orders; Saturday $= 22 + 5 = 27$ .
Compare. In local time Friday is the busiest day by $48 - 27 = 21$ orders; the UTC report reversed the ranking because Friday evening, the weekend’s busiest hours (18 orders in five hours), was filed under Saturday.
Fix the report, not the data: group orders by local date for any decision about staff, opening hours or daily targets, and say in the report which time zone defines a day.

Answer. Friday. By local day Friday had 48 orders and Saturday 27; the UTC report’s 36 and 40 put Friday evening’s 18 orders under Saturday.

What it means. Every timestamp was accurate, yet the report would have put the packer on the wrong day. Quality includes fitness of definitions: a “day” defined in UTC suits a system log, while a staffing decision needs the business’s own local day.

Explore

Common mistakes

“The file is clean, so the numbers are right.”
A file can pass every rule and still hold wrong values: valid isn’t accurate. And a perfectly accurate file can still mislead if its definitions don’t match the question, such as days counted in UTC for a staffing decision. Check fitness for the purpose, not just the absence of obvious errors.
“A few duplicates don’t matter.”
Every duplicate adds a whole order to the count and its value to revenue, and a fault that repeats large orders also lifts the average. Test the key (distinct identifiers against rows) before counting anything; it takes seconds.
“Missing values only reduce the sample size.”
Only if they are missing completely at random. When the gaps fall more often on some kinds of customer, as optional ratings do, the values that remain describe a different group from the whole, and averages shift. Ask who is missing, not just how many.
“Every blank is a defect.”
Completeness is measured against what is required. A blank e-mail address on an order is a defect; a blank rating is allowed. Calling optional blanks defects exaggerates the problem; ignoring them when they bias an average understates it.
“Data quality is the analyst’s job.”
Analysts find problems; producers create them and owners decide how they are resolved. Problems fixed where they enter, such as a required field on a form, stay fixed. Problems cleaned downstream come back every month.
“If the systems disagree, one of them is wrong.”
Often each system counts something different: orders, rows or card payments. Before calling a difference an error, find each system’s definition; then agree which one the decision needs and how large a gap is acceptable.

Guided practice

Work through these with hints when you need them. Every hint and every worked solution is there to be used.

Loading four questions…

On your own

No hints this time. Answer, check, and read the feedback; the solution appears once you have answered or if you ask for it. Your first answers count toward mastery.

Loading six questions…

In practice

Back to Ana’s three numbers. Jun Park, Lantern’s analyst, reconciles them before the review starts. The export’s 448 rows contain 13 exact duplicates, created when the app’s sync with the platform retried after a time-out; removing them leaves 435 orders, matching the dashboard, which, like the export, counts November by Lantern’s local date.

The payment provider’s 431 is not an error at all: 4 November orders were paid with gift vouchers, which never pass through the card system. Three numbers, three definitions: rows, orders and card payments. Only one of them counts what the review needs.

Reconciling sources this way is routine wherever several systems record the same events, and the right test is rarely “are the numbers equal?”. Systems legitimately differ. Google’s own documentation for Google Analytics, for example, says that a discrepancy of 2–5% between the total event count in Analytics and the same data exported to Google’s BigQuery data warehouse is expected, and warns that comparing data stored in different time zones compares different periods. A sensible business decides in advance how large a gap it will accept between which sources, and investigates anything larger.

From then on, Jun runs the same short checklist each month before any figure reaches the review:

Reconcile order counts across the dashboard, the export and the payment report, and explain every difference by its cause.
Test the key: distinct order_ids against rows.
Assign orders to days and months by Lantern’s local time.
Wait until the overnight app sync has finished before pulling the month.
Measure the completeness of required fields, and report the share of orders rated as a separate figure, not as a defect.
Check the ranges: quantities of at least 1, ratings from 1 to 5, prices above zero.
Write a two-line quality note in the review: what was checked, what was found and what was done.

The checklist finds problems; Ana, as the data owner, removes their causes. She asks the platform’s supplier to stop the sync from repeating orders when it retries, makes e-mail a required field at checkout and checks that the dashboard and every export count days in local time. Each fix at the source removes a step from next month’s checklist.

Many hotels work the same way at the end of every day. In what they call the night audit, staff check that every occupied room has a booking and a charge, and that the day’s charges agree with the payments taken, before the date in the hotel’s system rolls over. Problems are cheapest to resolve while the guest is still in the building. The habit is the one this lesson teaches: name the purpose, check the dimensions it depends on, find the causes of differences, and fix them where they start.

Knowledge check

Six questions, one attempt each, no hints. Score 80% or more to complete the lesson; you can take it again at any time.

Loading six questions…

Summary

Data quality is fitness for purpose: whether the data is good enough for the use intended. The same data can be fit for one decision and unfit for another.
Six common dimensions: accuracy, completeness, consistency, validity, timeliness and uniqueness. Each asks a different question and has its own business cost.
Valid is not the same as accurate: rules catch the impossible; only a check against the source catches the wrong but possible.
Duplicates inflate counts and totals; missing values bias averages when the gaps fall unevenly; invalid values pull totals and means; inconsistent codes split groups; time zones move records between days; late data understates the latest period.
One wrong value shifts a mean by (wrong − right) ÷ n. Duplicates overstate a count by (rows − true records) ÷ true records.
Quality problems enter at every stage of the data lifecycle. Producers create data, owners are accountable for it, users judge fitness and report problems; fix problems where they enter.
Look before you fix: inspect a raw export, name each problem by dimension and ask the owner. B02 teaches the repairs.

Terms introduced

Fitness for purpose: Whether data is good enough for the use intended. The UK Government Data Quality Framework treats it as the definition of data quality: the same data can be fit for one purpose and unfit for another.
Data quality dimension: One aspect of data quality that can be assessed and measured on its own, such as completeness or validity.
Accuracy: Whether values correctly describe the real-world thing or event they represent.
Completeness: The proportion of values present out of those that should be present.
Consistency: Whether the same thing is represented the same way wherever it appears, within a dataset and across datasets.
Validity: Whether values conform to their definition: the right type, format and range, and a member of the allowed set.
Timeliness: Whether data represents reality at the point in time it is needed and is up to date.
Uniqueness: Whether each real-world thing is recorded only once.
Duplicate record: A row that describes the same real-world entity or event as another row in the same dataset.
Missing value: A cell where a value should exist but was not recorded, whether it appears as a blank, a code such as NA or −999, a text stand-in such as “unknown”, or an impossible value.
UTC: Coordinated Universal Time, the reference time scale against which time zones are defined by their offsets, such as −05:00.
Data lifecycle: The stages data passes through, from planning and collection through preparation, storage and use to sharing and finally archiving or deletion.
Data owner: The person accountable for a dataset: for deciding what it should contain and how it is defined, who may use it, and how its quality problems are resolved.

Sources

DAMA UK Working Group on “Data Quality Dimensions” (2013). The Six Primary Dimensions for Data Quality Assessment. White paper, October 2013.
Government Data Quality Hub (2020). The Government Data Quality Framework. GOV.UK, published 3 December 2020. gov.uk/government/publications/the-government-data-quality-f…
Ault, S. V., Nam Liao, S. & Musolino, L. (2025). Principles of Data Science, section 2.4, “Data Cleaning and Preprocessing”. OpenStax. openstax.org/books/principles-data-science/pages/2-4-data-cl…
Google. “[GA4] Compare Analytics reports and data exported to BigQuery”. Analytics Help. support.google.com/analytics/answer/13578783?hl=en

Before you start

You will be able to

Review first

The idea

Six dimensions of data quality

Where quality problems come from

In depth

How quality problems move a metric

Fitness for purpose

Measuring quality

Who is responsible for quality

Looking before fixing

Formulas

Completeness of a required field

Overstatement caused by duplicates

Effect of one wrong value on a mean

Worked examples

Explore

Common mistakes

“The file is clean, so the numbers are right.”

“A few duplicates don’t matter.”

“Missing values only reduce the sample size.”

“Every blank is a defect.”

“Data quality is the analyst’s job.”

“If the systems disagree, one of them is wrong.”

Guided practice

On your own

In practice

Knowledge check

Summary

Key formulas

Terms introduced

Sources