← All Kits · All Guides

What Is Data Analysis?

A starting point for people brand new to data work: what the job is, what the jobs are like, and what to learn first · Part of the Analyst Prep Kit

By the end of this page you will have done a real piece of data analysis. It is a small one, on paper, with arithmetic you can do in your head. You will also know what the actual jobs look like hour by hour, which is the part most beginner articles skip, and what to learn first if you want one.

The work itself is four moves. You start with a question that has a decision behind it. You get the records of what happened. You split those records into groups and compare the groups. Then you say what to do about it. Everything else, every tool and every job title, is a variation on those four moves.

What data analysis actually is

Data is just a record of something that happened. A receipt is data. A timestamp on a door badge is data. A row saying customer 4471 cancelled on March 3rd is data.

Analysis is what you do to a pile of those records to answer a question. Usually the question is a comparison. Which group is bigger? Which one is growing? Which one costs us money?

Here is the part that makes it a job rather than a hobby. A single record tells you nothing useful. One customer cancelled, so what. Ten thousand records have a shape to them, and the shape is only visible once you group them. Grouping is the whole trick. You take rows that are alike, put them in a bucket, and count the buckets.

One word you will see everywhere: a metric. A metric is a number you decided to track, with a definition attached. "Sales" is not a metric until someone says whether it includes refunds. Half of all analysis arguments are really arguments about a definition, and the guide on defining metrics is entirely about that.

A worked example you can follow on paper

A coffee shop owner has a question with a decision behind it. She is paying staff for two extra hours, one at each end of the day. She can only afford one. Should she open at 7am, or stay open until 8pm?

Stop for a second and decide what you would want to know to answer that. Not how you would calculate it. Just what you would need to see. Hold onto your answer and compare it to the four steps she takes.

She has a till record of every sale for the last three months. That is about 1,200 rows, and every row looks like this:

date         time     item        amount
2026-04-02   07:14    latte       4.50
2026-04-02   07:22    croissant   3.20
2026-04-02   19:41    tea         2.80

Nobody can read 1,200 rows. So she groups them. Every sale before 8am goes in one bucket. Every sale after 7pm goes in the other. Then she adds up the amounts in each bucket.

That is a complete analysis. Four columns, two rows, and a decision falls out of it: open early. The morning hour brings in close to four times as much per day as the evening hour.

Notice what you did not need. No statistics. No machine learning. No forecast. You grouped rows and compared the groups, which is what the overwhelming majority of paid analysis work is.

Where data analysis gets used

Anywhere someone keeps records and has to make a choice. That is broader than "tech company", and the everyday version is far more common than the famous version.

Every one of those is the coffee shop. Take the records, split them into groups, compare the groups, recommend a change.

The four steps, in order

Every analysis you will ever do is these four steps. The step names change between companies. The order does not.

The tools, and the order to learn them

Guess the order first. Excel, SQL, a visualisation tool, Python. Which comes first, and which can wait longest? Most people put the wrong one last.

The tools do the four steps for you at larger sizes. That is all they are. There is a sensible order, and it is not the order the job ads imply.

Learn them in that order. Spreadsheets and SQL cover most entry-level work on their own. Python is genuinely useful and it is also the most common way beginners stall out for six months without producing anything anyone can look at.

When the obvious answer is wrong

Here is the thing that makes analysis a skill rather than a lookup. The number for the whole group can point one way while every subgroup points the other way.

Say whether you believe that before reading the example. A hospital has a worse survival rate than another one overall, and yet does better with every single type of patient. Possible, or a mistake in the arithmetic?

A made-up example first, so the mechanic is clear. Two hospitals, and you want the one more likely to get you home alive.

Hospital B looks better overall, 78% against 72%. But A is better in both of the groups it actually treats, 95% against 90% and 60% against 55%. B simply receives twice as many easy cases. The overall number is measuring who walks in the door, not what the hospital does.

