Excel for Data Analysis: What Analysts Actually Use (and What They Skip)

Excel for Data Analysis: What Analysts Actually Use (and What They Skip)

Most Excel tutorials are built for the widest possible audience, which means they teach Excel as a product rather than as an analyst's tool. You get 400 functions, a chapter on macros, a section on conditional formattinExcel for Data Analysis: What Analysts Actually Use (and What They Skip)

Most Excel tutorials are built for the widest possible audience, which means they teach Excel as a product rather than as an analyst's tool. You get 400 functions, a chapter on macros, a section on conditional formatting colour scales, and no guidance on which of it you will ever open again.

Here's the actual answer to what Excel skills a Data Analyst needs: you do not need to learn all of Excel. You need to know which parts solve real analyst problems, and, just as importantly, the point at which Excel stops being the right tool for the problem in front of you. This guide is built around that distinction: what to learn, what to skip, and where the line sits. If you're still working out where Excel fits in the wider sequence, our step-by-step guide to becoming a Data Analyst in India sets out the full learning path this article sits inside.

If you only learn 7 Excel skills

Before the detail, here's the practical working set in one table. This isn't an exhaustive curriculum, it's the short list that covers most generalist analyst work.

The rest of this article expands on why these seven earn their place, what surrounds them, what you can reasonably skip, and where Excel's limits actually sit.

Why Excel survives, and what that actually means for you

There's a persistent story that Excel is on the way out, replaced by SQL and Python. It isn't, for a fairly simple reason: Excel is where the business keeps the data that doesn't live in the database. Budget assumptions, campaign trackers, vendor lists, targets agreed in a meeting, the mapping between an internal product code and a marketing name. None of that is in the warehouse. Someone will hand it to you in a spreadsheet, and you will need to join it to the clean data you pulled with SQL.

Excel is also the interface stakeholders trust. A finance manager will open your workbook and start clicking into cells to check your arithmetic. That's a feature, not an annoyance: it's how your analysis earns credibility with someone who can't read a Python notebook.

What employers are actually buying, though, isn't the tool. The World Economic Forum's Future of Jobs Report 2025 identifies analytical thinking as the single most sought-after core skill, with seven in ten employers calling it essential. Excel is one of the places you demonstrate that thinking, not the thing being tested. That's the real argument against memorising the function list: it optimises for the wrong signal.

The working set, in detail

Everything below expands on the four skills from the table above that carry the most weight day to day.

Lookups: default to XLOOKUP, understand INDEX MATCH

A lookup answers a join question: this table has customer IDs and spend, that table has customer IDs and city, give me spend by city.

XLOOKUP is the sensible modern default. Microsoft's own documentation recommends it over VLOOKUP as an improved version that works in any direction and returns exact matches by default. Those two differences alone remove the two most common lookup bugs.

excel

=XLOOKUP(A2, customers[customer_id], customers[city], "Unmapped")

Four arguments: what you're looking for, where to look, what to return, and what to show when there's no match. That fourth argument is the one beginners skip. Without it, a failed lookup returns #N/A, which then poisons every SUM downstream. With "Unmapped" you get a visible count of unmatched rows, which is itself a finding. If 8% of your orders have no mapped city, that's a data quality issue worth raising before you present anything.

The judgment call here mirrors a LEFT JOIN decision in SQL: you have to decide what unmatched rows mean, and whether dropping them silently would change the answer. If joins are still shaky for you, the essential SQL skills and query guide covers the same logic in its native setting.

INDEX + MATCH is the older two-function equivalent:

excel

=INDEX(customers[city], MATCH(A2, customers[customer_id], 0))

Worth learning anyway, for two practical reasons. XLOOKUP isn't available in Excel 2016 or Excel 2019, so any organisation on an older Office installation, or handling files built by someone using one, will need it. And it's a common interview question, precisely because it separates people who understand why a lookup works from people who've only memorised XLOOKUP's syntax.

SUMIFS and COUNTIFS: the conditional aggregate

These answer the "how much, filtered by what" question directly, without building a full Pivot Table.

excel

=SUMIFS(orders[order_amount],
        orders[region], "West",
        orders[order_date], ">="&DATE(2026,7,1),
        orders[order_date], "<="&DATE(2026,7,31))

Total July revenue in the West region. Note the ">="&DATE(...) pattern, concatenating an operator with a date function, rather than typing ">=01/07/2026" as text. Hard-coded date strings can silently misread on a machine with different regional settings, and that failure won't announce itself. Your number just changes.

