“Can you just make us a quick dashboard?” “We want something insightful.” “Add all the filters so people can self-serve.”

I would always get excited when I heard things like this. As a BA, access to data and dashboards is my bread and butter. Building something insightful felt like I was making a difference.

But over time, a pattern started to emerge that made me realise one simple truth:

Everyone wants data… until they actually see it.

Then they ignore it. Or misread it. Or never log in to the dashboard again.

It took me a while to realise the problem wasn’t the complexity of the data itself. It wasn’t even the dull default design templates.

Most dashboards fail because no one knows what to do with them.

Case Study: "insightful" dashboard that no one used

A while ago, I was asked to build a “sales visibility dashboard” for the Sales Ops team. It seemed straightforward. I had access to everything needed: CRM data, historical performance, quota trends and benchmark reports.

I was excited. I wanted to impress my new team. I was fresh out of academia. So I built a sleek, complex dashboard using pretty much every concept I had learned in my quantitative data analysis module at uni. My approach was very prim and proper. Very academic.

And lo and behold - I had the dashboard. It had everything. And I mean everything you could think of (and more).

Monthly and quarterly performance trend lines? Check. Heatmaps by region and offering category? Check. Leaderboard of account managers by closed-won ratio? Check. A toggle feature to compare YoY trends? Once again, check.

It looked complicated, logical, visually polished, sophisticated. As I later came to realise, it also had too much of everything. Thus soon learned: If your dashboard has everything, it may as well have nothing.

A few weeks after delivering my masterpiece, I checked the usage metrics. To my surprise the numbers were disappointing.

Three total visits. Two of them were me.

Needless to say, it didn’t feel great.

Not All Metrics Are Useful

That uncomfortable and genuinely humbling experience changed everything about how I approach data. It also nudged me toward business analysis as a career.

I realised that outside the safe walls of academia, complex, mathematically-sophisticated data manipulations don’t hold much intrinsic value. Sure, it might look impressive. It might even feel insightful. But insightful doesn’t always mean useful.

As pretty as a well designed dashboard may look it's not exactly a museum exhibit. Most people don’t come to a dashboard to admire it, they come with a purpose to extract something from it. Something they can understand quickly, something they can trust to be true and something they can act upon. And if that something doesn’t clearly lead to a decision or behaviour change, then what’s the point?

What I had built assumed a shared understanding of goals, data literacy and business context. That was naive and completely disconnected, It was the exact opposite of what I wanted this dashboard to achieve.

Looking back, I can see exactly what was missing: an action layer. I showed everyone what was happening. Not just the headlines, but everything. And most importantly, it offered no guidance on what to do about it.

The 3 Mistakes I Made

Looking back at my first attempt at a CRM dashboard, I can clearly spot three major issues with the first iteration:

1. Too much flexibility = decision fatigue

What I thought was user empowerment turned out to be user overwhelm. The sections, filters and toggles that I had proudly built to cover every scenario, created so much friction that people didn’t even know where to start. It looked like a dashboard, but felt like a maze.

2. Misaligned metrics and KPIs

This one still makes me cringe. The metrics I highlighted were based on what I thought was interesting and not what sales managers actually needed to run effective pipeline reviews or coaching sessions. In hindsight, it was a cardinal sin: assuming without validating.

3. No connection to real workflows

Most painfully, the dashboard existed in complete isolation, like a beautifully designed tropical island that no one could live on. There was no embedded workflow, no tie-ins to team chats, Slack threads or performance check-ins. No nudges, no triggers, no integration. She was a loner.

Eureka Moment: Thinking About Data Like a Product

That monumental flop was a turning point in how I approach data as well as how I approach my work in general. I stopped thinking rigidly and academically like a “data person” and started thinking more like a product manager.

No piece of work exists in isolation or for its own sake. Watching the senior PMs on my team (who were absolute superstars in their field) I started to notice patterns in not just what they did, but how they thought.

Whatever problem we faced, their minds immediately jumped to a series of clarifying questions to help scope the problem effectively. So I started doing the same, especially in relation to my dashboard conundrum.

