Data quality reporting and a reproducible workflow · B02

Before you start

You will be able to

Explain who reads a data quality report and what each reader needs from it.
Write the sections of a data quality report, including each issue, the decision taken and its rationale, and the limitations that remain.
Calculate before-and-after profile figures and describe how exclusions change who the data represent.
Construct a reproducible cleaning workflow that keeps the raw data untouched and records its lineage.
Evaluate reporting choices for honesty, bias and the protection of personal data.

Review first

Transforming and reshaping data — The report records every transformation, with the row-count and total checks that go with it.
Missing values — Deciding whether an exclusion biases a result uses the reasons values go missing.
Percentages, and the difference between a change in percentage points and a percentage change.

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

Ana Lim is meeting a potential investor next week. Lantern’s analyst, Jun Park, has spent the past few weeks cleaning the lantern-orders export and has produced the figures Ana will show: revenue by region for March to June 2026, how subscribers’ orders compare with one-off orders, and the average customer rating. The investor’s analyst will ask three things before believing any of it. Where did the data come from? What did you change? Could anything you removed change the story? If the answers live only in Jun’s memory and in a spreadsheet he edited by hand, Lantern can’t give them.

A data quality report answers those questions. It travels with the cleaned data and records where the data came from, what was wrong with them, what was done about each problem and why, what those decisions mean for the results, and how to repeat every step. It is the last stage of cleaning, not an optional extra, because data are trustworthy only to someone who can check how they were made.

Who reads it

Different readers come to the report for different parts, and a good report lets each find theirs quickly.

Decision makers (Ana, the investor) want to know whether they can rely on a figure and what caveats come with it. They read the summary, the effect of the decisions on the results, and the limitations.
Analysts who will reuse or extend the data, including you in six months, want the exact steps, the definitions and the assumptions. They read the data dictionary and the cleaning log.
Data owners and reviewers (the team that runs the shop platform, an auditor, a regulator) want to know where the data came from, who handled them, and what happened to personal information. They read the source, the lineage and the privacy notes.

Quality is relative to a use. The UK government’s Data Quality Framework describes data quality as “fitness for purpose”, and the idea applies to any organisation. Lantern’s cleaned file can be good enough to report monthly revenue and not good enough to judge customer satisfaction, because ratings are missing far more often for some kinds of customer than for others. So a report states its purpose first, and the reader judges fitness against that purpose.

Raw data, the log and reproducibility

Raw data are the data exactly as received from their source, before any change: here, the export file downloaded from the shop platform. Treat the raw file as read-only. Every cleaned table is produced from it by recorded steps, and the ordered record of those steps is the cleaning log. Each entry says what was done, to which rows and columns, by what rule, and with what effect on the row count.

Two properties follow when you work this way. Reproducibility: running the same steps on the same raw data gives the same result every time, so anyone can check your figures by rerunning them. Data lineage: every figure in the report can be traced back through the steps to the raw file it came from, and to the version of the steps that produced it. When the investor’s analyst asks where the March revenue for the North region comes from, lineage is the answer: this file, these steps, this version.

What a report is not

A data quality report is not a list of apologies, and it is not a sales document. It doesn’t hide problems to make the data look better, and it doesn’t bury the reader in every trivial fix. Its test is simple: could a sceptical reader, with the raw file and the report, understand every decision, judge whether it was reasonable, and reproduce the cleaned data? If so, the report has done its job, even when the honest conclusion is that some questions can’t be answered with these data.

In depth

The sections of a report

There is no single required template, but the sections below cover what reviewers ask for. They draw on published guidance: Broman and Woo’s advice on organising data in spreadsheets (including a separate data dictionary and an untouched primary data file), Wilson and colleagues’ “good enough practices” for scientific computing (save the raw data; record every processing step), and the “datasheets for datasets” proposal of Gebru and colleagues, which asks dataset creators, among much else, whether the raw data were saved and whether the cleaning software is available.

