Debunking the 10 Biggest Misconceptions About Data Analytics
- Sarah Rajani
- 3 days ago
- 8 min read
Updated: 13 hours ago
Data Analytics is not all about dashboards and insights.
Before I worked in data analytics, I thought I knew exactly what the role would entail. I seemed so sure, in my mind, anyway.
I figured it would be mostly writing SQL queries, building dashboards, and occasionally finding something interesting to discuss in a meeting. I’d solve simple business problems with clean data, deliver my insights, and move on to the next interesting project.
I also thought I’d be standing up in meetings regularly, walking people through my dashboards while everyone nodded and clapped at my amazing insights... (Just kidding!)
But seriously, I had an idea in my head of what it would look like in the day-to-day, and though my ideas were not completely off base, there were a lot of things that surprised me. Some of these you really won't be able to understand until you've been through it.
Maybe you had some initial assumptions about what data analytics would be like in the workplace?
After 5 years in data analytics and a few different roles under my belt, I can share with you some common misconceptions about the work that are floating around out there, and what you should actually expect.
Keep in mind that each role is different; these are some general "myths" that are relevant to many of them.
Let's get into it!
10 Misconceptions About Data Analytics
1. “Most of your time is spent analyzing data.”
This is probably the most common misconception, and the one that disappoints people the most.
Yes, the word “analysis” is in your job title, but in reality, a lot of your time is spent preparing for analysis.
That means:
Cleaning the data.
Validating it.
Figuring out which version of a metric to use. (I spend a lot of my time on this phase.)
Clarifying what the request is even asking for.
Re-running queries when logic changes. (Logic changes are inevitable as an organization grows and business requirements change.)
Sometimes, just getting access to the right table can take several days, depending on your org.
Many requests don’t start with a clear question. You have to spend time with various stakeholders, trying to align what “conversion” actually means for this use case, figure out which system holds that information, and then double-check that the numbers make sense. There's a lot of behind-the-scenes work before you can even get into the analysis part.
By the time you get to the analysis, you’ve already done half the work and, sometimes, the rest of the request gets deprioritized before you even get there. This is the worst feeling ever, when your hard work feels like a waste of time!
2. "You get a request, build the report, and that’s it."
If only it were that simple. Most requests aren't clear-cut.
For example, you might get asked:
“Can you pull retention rates by channel for Q1?”
Sounds simple enough, right?
But that simple request then turns into:
What does “retention” mean for this team?
What does “channel” refer to? Email, paid, or acquisition source?
Do they want it done by customer or order?
And does Q1 include trial users?
The first answer you get is rarely the final one.
This back-and-forth is not unusual. It’s not the stakeholders’ fault that this happens, either. They often don’t know what’s technically possible or how the data is structured. But this part takes time, and you need to expect that going in.
Why?
If you think about it, the end users know the business, and you know the data, so you need to figure out, together, how to get from A to B to C, and if it's even possible.
If you made it this far, you'll probably like my other posts.
Subscribe to the newsletter:
3. "If you know SQL, you don’t need Excel."
This is a big misconception. SQL is a powerful tool, but you still need to use Excel. It's often the bread and butter of many analytics roles.
You could be writing amazing SQL queries using CTEs and window functions, but you’ll still get asked to export the output to Excel so someone can “have a look” or manipulate it on their own.
In every data-related role I’ve had, Excel showed up in some way:
Someone sends a report that they built manually in Excel years ago, and no one remembers how it works.
Stakeholders want the final table in Excel even if the logic was built in SQL.
Teams without BI tools still rely on spreadsheets as their main reporting format. (This was like my previous company a few years before they got a BI tool.)
Even now, I might do the analysis in SQL, build a dashboard in Power BI or Looker, and still often end up exporting the results to Excel for the final presentation.
4. “All data roles are basically the same.”
You’ll see job titles like Data Analyst, Product Analyst, Business Analyst, Marketing Analyst, and sometimes they are all within the same department, but the work can be vastly different between them. Some data roles don't even have the word "Analyst" or "Data" in them. This makes for a difficult job search.
I’ve worked with analysts of all types, including those who:
Spent most of their workday writing SQL queries for ad hoc requests.
Focus on experimentation and A/B testing.
Build and maintain dashboards.
Manage Salesforce data and operations reports.
Clean up backend logic and work with data engineers.
Even within one company, your day-to-day depends on the team you’re on, the tools you use, and the types of questions people are asking.
In my financial analyst role, I mostly worked in Excel and only used SQL occasionally. In my next data insights role, I was using version control in GitHub, writing queries for our data warehouse, and building dashboards using BI platforms.
This is one reason why job descriptions can be misleading. One “data analyst” role might be mostly dashboard maintenance, while another is all about business strategy. It's important to look past the job title in your search.
5. “Once you build a dashboard, you’re done.”
Unfortunately, that's not exactly how it works. You don't build something, then forget about it. It often requires maintenance or adjustments.
You might build a dashboard, but then:
The table structure changes.
A field gets deprecated or renamed.
The business definition behind a metric changes.
Someone wants a new filter or an extra column.
Someone else wants it split by a different dimension.
Eventually, no one remembers why that one metric is calculated the way it is. You’ll end up maintaining dashboards way more than building new ones.
I've spent a lot of my time updating legacy reports and the queries behind them, and very rarely on building new dashboards from start to finish. This also adds to the challenge of the work.
I remember when a key column in our main table was renamed in the database without anyone looking at the possible repercussions downstream. The dashboard still loaded, but the numbers were wrong for two weeks before anyone noticed. When you are working with financial data, like in my case, accurate data is crucial to business decisions.
Since then, I've built "sanity checks" into everything I work on. That way, at least when I work on something, I can ensure I did all the necessary validations.
6. “Metric definitions are consistent across teams.”
In a perfect world, there is one definition for every metric in an org. In the real world, though, definitions evolve, and they vary across teams.
I once joined a meeting where Sales, Finance, and Operations all had different numbers for “active users.”
Sales included anyone who opened a promotional email.
Finance counted paying users only.
Operations included users who booked a transaction, regardless if it was completed.
Everyone had a valid reason for their definitions, as the logic was based on their requirements. But without shared definitions, it meant more meetings and clarifications.
Even if you have a data dictionary or documentation, it won’t automatically fix things. You have to reinforce consistent use, update them regularly, and explain them in meetings (over and over again).
7. “Once a report is built, it can be reused.”
This one is a maybe.
Even if a report is reusable, you’ll likely have to revisit it sooner than you think. It's not just one and done.
Why?
Because metrics change, stakeholders change, and priorities change.
You’ll inherit reports with logic that doesn’t make sense, or SQL files that work but have no documentation, or worse, Excel reports with layers of hidden filters and color-coded notes.
I’ve spent full weeks of investigation just to figure out what an old report was doing and whether it could be trusted going forward. And if it can't, the effort to fix it is often not worth it, so it ends up being a full rebuild. A lot of time is spent on investigation and analytical deep dives.
8. “You’ll mostly be working on exciting new projects.”
Nope. As I mentioned a few times, a lot of the job is maintenance of the current system.
You could be doing a lot of things like:
Fixing broken pipelines.
Updating reports that stopped running.
Explaining why this week’s numbers don’t match last week’s.
Responding to the same five questions from different people.
It’s this behind-the-scenes, invisible work that no one notices or gives recognition for, but it's some of the most important work.
Keeping the data reliable and accessible is just as valuable as delivering new insights, and most of the time, that’s what your team needs more of.
9. “Data tells the whole story.”
Data tells you what happened, but it doesn’t always tell you why.
A spike in traffic could be from a new campaign, a bot, or even a pricing glitch.
A drop in sales might not show up in the data if it’s tied to seasonality or a supply issue.
You need context.
Our job as data analysts is to provide those insights and figure out what's driving the change, connect with the right people to validate assumptions, and explain what matters to the business.
10. “Once the numbers are correct, your job is done.”
Even if your output is technically correct, your job isn’t over.
You still need to:
Explain the logic clearly.
Present the findings in a way that makes sense to the various stakeholders.
Build people's trust in the results.
Sometimes, train people on how to use the report.
Create documentation if not already done. (This part can take a lot of time, but it's critical.)
I've held many training sessions to help new stakeholders navigate a dashboard. Just sending a link to a dashboard and saying “here you go” isn’t enough. There will be questions, and a live walkthrough is almost always the best method.
If You’re Just Starting Out in Data Analytics
If you're early in your data career or transitioning from another field, it’s easy to feel frustrated when the work doesn’t match what you imagined.
But the messy logic, the clarifying questions, and the maintenance work are what make you better at your job. They’re how you learn to think critically, navigate ambiguity, and make data more usable for your team.
I learned so much more from debugging someone else's query or fixing an issue in a legacy dashboard, because I had to dissect each layer, logically, and find the solution.
It's a skill that’s hard to teach but incredibly valuable once you have it, and you gain it best from experience.
So don't feel disappointed if your expectations about data analytics don't align with reality. If you read this whole post, then you will be able to go into your first (or next) role with that much more understanding of what the role might actually require.
And hey, maybe it will help you confirm if you are interested in the field, after all.
Which of these misconceptions is the most surprising to you?
Or if you’re already working in data, what’s one misconception you had before you started?
Share your experiences in the comments below! I'd love to hear your thoughts.
Enjoyed this post?
I write about data, career transitions, and making analytics easier to understand.
Subscribe to my newsletter to get the latest posts.
If you want more content, I post regularly on LinkedIn, so connect and say hi!
