When the Analyst Doesn’t Understand the Data
There’s a common phrase in analytics: “The data tells a story.” That’s nice in theory, but in practice, the story being told depends entirely on whether the analyst actually understands the data they’re looking at. And often, they don’t.
It’s not always the analyst’s fault. You get dropped into a new environment with five years of data, thousands of columns, and no documentation. You’re told to build a dashboard, explain why churn is up, or find something “insightful.” So you do what you can. You click around in a BI tool, run some queries, and start pulling numbers. Everything looks fine—until someone from the product or engineering team tells you that column doesn’t mean what you think it does. Or that the data is stale. Or that it’s not even used anymore.
The problem is that most analysts start with exploration before context. But in systems with real operational complexity, column names don’t always match what’s actually happening in the source application. “Status = active” might mean the user clicked a checkbox once three years ago. A timestamp might be when a job last ran, not when the event actually occurred. Without understanding how the data is created and used, you’re just guessing.
If this sounds familiar, don’t worry—it’s fixable. The goal of this series is to walk through the common traps analysts fall into, how to recognize them, and what to do instead.
Here are three things that help right away:
- Talk to the people who built or use the system. Ask what each field means in practice—not just what the label says.
- Don’t assume nulls or zeros mean “nothing.” They often mean “something went wrong” or “data never landed.”
- Write down your assumptions before building reports. Even a short bullet list can help catch misunderstandings early.
In Part 2, I’ll cover what happens when the data does tell a story—but it’s the wrong one.