Sections of a data quality report, with an example line for Lantern
Section	What it contains	Lantern example
1. Purpose and scope	The questions the data will answer; which records are in scope and which are not	Revenue, order values and ratings for online-shop orders, 1 March to 30 June 2026; catering and training sales are out of scope.
2. Source	System, file name, extraction date, who extracted it, rows and columns as received, a fingerprint of the file	The `lantern-orders` export from the shop platform, downloaded by Jun Park, with its checksum.
3. Data dictionary	Every variable: name, meaning, type, unit, allowed values or range, missing-value codes	`order_total`: amount charged, US dollars, equal to quantity × unit_price − discount.
4. Profile before and after	Rows, columns, missing values per column, duplicates and failures of each validation rule, before and after cleaning	Missing ratings and order-total rule failures, before and after.
5. Issues and decisions	Each issue: how it was found, how many rows, the decision, the rationale and the alternatives considered	Repeated order ids with changed values: kept the copy confirmed by the shop system.
6. Effect on the analysis	What the decisions removed or changed, which records they affect, and whether that could bias a result	Ratings analysed only where present, so the average rating speaks mainly for the customers who rate most.
7. Assumptions	What was taken to be true without proof	Ambiguous slash dates read with the convention that the unambiguous dates in the same format follow.
8. Limitations	Problems that remain or can’t be fixed with these data	Some missing e-mail addresses can’t be recovered from the file.
9. Cleaning log	The ordered, rerunnable list of steps, with the row count after each	The script, or the recorded steps, and their row counts.
10. Version and history	Version number, date, author, what changed since the previous version	Version 1.1: June orders added; same rules.

Two pairs of sections are easily confused. Effect on the analysis describes the consequences of decisions you made (you excluded these rows, so this group is under-represented); limitations describe problems you could not solve (these values are missing and can’t be recovered). Assumptions are things you believe but haven’t proved, such as how an ambiguous date should be read; if an assumption is wrong, a figure is wrong, so state it where the reader can find it.

A fingerprint, usually a checksum computed from the file’s bytes, lets anyone confirm that the file they hold is identical to the one you cleaned, which matters when exports are regenerated and quietly change.

Profiles before and after

The profile section puts the same measures side by side for the raw and the cleaned data: rows, columns, the share of missing values in each column, the number of duplicates, and the number of rows failing each validation rule. Report counts and their denominators, because cleaning changes the denominator. The missing share of a column is

\text{missing \%} = \dfrac{\text{missing values in the column}}{\text{rows}} \times 100

and the share of rows kept is rows after ÷ rows before × 100. When rows are removed, a missing share can rise even though missing values fell, simply because the denominator fell faster, as the first worked example shows. Compare shares in percentage points (the difference between two percentages: 8% to 5% is a fall of 3 points) and say so; a fall from 8% to 5% is also a 37.5% relative fall, and mixing up the two misleads.

Writing a decision and its rationale

The heart of the report is one entry per issue. Each entry has five parts: the evidence (what you saw and how you found it, usually a validation rule), the scale (how many rows, and which), the decision, the rationale (why this option, with the evidence that supports it), and the alternatives considered and what they would have done to the results. Here is an entry for Harborview Hotel’s bookings:

Issue: Some bookings have a nightly rate of 0 or 9999, outside the hotel’s price range.
Evidence and scale: Found by the range rule on rate; the entry lists the bookings affected. For every one of them, total ÷ nights gives a rate inside the usual range for its room type.
Decision: Replace the rate with total ÷ nights, and add a flag column marking the replaced values.
Rationale: The totals agree with the price list and with similar bookings, so they are the reliable field; 0 and 9999 are placeholder codes, not prices.
Alternative: Excluding the bookings would remove real stays and bias the average rate (see the applied example).

A rationale that says only “cleaned the rates” or “removed bad rows” is not a rationale. The reader must be able to disagree with you, and they can only do that if you show what you saw and what you weighed.

Effect on the analysis: who is left out

Every exclusion changes whom the data represent. If the removed rows are like the rest, results computed on what remains are unbiased, only less precise. If they differ, the results shift. The test is to compare the excluded and the kept rows on the variables that matter for the question: customer type, region, channel, month. When the groups differ, report the figure computed on the kept rows, say which groups are under-represented, and, where you can, show an adjusted figure, for example a weighted average of group results using each group’s true size, together with the assumption it rests on.

This is where the reasons for missingness from the lesson on missing values reach the report. Lantern’s ratings are missing more often for some customers than others, so an average over the ratings that exist describes the customers who rate, not all customers. That is not a reason to hide the average; it is a reason to label it honestly.

Reproducibility and lineage in practice

