What a Data Analyst Actually Does All Day
Strip away the job title and the daily list is fairly consistent across companies. You write SQL to pull numbers, you keep a few dashboards updated, you answer one-off requests from people who 'just need a quick number,' and you explain what the numbers mean to people who have never joined two tables in their life. The glamorous part — finding a hidden insight that saves the company — happens sometimes, but it is a small slice. Most days are plumbing and communication with a little analysis in the middle.
I usually end a day having written more Slack messages than lines of analysis. That is not a failure; it is the job. The analysts who last are the ones who treat 'explain it so a salesperson gets it' as a core skill, not a chore.
A Rough Time Budget, Not a Perfect Plan
No two days are identical, but the proportions are stable. Here is the breakdown from a normal week of mine, rounded. Meetings and check-ins eat the most time, then SQL and data pulls, then dashboards and cleanup, then ad-hoc requests, and finally the analysis itself. If you are surprised that 'analysis' is not at the top, you now know the honest shape of the job.
One team standup, one stakeholder sync, plus comments in Slack and Jira. This is where scope gets set and where 'we need a number by Friday' turns into a real request with a definition of what 'the number' means. Skipping these to write code saves time today and costs more later when the number does not match what people expected.
Writing new queries, debugging a JOIN that returns too many rows, and reshaping data so it lines up. I spend most of this on the debugging, not the first draft. A query that looks right on the screen often produces nonsense until I check row counts and duplicates.
Refreshing a revenue dashboard, checking whether last night's pipeline ran, and chasing a source table that changed shape. A column renamed by an upstream team can silently break a chart, so a chunk of every day is verifying that what is displayed is still true.
A project manager asks for a quick look at signup trends. A marketer asks for a breakdown by channel. Each one is 'quick' on its own, and together they fill a big chunk of the afternoon. I keep a template of common queries so the repetitive ones take five minutes instead of forty.
The focused work where I dig into a real question, test a hypothesis, and produce something a stakeholder can act on. This is the satisfying part, and it is smaller than most people expect. Guarding this hour is the single best habit I have for doing meaningful work instead of only busywork.
9:00 — Standup and the Day Gets Its Shape
The standup is short, usually fifteen minutes. Each person says what they did yesterday, what they are doing today, and what is blocking them. My updates are concrete: 'finished the refund reconciliation, the discrepancy was a duplicated feed, blocked on access to the new payments table.' After standup I check Jira and Slack for anything that changed overnight, then decide what actually matters before the requests start coming.
Standup is the cheapest place to catch scope problems. I recommend saying the number you are about to produce out loud: 'I am pulling total signups for Q3 by channel.' If a stakeholder hears that and replies 'oh, I meant unique users,' you just saved yourself an afternoon. Define the metric at the start and the day goes smoother.
10:00 to 12:30 — SQL, and the Query That Would Not Cooperate
The morning block is when I do the real query work, before meetings pile up. A recent one: the product manager wanted churn for the last 90 days, by plan tier. That sounds like a single query, but it turned into three because the events table did not have a clean 'user churned' flag. I built it from a subscriptions table with columns subscription_id, user_id, plan_tier, started_at, and status. The status column had 'canceled', 'active', and, annoyingly, 'canceled_trial', which is not real churn.
SELECT plan_tier, COUNT(DISTINCT user_id) FROM subscriptions WHERE status = 'canceled' AND canceled_at >= date('now','-90 days') GROUP BY plan_tier. Straightforward, but it counts trial cancellations as churn, which inflates the number. The first draft of any query is usually wrong in a way you only see once you know the data.
I run SELECT COUNT(*) and COUNT(DISTINCT user_id) before and after adding a JOIN. Yesterday the orders table had 30,000 duplicate rows from a double-run of the nightly import, so any JOIN against it came back inflated. I usually catch this by comparing row counts — if a LEFT JOIN triples the rows, I have a duplicate key problem and stop before building charts.
I added WHERE status = 'canceled' AND plan_tier != 'trial' AND refunded = 0. A refunded cancel is not churn either; the customer left for a billing reason. Each filter is a business decision I confirm with the project manager, not something I guess. Getting the definition right is half the job.
I posted the final number with a one-line note: 'Churn for the last 90 days is 4.8%, and that excludes trials and refunds. If you want those included, the number is 6.2%.' Stakeholders trust the number more when they see the edge cases were handled. For a fuller walkthrough of this kind of query, the SQL for data analysis guide covers the exact patterns.
When a query returns a suspiciously clean result, assume the bug is in the definition, not the syntax. In my experience most 'wrong numbers' happen because the query counted something that should have been excluded, not because the JOIN failed. Pull the raw rows for the biggest group, eyeball ten of them, and the error shows itself.
Lunch, and the Triage Queue
By one o'clock the ad-hoc requests have piled up. A project manager wants a quick look at signup trends. A marketer asks for a channel breakdown. A salesperson needs a number for a call at three. None is urgent alone, but together they fill the afternoon. I sort them by impact and effort: a five-minute pull that unblocks a decision goes first; a forty-minute build that nobody asked for goes last, or I push back.
This triage is the part of the job nobody lists in the job description. I usually spend the first ten minutes after lunch just answering 'can you quickly...' messages, most of which are variants of queries I already have in a template file. Keeping those templates is how I protect the afternoon for real work.
2:00 — Explaining a Number to a Non-Technical Stakeholder
A vice president asks why revenue on the dashboard is down 5% this week. The temptation is to dump a table. The better move is one sentence: 'Revenue is down because the team paused the paid campaigns for two days, and the dip matches the drop in sessions.' I bring the chart, point at the dates, and leave the SQL out of it unless they ask. This is a skill, and it is the difference between being seen as a helper and being seen as a bottleneck.
When the stakeholder wants more, I walk through the actual numbers: sessions fell from 42,000 to 39,900, the conversion rate held steady at 2.1%, so the drop is volume, not performance. That decomposition — split a scary total into a volume effect and a rate effect — answers 'why' faster than any chart alone.
4:00 — Dashboard Health Check and Data Quality
The end of the day is cleanup and verification. I refresh the main revenue dashboard and check that the numbers match the source. This is where the real data quality work happens. The revenue dashboard is a simple bar chart by week with a line for target, built from the orders table filtered to status = 'paid' and refunded = 0.
I run a quick row count on the orders table and compare it to yesterday. If it is 30,000 rows higher than expected, the import probably duplicated, and I flag it before anyone reads the chart as real. Catching this at 4:00 beats a stakeholder catching it at the 9:00 exec meeting.
I write one query that sums revenue by week and compare it to what the dashboard shows. If they disagree, the dashboard filter is wrong, not the data. This sounds obvious, but I have spent more time than I like discovering the chart was filtering on the wrong status value.
A one-line note in the team channel: 'Payments table got two new columns today, dashboard unchanged.' If a rename or a schema change is coming, I write it down now so next week is not a surprise. The how to choose a data tool stack guide goes deeper on why this maintenance work matters as much as the build.
Schedule fifteen minutes at the end of the day for data quality, not at the start. In my experience the pipeline breaks overnight, so checking in the morning means a broken dashboard has already been seen by the morning crew. A late-day check catches the break before it reaches anyone. If you keep a daily log of what changed, you will solve next week's mystery in minutes.
The Skills That Make These Days Bearable
None of the above is rocket science, which is the point. The day is survivable when three things are solid: SQL you can write without looking things up, spreadsheets for the fast answer, and the ability to say 'no' to a request with a reason. I have seen people burn out on the job because they could not protect their time, not because the queries were hard.
If you are building toward this role, the foundations are SQL and Excel, then a BI tool. The how to become a data analyst path orders those for you. For the spreadsheet half, the Excel for data analysis guide covers the 20% of Excel that shows up every day — pivot tables, SUMIFS, XLOOKUP, and filters.
Your Next Step This Week
If you want to know whether this day appeals to you, run a one-week experiment. Spend an hour each day pulling numbers from a real dataset and explaining them out loud to a friend or a rubber duck. Write one SQL query that answers a question, check the row counts, and write a two-sentence summary a non-technical person would understand. If you enjoy the explaining as much as the querying, the job will not feel like a grind. If you dread the explaining, that is the part you need to practice before you commit.