Use SUMIFS when you need a single figure for a summary cell or a chart. Use a Pivot Table when you need the full breakdown.

Pivot Tables: the highest-return skill in Excel

If you learn one thing properly, learn this. A Pivot Table takes a flat table and answers grouping questions in seconds: revenue by region by month, orders by category by channel, average basket size by customer tier. It's Excel's equivalent of GROUP BY, and it's what a Pivot Table is for: answering "what happened?"

What separates a fast analyst from a slow one isn't building the pivot, it's handling the follow-ups. A sales manager asks for revenue by region. You deliver it. They'll then ask, roughly in this order: is that up or down on last month, which products drove it, and is one large customer distorting the total. If you built the pivot from a clean source table, all three are drag-and-drop. If you built it from a manually filtered copy-paste of the data, you start over.

A few habits that save real time:

• Build pivots from an Excel Table (Ctrl+T), not a fixed range, so new rows are picked up automatically on refresh.

• Try "Value Field Settings → Show Values As → % of Column Total" before reaching for a formula. Share-of-total is often what the question actually meant.

• Use slicers rather than filters when someone else will open the workbook. Filters are easy to miss; a stakeholder reading a filtered pivot without noticing is how a wrong number reaches a leadership deck.

Power Query: cleaning that answers "how do I repeat this?"

Where the Pivot Table answers "what happened," Power Query answers "how do I clean and repeat this process." That distinction is the reason it's worth the effort once your basics are steady.

Manual cleaning produces a clean file, once. Power Query produces a clean process: you record the transformation steps a single time, and the following month you drop in the new file and hit refresh. Splitting columns, trimming whitespace, changing data types, unpivoting a cross-tab report that finance sent with months as columns, appending twelve monthly files into one table: all of it becomes a query you run again rather than work you repeat.

It's also the closest thing in Excel to how a real data pipeline thinks, which makes it a natural bridge into SQL later, the third stage in the progression, where the question shifts again to "how do I retrieve and analyse the data at the source?" If the words database and warehouse are still fuzzy, this primer on what a DBMS is and how it works is a short detour worth taking before you start writing queries.

What analysts skip, and what depends on the role

This is the part most tutorials leave out, because a longer syllabus sells better. The table below reflects what a generalist Data Analyst role typically doesn't require. It isn't a claim that these features are useless everywhere.

On the first row: if automation is the part of the job that appeals to you, that energy is better spent on Python than on VBA. Our breakdown of the Python skills every Data Analyst needs is deliberately scoped to analyst work rather than general software development, so you can see how small that surface area really is.

The caveat worth stating plainly: if you're aiming specifically at finance, FP&A, BFSI reporting, or an operations team running on an existing VBA estate, some of these move back onto your list. This table describes a general Data Analyst path in a product or business-analytics setting, not every Excel-adjacent role.

Where Excel breaks: three ceilings, not one number

Interviewers who ask about Excel's limits are usually probing for judgment, not the row-count trivia. There are three separate ceilings worth knowing apart.

The performance ceiling. A worksheet technically holds 1,048,576 rows, but that number is rarely where the real limit sits. Performance depends far more on formula complexity, the number of volatile or array formulas, workbook size, whether Power Query or the data model is involved, and the hardware you're on. A workbook with 300,000 rows and a column of recalculating XLOOKUPs can become unusable long before the row limit is anywhere close. The practical rule: if you're waiting on the calculation, you've already outgrown the tool for this task, regardless of what the row count says.

The silent ceiling. Excel's real risk isn't size, it's that mistakes don't announce themselves. This is a well-studied problem: EuSpRIG's summary of the spreadsheet-risk research literature notes that the majority of audited spreadsheets contain errors, and because spreadsheets are rarely tested, those errors tend to persist undetected. A mistyped range in one formula can produce a number that looks entirely plausible in a deck.

The defence isn't carefulness (the same body of research finds that carefulness alone doesn't meaningfully reduce error rates). It's structure:

• Sanity-check totals against a known figure before presenting anything. If your workbook says July revenue was ₹4.2 crore and the finance dashboard says ₹3.8 crore, resolve the gap before the meeting, not during it.

• Keep raw data, working calculations, and the output view on separate sheets. Never edit the raw sheet directly.

• Count rows after every join and every filter. A lookup that quietly dropped 900 orders won't tell you on its own.

