Data Analyst vs Data Scientist: tasks, responsibility and choosing a path

Data analyst or data scientist? I would start by asking what work you want to do once you stop browsing course titles. Both roles can involve writing code, checking data, talking to business colleagues and presenting findings. The distinction becomes more useful when we identify a specific problem, the expected output and a way to check whether the solution actually helps.

I would not arrange the two titles on a single ladder that every analyst must climb into data science. You can develop expertise in analysis, metric design, experiments, data modelling or a particular business domain. You can also move towards statistical models and machine learning. Your choice should reflect an interest in the tasks and the requirements of the positions you are considering.

I will use a fictional delivery company to make the comparison concrete. First, we will establish what can be said about late deliveries. Then we will examine what changes when we try to predict them before delivery is complete. The numbers are synthetic and illustrate a way of thinking. They do not describe a real fitted model or a client project.

Titles provide orientation; investigate the actual scope

Within the UK government role framework, a data analyst prepares, analyses and communicates data. The data scientist description includes statistics, programming, communication and techniques such as machine learning. This is one public-sector framework for organising capabilities. Employers can distribute similar work differently.

Do not assume that an analyst always stops at spreadsheets or that a data scientist spends every day training models. Analysts can write substantial programs and run experiments. Data scientists can spend considerable time agreeing definitions and preparing data. The table below describes two responsibilities in our example, rather than fixed boundaries that apply across the entire employment market.

The shared starting point: define a late delivery

The company wants to improve delivery performance. Before building a report or model, we need to agree which deadline the arrival time will be compared with. Does it come from the customer promise, an internal plan or a later revision? Should a change after dispatch replace the original deadline? Each answer can change the label “late”, so I would record the rule before calculating anything.

We also need a unit of observation. One order can contain several parcels, and a parcel can have many tracking events. Accidentally counting events instead of deliveries gives more weight to parcels that are scanned more often. I would begin with a parcel identifier and check whether each completed delivery appears exactly once in the table being analysed.

A missing arrival time does not automatically indicate an on-time delivery. The parcel may still be travelling, or the final event may not have reached the system. Establish the observation date and a policy for incomplete cases. Those decisions affect both the report and the labels used later to evaluate predictions. Careful data cleaning supports both tasks.

What the analyst would prepare in this example

The analyst might begin with the number of completed deliveries, the number that were late and the late-delivery rate. Next, they could compare periods, regions or service types. They would check whether a difference reflects changing performance within groups or a change in the groups’ proportions. An increasing overall rate does not necessarily mean that every part of the process has deteriorated.

Suppose our small sample contains 100 completed deliveries, including 10 late ones. The late-delivery rate is 10%. That describes this sample. Without knowing how it was selected, I would not assign the same rate to the whole company. I would also ask which parcels were excluded and which period the report covers. The number alone does not explain why the delays happened.

The output might be a short report showing the scale of the issue, areas requiring investigation and questions for the operations team. If one region stands out, the analyst should also consider differences in service types or event recording. A relationship in a table can guide the next investigation. It does not automatically establish that the region itself caused the problem.

What changes when the question concerns a future delivery

The company now wants to flag at-risk parcels at dispatch. We must define the prediction moment, the information available then and the action following a flag. Should an employee inspect the route or contact the carrier? Can they handle every flagged case? Without those answers, it is possible to produce risk scores that nobody can use in the everyday process.

A data scientist can investigate whether historical data supports a useful rule or model. They need a simple baseline and a fair comparison method before adding complexity. A more complicated approach needs to improve an important outcome and remain maintainable. Running a library’s ready-made algorithm represents a small part of the responsibility for such a solution.

The output should include more than a saved model file. It needs data preparation rules, an evaluation description, known limitations and an agreed use of predictions. If a source or process changes later, someone must know how to detect the problem and assess its effect. The team should agree how that responsibility is divided between the people involved.

Future information can invalidate an evaluation

The actual arrival time is very useful for identifying a delay after delivery. It is unavailable at dispatch. Using it as an input to a model that predicts at that earlier moment means evaluating with information the solution will not receive in normal operation. A similar problem can hide in a status field that is overwritten only when the process finishes.

The scikit-learn discussion of data leakage explains this risk and why preprocessing must be learned from training data. In practice, I would check when each input value becomes known. A value present in a historical row today may not have existed at the moment you are trying to reconstruct.

For predictions about future deliveries, I would plan an evaluation period later than the training period. TimeSeriesSplit documentation explains the problem of training on the future and evaluating on the past; comparable durations across its folds require equally spaced samples. Irregular deliveries may need explicit date boundaries instead. Related parcels and the delay before outcomes become known also need consideration.

Evaluating predictions: 86% correct may be insufficient

Consider a synthetic set of 100 deliveries. We have the actual outcomes and earlier flags invented for this exercise. This is an evaluation table, with no model training behind it. The system flagged 20 parcels as at risk. Eight of those really arrived late. Two additional late parcels were not flagged.

There were 86 correct classifications: eight detected delays and 78 on-time deliveries correctly left unflagged. Accuracy is therefore 86%. Precision asks what proportion of flags were correct: eight divided by 20 gives 40%. Recall asks what proportion of all delays were found: eight divided by 10 gives 80%. The definitions are documented in scikit-learn’s evaluation guide.

