What does a Data Analyst Do Day-to-Day?

If you’re interested in a career as a Data Analyst, you’ve probably seen all the advice to learn tools like Excel, SQL, and Tableau, to do projects to practice and demonstrate your skills, etc. But what does a Data Analyst actually do on the job? What types of tasks and projects do they work on — and where do they come from, how do they use their skills, what kind of meetings do they attend, do they give presentations, etc?

While no two jobs are going to be exactly alike, here are some generalities about what it’s like day-to-day working as a Data Analyst.

What department are you in? Who is your boss?

Some companies have a centralized data analytics team, with a Manager, Director, or VP of Data Analytics (or some variation) leading the team. Your teammates are also Data Analysts. You might support different departments or “verticals” within your company.

Other companies have “decentralized” Data Analysts, where you are part of a functional team, such as Marketing, Sales, Customer Support, Finance, HR, etc. You might be part of a small sub-team of data professionals, or you might be a lone Data Analyst reporting to a Manager, Director, or VP of a non-data function.

Where do your projects and tasks come from?

Every data role is going to have stakeholders — internal or external clients. They are going to have some kind of functional focus — marketing, sales, product, finance, etc. Usually, your projects come from their “OKRs” — objectives and key results, which are usually their goals for the year or quarter. Or they might have established “KPIs” — key performance indicators, and will need your help tracking the success of those metrics.

Or they might not use those terms and need your support on whatever major tasks or initiatives they are working on. For example, if you are supporting the marketing team, your tasks might include measuring the success of a marketing campaign or comparing engagement or conversion from various marketing channels, like websites, social media, email, search, paid ads, etc.

How do you use technical tools on the job?

So you’ve learned (or plan to learn) some combination of Excel, SQL, Tableau or Power BI, Python or R … how do you use them? Which tool is right for the job?

There are two things to consider when picking the right tool for the job — what will accomplish what you need, and what are your stakeholders comfortable using?

If they want to be able to look up data/reports themselves with real-time data, then a dashboard is probably the best deliverable, so use Tableau or Power BI. Depending on how your data is connected, you might need to use a SQL query to get the right data for your dashboard.

If they just need the analysis this one time, and it’s a simple question, then Excel is fine. Depending on how your data is stored, you might need to use SQL to query your data, export as a CSV, and then open in Excel to create some pivot tables or visuals to answer their question.

If it’s a more complicated project, then some combination of tools might be necessary. I often query my data via SQL in a Python notebook, then do my data cleaning and exploration via Python, and then summarize, often in PowerPoint.

If you’re not sure what tools to use, ask your boss for guidance.

What kind of projects will you work on?

This is another thing that will vary depending on your industry and company, the teams you support, the size of your team, and the overall structure of the data team or teams. For example, if your company has all of the following: Data Engineers, Business Intelligence Analysts or Engineers, Data Analysts, Data (or Machine Learning) Scientists, then your work might be very focused on a specific set of tasks. If your company doesn’t have all of those things, then you might take on some of the tasks that would normally fall to the teams your lack.

In general, common tasks for Data Analysts include some combination of the following:

Building a dashboard to track KPIs (key performance indicators) or metrics for a team/department or a specific campaign or project. Depending on the size of the company or the structure of data teams, sometimes this is handled by a Business Intelligence or Data Engineering team.

Do an ad hoc analysis to answer a specific question for a stakeholder. “Ad hoc” just means “when necessary”, so this is just a one-time analysis to answer a specific business question. If ongoing data is needed, then create a dashboard instead. But for a one-time analysis, you can usually query SQL or get the data into Excel (or another tool) some other way, and then do an analysis that will answer the question(s) from your stakeholders.

How you answer the question will vary. Sometimes descriptive statistics is enough (mean, median, quartiles, count, distribution). Often visuals will help tell the story. Sometimes (if it’s in your toolbox) doing predictive modeling or clustering is the right solution.

Identify KPIs or other success metrics. Often stakeholders will need help figuring out “what does success look like?” for their team, campaign, or project. Often they will work with Data Analysts to understand what’s possible and what is a good data point to track success.

Establish requirements for data collection. Data doesn’t just magically appear, it needs to be collected. Data engineers often aren’t close enough to the business to know what data is necessary, so they often turn to the Data Analysts to advise.

Experimentation. Not all data teams do experimentation, and sometimes this is handled by Data Scientists, but sometimes a Data Analyst will need to be part of experiments. Usually, this is through hypothesis testing, or as it’s referred to in the business world — A/B testing. The Data Analyst (or Scientist) will advise on the success metrics and test design and then analyze the results to determine the outcome.

How often are you in meetings and what type of meetings?

Meeting frequency is really going to vary by company, team/department, job level, and how many stakeholders you support. The more junior you are, the fewer meetings you have to attend. But some teams and companies have a much more meeting-heavy culture, whereas other teams and companies are more comfortable communicating asynchronously via shared documents (like Confluence), chat platforms (like Slack), ticketing systems like JIRA or Service Now), and of course email.

If you’re in an entry-level role, I would expect to spend roughly 5–10 hours per week in meetings, although some folks will experience more or less.

The type of meetings can also vary. The most common types:

• Status updates. These are usually by team, often held regularly like weekly or bi-weekly or monthly. You either share an update by employee or by project.
• Project-focused. These are for the purpose of talking about a specific project. Either it’s another status update meeting or it’s more of a working meeting. Expect that you might have to give a presentation at some point depending on how you are contributing.
• Team Focused. These are usually to share updates with the team. It could be a mix of company updates, project updates, presentations, team training, brainstorming, or something else. Every team seems to do them a little bit differently.
• Town Hall or All Hands. These are usually meetings where leadership shares updates about the company and very high-level goals and projects.

This is not a comprehensive list of all types of meetings, there are certainly more that you’ll experience.

How often do you have to present your work?

This is another thing that will really vary by company, team, job level, etc. There are also varying degrees of “presentations.” At a minimum, expect that you will have to present pretty much all of your projects or bigger tasks in some way to your boss or stakeholders. This just might be a quick 5 minutes in a weekly status meeting to give an overview of a dashboard you build.

The more senior you are and/or the more you do or lead end-to-end projects and not just tasks, the more you will have to present your work. Once you get to the level of leading end-to-end projects (which is more common for Senior Data Analysts), expect to present the project multiple times to your boss, stakeholders, and leadership. Often you might have to present at the beginning or mid-point as well as when the project is finished, and these presentations can last anywhere from 5–60 minutes depending on the audience and the scope of the project.

What do you think? Anything else you’d add? Any other questions about a career in analytics?

Want more career advice? Follow me on TikTok, Instagram, or LinkedIn, and sign up for my free data career newsletter.