GROUND TRUTH · DATA & ANALYTICS

What Data Analyst Work Involves Beyond SQL and Dashboards

A perfectly correct calculation can still support a bad conclusion.

A database can hand you a correct number without giving you a reason to trust the story built around it. Professional data analysis is closer to investigation than reporting: defining the question, checking the data model, and knowing when the numbers do not deserve to be believed.

By Prashanth Jakkula · Published 10 September 2026 · Last reviewed 30 September 2026 · Researched from job postings, engineering references, and public practitioner accounts, then written and checked by the author before publication. AI tools may help with research and editing. See our Editorial Policy for how articles are produced and reviewed, or About HireSetu for who operates it.

There is a version of data analysis that is very easy to learn. Take a dataset. Write SQL. Group something by month. Calculate a percentage. Put the result into Power BI or Tableau. Add a few charts. Call out the biggest increase and the biggest decrease.

It feels like analysis because numbers have been turned into information. But there is a catch: a database can give you a number without giving you a reason to trust the story built around that number. That is where professional data analysis becomes much more interesting.

The common picture vs the real work

A manager rarely gives you a clean question

Suppose your manager says: "Customers are leaving. Find out why." That is the assignment. There is no table called reason_customers_left. There probably is not a column that neatly answers the question.

Before touching SQL, you have to decide what "leaving" means. Has the customer cancelled? Stopped purchasing? Stopped logging in? Failed to renew? Moved to a competitor? Those definitions can produce very different populations.

Then there is the word "why". Are you looking for a correlation? A pattern? A likely cause? A confirmed cause? A useful segment? The database will not make those decisions for you. Someone has to. And that is already analytical work.

The number you calculated may be perfectly correct

Here things get uncomfortable. Imagine your query shows that customers who use Feature A have a 72% retention rate, while customers who do not use it have a 43% retention rate.

You check your SQL. The joins are correct. The filters are correct. The calculation is correct. You publish: "Feature A increases customer retention."

The first half of that statement may be supported by the data. The second half may not be. Perhaps customers who are already highly engaged are the ones most likely to discover Feature A. Perhaps they have larger accounts. Perhaps they have been customers longer. Perhaps they came through a different acquisition channel.

You have found an association. You have not automatically found a cause. This is one of the biggest gaps between learning analytical tools and doing analytical work: a technically correct calculation can still support a bad conclusion.

Before you trust a table, find out what a row means

This sounds almost too basic. It is not. Suppose you are working with an orders table. What is one row? An order? An item inside an order? A payment attempt? A shipment? A status change?

Now imagine joining that table to customer data and counting rows. If the table contains multiple items per order, your "number of customers" can quietly become a count of order lines. The query runs. The dashboard loads. The number may even look believable. Nothing in SQL will stop you.

You need to understand the data model. This is why experienced analysts spend time asking questions that seem unrelated to visualisation:

• Where did this data come from?
• Which system created it?
• When is a record created, and when is it updated?
• What does each status mean?
• Can one entity appear multiple times?
• What happens when something is cancelled?

Without those answers, a clean query can produce a very clean mistake.

"Clean data" is not necessarily useful data

Data cleaning is often taught as if there is an obvious final state. Remove duplicates. Fix missing values. Standardise categories. Correct formatting. Then analyse. Real data does not behave so politely.

Imagine 15% of customer income values are missing. You remove those records. Your dataset now looks cleaner. But suppose most of those missing values belong to customers acquired through one particular channel. You have just changed the population.

Or perhaps the field became optional after a redesign of the registration process, so the missingness has a historical explanation. Or perhaps customers who do not provide the information behave differently from those who do, and deleting them distorts the result.

Sometimes missing information is a nuisance. Sometimes it is evidence about the process that created the data. The analyst has to figure out which one it is.

An average can hide an entirely different story

Suppose a company reports that average customer spending has fallen. That sounds straightforward. But split customers into new and existing groups and you discover something else: existing customers are spending more, new customers are spending less, and the company acquired a huge number of new customers this quarter, which moved the overall average.

The original number was not wrong. It was incomplete. This happens constantly when populations are combined. An overall average can conceal differences between regions, customer types, products, age groups or other meaningful segments.

The important question is not "what is the average?" It is "average for whom?" Sometimes the most useful analysis starts when you refuse to accept the first aggregate as the whole story.

Dashboards are where analysis becomes visible, not where it begins

A senior manager sees the final dashboard. They do not see the hours spent checking whether the metric was defined correctly. They do not see the argument over which date should count as the customer acquisition date. They do not see the investigation into why this month’s records suddenly doubled. They do not see the comparison between two systems that disagree by 4%.

They see a number on a screen. That number may represent a substantial amount of invisible reasoning.

