A Day in the Life of a Data Analyst

The job description said "drive insights to inform business decisions." Then your first Slack ping at 8:47am is "hey quick question — why is MRR off by $3K from last week's board deck?" and you spend the next ninety minutes proving the deck was right.

That gap between the JD and the day is why analyst attrition at SaaS companies runs roughly 22-28% annually. Nobody warned you the role is half SQL, half translation, and a quarter defending numbers you wrote three months ago. (Yes, that's 125%. The math is part of the problem.)

This is what a real Tuesday looks like for a Data Analyst IC at a B2B SaaS or mid-market company, 1-4 years in. Not the LinkedIn version. The actual one.

Why This Matters Now

Ad-hoc request volume has roughly doubled since self-serve BI tools went mainstream. Every PM thinks they need a custom cohort cut by Tuesday. Every VP has a hunch they want validated by Friday. The tooling promised democratized data and delivered a request avalanche.

The candidates who self-select into this job thinking it's a quiet desk where you build models all day quit inside eighteen months. The ones who stay learn to do something the JD never mentions: protect their thinking time while still feeling responsive. That's the actual senior skill.

If you're hiring, knowing this changes how you screen. If you're working as an analyst, naming the patterns makes them survivable. Let's walk the day.

8:00am — Dashboard Health Check

Before Slack opens, before the first stakeholder is awake, scan the six to eight dashboards your execs actually open. Not all twenty you've built. The ones that get clicked.

You're looking for three things:

Nulls where there shouldn't be any. A revenue number showing blank for yesterday. A signup count that says zero on a Wednesday.
Broken joins after last night's dbt run. A model failed silently and the dashboard is showing stale data with a fresh timestamp. This is the worst kind of bug because nobody notices until they make a decision on it.
Weird spikes. Traffic is 4x normal? Either marketing launched something nobody told you about, or a tracking event is double-firing. Both are worth a Slack message before someone else asks.

The whole sweep takes fifteen minutes if everything's clean. Forty-five if it's not. The point is to find the bug before the CFO opens the dashboard at 9:15am and pings you with "is this right?"

A clean morning check is invisible work. You'll never get credit for it. But the day you skip it is the day a board member sees broken numbers, and that day is much louder than the hundred quiet mornings before it.

9:30am — Ad-Hoc Request Triage

The Jira queue has eleven new tickets. Slack has six DMs. One VP texted your personal phone, which you regret giving him at the Christmas party.

Triage is sorting, not solving. Every request goes in one of four buckets:

10-minute pull. Someone wants a count, a list, a quick filter. Do these in line, post the answer in thread, move on.
2-day analysis. Real questions that need a model, a cohort, or a write-up. Schedule them.
Duplicate. Someone's asking what someone else asked last month. Find the old answer, link it, close the ticket. Politely.
Unclear. The ask doesn't say what decision it's feeding. These need a five-minute reply asking the question that saves you four hours.

That question is: "What decision will this change?"

Phrased nicely, it's: "Happy to dig in. Quick check first: what are you planning to do differently depending on what the data says?" If the answer is "nothing, I'm just curious," you can deprioritize honestly. If the answer is "we're deciding whether to kill the trial flow on Friday," you escalate it. Either way, you've done your job before writing any SQL.

A working intake template, paste this into your Jira/Linear/whatever:

**Decision this analysis will inform:**
**Date you need it by:**
**Who else is reviewing the result:**
**What you've already looked at:**
**Acceptable level of precision (rough estimate vs. audit-grade):**

Half the requests stop at field one because the requester realizes they don't have a decision yet. That's a feature.

11:00am — Mid-Day Requirements Interview

Thirty minutes on Zoom with a PM who said "I need churn data."

The real ask is always three layers deeper. Your job is to drill from vague to specific without making them feel dumb. The trick is to ask diagnostic questions, not interrogation questions.

A working flow:

Restate, then expand. "So you want to understand churn. To make sure I cut this right: are we talking customer churn, revenue churn, or logo churn? They move differently."
Ask the decision. "What are you going to do once you have this? Are you sizing a save-team headcount, or trying to find which segment to fix first?"
Define the cohort. "When you say 'churned customers,' do you mean canceled in the last 30 days, or canceled and didn't reactivate? And does downgrade count?"
Set a precision target. "Do you need this directionally right by EOD, or audit-grade for the QBR? The answer changes how I do this by about a day."

Most PMs don't want to look uncertain in front of leadership, so they ask for things in the language of the deck they have to present. Your job is to translate that back into a question SQL can answer. You're not undermining them by asking. You're protecting them from presenting a chart that doesn't say what they think it says.

Camellia's rule: never let a stakeholder leave a requirements call without you both saying out loud what the deliverable is, what the cohort is, and what decision it's feeding. If you can't fit that in one Slack message after the meeting, you don't have a spec yet.

1:30pm — Async With Eng and Product

The window between lunch and 4pm is when you do the work that nobody asks you for but that determines whether next quarter is survivable.

This is the async block. Three kinds of inputs:

dbt PR reviews. A data engineer changed how the fct_subscriptions model handles trial conversions. You read the diff. A sample comment that's actually useful:

This change looks right for new trials, but I think it'll
double-count any account that converts, downgrades, then
re-converts in the same quarter. We have ~40 of those a
quarter (checked in #data-quality last month). Can we add a
test on `subscription_id` uniqueness in the staging model
before this merges? Happy to write it.

Specific. References real data. Offers to help. Doesn't block the PR for vague reasons.

Product spec comments. A PM dropped a spec for a new onboarding flow. The event tracking section says "fire onboarding_completed when user finishes." You leave a comment: which step counts as "finishing"? What if they skip step three? Should we fire onboarding_completed for every flow variant or have separate events? Better to ask now than dig through bad data in six weeks.

Schema change flags. Engineering is renaming a column in production on Friday. You search every Looker explore, Hex notebook, and dbt model for that column name. Four dashboards will break. You message the eng lead with the list and either delay the rename or coordinate the cutover. This twenty-minute task is the difference between a quiet Saturday and a Saturday spent rebuilding executive dashboards while your kid watches TV.

This is where senior analysts earn their title. The IC writes the SQL. The senior catches the breakage three weeks before it happens.

4:00pm — End-of-Day Exec Data Pull

The CFO needs three numbers for tomorrow's board prep. They messaged you at 3:47pm. The board meeting is at 8am.

This is the moment SQL meets stakes. You query Snowflake (or BigQuery, or Postgres, whichever your company runs), and you double-check every number against last quarter's reported figures. If the new pull doesn't reconcile to the old number, you don't send anything until you understand why.

The deliverable isn't three numbers. It's three numbers plus context. A working format for the Notion or Confluence note:

**Q1 2026 quick-pull for board prep**

1. Net new ARR: $1.42M
   (vs. $1.38M reported in Q4 deck — +3%, in line)
   Caveat: includes 2 deals that close-dated 3/31 but
   booked 4/2; excluded from the strict-Q1 view below.

2. Logo churn rate: 4.1% (annualized)
   Strict Q1 view: $1.40M, 4.4%
   Pulled at 4:35pm 4/28; will refresh if you need before 8am.

3. Trial-to-paid: 18.7%
   (vs. 17.2% in Q4 — driven by the Feb pricing test cohort,
   which is a temporary lift, not a step change. Don't
   straight-line this one.)

Source models: fct_subscriptions, fct_trials, dim_accounts.
Ping me if anything in here doesn't match what you're seeing.

Four points, four lines of caveats. The CFO can present this without re-asking. Most importantly, when someone in the board meeting says "wait, that doesn't match what you said in February," the CFO has the answer pre-loaded.

This is the work that gets you promoted. Not the SQL. The four lines of context underneath it.

The Two Recurring Crises

Two patterns will eat your week if you let them. Naming them helps.

Crisis One: The Ad-Hoc Explosion

You said yes to a quick request on Monday. The requester told a peer you were helpful. Now four people are in your DMs by Wednesday. By Friday, you have eighteen tickets and no time for the strategic project your manager actually evaluates you on.

This is the duplicate-request loop. It compounds because saying yes is faster in the moment than setting a process, and because every "quick question" doesn't feel like a request. It just feels like a conversation.

The pattern that actually works:

Office hours, twice a week. A 60-minute block where anyone can show up with a question. Most "I need a quick number" asks fit in this format and don't need a Jira ticket at all.
Intake form for everything else. Linked in your Slack profile and in the channel topic. Includes the four-field template above. If someone DMs you, your reply is "great question, drop it in the form so I can prioritize it against the other twelve I have, here's the link."
A weekly digest of what you closed. Posted in #data on Friday. Three lines per closed ticket: who asked, what they wanted, what the answer was. Builds searchable history, reduces duplicate asks, and shows your team what you actually shipped.

You're not being obstructive. You're protecting the ten hours of focused work per week where you build the things that matter.

Crisis Two: The Definition-Mismatch Panic

Slack from a Director, 5:55pm on a Thursday: "This report is wrong. Active users dropped 30% week-over-week and that's not what marketing is seeing."

Ninety percent of the time, the report is right and the Director is comparing two different definitions. Marketing counts "active" as anyone who hit the site. The product dashboard counts "active" as anyone who completed a meaningful action. Both are correct. They will never agree.

The triage script:

Acknowledge the urgency, don't catch the panic. "Looking now, back in ten with what I find."
Pull the definition first, the number second. What field is the Director's source using? What field is the dashboard using? If they're different, you've already solved it.
Offer a side-by-side. Don't just say "they're using different metrics." Show the two numbers next to each other with the definitions underneath. "Marketing's source: page-view active, 142K. Dashboard: action-active, 98K. The 30% drop is real if you mean action-active; it's a 4% drop if you mean page-view active."
Document the mismatch. Add a note in your data dictionary or definitions doc. Link it in your reply. Next time this happens, you reply with the link.

The Director isn't wrong. They're working from a different definition. Your job is to surface the definition gap fast enough that nobody has to redo a deck.

Stack Reality Check

The tools you'll actually touch:

SQL. Snowflake, BigQuery, or Postgres. Pick what's at your company. Learn one well, the others translate. Window functions, CTEs, and QUALIFY (Snowflake/BQ) cover 90% of the work.
One BI tool. Looker, Tableau, Hex, or Mode. Each has a different philosophy: Looker leans semantic-layer, Tableau is drag-and-drop visual, Hex and Mode lean notebook-style with SQL+Python. You'll specialize in whichever your company picked. Don't try to be a Looker expert and a Tableau expert; the LookML and Tableau calc syntax don't transfer cleanly.
dbt for modeling. Reads YAML and writes SQL. If your company has a data engineering team, you'll review their PRs more than write your own models, but you need to read dbt fluently to understand what's upstream of every dashboard.
Notion or Confluence. For documentation, decision records, and the four-line caveat notes. The tool doesn't matter; the discipline of writing things down does.
Jira (or Linear, or Shortcut). For the request queue. Whichever your company uses for engineering tickets, route data work through it too. If data lives in a separate system, it gets ignored.

If a job description lists all five as required and expects expert-level proficiency in each, that's a red flag. Nobody is an expert in all five. The honest version is: deep in one BI tool, fluent in SQL, comfortable reading dbt, organized in Notion, responsive in Jira. That's it.

What the JD Doesn't Tell You

Roughly fifty percent of your week is communication and translation, not analysis. Requirements calls, Slack threads, definition arguments, async PR reviews, end-of-day caveat notes. The SQL is the iceberg tip.

Your most-used skill is asking "what decision are you trying to make?" Your second most-used is saying no without sounding obstructive. Your third is documenting decisions so the next analyst doesn't relitigate them.

The IC analysts who burn out are the ones who think the SQL is the job. The ones who get promoted are the ones who realize the SQL is twenty percent of the value, and the other eighty is everything around it: the triage, the translation, the caveats, the definition documentation, the Friday digest.

If that sounds like the job you want, you'll do well. If it sounds like a bait-and-switch, that's fair too — and better to know now than three years in.

Data Analyst Playbooks