I began asking myself:

• Who is the actual user of this dashboard?
• What decisions are they trying to make?
• When will they be opening it during their workflow?
• What might prevent them from doing that?

Below are some of the practical insights that came out of this shift in thinking.

Jobs To Be Done (JTBD): What’s the Dashboard Hired To Do?

Instead of thinking about a dashboard as just a visualisation of data, I started thinking of it as a product.

( In fact, I would argues that every deliverable in a business should be looked at this way. )

The guiding question in dashboard design can not be “What KPIs was I asked to show?” This barely scratches the surface. Here are some better questions worth asking before you build anything:

• What decisions are stakeholders trying to make more confidently or quickly?
• Which ambiguous processes could use a little more clarity and where data might help?
• Are there team habits or behaviours we want to change, reinforce or challenge through what is shown?

I would urge everyone working with data to treat it less like a static snapshot and more like a narrative. Something with intent that is embedded in the rest of the business.

This is where Jobs To Be Done (JTBD) comes in. It’s a framework that shifts the focus away from features and towards real use cases. The same thinking applies beautifully to dashboards.

Try writing a simple job statement for each dashboard you build. For example:

“When a sales manager reviews weekly performance, they want to identify underperforming reps early so they can intervene before the end of the quarter.”

That job becomes your dashboard design spec. It tells you what to include, what to leave out and what truly matters for those that use it.

Action-Oriented Metrics: Designing Data That Drives Decisions

The second principle I rely on is something I call Action-Oriented Metric Design(AOMD) The name says it all: every metric should nudge the user toward action, not just sitting there and look pretty.
To make sure that metrics are genuinely useful, I run them through the following three simple filters:

• Clarity: Is the metric instantly understandable at a first glance, without much prior context?
• Actionability: Does it suggest a clear next step or highlight where intervention is needed?
• Relevance: Is it connected to a decision, behaviour or workflow the user already cares about?

This way of thinking draws on how product teams approach North Star metrics and input/output metrics. A vanity metric like “total page views” may look good but it rarely leads to action. Instead, focus on trigger metrics i.e. the ones that highlight friction/opportunity and prompt a response.

For example:

“Accounts with no sales activity in the last 14 days”

“Reps with 3+ deals stuck in pipeline for over 30 days”

These kinds of metrics do more than inform, they direct. They serve as internal signals that something needs attention now. Designing with this mindset helps turn dashboards from passive reports into tools that actually shape how teams work.

Usage-Led Design: Let Behaviour Drive The Build

No matter how well-designed your dashboard is, it’s worthless if your team never opens it. To make sure it gets used, you need to design your dashboard with the same care and appeal as any great product.

What does this look like in practice? It starts with understanding your team’s workflow and reducing friction wherever possible. Here are three key principles to follow:

• Frictionless access

Integrate the dashboard seamlessly into tools your team already uses, like Slack alerts or embedding it in Notion. This way users don’t have to break their work flow to find the data they need.

• Progressive disclosure

Show the most important metrics front and centre. Keep detailed or complex data hidden behind expandable sections. This avoids overwhelming users and lets them dive deeper only when necessary.

• Behavioural nudges

Use clear visual cues and language to prompt action. A traffic light system (green, amber, red) paired with simple, direct prompts e.g. :

“🔴 5 reps haven’t updated deals in 7+ days. Reach out?”

These cues make it obvious when attention is needed and guide users toward the next step.

The points above are just a few examples of approach is inspired by Information Foraging Theory, which compares users to hunters looking for information. If the path to value is too long or unclear, users will simply abandon the search. It is also supported by frameworks from usability and behavioural science, including Jakob Nielsen’s 10 Usability Heuristics and The Fogg Behaviour Model. These frameworks highlight that action happens only when prompt, ability and motivation come together. I strongly suggest getting to know these frameworks if you want to level up in data or product work.

Dashboards as Dynamic Decision Tools

