Most people entering analytics believe the job is about knowing SQL and Python. It is not. The job is answering business questions under uncertainty, and the tools are just the vehicle. That distinction explains why two candidates with identical tool stacks get offers a year apart: one can say "revenue dropped 8% because acquisition mix shifted toward a low-retention channel," the other can only say "I wrote a JOIN."
Below is a practitioner's view of the field: one full walkthrough of a real analytical task, the places where the method itself breaks, and an honest map of the learning paths — self-study, courses, and practice — with their real costs.
What an analyst actually produces
An analyst's output is a decision, not a query. Every deliverable — a dashboard, a memo, a one-line Slack message — is an argument of the form: here is what happened, here is the most likely cause, here is what I'd do, here is how confident I am.
The mechanism is a chain of narrowing:
- Business question — vague by nature ("why did sales fall?")
- Metric definition — you choose what "sales" means and lock the definition
- Data source — you decide which table or system is authoritative
- Calculation — SQL, spreadsheet, or code
- Interpretation — you separate signal from noise and from seasonal effects
- Recommendation — you state what changes if the finding is wrong
Weak analysts start at step 4 and never revisit steps 2 and 5. That is where almost all expensive mistakes live.
One walkthrough, end to end
The task. An e-commerce team reports that monthly revenue fell from 1,000,000 to 920,000 — a drop of 80,000, or 8%. The head of growth wants to know why by Friday.
Step 1 — Decompose before you query. Revenue for a store equals orders × average order value (AOV). Splitting it first tells you where to look:
| Metric | Last month | This month | Change |
|---|---|---|---|
| Revenue | 1,000,000 | 920,000 | −8.0% |
| Orders | 10,000 | 8,800 | −12.0% |
| AOV | 100 | 104.5 | +4.5% |
Orders fell, AOV rose. The problem is traffic or conversion, not pricing. This single step eliminates half the possible causes before a line of SQL is written. Skipping it is the most common beginner failure: they open the orders table and start filtering.
Step 2 — Split orders by channel. Traffic sources rarely move together. Suppose paid social orders fell from 4,000 to 2,900 while organic stayed flat at 5,900. The drop is concentrated in one channel — a much smaller search space.
Step 3 — Separate volume from conversion. Paid social orders = clicks × conversion rate. If clicks fell 30% while conversion held steady, the cause is upstream: budget, bidding, or creative fatigue. If clicks were flat and conversion halved, the cause is on-site: a broken landing page, a checkout bug, a price change.
Step 4 — Check the boring explanations first. Was there a tracking change? A campaign pause? A holiday shift between months? An analyst who reports "the channel got worse" before checking whether the tracking pixel was redeployed will be embarrassed in the meeting.
Step 5 — Quantify the cost of the finding. If paid social clicks fell 30% because the daily budget was cut from 2,000 to 1,400 thirty days ago, the revenue loss is roughly proportional — and the recommendation writes itself: restore the budget or accept the lower revenue.
What breaks if you do it differently. If you skip decomposition and query raw orders, you may find a plausible cause in any channel (there's always one underperforming segment) and report a story that is coherent but wrong. The team spends a sprint fixing it, revenue doesn't recover, and the analyst's credibility is gone — not because the SQL was bad, but because the reasoning order was.
Where the method itself fails
The decomposition approach is not universal. Four scenarios where it breaks:
1. The metric definition silently changed. Revenue is "orders minus refunds," but the finance team moved refunds to a different period. The number drops with no underlying business change. Early signal: a drop that appears in the aggregate but in no single segment. If it's too late: rebuild the series under the old definition and present both — showing the artifact is more valuable than hiding it.
2. The data source stopped being authoritative. The warehouse table you rely on lags by 48 hours after an upstream migration. Early signal: totals that don't reconcile with the source system. If it's too late: always reconcile a headline number against a second source before presenting.
3. A/B test results that don't generalize. A test showed a 3% lift on a sample of 2,000 users over two weeks. Rolled out to everyone, the effect vanishes — because the test window overlapped a promotion or the sample skewed toward heavy users. Early signal: check segment-level results, not just the aggregate. If it's too late: run a holdout group on the rollout.
4. The question itself was wrong. Leadership asked "why did churn rise?" but the real issue is that a new pricing tier changed the customer mix. Early signal: the segment analysis shows the churn rate is flat within each tier while the mix shifted. If it's too late: present the mix effect explicitly — it reframes the question rather than dodging it.
Learning paths and their real trade-offs
There are three honest routes into analytics, and each has a cost that is rarely stated upfront.
Self-study. Free or cheap. You get flexibility and no obligation. You pay in feedback: nobody tells you your metric definition was wrong, your SQL is correct but your interpretation isn't, or your dashboard answers a question nobody asked. Beginners plateau precisely at the step where judgment matters — and judgment is what interviews test.
A structured course. Costs money and time, but supplies the missing feedback loop and a sequence. The Profession: Data Analyst — From Zero to Job Offer program is built around this: each block ends with a real case — a dashboard, a query, an analytical memo — so you practice the whole chain, not just the syntax. On asibiont.com the lessons are text-based and personalized to your level, and you can ask the course AI chat for feedback on a written answer, which is the closest thing to a reviewer most self-taught analysts ever get.
Practice-first. Get a junior role, an internship, or a volunteer data project and learn on the job. Fastest growth per month, but hardest to enter without a portfolio of decisions to show. It also depends on a mentor being present — many juniors spend a year building dashboards nobody reads.
| Path | Time to first offer | Cost | Main risk |
|---|---|---|---|
| Self-study | Variable, often long | Low | No feedback, plateau |
| Structured course | Predictable | Medium | Passive completion without practice |
| Practice-first | Fast if you get in | Opportunity cost | No mentor, low-value tasks |
The trade-off is not "which is best" but "which failure can you afford." If you can't afford to spend a year guessing, the feedback loop matters more than the price tag.
If you're also considering adjacent technical paths, the Full-Stack AI Engineer covers a different trade-off — deeper engineering, narrower business focus. And if spreadsheets are your weak spot, Family Budget Without Excel shows the same principle — automate the calculation, spend the time on interpretation.
Who this path suits — and who it doesn't
It suits you if: you enjoy ambiguity and like being the person who explains what happened; you're comfortable with numbers but not necessarily a math major; you can tolerate being wrong in public and correcting fast; you want a role that sits between engineering and business.
It doesn't suit you if: you want clean, well-specified tasks with a single right answer; you dislike writing memos and explaining findings to non-technical people; you expect the job to be mostly coding — it isn't, and the coding is a means to an end.
The course walks through exactly these calculations — decomposition, channel splits, experiment interpretation — with real cases and feedback on your decisions, and it closes with interview and test-assignment preparation. You can start at asibiont.com whenever you're ready.