• Avoid hard-coded numbers inside formulas. =B2*1.18 is a bug waiting to happen; put the GST rate in a labelled cell and reference it, so it can be audited and updated in one place.

The repeatability ceiling. If you'll run this analysis again next month, and refreshing it takes more than a few clicks, Excel is quietly costing you time every cycle. That's the practical signal to move the cleaning into Power Query, or the extraction itself into SQL.

None of these three ceilings requires Excel to literally stop working before you should act on them. The signal is the workflow becoming slow, hard to audit, or hard to hand to someone else, not a crash.

Excel to SQL: a sequence, not a hierarchy

It's tempting to read "learn Excel first" as "master Excel, then start SQL." That's not quite the right takeaway.

Excel is a good starting point for most beginners: it's visual, forgiving, and close to how non-technical stakeholders already think about data. But SQL becomes necessary the moment your data lives in a database or warehouse rather than a file someone emailed you, which is true of most real analyst work past the first few weeks. Some roles, particularly at product or tech companies, will expect SQL from day one regardless of your Excel fluency.

The practical guidance: learn enough Excel to be productive, the working set above, plus Power Query, and then broaden into SQL rather than spending months chasing deeper Excel mastery. Going from "I can build a Pivot Table" to "I can build an unusual nested formula" has a much lower return than going from "I know Excel" to "I can also query a database directly."

If you want a concrete measure of what that second step is worth, work through the Top 100 SQL interview questions for Data Analyst interviews. Reading the first twenty will tell you more about the gap between your current Excel skills and a hiring bar than any syllabus can.

A worked example: which region actually underperformed

Say a regional manager asks: "West is down this quarter. What happened?"

Pivot Table, what happened. Pull the order-level data, one row per order, with region, date, product category, and amount. Build a Pivot Table: region on rows, order month on columns, sum of order amount as values, shown as both absolute and month-on-month change.

Analysis. West revenue is down 12% quarter on quarter. Add order count as a second value field, and something changes: order count is flat. Revenue fell while the number of orders held steady. So this isn't a demand problem. Add average order value: it dropped from ₹3,400 to ₹2,990. Drag product category into rows, and the decline sits almost entirely in one high-value category.

Insight. West didn't lose customers. It lost the high-value product mix in one category, while overall order volume held. That's a different problem from "the West region is struggling," and it changes who should be asked next.

Business decision. The question for the manager is now specific and answerable: did that category go out of stock in West, did a competitor undercut it there, or did a discount campaign shift the mix? Each has a different owner and a different fix.

The skill on display here isn't knowing Pivot Tables. It's turning a vague worry into a testable, specific explanation, which is the actual work an analyst is paid for, regardless of which tool does the arithmetic.

Common mistakes

• Learning formulas as a list instead of by job. Nobody needs to know INDIRECT. Everybody needs to know which of several aggregation approaches fits the question in front of them.

• Analysing on top of the raw data. Inserting a helper column into the sheet you were sent means you can no longer prove what the original said.

• Merged cells anywhere near data. They break sorting, filtering, and Pivot Tables. Use "Center Across Selection" for formatting instead.

• Treating #N/A as noise to be wrapped in IFERROR. IFERROR hides the failure. Investigate first, then handle it deliberately.

• Dates stored as text. If a date column left-aligns by default, Excel doesn't recognise it as a date, and every downstream date calculation is wrong. Check this early.

• Building a polished dashboard on a source table that can't be refreshed. The dashboard loses most of its value the following month.

• Staying in Excel out of comfort rather than fit. Rebuilding the same monthly report by hand for a year has a real cost, even if it doesn't feel urgent week to week.

Excel and AI, realistically

AI assistants are useful for Excel work: generating a formula from a plain description, debugging one that's returning the wrong value, or explaining what an inherited formula is actually doing. That's a real time saver, and there's no reason to be precious about using it. Formula syntax was never the valuable part of the job.

What these tools can't do reliably is judge your data. An assistant has no way to know that your lookup silently dropped 900 orders, that a supposedly clean column mixes two date formats, or that the total it produced doesn't reconcile with the figure finance is using. It has no view of the business context that makes a number right or wrong.

So the practical split holds: let AI draft the formula or explain the syntax. Keep verification, row counts, and the judgment of whether a result makes sense on your side. That division doesn't change as the tools get better; if anything, it becomes more important, since a fluent, confident wrong answer is easier to generate at speed than it used to be. We've written about where that line falls across the rest of the workflow in AI and GenAI tools changing analytics workflows.