Stop treating BI reports as one-and-done deliverables. Think of your dashboards like interactive systems that evolve based on how users engage with them. Just like web or mobile apps, you can track how people use your reports (e.g. what they focus on, what they ignore) and use that feedback to make your dashboards smarter and more useful.

I view dashboards as feedback loops, not static outputs. A useful way to frame this is with the OODA loop - originally developed for military strategy (something I learned during my International Relations MA ) but incredibly useful in fast-moving product and business environments.

OODA stands for:

• Observe: Gather data and monitor what’s happening
• Orient: Make sense of the data in the context of your goals and environment
• Decide: Choose the best course of action based on your understanding
• Act: Take that action quickly and confidently

For Business Intelligence and Dashboards, I add two more crucial steps to complete the loop:

• Feedback: Track how users interact with your dashboards and the impact of your actions
• Iterate: Use that feedback to improve your dashboards and decision process continuously

So your loop looks as following:

How this works in practice:

When building dashboards, start by observing key metrics that matter. Then orient yourself by understanding what those metrics mean for your business goals. Decide on the best actions for your team and act accordingly. After deployment, collect feedback on how the dashboard is used and its outcomes. Finally, iterate to refine and optimise your dashboard. This cycle helps you spot problems early ( like falling user engagement or lagging feature adoption ) and adjust your approach fast.

Round 2 – A CRM Dashboard That Actually Worked

A month later, after staring at the dashboard I had built and realising no one else seemed to see its potential, I scrapped the whole thing and started again from scratch, this time with product and UX design principles front and centre.

The planning phase took way longer than the first time. I treated this like I was the founder of a startup designing a solution for an external client rather than building something internal to tick a box. I wrote a mission statement and defined the exact problem I was solving.

And that problem was simple:

Sales managers didn’t know which reps weren’t using the CRM consistently. As a result, leads were falling through the cracks and deals were being missed.

So I built a minimalist dashboard focused on exactly that problem and only that problem. The entire product centred on a few key metrics:

🔴 Reps with <3 logins per week

🔴 Leads untouched in 7+ days

🟠 Deals stuck in pipeline >14 days

✅ Closed-won deals with completed CRM notes

Each one was specific, time-bound and directly linked to a coaching action.

The dashboard wasn’t as "cool looking" as the original version but it landed much better. Usage went up 5x within weeks. Sales managers actually started using it in weekly pipeline reviews. They stopped chasing updates via email and Teams and thus the dashboard saved hours of chasing. Eventually, other teams (Telecoms, Logistics) saw it and wanted their own versions.

Conclusion: Why This Matters for Product & Analytics

As a PM (or even someone thinking like one) your edge isn’t that you can work with data. It’s that you can translate data into decisions. Every dashboard should be a tiny decision-supporting tool rather that a museum of KPIs. The best dashboards live in the workflow of your teams rather than collect dust and stay untouched in some folder. They are tied to recurring and current rituals (pipeline reviews, team check-ins). They are designed around real jobs-to-be-done and are focused on the next steps. For those in charge of creating BI Reports it is vital you:

• Designing with the user’s workflows in mind
• Choosing metrics that influence behaviour
• Treating dashboards like products with UX, adoption curves and retention

As I said earlier, everybody wants data - until they actually see it.

So the job isn’t to surface everything. It’s to surface exactly what matters at the right moment, for the right user, in the right context.

That’s the shift: from static dashboard to living product. When you build with focus, simplicity and empathy, your dashboard becomes more than a report. It becomes a tool that actually drives outcomes. And that is what good product thinking and good analytics is really about.

When people talk about what makes a great Product Manager, the usual suspects show up: product sense, customer obsession, prioritisation frameworks and so on. All important, no doubt.

But having worked as a Business Analyst for a few years now (often side by side with product managers) I’ve realised there is something else that makes or breaks product success: alignment. Quiet, behind-the-scenes and often overlooked alignment. And it’s something BAs do really well.

Product Managers and Business Analysts tend to be in the same rooms, working side-by-side and talking to the same people but when it comes to stakeholder work, the line between them gets blurry very fast.

Here are a few key lessons in stakeholder alignment that I believe Product Managers can benefit from.