Keep the raw file pristine. Store it read-only in its own folder, record its fingerprint, and back it up in more than one place. Broman and Woo put it plainly: the primary data file should stay a pristine store of data, with calculations done elsewhere.
Make every change a recorded step. Wilson and colleagues recommend writing scripts for every stage of data processing: a pandas or R script, a SQL query, or a tool that records steps. Excel’s Power Query, for example, saves every transformation as an applied step that can be inspected and rerun.
One step, one purpose, in a fixed order, with the row count logged after each step.
Keep parameters in one place: thresholds such as the 1.5 × IQR fence, mapping tables for categories, date conventions and cut-off dates. Changing a rule should mean changing one line.
Treat outputs as disposable. Never hand-edit a cleaned file or a report figure. Fix the step and rerun.
Version the steps and the outputs together, and note the software used, so that version 1.1 of the report can always be traced to version 1.1 of the steps.
Test the chain: rerun everything from the raw file into an empty folder and confirm the outputs are identical.

Order is part of the recipe. Trim spaces and standardise case before removing duplicates, or “north ” and “North” keep two rows apart that are really one. Convert types before checking ranges, because a price stored as text can’t be compared with a number. Remove duplicates before joining, or each duplicate multiplies. Split training and test data before fitting any scaler or encoder, so that nothing learned from the test set leaks into training. If you must work in a spreadsheet, keep the raw sheet untouched, do the work in a copy, and keep a log sheet that lists each step in words precise enough for someone else to repeat.

The Turing Way, a community handbook on reproducible research, distinguishes reproducing a result (same data, same analysis) from replicating it (new data, same analysis). A data quality report makes the first possible and supports the second: when Lantern’s July export arrives, the same steps run on new data, and any new kind of problem shows up as a rule failure in the profile.

Honesty and personal data

Cleaning is full of judgement calls, and judgement can drift towards the answer you hoped for. A few rules keep it honest. Decide the rules before looking at the results they produce, where you can. Apply the same rule to convenient and inconvenient values: a one-star rating is a valid value on a one-to-five scale, not an outlier to be trimmed. Disclose every exclusion, with counts. And when a contested decision changes the conclusion, show the result both ways and explain which you prefer and why.

The data often contain personal information, and Lantern’s export holds customers’ e-mail addresses. Data protection laws such as the EU and UK GDPR require personal data to be “adequate, relevant and limited to what is necessary” for the purpose, the principle of data minimisation. In practice: use e-mail addresses only where they are needed (for example, to recover a missing customer number), then drop them from the analysis file and work with customer_id, a pseudonymised key; restrict access to the raw file; never put personal details in the report itself; and avoid publishing figures for groups so small that a reader could identify the people in them.

Formulas

Share of rows retained

\text{retained \%} = \dfrac{n_{\text{after}}}{n_{\text{before}}} \times 100

$n_{\text{before}}$: Rows in the raw datarows
$n_{\text{after}}$: Rows in the cleaned datarows

Pair it with a breakdown of the removed rows by reason, so that the reader can see what went.

Change in percentage points and relative change

\Delta_{\text{pp}} = p_2 - p_1 \qquad \Delta_{\%} = \dfrac{p_2 - p_1}{p_1} \times 100

$p_1,\ p_2$: A percentage before and after%
$\Delta_{\text{pp}}$: Change in percentage pointspp
$\Delta_{\%}$: Relative (percentage) change%

From 8% to 5% is −3 percentage points and a relative change of −37.5%.

Worked examples

A first example: A before-and-after profile

Fictional figures

Fernwood Apparel, a fictional clothing brand, exports 2,400 rows of product returns. Cleaning removes 120 exact duplicates and excludes 30 rows whose return date is before the order date. Before cleaning, 360 rows have no return-reason code; 18 of those were among the duplicates and 2 among the excluded rows. Complete the profile lines for rows and for missing reason codes.

Rows after cleaning: $2{,}400 - 120 - 30 = 2{,}250$ . Share retained: $2{,}250 \div 2{,}400 \times 100 = 93.75\%$ , which the report rounds to 93.8%.
Missing reason codes before: $360 \div 2{,}400 \times 100 = 15.0\%$ .
Missing reason codes after: $360 - 18 - 2 = 340$ values, and $340 \div 2{,}250 \times 100 \approx 15.1\%$ .
Interpret the change. The count fell by 20, a relative fall of $20 \div 360 \approx 5.6\%$ , but the rows fell by $150 \div 2{,}400 = 6.25\%$ , so the share rose by about 0.1 percentage points. Removing duplicates and invalid rows did nothing about missing reasons; it only changed the denominator.