Where to go from here

Get comfortable with the working set above, build one dashboard end to end from genuinely messy data, and then move toward SQL rather than continuing to go deeper into Excel. That's where the next real gain in employability tends to sit: SQL is what lets you retrieve and analyse data at the source, rather than working from whatever someone else has already exported into a spreadsheet. If that's your next step, SQL for Data Analysts: Essential Skills & Query Guide is a reasonable place to continue, and the free live sessions are a low-commitment way to watch someone work through a real dataset before you attempt one yourself.

If you'd rather work through Excel, SQL, Python, and dashboarding in sequence with feedback on real business datasets, rather than piecing it together from scattered tutorials, the 20-week Data Analytics program covers that path, though plenty of people get there on their own with enough consistency.g colour scales, and no guidance on which of it you will ever open again.

Here's the actual answer to what Excel skills a Data Analyst needs: you do not need to learn all of Excel. You need to know which parts solve real analyst problems, and — just as importantly — the point at which Excel stops being the right tool for the problem in front of you. This guide is built around that distinction: what to learn, what to skip, and where the line sits.

If you only learn 7 Excel skills

Before the detail, here's the practical working set in one table. This isn't an exhaustive curriculum — it's the short list that covers most generalist analyst work.

The rest of this article expands on why these seven earn their place, what surrounds them, what you can reasonably skip, and where Excel's limits actually sit.

Why Excel survives, and what that actually means for you

There's a persistent story that Excel is on the way out, replaced by SQL and Python. It isn't, for a fairly simple reason: Excel is where the business keeps the data that doesn't live in the database. Budget assumptions, campaign trackers, vendor lists, targets agreed in a meeting, the mapping between an internal product code and a marketing name. None of that is in the warehouse. Someone will hand it to you in a spreadsheet, and you will need to join it to the clean data you pulled with SQL.

Excel is also the interface stakeholders trust. A finance manager will open your workbook and start clicking into cells to check your arithmetic. That's a feature, not an annoyance — it's how your analysis earns credibility with someone who can't read a Python notebook.

What employers are actually buying, though, isn't the tool. The World Economic Forum's Future of Jobs Report 2025 identifies analytical thinking as the single most sought-after core skill, with seven in ten employers calling it essential. Excel is one of the places you demonstrate that thinking — not the thing being tested. That's the real argument against memorising the function list: it optimises for the wrong signal.

The working set, in detail

Everything below expands on the four skills from the table above that carry the most weight day to day.

Lookups: default to XLOOKUP, understand INDEX MATCH

A lookup answers a join question: this table has customer IDs and spend, that table has customer IDs and city — give me spend by city.

XLOOKUP is the sensible modern default. Microsoft's own documentation recommends it over VLOOKUP as an improved version that works in any direction and returns exact matches by default. Those two differences alone remove the two most common lookup bugs.

excel

=XLOOKUP(A2, customers[customer_id], customers[city], "Unmapped")

Four arguments: what you're looking for, where to look, what to return, and what to show when there's no match. That fourth argument is the one beginners skip. Without it, a failed lookup returns #N/A, which then poisons every SUM downstream. With "Unmapped" you get a visible count of unmatched rows — which is itself a finding. If 8% of your orders have no mapped city, that's a data quality issue worth raising before you present anything.

The judgment call here mirrors a LEFT JOIN decision in SQL: you have to decide what unmatched rows mean, and whether dropping them silently would change the answer.

INDEX + MATCH is the older two-function equivalent:

excel

=INDEX(customers[city], MATCH(A2, customers[customer_id], 0))

Worth learning anyway, for two practical reasons. XLOOKUP isn't available in Excel 2016 or Excel 2019 — so any organisation on an older Office installation, or handling files built by someone using one, will need it. And it's a common interview question, precisely because it separates people who understand why a lookup works from people who've only memorised XLOOKUP's syntax.

SUMIFS and COUNTIFS: the conditional aggregate

These answer the "how much, filtered by what" question directly, without building a full Pivot Table.

excel

=SUMIFS(orders[order_amount],
        orders[region], "West",
        orders[order_date], ">="&DATE(2026,7,1),
        orders[order_date], "<="&DATE(2026,7,31))

Total July revenue in the West region. Note the ">="&DATE(...) pattern — concatenating an operator with a date function, rather than typing ">=01/07/2026" as text. Hard-coded date strings can silently misread on a machine with different regional settings, and that failure won't announce itself. Your number just changes.