Make the implicit, explicit

When disagreement arises within a team, its usually rooted in misunderstanding. Most of the time, your teams are not arguing  -  they’re operating on totally different assumptions alltogether.

What does “done” mean? What does "success" look like? What are we not doing in MVP? Why is that feature suddenly considered a priority when no one asked for it? I can't tell you how many times I’ve sat in meetings where people were nodding along, only to discover weeks later that we were all thinking completely different things.

As a BA, you learn to get very good at surfacing that which is unspoken. Beyond the surface level meaning of whatever the Jira ticket say to what it actually means. This skill in particular - asking (sometimes seemingly obvious) clarifying questions, reflecting back what you’ve heard and checking for gaps - is vital for Product Managers.

Yes, it risks making you feel like the least informed person in the room. But it saves time, prevents tech debt and spares your team endless rework. Sometimes, the death of your ego is a small price to pay for avoiding the sunk cost of a misunderstanding.

"Sometimes, the death of your ego is a small price to pay for avoiding the sunk cost of a misunderstanding."

Alignment isn’t a one-off thing

There is this notion that once you have set the correct expectations, asked all the right questions and got the sign-offs, alignment is done. But this couldn't be further from the truth.

Alignment isn’t a one-and-done checkbox - it’s a rhythm. It shifts constantly as people’s priorities change, as new stakeholders appear, or when half the team quietly forgets why they’re building what they’re building in the first place. Without ongoing effort to keep teams aligned, momentum can be lost fast.

I have learned to think of alignment not as a milestone, but as a continuous process - one built around feedback loops, regular check-ins and small adjustments as new information comes in. Like birds flying in formation, each person moves individually and also in sync with the rest of the group. Daily and weekly clarity on both short-term goals and the bigger picture is what keeps everyone flying in the same direction.

It sounds obvious, but this kind of steady re-alignment is what keeps teams from drifting completely off course.

“Alignment isn’t a checkbox. It’s a rhythm.”

What you do not build matters as much as what you do

In almost every project there will be more ideas, opinions and potential rabbit holes than your team is capable of chasing. How you chose to handle the ideas that do not make the cut is just as impactful as  how you engage with those that do

As a BA I have often found myself politely shelving side-quests disguised as urgent requests and as I am pivoting into product I see this skill as essential. Beyond simple time management and practicing backlog hygiene, the ability to say "not right now"  helps project teams focus, manage expectations and maintain the clarity needed to deliver what actually moves the needle

Speak both languages

One of the most underrated parts of my role has been acting as translator:  between business goals and technical constraints, between high-level strategy and the backlog items that drive each sprint. Although I'm not a language translator in the traditional sense, but it often feels like the same job. The language of the business and the language of the tech team can differ - sometimes drastically - and bridging that gap is what keeps things moving.

It’s not always easy. But being able to jump on a call with developers, then turn around and explain the trade-offs in plain English to stakeholders, who aren't concerned with the latest tech stack but just want it done, is a superpower.

Product managers need this too. In fact, some of the best PMs I’ve worked with are the ones who know how to listen carefully, translate clearly and keep conversations flowing both ways up and down the workstream.

Final thoughts

Stakeholder management doesn’t get as much attention as roadmaps or OKRs yet without it, none of those things land. The truth is, business analysts spend a lot of time doing exactly what product managers need to do: making sense of competing inputs, finding clarity in chaos and helping people row in the same direction. Ultimately, alignment is way more than an outcome of good product work, it is one of its' fundamental pillars that makes it possible in the first place.

In this project, I attempted to make sense of Credit Card customer data I came across on Kaggle. The dataset contained information about approximately 9000 active credit card users over a 6 months period.

Objective:

In order to better understand the data at hand, I decided to implement a  K-Means Clustering algorithm from the Scikit-Learn package in Python. The objective behind using this algorithm was to create clusters of customers based on the balance to credit limit ratio in their accounts. The clusters would serve to better inform the bank's management of customer touchpoints such as a potential email marketing campaign.

