Guide
How to Score the Quality of a Data File — and Show Your Working
Somebody asks whether the file is any good. The honest answer is usually "it depends what you need from it", which is true and completely useless.
The short answer
Score a file across five measurable dimensions and publish the weights alongside the number. In DataTray, open Data Explorer → Columns and the quality score is computed as part of the profile: a 0–100 headline over completeness, validity, uniqueness, consistency and structure, with each dimension's weight printed in the report. It is measured against the file's own shape, never against a benchmark, and every component links to the rows that caused it.
The five dimensions, and what each one measures
| Dimension | What it measures | Weight |
|---|---|---|
| Completeness | Non-null density, weighted toward key columns | 30 |
| Validity | Values conforming to the column's inferred type and semantic role | 25 |
| Uniqueness | Duplicate row rate, and uniqueness of key columns | 20 |
| Consistency | Format, casing and encoding coherence within a column | 15 |
| Structure | Ragged rows, duplicate headers, empty and constant columns | 10 |
Completeness carries the most weight because a missing value is the failure that propagates furthest — it survives every downstream join and quietly becomes a zero in somebody's total. Structure carries the least because structural faults are loud: you usually find out immediately.
Why the weights have to be visible
An unexplained score is worse than no score. If a file comes back as 62 and you cannot see which dimension cost it, there is nothing to do except distrust the whole file — which is exactly the outcome the score was supposed to prevent.
Publishing the weights also makes the number arguable, which is a feature. If completeness matters less for your use case than validity does, you can say so with a reason, and the score stops being something handed down and starts being something you reason with.
Relative to the file, never to a benchmark
The report says "38% of phone values do not match any phone pattern" and shows you five of
them. It does not say "your data is bad", and it does not compare your file against an industry
average that was computed from data nothing like yours.
That distinction matters more than it sounds. A 40% null rate is a catastrophe in a billing identifier and completely normal in an optional free-text field. A score that pretends to know which one it is looking at will be wrong roughly half the time; a score that shows you where the nulls are lets you make that call in a second.
Every number links to its rows
The most useful property of the score is not the number. It is that each contributing finding carries an affected-row count and a "show me these rows" action, which applies the matching filter to the grid.
That round trip — from a summary statistic to the actual offending records and back — is what turns a quality report from a status update into something you can act on before lunch.
What to do with a score that dropped
A single score is weak evidence. A score that fell between last month's export and this month's is strong evidence that something upstream changed, and it is worth two minutes:
- Compare the two files directly to see whether a column was added, removed or retyped.
- Look at which dimension moved. Validity falling usually means a source system changed a format; completeness falling usually means a field stopped being populated.
- Check the row counts. A big change in either direction is its own story.
Fix what the score found, in the same app
Most of what drags a score down is repairable, and it is repairable mechanically: type coercion, date normalization, whitespace, casing, near-duplicate category values. Clean & Anonymize applies those as one previewable pass, and Dedupe & Merge handles the uniqueness dimension with a report of every row it removed.
Re-profile afterwards and the score moves. That loop — measure, fix, measure — is the entire value, and it is quick enough to run on a file that arrived ten minutes ago.
Every other free way to do this asks you to upload the file first. A quality report on a customer list is not something to hand to a website you have not heard of.
Do this in one pass with — Data Explorer
Read-only, always. Open a CSV, Excel workbook, Parquet directory or JSON file of any size and look at the rows — then switch to Columns for a full data profile: what every column actually holds, where the nulls and the mixed types and the outliers are, a data-quality read on each one, and a data dictionary you can hand to someone. A third tab takes SQL if you want it, and never asks you to write any if you don’t. Nothing here modifies the file; the only things written are the exports and reports you ask for. Learn more about the Data Explorer.
Windows 10/11 (x64) · Free · No account