Use SUMIFS when you need a single figure for a summary cell or a chart. Use a Pivot Table when you need the full breakdown.

Pivot Tables: the highest-return skill in Excel

If you learn one thing properly, learn this. A Pivot Table takes a flat table and answers grouping questions in seconds — revenue by region by month, orders by category by channel, average basket size by customer tier. It's Excel's equivalent of GROUP BY, and it's what a Pivot Table is for: answering "what happened?"

What separates a fast analyst from a slow one isn't building the pivot — it's handling the follow-ups. A sales manager asks for revenue by region. You deliver it. They'll then ask, roughly in this order: is that up or down on last month, which products drove it, and is one large customer distorting the total. If you built the pivot from a clean source table, all three are drag-and-drop. If you built it from a manually filtered copy-paste of the data, you start over.

A few habits that save real time:

• Build pivots from an Excel Table (Ctrl+T), not a fixed range, so new rows are picked up automatically on refresh.

• Try "Value Field Settings → Show Values As → % of Column Total" before reaching for a formula. Share-of-total is often what the question actually meant.

• Use slicers rather than filters when someone else will open the workbook. Filters are easy to miss; a stakeholder reading a filtered pivot without noticing is how a wrong number reaches a leadership deck.

Power Query: cleaning that answers "how do I repeat this?"

Where the Pivot Table answers "what happened," Power Query answers "how do I clean and repeat this process." That distinction is the reason it's worth the effort once your basics are steady.

Manual cleaning produces a clean file, once. Power Query produces a clean process — you record the transformation steps a single time, and the following month you drop in the new file and hit refresh. Splitting columns, trimming whitespace, changing data types, unpivoting a cross-tab report that finance sent with months as columns, appending twelve monthly files into one table: all of it becomes a query you run again rather than work you repeat.

It's also the closest thing in Excel to how a real data pipeline thinks, which makes it a natural bridge into SQL later — the third stage in the progression, where the question shifts again to "how do I retrieve and analyse the data at the source?"

What analysts skip — and what depends on the role

This is the part most tutorials leave out, because a longer syllabus sells better. The table below reflects what a generalist Data Analyst role typically doesn't require. It isn't a claim that these features are useless everywhere.

The caveat worth stating plainly: if you're aiming specifically at finance, FP&A, BFSI reporting, or an operations team running on an existing VBA estate, some of these move back onto your list. This table describes a general Data Analyst path in a product or business-analytics setting, not every Excel-adjacent role.

Where Excel breaks — three ceilings, not one number

Interviewers who ask about Excel's limits are usually probing for judgment, not the row-count trivia. There are three separate ceilings worth knowing apart.

The performance ceiling. A worksheet technically holds 1,048,576 rows, but that number is rarely where the real limit sits. Performance depends far more on formula complexity, the number of volatile or array formulas, workbook size, whether Power Query or the data model is involved, and the hardware you're on. A workbook with 300,000 rows and a column of recalculating XLOOKUPs can become unusable long before the row limit is anywhere close. The practical rule: if you're waiting on the calculation, you've already outgrown the tool for this task, regardless of what the row count says.

The silent ceiling. Excel's real risk isn't size — it's that mistakes don't announce themselves. This is a well-studied problem: EuSpRIG's summary of the spreadsheet-risk research literature notes that the majority of audited spreadsheets contain errors, and because spreadsheets are rarely tested, those errors tend to persist undetected. A mistyped range in one formula can produce a number that looks entirely plausible in a deck.

The defence isn't carefulness — the same body of research finds that carefulness alone doesn't meaningfully reduce error rates. It's structure:

• Sanity-check totals against a known figure before presenting anything. If your workbook says July revenue was ₹4.2 crore and the finance dashboard says ₹3.8 crore, resolve the gap before the meeting, not during it.

• Keep raw data, working calculations, and the output view on separate sheets. Never edit the raw sheet directly.

• Count rows after every join and every filter. A lookup that quietly dropped 900 orders won't tell you on its own.

• Avoid hard-coded numbers inside formulas. =B2*1.18 is a bug waiting to happen; put the GST rate in a labelled cell and reference it, so it can be audited and updated in one place.

The repeatability ceiling. If you'll run this analysis again next month, and refreshing it takes more than a few clicks, Excel is quietly costing you time every cycle. That's the practical signal to move the cleaning into Power Query, or the extraction itself into SQL.