Below is the plot of the data we will be working with prior to the creation of customer clusters:

Note:

It is important to highlight that the dataset we are working with is not perfect for the application of the K-Means Clustering Algorithm.

Oftentimes data we work with can be quite noisy( i.e. containing duplicates, outliers, or simply being incomplete). This can be a big problem for a project like this for improper data can affect the results we get from ML operations, leading to erroneous answers and, consequently, erroneous suggestions.

There are certain things we need to be on the lookout for when performing K-Means Clustering:

• The values we are working with must be numerical
• Secondly, our data must not contain any outliers or missing/duplicate values that create noise (the K-Means algorithm is notoriously sensitive to them)
• Lastly, our data must be on the same scale having the same mean and variance

Thus I begin by ensuring that our dataset meets the parameters listed above.

What is a K-Means Clustering Algorithm?

Before applying the K-Means Clustering algorithm to our dataset let us first understand how it works and what it is supposed to achieve.

In simple terms, K-Means is a method that aims to partition our observations into a set amount of clusters in which each of our observations belongs to the cluster with the nearest cluster center (i.e. cluster centroid). Upon the first iteration, these clusters will be set at random. On the second iteration, we adjust the location of centroids by finding the mean of every cluster. This process is repeated until the variance is minimised and the centroids are no longer moving. The algorithm then chooses the centroids with the lowest total variance.

The visual representation of this process is shown below:

The Problem - Finding optimal K value

The problem we are faced with when creating customer clusters on a messy dataset is that we have no clue about how many clusters we need to create?

Theoretically speaking, if we would have an equal number of clusters to the number of observations, the distance between data points to the cluster centroids would be minimal. Nonetheless, in this case, we would not have any meaningful clusters and our problem would be unresolved. For that reason, we can utilize the Elbow Method to find the optimal number of clusters (i.e. K).

From the Elbow Method graph above we can see that with each run the total variance is minimised until it hits a plateau. Our optimal K value lies at the point where total variance is minimal but does not reach zero (which is the elbow of the curve). In this example, the elbow of the curve is approximately between 7 and 7.5.

For my K-Means Clustering algorithm, I choose a K value of 7.

Application of the Algorithm

Having used Python's Scikit-Learn Package I managed to create 7 Clusters of Customers based on the state of their account's Credit Limit and Credit Balance.

Here are my results:

Application

We can use our customer segmentation above to inform an email marketing campaign. Below are the suggestions for the type of outreach each cluster of customers should receive:

• For clusters 1 and 5 Run a check if they are qualified for a higher credit limit. Bring to their attention that a higher credit limit can lower credit utilization, potentially boosting credit score and providing an additional emergency fund safety net. Customers in Cluster 1 that lean towards the higher balance may be cautioned that if an increased credit limit encourages spending outside of their budget, the benefits of having a higher limit could be outweighed by unmanaged debt.
• For cluster 2 send help to newer customers to encourage the usage of their credit cards(assuming that they are new give the lowest balance and credit scores from the overall group). Perhaps suggest an appointment where they can receive advice on how to use their credit cards more effectively.
• For Clusters 3 and 6 the credit limit to credit balance ratio is high. These customers would have a high credit score and thus you could suggest some additional rewards to nurture the relationship with these customers. Customers in cluster 3 in particular can qualify for higher rewards.
• Customers in cluster 7 are well within their credit limit and their balance does not exceed it. These customers have the potential to move into clusters 3 and 6 which is the desired area for the business.
• The customers in the remaining cluster 4 have relatively high balances compared to their credit limits with some of them even exceeding their limit. These customers should be encouraged to work on ways of improving their credit scores and paying off their balance.

Follow the link below to view my code in greater detail.

In this project, I attempted to implement a Random Forest Algorithm on The Iris Flower Dataset using a Scikit-learn package in Python. The Iris Flower dataset comes with the Scikit-Learn package itself, meaning that it is clean enough to be used for training an ML model. This is useful for the scope of this project as it will allow me to explore the Scikit-learn package and focus on the nature of the Random Forest Algorithm without spending time on obtaining, cleaning, and transforming data.