Answer. Rows: 2,400 before, 2,250 after (93.8% retained). Missing reason codes: 360 of 2,400 (15.0%) before, 340 of 2,250 (15.1%) after.

What it means. The report should show counts and denominators side by side and say plainly that missing reason codes remain at about 15%, so any analysis of why customers return clothes rests on 85% of the returns. That is a limitation to state, not a figure to dress up.

A harder example: Does excluding missing ratings bias the average?

Fictional figures

Kestrel Battery Installers, a fictional company that fits home and commercial battery-storage systems, surveys every customer after installation. Of 300 residential jobs, 240 have a satisfaction score (0–10), averaging 8.0. Of 100 commercial jobs, 30 have a score, averaging 6.0. The draft report says “average satisfaction 7.8”. Is that fair, and what should the report say?

Response rates: residential $240 \div 300 = 80\%$ , commercial $30 \div 100 = 30\%$ , overall $270 \div 400 = 67.5\%$ .
Composition: commercial customers are $100 \div 400 = 25\%$ of jobs but only $30 \div 270 \approx 11.1\%$ of scores. The kept rows over-represent residential customers, who score higher.
Average over the scores that exist: $(240 \times 8.0 + 30 \times 6.0) \div 270 = 2{,}100 \div 270 \approx 7.78$ , the draft’s 7.8.
Adjusted average, weighting each segment by its share of jobs: $(300 \times 8.0 + 100 \times 6.0) \div 400 = 3{,}000 \div 400 = 7.50$ . This assumes that within each segment the customers who answered are like those who didn’t, an assumption the report must state.
Write the effect entry: “Scores exist for 270 of 400 jobs (67.5%): 80% of residential and 30% of commercial. Commercial customers are 25% of jobs but 11.1% of scores. The unadjusted average is 7.78; weighted by segment it is 7.50, assuming respondents represent their segment.”

Answer. The unadjusted 7.78 overstates satisfaction across all jobs, because the lower-scoring commercial segment rarely answers. A segment-weighted 7.50 is the better single figure, reported with both segment averages, the response rates and the assumption.

What it means. The bias isn’t in anyone’s arithmetic; it comes from who answered. Commercial customers are the business Kestrel most needs to understand, and they are the ones the survey hears least from. The report’s job is to make that visible, and the obvious next step is to chase commercial responses.

Applied: a business decision: Placeholder rates and Harborview’s average daily rate

Fictional figures

Harborview Hotel’s revenue manager needs the average daily rate (room revenue ÷ room nights sold) for a group of eight completed stays in March 2026, from the fictional extract below. Three bookings carry placeholder rates. Decide how to handle them, compute the figure, and write what the report should say.

Eight completed stays (fictional)
Booking	Room type	Nights	Rate ($)	Total ($)
B1	Standard	2	128	256
B2	Deluxe	3	169	507
B3	Standard	1	0	131
B4	Suite	2	9999	596
B5	Family	4	195	780
B6	Deluxe	1	172	172
B7	Standard	3	0	375
B8	Deluxe	2	165	330

See the damage of doing nothing: using the rate column as stored, room revenue would be $\sum \text{nights} \times \text{rate} = 22{,}043$ over 18 nights, about $1,224.61 a night. The 9999 placeholder alone adds $19,998.
Check whether another field is reliable. For B3, B4 and B7, total ÷ nights gives $131 \div 1 = 131$ , $596 \div 2 = 298$ and $375 \div 3 = 125$ , each in line with the other rates for its room type; for the five other bookings, total = nights × rate exactly. The totals are trustworthy, and the rates of 0 and 9999 are placeholders.
Option A, exclude the three bookings: $(256 + 507 + 780 + 172 + 330) \div (2 + 3 + 4 + 1 + 2) = 2{,}045 \div 12 \approx 170.42$ .
Option B, recover the rates and use every stay: room revenue $= 3{,}147$ over 18 nights, so $3{,}147 \div 18 \approx 174.83$ .
Choose and record. Option B uses evidence (the totals) and keeps real stays; option A removes the only Suite stay and understates the figure by $174.83 - 170.42 \approx 4.42$ , or about 2.5%. The decision entry states the rule (rate = total ÷ nights where rate is 0 or 9999), the three bookings affected, and option A as the rejected alternative.

Answer. Average daily rate $174.83, with the three placeholder rates recovered from total ÷ nights. Excluding them would have given $170.42, about 2.5% too low.