A rule predicting that every parcel will arrive on time would achieve 90% accuracy here, because 90 deliveries were on time. It would find no delays, giving recall of 0%. That shows why a single metric cannot decide which approach is useful. Our flags detect eight problems while also sending 12 on-time parcels for inspection. The consequences of both error types need assessment.

The illustration represents separating outcomes into groups. Use the table for calculations; the number of drawn parcels does not represent its values. When discussing the result with a recipient, I would keep the same practical categories: correct flags, false alarms, missed delays and deliveries correctly left unflagged. They make the operational implications easier to discuss than an isolated percentage.

Connect the decision threshold to an action

If the solution returns a risk score, the team must decide which score triggers action. A lower threshold may flag more parcels while increasing the workload for people checking them. Our exercise selected 20 parcels. We do not have results for other thresholds, so this table cannot tell us what a different setting would produce.

I would ask whether the team can handle those 20 cases and what missing two late deliveries means for the process. These decisions need the person responsible for operations. Algorithm knowledge alone cannot determine which tradeoff the organisation can accept. Results should also be checked across relevant groups and later periods, because an overall average can conceal weaker performance in part of the intended use.

Predicting a delay does not establish that a proposed phone call or route change will prevent it. The intervention needs its own evaluation. If employees begin acting on flags, they also change the process producing later outcomes. Record the actions taken and interpret subsequent data carefully. This is a point where analysis and modelling need to work together.

Tools follow the task

Before comparing tools, follow an ordinary change after publication. The company introduces a new delivery service. The report needs a check that the category is included and that its deadline is comparable with the others. The prediction system also needs a check of whether the model encountered similar cases during training. The same new source row can therefore require two different assessments.

You cannot evaluate predictions for newly dispatched parcels immediately, because their outcomes are still unknown. Earlier checks can examine data completeness, the number of flags and unfamiliar categories. Accuracy can be evaluated later, once deliveries finish and reliable labels become available. Understanding that delay helps prevent a team from treating the absence of an alert as proof that everything is working correctly.

SQL can support extracting and joining data in both roles. A spreadsheet can help inspect a small sample and verify calculations manually. Python or R can serve analysis, automation and modelling. A BI tool can make measures available to users. None of these tools independently determines your role or the difficulty of the problem you are solving.

Analytical work may emphasise data models, aggregations, metric definitions and readable reports. Modelling work places additional weight on statistics, validation, programming and understanding algorithm behaviour. The exact requirements still depend on the position. In a job description, I would look for examples of expected outputs, then check how the listed technologies contribute to producing them.

Shared foundations let you explore both directions

At the start, I would spend time understanding tables: row meaning, keys, missing values, duplicates and joins. Then I would work on aggregations, percentages and the distinction between describing a relationship and explaining a cause. These skills help with reporting and with preparing model inputs. Recording steps so that a result can be reproduced and checked is valuable in both areas.

To explore analysis, extend a project with a recipient’s question, a set of measures, useful breakdowns and a clear explanation of your recommendation. To explore data science, add probability, statistical inference and model evaluation on new data. Choose the next topic by identifying something you cannot yet explain in the project. There is little value in trying to master every library that appears in a search result simultaneously.

The guide to becoming a data analyst provides a broader starting plan. Use it as a way to organise learning around outcomes. Completing a tool tutorial does not establish whether you can apply the tool independently to a new question. Your own attempt and a discussion of its limitations provide much more useful evidence of progress.

Two exercises built around the same problem

The first exercise concerns analysis. Create a small synthetic delivery table containing an identifier, promised deadline, actual completion time and region. Add a missing date and a repeated identifier. Record your policy for those cases, calculate delivery performance and present the result on one page. The reader should understand which deliveries are included and which questions the report cannot resolve.

The second exercise concerns prediction evaluation. Start with this article’s table of 100 outcomes and reproduce accuracy, precision and recall. Then list what information would be available at dispatch and how you would divide historical data for later training and evaluation. Once that plan is clear, move to a simple rule and potentially a model on an appropriate dataset. The invented table does not demonstrate the quality of a future solution.

After both attempts, record what held your interest. Was it clarifying definitions, finding discrepancies, designing the presentation or investigating prediction errors? Notice where you needed help as well. One exercise cannot decide your entire career, but it gives you a concrete basis for choosing the next project. You can change direction as you gain experience without treating earlier learning as wasted effort.

Evaluate an offer through responsibility and support

In an interview, ask for an example of a recent task and what the new colleague is expected to deliver independently. For an analytical role, ask about metric owners, data sources and report checks. For a modelling role, ask about evaluation, deployment, monitoring and the division of responsibilities with engineers. Access to people who understand the process matters in both cases.

Do not assume that one title guarantees higher compensation, easier recruitment or less risk of changing responsibilities. Compare specific positions with similar responsibility levels and working arrangements. The guide to analyst disadvantages and working conditions offers questions for that conversation. A title starts the investigation; the details of an offer help you assess its fit.

I would take a similar approach to AI tools. They can help draft a query, code or an explanation, but the result still needs checking against the data and the objective. Their existence does not justify a promise of security for either career. Build your learning around asking useful questions, detecting mistakes and explaining decisions, including when some of the code has been generated automatically.