This is not a curiosity. It happened in public, on real data, in 1973. The University of California, Berkeley looked like it was admitting men at a much higher rate than women to graduate study: 8,442 men applied and about 44% got in, against 4,321 women and about 35%. Three researchers then split the numbers by department, and the pattern largely vanished. Women were applying in far greater numbers to the departments that admitted the smallest share of anyone (Bickel, Hammel & O'Connell, 1975, Science 187(4175), 398–404).

One habit protects you from this: after you compare two groups, split them again and check the answer survives. That is it. It costs one extra pivot table.

The jobs, and what the day actually looks like

Job titles in this field are not consistent between companies. The same work is called three different things, and the same title means three different jobs. So the table below describes the work rather than the label, and gives a rough split of where a week actually goes.

On the week splits: these are my estimate from job postings, from the research cited below, and from doing the work. They are not survey figures. Treat them as the shape of the week, not a measurement of it.

The pattern across all six: preparing data takes more of the week than analysing it. That is not a sign of a badly run company. It is the job.

On pay, I would rather point you at the source than repeat a number from a salary blog. The US Bureau of Labor Statistics publishes median pay, expected growth and typical entry education for each of these, and it is updated yearly: bls.gov/ooh. Search there for "data scientists", "management analysts", and "operations research analysts", since those are the categories that cover most analyst work.

Where these numbers come from

The claim that data preparation eats the week is not folklore. Researchers interviewed 35 analysts at 25 organisations, in sectors including healthcare, retail, marketing and finance. Finding the data, cleaning it and working out what is in it came up again and again as the recurring pain points of the job, across every kind of analyst they spoke to (Kandel, Paepcke, Hellerstein & Heer, 2012, IEEE Transactions on Visualization and Computer Graphics 18(12), 2917–2926).

The same study found analysts split into three groups by how they work: people who write code freely, people who write scripts, and people who work inside an application such as Excel or a dashboard tool. All three are real analyst jobs. You do not have to be the first kind.

A later study interviewed thirty professional analysts about exploration specifically. It found no single tidy pipeline. Sometimes exploration is a warm-up before a directed analysis, and sometimes finding something interesting is itself the goal, and analysts disagree with each other about whether that second one counts (Alspaugh, Zokaei, Liu, Jin & Hearst, 2019, IEEE Transactions on Visualization and Computer Graphics 25(1), 22–31).

That is worth holding on to as a beginner. The four steps are the right order to learn. In real work you will go back to step one halfway through step three, because the data told you the question was wrong. That is the work going well, not badly.

How to get into the field

The barrier is not intelligence and it is usually not a degree. It is that hiring managers cannot tell from a certificate whether you can actually do it. So the whole plan is aimed at producing something they can look at.

1. Get comfortable in a spreadsheet first. Pivot tables, SUMIFS, VLOOKUP or XLOOKUP, and basic charts. A week or two. This is genuinely most of step three, and it is on almost every job description.
2. Learn SQL next, and go further than the basics. SELECT, WHERE, GROUP BY, and then joins. Joins are where beginners quietly lose or duplicate rows, and they are the single most tested topic in analyst interviews. Budget a month of real practice.
3. Do one project on data you actually care about. Not the Titanic dataset. Something you have an opinion about: your city's open data, a game you play, your own spending. Caring is what gets you through the boring cleaning part.
4. Write the project up so a stranger can follow it. State the question, show the data's problems, show the comparison, state the recommendation, and state what would make you wrong. This document is your qualification. It is what actually gets read.
5. Publish it on GitHub. A link beats a bullet point on a résumé. The Git guide covers this from zero.
6. Add a dashboard tool only if the postings you want ask for it. Read ten real job ads in your city first. Let them tell you whether to learn Power BI or Tableau, instead of guessing.
7. Practice explaining out loud. Interviews are mostly "walk me through a time you found something surprising." Say your project's story to a person who does not work in data, and cut anything they glaze over at.

Two things to skip early on: a second certificate before you have a first project, and Python before SQL. Both feel productive and both delay the thing that gets you hired.

A cheat sheet

What to read next

Each of the four steps has a guide that goes deeper. In order:

• Step one, pinning down the question: Turning fuzzy questions into measurable definitions and picking cutoffs you can defend.
• Step two, looking at the data: Why exploratory data analysis matters, and how to set up a SQL database when the file gets too big.
• Step three, grouping and comparing: COUNT in SQL, the CASE expression, and joins without losing or doubling rows.
• Step four, saying what it means: documenting limitations and building a dashboard and story.
• When the tools fight back, which they will: Technical tenacity.

A question, if you have a minute. What is the first question you would want to answer with data, from your own life or your own job? Not a practice dataset. The real one you already wonder about. That question is a better starting project than anything I could assign you, and I read every reply.

References

• Bickel, P. J., Hammel, E. A., & O'Connell, J. W. (1975). Sex bias in graduate admissions: Data from Berkeley. Science, 187(4175), 398–404.
• Kandel, S., Paepcke, A., Hellerstein, J. M., & Heer, J. (2012). Enterprise data analysis and visualization: An interview study. IEEE Transactions on Visualization and Computer Graphics, 18(12), 2917–2926.
• Alspaugh, S., Zokaei, N., Liu, A., Jin, C., & Hearst, M. A. (2019). Futzing and moseying: Interviews with professional data analysts on exploration practices. IEEE Transactions on Visualization and Computer Graphics, 25(1), 22–31.