None of these three ceilings requires Excel to literally stop working before you should act on them. The signal is the workflow becoming slow, hard to audit, or hard to hand to someone else — not a crash.

Excel to SQL: a sequence, not a hierarchy

It's tempting to read "learn Excel first" as "master Excel, then start SQL." That's not quite the right takeaway.

Excel is a genuinely good starting point for most beginners — it's visual, forgiving, and close to how non-technical stakeholders already think about data. But SQL becomes necessary the moment your data lives in a database or warehouse rather than a file someone emailed you, which is true of most real analyst work past the first few weeks. Some roles, particularly at product or tech companies, will expect SQL from day one regardless of your Excel fluency.

The practical guidance: learn enough Excel to be genuinely productive — the working set above, plus Power Query — and then broaden into SQL rather than spending months chasing deeper Excel mastery. Going from "I can build a Pivot Table" to "I can build an unusual nested formula" has a much lower return than going from "I know Excel" to "I can also query a database directly."

A worked example: which region actually underperformed

Say a regional manager asks: "West is down this quarter. What happened?"

Pivot Table — what happened. Pull the order-level data, one row per order, with region, date, product category, and amount. Build a Pivot Table: region on rows, order month on columns, sum of order amount as values, shown as both absolute and month-on-month change.

Analysis. West revenue is down 12% quarter on quarter. Add order count as a second value field, and something changes — order count is flat. Revenue fell while the number of orders held steady. So this isn't a demand problem. Add average order value: it dropped from ₹3,400 to ₹2,990. Drag product category into rows, and the decline sits almost entirely in one high-value category.

Insight. West didn't lose customers. It lost the high-value product mix in one category, while overall order volume held. That's a different problem from "the West region is struggling," and it changes who should be asked next.

Business decision. The question for the manager is now specific and answerable: did that category go out of stock in West, did a competitor undercut it there, or did a discount campaign shift the mix? Each has a different owner and a different fix.

The skill on display here isn't knowing Pivot Tables. It's turning a vague worry into a testable, specific explanation — which is the actual work an analyst is paid for, regardless of which tool does the arithmetic.

Common mistakes

• Learning formulas as a list instead of by job. Nobody needs to know INDIRECT. Everybody needs to know which of several aggregation approaches fits the question in front of them.

• Analysing on top of the raw data. Inserting a helper column into the sheet you were sent means you can no longer prove what the original said.

• Merged cells anywhere near data. They break sorting, filtering, and Pivot Tables. Use "Center Across Selection" for formatting instead.

• Treating #N/A as noise to be wrapped in IFERROR. IFERROR hides the failure. Investigate first, then handle it deliberately.

• Dates stored as text. If a date column left-aligns by default, Excel doesn't recognise it as a date, and every downstream date calculation is wrong. Check this early.

• Building a polished dashboard on a source table that can't be refreshed. The dashboard loses most of its value the following month.

• Staying in Excel out of comfort rather than fit. Rebuilding the same monthly report by hand for a year has a real cost, even if it doesn't feel urgent week to week.

Excel and AI, realistically

AI assistants are genuinely useful for Excel work — generating a formula from a plain description, debugging one that's returning the wrong value, or explaining what an inherited formula is actually doing. That's a real time saver, and there's no reason to be precious about using it. Formula syntax was never the valuable part of the job.

What these tools can't do reliably is judge your data. An assistant has no way to know that your lookup silently dropped 900 orders, that a supposedly clean column mixes two date formats, or that the total it produced doesn't reconcile with the figure finance is using. It has no view of the business context that makes a number right or wrong.

So the practical split holds: let AI draft the formula or explain the syntax. Keep verification, row counts, and the judgment of whether a result makes sense on your side. That division doesn't change as the tools get better — if anything, it becomes more important, since a fluent, confident wrong answer is easier to generate at speed than it used to be.

Where to go from here

Get comfortable with the working set above, build one dashboard end to end from genuinely messy data, and then move toward SQL rather than continuing to go deeper into Excel. That's where the next real gain in employability tends to sit — SQL is what lets you retrieve and analyse data at the source, rather than working from whatever someone else has already exported into a spreadsheet. If that's your next step, SQL for Data Analysts: Essential Skills & Query Guide is a reasonable place to continue.

If you'd rather work through Excel, SQL, Python, and dashboarding in sequence with feedback on real business datasets, rather than piecing it together from scattered tutorials, the 20-week Data Analytics program covers that path — though plenty of people get there on their own with enough consistency.