Data Quality and Fitness for Purpose Before Dashboarding
5 min read
Lesson objectives
- Assess a data issue using relevant quality dimensions and connect it to analytical purpose.
- Use profiling to identify issues needing deeper verification without treating it as proof of accuracy.
- Propose a transparent treatment for a quality issue and explain its effect on the dashboard.
A trustworthy dashboard starts with knowing the condition of its data
Data quality does not mean every value must be perfect. The practical question is whether the data are fit for the intended purpose, with known weaknesses and effects. A dataset can be nearly complete but three weeks late, making it unsuitable for daily operations monitoring. Another dataset can be current but contain duplicate identifiers that inflate request counts. We therefore assess more than one dimension and always ask: Could the defect change the decision the dashboard is meant to support?
| Dimension | Practical question | Example problem |
|---|---|---|
| Accuracy | Does the value represent reality as intended? | Close timestamp earlier than open timestamp |
| Completeness | Are required fields or records present? | 20% of requests have no service type |
| Consistency | Do values align across sources and rules? | Same team stored under two names |
| Timeliness | Are data available when the decision needs them? | Weekly refresh for a daily operations view |
| Uniqueness | Is the logical record duplicated? | Same RequestID appears twice without justification |
| Conformity/format | Do values follow agreed formats and rules? | Region codes use incompatible formats and fail to group |
Profile first, then investigate the cause
Data profiling is descriptive inspection used to understand data condition: missing-value counts, distinct values, ranges, unusual patterns, and duplicates. Profiling alone does not prove a value is accurate; all values may look plausible but come from the wrong source. Its value is to point to areas that need deeper verification. The idea can be implemented with any tool that provides statistics or queries; the learning goal is the questions, not a vendor’s buttons.
Fitness for purpose also means time and logic definitions must match the decision. A monthly financial report may refresh after close, while a field-team dispatch view may require much fresher data. There is no universal value for a “good refresh.” A business dashboard should therefore show the last refresh time, define expected freshness, and prevent users from treating stale data as current status.
A small quality log is better than a vague warning
| Issue | Measurement | Dashboard impact | Action |
|---|---|---|---|
| Missing TeamID | 15% of requests | Team comparison is incomplete | Show Unknown; fix capture; monitor the gap |
| Duplicate RequestID | 40 IDs require verification | Counts and rates may be inflated | Define business key and deduplication rule |
| Refresh lag | 5 days | Dashboard does not represent daily status | Show last refresh; fix schedule before daily dispatch use |
Lesson summary
Data quality is judged against purpose. Dimensions such as accuracy, completeness, consistency, timeliness, uniqueness, and conformity help describe issues, while profiling surfaces signals for verification. A good treatment does not hide a defect; it documents the issue and its impact.