top of page
  • Writer's pictureKelly Adams

A Day in the Life of a Data Analyst


high angle desk arrangement with laptop

I’ve been a full time data analyst for almost 6 months. Since starting, it has been a journey of learning, adapting, and contributing to my company. I wanted to go into what my day to day life is like. From the tools I use to how I structure my day and the types of requests I get. The work data analysts do varies, so I wanted to explain my day for those entering the field. Even if you’re more seasoned and in a different field, you can get a glimpse into a data analyst at a startup company.


Tools

Below is a quick summary of the tools I use daily (or at least almost every day) and how I use them.

  • Excel - I use it to export data from my queries and check it manually.

  • SQL - I write in PostgreSQL and BigQuery the most.

  • Looker Studio - I use this to create dashboards and reports.

  • Google Docs - I write notes on projects and meetings, or to share anything with my co-workers.

  • Github - I use this for version control (SQL queries) at my work.

My Day

While every day isn’t the same I do have a general structure to my day. As a note, I work remotely. I have a home office, if you want a photo of that see my LinkedIn post. But I start my day either working out at the gym or exercising my dog.


Breakdown

Then I spend a lot of my time, I’d say about 60% is working on major projects solo. Like various ad-hoc requests or maintaining or generating reports in Looker Studio. 30% of my time is either working on projects with my co-worker or meeting with stakeholders to get more information on their requests. The last 10% or so is doing important but less intensive tasks like documentation. These are general percentages and varies from each day.


Schedule

This varies from day-to-day, I don’t have a set agenda except for a weekly meeting or two. I can structure my day how I want to but I do need to be online for a few set hours during the day. That way my colleagues can get in touch with me. But here’s a typical day for me (this is in 24hr format):

  • 8:30 - 10:00 In the mornings I like to spend my time in deep work, or those solo projects I talked about.

  • 10:00 -11:30 Late mornings I schedule my meetings and working sessions with my other colleagues.

  • 12:00 - 13:00 I take lunch, it’s only a half hour lunch but the time I take it depends on how busy I am.

  • 13:00 - 15:00 I spend my time working on anything else I didn’t finish in the morning, mostly solo projects.

  • 15:00 - 17:00 Later when I don’t have much energy I like to work on less intensive tasks like documentation.

Again, not every day is like this. Some days I’m working with my co-workers for a few hours in the afternoon. Or other days I am spending by myself deep immersed in a data project. But this is how it is on typical days. I don’t include breaks but I do have the freedom to take breaks when I want to.

What I Do

Now what do I actually do? While I have listed the tools above and how I use them in my job. The purpose of my job isn’t only to write queries using SQL or create Looker dashboards, it’s to help solve business problems. I work closely with the product and marketing team to get insights on our users. Both to see how they use our product and to try to get more users to our product. There are 3 types of projects I do:

  1. Ad Hoc Requests

  2. Reports

  3. Other Projects

Ad Hoc Requests

If necessary I do ad hoc requests when we need to gain insights on something that happens once in a while. Say a marketing campaign, we need to see how well it does. Did more users sign up? Did revenue increase? I look at these things to see if this campaign was successful and what we can do in the future based on this data. For product if we add a new feature I look at how well it performed with our users. Did users drop off? Or did we get users to use our product longer?


Reports

Reports and dashboards are more for looking at how the business or aspects of the business is doing. Like looking at revenue, profit or users who signed up on our site. For this I maintain the dashboards we have now and I also create new dashboards based on the need of the company. Since I’m a newer analyst most of the dashboards I make are given to me. The goal of these is to look at other aspects of our business that aren’t shown in other reports. Sometimes an ad hoc request can transform into a report.


Other Projects

I also always have other projects to work on. One of these are what’s listed in my someday/maybe list. These are projects or tasks that my team and I have talked about but it’s more of a “nice to have”. If I have a lot of down time I’ll work on these projects. The other type of projects are bigger ones I take on myself. These are things I want to improve about our processes whether in analytics or our data pipeline. Since I work at a startup I have quite a bit of freedom to work on projects I care about.


Prioritizing Projects

My requests are usually filtered through my manager. She helps me decide the priority of these requests and any deadlines. From there I start working on the order. If I have several projects that are the same priority level I clarify with her what I should do first. Now if I have a lot of projects I do update stakeholders on the status of their request. For example, if I’m working on a request and a critical request from my boss comes in, I let the other person know I will get to their request later. This isn’t a hard or fast rule, but something I do to keep everyone up-to-date on their request. For my company it’s all about open communication. They let me know the priority and I let them know about the realistic timeline I can get it out by.


Having a clear priority of what to do lets me structure my day. Typically I only like to work on 2-3 requests/projects in one day. That way I have enough time to work on each and get into the data. But again there are days when things must get done and I have to do a lot more. In those cases it helps me to take notes on everything (what’s required of me and next steps) along with documenting my process. Just in case I miss something I can look back and understand what I was doing.


Conclusion

Over these past 6 months, I’ve realized that being a data analyst is more that the technical skills. It’s about developing business acumen, improving project management skills, and continuously learning and improving my skills. I can’t wait to see what the upcoming months will be like. In a few weeks I’ll be sharing the challenges and what I’ve learned as a new data analyst. So check back on my blog or subscribe to my newsletter.

bottom of page