What it means. Two defensible-looking choices differ by $4.42 a night, enough to move a pricing decision, and only one is supported by evidence. Recording the decision, its evidence and the rejected alternative lets the revenue manager, or an auditor, see why the report’s figure is $174.83 and not something else.

Explore

Common mistakes

“The report is just the list of cleaning steps.”
The log says what was done; the report also says why, what it changed, and what it means for the results. A reader can’t judge “removed 30 rows” without knowing which rows, by what rule, and whether their removal shifts who the data represent.
“Fewer missing values means a lower missing percentage.”
Not if rows were removed too. The share is missing values ÷ rows, and cleaning changes both. Report counts and denominators, and compare percentages in percentage points.
“I’ll fix the odd cell by hand; it’s only one.”
One unrecorded edit breaks reproducibility: the next export brings the problem back, and nobody can trace the figure that changed. Express even a single correction as a rule or a documented replacement table, and run it as a step.
“Excluding incomplete rows is neutral.”
It is neutral only if the excluded rows are like the rest. When some groups are missing more often, the remaining data over-represent the others and averages shift. Compare kept and excluded rows, and report the effect.
“Outliers should come out before reporting.”
Only values shown to be errors, or out of scope, should be changed or excluded, and the report says which and why. A genuine bulk order or a one-star review is real data; removing it to tidy a chart changes the answer.
“Personal data can stay in the file; it’s internal.”
Keep personal data only where the purpose needs it. Once e-mail addresses have helped recover missing customer numbers, drop them from the analysis file, keep the raw file access-restricted, and never quote personal details in the report.

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

Here is how Jun takes Lantern’s order export from raw to reported, step by step. Each step uses a lesson from this course, and each leaves an entry in the cleaning log and a line in the report.

Freeze the source. He saves the export exactly as downloaded, makes it read-only, and records the extraction date, the file’s fingerprint, and its rows and columns as received. That is the report’s source section.
Describe the data. One row per order, order_id as the key, fourteen variables with their types and units in a data dictionary (the lesson on datasets and variables).
Profile and write rules. Quantities must be whole numbers from 1 to 200, the data dictionary’s range; dates must fall between 1 March and 30 June 2026; regions must be one of five names; order_total must equal quantity × unit_price − discount to the cent. The raw profile records how often each rule fails (profiling and validation).
Fix records and formats. He trims spaces and standardises case first, then removes exact duplicates; for order ids that repeat with a changed value, he keeps the copy the shop system confirms. He converts the several date formats and the text prices, including the one written with a decimal comma, and maps region spellings with a mapping table (duplicates; types and formats; text and categories).
Decide about missing and unusual values. Missing e-mails are recovered from the same customer’s other orders where possible and otherwise left missing; missing ratings stay missing and are not imputed for the rating analysis. The genuine bulk order stays, flagged; the typing-error outlier is corrected only if other evidence, such as the order total or the price list, shows the right value. Right-skewed totals are reported with medians (missing values; outliers; skewed data).
Transform for the questions. He derives expected totals and months, aggregates by region and month with totals reconciled, and joins the product-cost table after checking that its key is unique (transforming data). Scaling and encoding, if a model is built, are fitted on the training set inside the modelling pipeline (scaling; encoding categories).
Protect personal data. With duplicates and recoveries done, he drops email from the analysis file and works with customer_id.
Profile again, write the report, and rerun. The after profile shows every rule passing or every remaining failure explained. He writes the decisions, their effects and the limitations, deletes the outputs, reruns the steps from the raw file, confirms identical results, and labels the report version 1.0.

The report Ana takes to the investor is short at the front: what the data cover, what the figures are, and the three caveats that matter (ratings come mostly from the customers who rate most; one order was a genuine bulk purchase that lifts March to June revenue; a few customers can’t be matched across orders). Behind it sit the dictionary, the profiles, the decision entries and the log. When the investor’s analyst asks how the regional revenue was computed, Jun can show the step, rerun it in front of her, and get the same number.

The same discipline appears wherever data inform decisions that others check. Harborview’s revenue manager attaches a short quality note to each monthly report, listing placeholder rates recovered and channel-manager duplicates removed, so that the owners can compare months fairly. Northfield University’s planning office converts grade point averages recorded on two scales to one, and states the conversion rule in every report that uses them, because a regulator or an accreditation panel may ask. In each case the report costs little to write once the steps are recorded, and it is what turns a cleaned file into evidence.

