By Andy Huynh

A dashboard can be visually impressive, easily understandable, and yet can still be completely wrong. Throughout my six years of professional experience in data analytics and development, that is one lesson I have learned to never overlook: a report is only as reliable as the data behind it. Over those years, I’ve worked with plenty of datasets, reports, dashboards, and the occasional number that just did not look right. One thing I’ve learned is that creating a good dashboard is not just about making the data look good—it is about being able to trust the data in the first place. A dashboard can be clean, polished, and easy to understand, but none of that matters if the numbers behind it are wrong. That is why I consider data quality to be one of the most important foundations of effective reporting and decision-making.

A large part of ensuring data quality starts before I even build the dashboard. When pulling data, I create scripts designed to retrieve the specific information I need while also looking for potential problems along the way. Sometimes an individual value is technically valid but does not make sense when compared with another attribute or field. For example, in the phone call data I work with, a call can be classified as either good or bad while another field identifies the topic or outcome of the call. Occasionally, a call may be marked as “Good,” but the topic says “Disconnected,” meaning the operator was unable to speak with the intended person. Both values exist legitimately in the dataset, but together they raise a red flag. Knowing the data and understanding what it represents allows me to build checks that catch these contradictions before they become part of a report.

I also like to build “sanity checks” into my reporting tools (I picked up this habit and terminology from my high school physics teacher, thank you, Mr. Chamblee). The idea is simple: if one number is correct, what else in the data should also be true? For example, I may calculate the total number of calls and then separately count the total number of call topics. If every call is expected to have an associated topic, those two numbers should match. If they do not, I know something deserves a second look. It could be a missing value, an incorrect classification, a filter behaving differently than expected, or another issue entirely. Sometimes… it could be that I made a mistake pulling in the data as well! The sanity check does not necessarily tell me what went wrong, but it tells me not to blindly trust the result right away. I would much rather question a number before publishing it than explain afterward why it was wrong.

This becomes especially important when the data reaches a dashboard or report. Once a number is placed on a chart, KPI table, or an executive report, people naturally begin to treat it as authoritative. In my experience, that makes the work behind the visualization just as important as the visualization itself. A dashboard cannot fix bad data, it can only make bad data easier to see and, potentially, easier to act on and then attacked. My goal is not only to produce a report, but to be confident that the information I am presenting accurately represents what is happening. Scripts, validation rules, cross-checks, and an understanding of the business process all contribute to that confidence.

Ultimately, I believe one of the most important things a data analyst provides is trust. Decision-makers should be able to look at a dashboard or report and focus on what the information is telling them rather than wondering whether the numbers are correct. Gaining that trust involves more than removing duplicates or filling in missing values. It requires knowing the data well enough to recognize when something does not make sense and building processes that catch those issues early on. Good visualizations may make information easier to understand, but data quality well done is what makes that information worth using. After six years working with data, one lesson continues to hold true: before asking what the data is telling us, I first want to know that I can trust what I am working with.