Objective

The objective of this project is to build a model that allows us to predict the type of an Iris flower based on its Petal and Sepal features such as length and width. By creating such a model we would be able to input whatever parameters we choose and determine the class to which our hypothetical Iris flower could belong.

The Data at Hand

Upon the first look we can see:

1. the "data" array which composites of a 150 flowers
2. the "target" array that represents various class labels such as 0,1,2
3. the "target_names" array which corresponds to the class labels above such as 'setosa', 'versicolor', 'virginica'

Additionally, the dataset contains a list of "feature_names" which represents the 4 characteristics of Iris Flower such as: "sepal Length"(cm),"sepal width"(cm); "petal length"(cm) and "petal width"(cm).

Iris Dataset gives us 1 class output variable (i.e."target"/"target_names") and 4 input features (i.e."feature_names"). This will inform the parameters used for out Classification Model.

Splitting and Training Data

I have chosen to split the dataset into a training set and a test set. This is done for the purpose of an unbiased evaluation of prediction performance. The Training set is applied to fit a model whilst a test set is used for an independent assessment of the final model. To do so I will use the model selection package of Scikit-learn, in particular on the function train_test_split():

The Test_Size value of 0.3 indicates to us the size of the test set. We can think of a 0.3 test size as 30%, with the remainder in this case (70%) indicating the training size.

Random Forest Algorithm

How exactly does a Random Forest Algorithm work? Random Forest algorithm is made up of many Decision Trees which operate together, thereby producing a strong "collective" guess. When used for Classification Models, all Decision Trees in the algorithm produce a class prediction with the most commonly chosen class becoming the prediction of the overall model.

Fundamentally, a Random Forest algorithm prediction is effective due to the low correlation between each class prediction produced by individual Decision Trees. In other words, each Decision Tree in a Random Forest algorithm makes up for the errors from other Trees. Although some class predictions of Decision Trees will be incorrect, a substantial number of predictions will be correct, moving the collective group of Trees in the right overall direction.

This process looks something like this:

Creating the Model

Having covered this, we can proceed with creating a Random Forest Classifier

The n_estimators above is the number of Decision Trees used for our model. The larger this number the slower (but also more accurate) is the model, in this case, we are using 100 Decision Trees for our Random Forest.

The Classification Model (clf) is trained using the X and y training sets created above:

Let us create a predicted value of y (i.e. y_pred) based on the input of X testing set (i.e.X-test) using a Random Forest Predict function:

As indicated above, our Random Forest generates the predicted value of y( i.e. classification of the Iris Flower) by using the predict function on the X input( i.e. the features of the Iris Flower).

Prediction

Using the code from above we can input a random array of X values of our choice and predict the classification of the Iris Flower at hand. We should bear in mind that the model is using the numerical representation of the Iris Flower Class. Thus the first prediction we obtain is the number of the class. Having found the predicted numeric value of the class to which our hypothetical Iris flower belongs, we can match it to the appropriate Class name:

And the Output is:

Evaluating Accuracy

To assess and calculate the accuracy of our model we will have to import metrics package from Scikit-learn. Then we must use a metrics accuracy_score function of y testing set( i.e. y_test) against the predicted y value of our model( i.e. y_pred):

What the metrics accuracy_score function shows the percentage of correct predictions. This also could be simply found by a few lines of code I wrote below:

The metrics accuracy function as well as my own calculations conclude that the accuracy of the Iris classification model is over 90%. We should note that the accuracy of the model will vary every time you run the code because of the nature of the Random Forest algorithm. For that reason, it is important to double-check the metrics.accuracy_score function from Scikit-Learn with your own calculations as I have done above.

Significant Parameters

Having evaluated the accuracy of the model we may be interested in considering which input parameters of the model play the most significant role in determining our predictions. Below is the chart that demonstrates my findings:

Conclusion:

In this project, we have managed to build a classification model for the Iris Flower Dataset using the Random Forrest Algorithm by focusing on the Petal and Sepal features of the Iris Flower.