This lesson closes the course. You began with a messy export and a question; you can now describe the data, profile them, fix their records and formats, decide about missing and unusual values, prepare them for analysis, and, finally, show your work so that someone else can trust it and repeat it.

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

A data quality report records where the data came from, what was wrong, what was done and why, what that means for the results, and how to repeat it. Quality is judged against a stated purpose.
Core sections: purpose and scope, source, data dictionary, profile before and after, issues and decisions, effect on the analysis, assumptions, limitations, cleaning log, version.
Each decision entry gives the evidence, the scale, the decision, the rationale and the alternatives, so that a reader can disagree with it.
Report counts with their denominators: removing rows changes every share. Compare percentages in percentage points, and keep relative changes separate.
Exclusions change whom the data represent. Compare kept and excluded rows, report the effect, and give an adjusted figure with its assumption where possible.
Keep the raw data read-only and make every change a recorded, rerunnable step in a fixed order; reproducibility and lineage follow.
Be honest and minimise personal data: never remove values because they are inconvenient, disclose every exclusion, and keep personal details out of analysis files and reports.

Key formulas

Share of values missing in a column
Share of rows retained
Change in percentage points and relative change

Terms introduced

Data quality report: A document that travels with a cleaned dataset and records its source, its problems, the decisions taken and why, their effect on the results, the remaining limitations and how to reproduce the cleaning.
Raw data: Data exactly as received from their source, before any cleaning or transformation. Kept read-only so that every cleaned version can be rebuilt from them.
Cleaning log: The ordered record of every cleaning step: what was done, to which rows and columns, by what rule, and the row count afterwards.
Reproducibility: The property that running the same steps on the same data gives the same result every time.
Data lineage: The traceable path from a figure or cleaned table back through every step to the raw data and the version of the steps that produced it.
Percentage point: The unit for the difference between two percentages: a change from 8% to 5% is a fall of 3 percentage points (and a relative fall of 37.5%).
Data minimisation: The data-protection principle that personal data should be adequate, relevant and limited to what is necessary for the purpose.
Pseudonymised: Describes data in which direct identifiers such as names or e-mail addresses are replaced by codes, so that records can still be linked but people can’t be identified without separately held information.

Sources

Broman, K. W. & Woo, K. H. (2018). Data organization in spreadsheets. The American Statistician, 72(1), 2–10. Free preprint: PeerJ Preprints 6:e3183v2. peerj.com/preprints/3183
Wilson, G., Bryan, J., Cranston, K., Kitzes, J., Nederbragt, L. & Teal, T. K. (2017). Good enough practices in scientific computing. PLOS Computational Biology, 13(6), e1005510. journals.plos.org/ploscompbiol/article?id=10.1371/journal.pc…
The Turing Way Community (2025). The Turing Way: A handbook for reproducible, ethical and collaborative research, “Definitions for reproducibility”. Zenodo, doi:10.5281/zenodo.3233853. book.the-turing-way.org/reproducible-research/overview/overv…
Gebru, T., Morgenstern, J., Vecchione, B., Vaughan, J. W., Wallach, H., Daumé III, H. & Crawford, K. (2021). Datasheets for datasets. Communications of the ACM, 64(12), 86–92. Free version: arXiv:1803.09010. arxiv.org/abs/1803.09010
Government Data Quality Hub (2020). The Government Data Quality Framework. UK Government, published 3 December 2020. gov.uk/government/publications/the-government-data-quality-f…
Information Commissioner’s Office. Principle (c): Data minimisation (UK GDPR guidance). ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/…

Before you start

You will be able to

Review first

The idea

Who reads it

Raw data, the log and reproducibility

What a report is not

In depth

The sections of a report

Profiles before and after

Writing a decision and its rationale

Effect on the analysis: who is left out

Reproducibility and lineage in practice

Honesty and personal data

Formulas

Share of values missing in a column

Share of rows retained

Change in percentage points and relative change

Worked examples

Explore

Common mistakes

“The report is just the list of cleaning steps.”

“Fewer missing values means a lower missing percentage.”

“I’ll fix the odd cell by hand; it’s only one.”

“Excluding incomplete rows is neutral.”

“Outliers should come out before reporting.”

“Personal data can stay in the file; it’s internal.”

Guided practice

On your own

In practice

Knowledge check

Summary

Key formulas

Terms introduced

Sources