A data-quality dashboard should tell readers whether a number is fit for its intended use. An executive report can tolerate a different delay from a live dispatch screen. A missing optional description is not equivalent to a missing order identifier. Useful checks reflect those differences instead of producing one unexplained quality score.
Begin by naming the decisions the data supports and the cost of an incorrect result. Then define checks for freshness, completeness, validity, uniqueness and reconciliation. Each failed check needs an owner and a response.
Show freshness at the right level
A page's refresh time can be misleading. The dashboard may have refreshed successfully while its source system stopped sending updates. Show source event time, ingestion time and report refresh time separately when they differ materially.
For a hypothetical stock report, the warehouse movement feed might be current while the supplier catalogue is a day old. Display that distinction on the relevant figures. A single green status for the whole page should not imply both sources are current.
Choose checks that expose real problems
| Dimension | Example check | Useful response |
|---|---|---|
| Completeness | Orders missing a warehouse assignment | Send to an exception owner |
| Validity | Negative received quantity without correction type | Investigate the event |
| Uniqueness | Duplicate external order ID | Hold repeated processing |
| Consistency | Shipment references an unknown product | Reconcile master data |
| Reconciliation | Daily source total differs from imported total | Inspect missing and rejected records |
The rule should describe exceptions clearly. Negative quantities can be legitimate returns, so a simplistic rule may create false alarms.
Keep operational totals independent of quality totals
If 1,000 orders are received and 20 have incomplete addresses, the report should show both the order total and the incomplete-record count. Silently excluding the 20 makes the business figure look cleaner while hiding the work that remains.
Decide whether unreliable data should be shown with a warning, partially hidden or prevented from driving an automated action. That decision belongs to the business and data owners together. It should not emerge accidentally from a developer's default filter.
Reconcile transformations
A source-to-report pipeline can change units, time zones, identifiers and categories. Verify counts and amounts at meaningful boundaries. Database consistency protects individual updates, while reconciliation checks whether the intended business records actually arrived.
Keep rejected records available to an authorised recovery process. Avoid dumping raw personal data into a general log or public quality report. Staff usually need the record reference, reason and affected field, not the entire customer document.
Establish a response cadence
Some failures need immediate intervention, while others belong in a daily review. A stale dispatch feed can affect current routes. An incomplete product description may be resolved during catalogue maintenance. Make alert urgency reflect that difference.
Track the age of unresolved issues and repeated causes. If the same missing field appears every week, fix the capture process rather than only repairing individual records downstream.
Demonstrate trust before launch
Create a deliberately stale feed, a duplicate event and a malformed record in a test environment. Ask a business reader to explain which metrics remain usable and who should respond. If they cannot tell, the quality interface needs clearer language.
A trustworthy dashboard makes uncertainty visible without overwhelming the reader. Its purpose is to support responsible use of data, not to turn every imperfection into a red badge.
Primary references
Related reading
For help applying this planning approach, explore our data analytics dashboards or discuss your requirements.