The input parameters of the petal play a significant role in determining the classification prediction whilst the parameter of sepal width seems to be of little importance. According to the accuracy function and my own calculations, the model produces an accurate prediction over 90% of the time.

Follow the link below to view my code in greater detail.

In this project, I explored a  Marketing Dataset that contains information about sales for two consecutive years. Each row contains weekly data about the Volume of Sales and different types of campaign/promotion methods used for the marketing of that product.

I decided to use this data to establish the relationships between Sales Volume and marketing campaigns that were pursued in the course of 2 years. To do so, I will be using Multivariate Regression.

Data at Hand

We can see that the dataset is not very large but it is a good amount to demonstrate multivariate regression nicely. Below are the histograms of the rows we are working with:

From these, we can see all of the distributions. In particular, we can see that Discount and Radio have a high frequency at 0. Although this may seem like an outlier, this could be justified by the fact that most items are not discounted and that Radio Promotion was not used frequently. We now need to clean the data and treat the missing values.

Cleaning Data

Here we found that NewVolSales, Base_Price, Radio, InStore, Discount, TV, Stout are the numeric columns so we can drop the columns containing categorical data.

Let's check if we have any n/a values

We see that the only column containing missing values is Radio. We can fill these out with the mean of other values present in the column

Let's look at our data again:

And.. we got rid of all the n/a values. There are no more missing values, and the outliers have been accounted for. This means we can now split this data and train our model.

Multivariate Regression

First, we can split this into our X (independent variables) and y (dependent variables). Then we can plot their relationship to the Sales Volume.

Here we see a negative relationship between the Base_Price and the Sales Volume as well as a positive relationship with the InStore column. Now that we have a good idea of the relationship each variable has with the Sales Volume. We can start by splitting the data.

We can check the accuracy of our model looking at R^2

The R^2 value is around 0.66 which is rather low however considering the type of data we are dealing with, it is satisfactory.

As previously mentioned, there is a strong negative relationship between the Sales Volume and the Base_Price. We can visualise this dimension of the model by plotting a line of best fit.

As we can see here the line of best fit misses the data by a significant amount. This is due to the poor choice of independent variables. In order to remedy this, we should be more rigorous with choosing our independent variables. For example, I suspect that the Discounts variable had a negative impact on the accuracy of this line as it had a lot of values at 0.

Prediction

Nevertheless, this model can still be used for prediction as it follows the correct trend. Below is an example of a prediction made by the model.

Here is the output

We see that for average values of the input parameters we get a prediction order of magnitude.

You can view my Jupyter Notebook using the link below.

This is my MA International Relations Dissertation Project where I investigate the threat of Cyber Warfare in 2021. The threat assessment was conducted through data analysis of publicly known state-sponsored cyber attacks from 2004. Additionally, qualitative secondary literature research was conducted by analysing a series of recent reports and newspaper articles. My analysis demonstrates that state-sponsored cyber operations pose a serious threat to today's global security. This dissertation concludes that the prospect of cyber warfare is a real threat political actors should be concerned with.

This was the second assessment for my Quantitative Data Analysis Module. The aim of this assessment was to provide structure for the initial stages of research for the MA Dissertation. At that stage, I wanted to look at Covid Data because I wanted to write a Dissertation on the relationship between political populism, the economic stability of a nation, and Anti-Vax movement. I ended up writing a Dissertation on Cyber Warfare between nation-states instead because at that point in time I did not have adequate access to extensive up-to-date data I was hoping to find.

This was my first assessment for the Quantitative Data Analysis module I have completed during my MA International Relations program at the University of Exeter. We were tasked with answering a set of questions using SPSS software on a NELS Dataset.

This is my first python project where I attempted to create a guessing game with a guess limit for users. This project has solidified my understanding of basic python concepts.

To view my code use the GitHub Link Below

In this project, I created a web scraping tool that allows the user to input a film title which then downloads the script of that film to their device as a text file.

To do so I used the BeautifulSoup Library in Python. To view my code use the GitHub link below.