So dashboard-building alone is not a definition of analytical ability. Visualisation is communication. It is important. But communication cannot repair an invalid analysis. A beautifully designed chart showing the wrong metric is still wrong.

Sometimes the data contradicts the story everyone expects

Imagine a company launches a marketing campaign. Management expects sales to rise. Sales do rise. The easy conclusion is: "The campaign worked."

A careful analyst might ask a few more questions. Did sales increase in regions where the campaign did not run? Did another promotion happen at the same time? Did prices change? Did a major customer place an unusually large order? Did the reporting system change? Did the campaign reach the customers being measured?

Maybe the campaign really did work. The point is not to become suspicious of everything. It is to avoid turning the first plausible explanation into the final answer. Good analysts are not paid to produce the story people hope to hear. They are paid to understand what the evidence supports.

Correlation is not automatically explanation

Two things change together, a graph shows a relationship, and the student concludes "A caused B." Another factor may exist. The relationship may be coincidental. The direction may be reversed. The data may be incomplete. Instead of asking "what conclusion can I make?", ask "what does the evidence allow me to conclude?" That difference prevents overconfident analysis.

The business question can itself be wrong

That part of the job matters more than it looks. Suppose a company asks: "Which marketing channel brings us the most customers?" You can answer it. But perhaps customer count is not the thing the company needs to optimise.

One channel might produce 10,000 customers who make one small purchase. Another might produce 2,000 customers who stay for three years. If the business cares about long-term value, the original question is incomplete. You can perform the requested analysis perfectly and still fail to help with the actual decision.

That is why experienced analysts sometimes push back on the question itself, not to make the project complicated, but because the wrong question can produce a perfectly correct answer that nobody should use.

Sometimes "I don’t know" is the best analysis

For someone starting out, this is probably one of the hardest lessons. You have been asked a question. You have access to data. You feel pressure to produce a result. But what if the available information is not good enough?

• Tracking started halfway through the period.
• The definition changed.
• Important records are missing.
• Two systems cannot be reconciled.
• The sample is too small.
• The data can show a relationship but not establish the proposed cause.

You could still create a chart. You could still produce a percentage. You could still write a confident paragraph. But the honest answer might be: "We cannot reliably answer this from the data we currently have."

A good analyst should be comfortable saying that, and explaining what would be needed to answer it properly. That is not a lack of analytical skill. It is analytical discipline.

Where SQL, Excel and Python fit

None of this makes technical skills less important. They are extremely important. You need to retrieve data efficiently, manipulate it, automate repetitive work where appropriate, and communicate findings clearly. SQL may be central to the role. Excel may still be used constantly. Python may become valuable for deeper analysis or automation. Visualisation tools may be part of everyday work.

But these tools do not decide what a metric should mean. They do not automatically recognise that your join changed the grain of the data. They do not know that a tracking event was introduced three months ago. They do not know whether a correlation has another plausible explanation. And they do not know whether the question you are answering is the question the business needs.

The tools execute. The analyst judges.

A better test of your analytical ability

Instead of measuring yourself only by how quickly you can write a query, take a simple dataset and try something harder.

Try this on one dataset

• Write down what one row represents.
• Define your metric before calculating it.
• Look for missing or duplicated records.
• Calculate the same business measure two reasonable ways and see whether the result changes.
• Break the population into meaningful groups.
• Find something surprising and investigate it.
• Then write down what your analysis cannot prove.

That last step is particularly valuable. Knowing the limits of your conclusion is part of knowing your conclusion. A fresher who can do that is already thinking differently from someone who knows how to make a dashboard.

The real job is closer to investigation than reporting

Data analysis is often introduced through tools because tools are easy to demonstrate. A course can teach you a SQL query in ten minutes, a chart in five, and a dashboard template on top of that.

What takes longer is learning how to sit with an ambiguous question and refuse to rush toward a convenient answer. Where did this number come from? What exactly are we measuring? Who is included? Who is missing? What assumptions are hiding inside this calculation? What else could explain the pattern? How confident should we be? And if someone makes a decision based on this result, what could make that decision wrong?

Those questions do not belong to Excel. They do not belong to SQL. They belong to the analyst. That is why knowing the tools is necessary, but it is not what makes someone good at data analysis.

The real skill is knowing when the numbers deserve to be believed, and when they do not.

Frequently asked

Should I still build dashboard projects for my portfolio?

Yes, but frame each around a decision. Show the question, the data problems you found, the checks you ran, and what the evidence did and did not support, not just the finished visuals.

Do I need machine learning to get a data analyst job?

Usually not for an analyst role. Strong SQL, clear reasoning about data quality and definitions, and the ability to turn a business question into an evidence-backed answer matter more.

All Ground Truth articles · Career Insights · Discover jobs · Companies